Phase 1: Defining a New Software Development Program

This post will define the first step in a development lifecycle.

One of the principles of a solid process is that you push the composition of content out to the point where it can be completely composed, avoiding the desire to do too much too soon. In this simple first phase we will define only what could reasonably be known at the start:
* A scope as the definition of the product to frame the subsequent content.
* A description of why this scope is important and worthy of consideration. This description should include an estimate of the likely benefits of completing the program.
* An estimate of the maximum cost that those benefits would support. More on this idea follows.

We would like to define scope in a manner that allows the definition to be used consistently throughout the lifecycle. In other words, we would like to avoid rewriting the scope with each iteration. Scope can creep up or down through the process. Most readers will be familiar with scope increasing over time, but it is a problem when an ambitious scope is used to justify a particular spend and then the scope is reduced to hit some deadline without reducing the cost.

Since to start we do not know if we will buy or build, use waterfall or agile, we need to capture the definition that defines the scope for any approach. Agile methods use a simple one-sentence form to capture groups of user stories as themes or epics. I suggest this format to define a program. I will not go into detail on the form, as there are lots of articles available to help, but here is an example:

As an Executive I need the project definition to consistently scope a project from inception to completion.

In my experience, even very large projects can be completely scoped in less than twelve statements. In fact, I would suggest that if you have fewer than five themes or more than fifteen themes you are working at too high or too low a level. Note that this approach provides a usable definition even for waterfall projects.

This format leaves you with an unambiguous definition of the program that must pass a simple test: if the product owner can imagine any user story that would not fit cleanly under a theme, then you missed a theme.

Often the business justification will follow naturally from each theme. The themes provide a basis for asking what are the outcomes expected if the theme is implemented? For commercial entities most outcomes are financial: the company makes money or reduces costs. For the government, the outcomes may be financial or they may involve providing better service to the public. You might expect 3-5 outcomes to fall for each of the 5-15 themes. Each outcome should include a narrative describing the financial or service-oriented benefits.

The last deliverable is designed to put an upper limit on the amount that is warranted by the business justification. This is a limit, not an estimate. There is no reasonable way to estimate the costs until more work is completed in the subsequent phases. This is an important concept. Forcing staff to estimate costs from nothing more than a scope statement just sets the stage for silliness to follow. But it may be possible to set a limit. The limit may be a budget limit. If you have only $25M to spend then specify that here. If the justification is purely economic and the savings or revenue is equal to $70M over five years then use break-even as a limit. If neither of these techniques works then estimate the maximum amount you think that your overseers would approve and use that as a limit.

The point of this limit is to suggest that it is justified to spend up to the limit in order to achieve the outcomes associated with the scope. If the scope is cut then the amount is no longer justified. If the cost that emerges from an evaluation of the alternatives and the approach exceeds the limit then the project is not justified.

It is not the usual case that, in an environment with limited funds, silly projects are put forward for funding. Most organizations have internal software portfolio review procedures that catch silliness. In other words, oversight committees should not overdo the process here. If their is a reasonable portfolio review at the divisional or departmental level, and the review process is periodically reviewed, then delaying progress to the next step may not be justified. Let the internal process control at this stage knowing that there will be more oversight to follow where mistakes here can be detected.

One final, last point. Reviewers, whether internal to the team building the Phase 1 output or external, are obligated to help to fix issues. They do not get to just raise issues. If they object to the scope they must suggest a new scope and justify their changes in writing. If they take issue with one or more of the suggested outcomes they must suggest and justify revisions. If they disagree with the financial limit they must propose and justify an alternative. There is nothing less constructive than a review that raises objections without proposing the fix.

Using this simple approach it should be relatively easy to compose a Phase 1 deliverable in 2-4 weeks. The agile theme scoping is both structured and flexible. The themes can be easily decomposed into outcomes (not too easily… some smarts are required here) and the outcomes can be tied to an evaluation of the amount of money your financial or political environment may bear as an upper limit.

In the next post we will consider how to extend this first step to consider alternatives, to decompose themes into epics and to extend the cost estimates based on the new details that emerge.

Rob Klopp is part of the GovLoop Featured Contributor program, where we feature articles by government voices from all across the country (and world!). To see more Featured Contributor posts, click here.