Wednesday, April 19, 2006


The Proposals Stage

It is very difficult to get a business proposal from the idea stage to the start of an Agile project. Most business ideas go through some sort of process that decides whether or not the business thinks it is worth the expenditure. However, the way that the expenditure is calculated is usually by some pretty in-depth business and technical analysis. Usually quite bit of time and effort (and therefore expenditure) is spent on this stage in the projects life, and the outcomes from this are usually a high-level technical solution and a budget. The business uses this information the work out whether it is beneficial to go ahead with this proposal. Already we aren't working in an Agile way, as the first that the Agile team will see of a project will be at a point where the budget is set and the technical solution has been decided. In addition, a lot of money will already have been spent on the project, leaving less for the Agile team to spend creating the solution.

Business Outcomes

Recently, a collegue and I were approached by somebody who was part of the Analysis stage of a proposal. They thought they might want to do a project in an Agile way, and wanted to know how much budget would be required to implement a timesheets system. I said that it really depended on what they wanted, and asked them what their outcomes were. They replied with outcomes such as 'to reduce the time it takes to process the timesheets from 4 days to 1 day.'. This is a perfectly valid outcome, but it is a Business Outcome. It cites the benefits of the solution being implemented.

Solution Outcomes

Each Business Outcome has to be supported by one or more Solution Outcomes. Solution Outcomes identify what the solution has to achieve. An example of a Solution Outcome for the timesheets system would be:
The ability to electronically receive 400 timesheet submissions from employees who are on the corporate network, peaking at 10 submissions a minute.
To validate that the timesheet submission is actually from the employee in question.
The ability to process 400 timesheet submissions and collate them into central database within 5hrs.
To report progress on the import and report if there are any issues when processing the timesheets.

These outcomes are non-technical, and they don't identify how you should implement the solution. This retains the Agility to fulfil the outcomes in various ways.
A full and prioritised list of business and solution outcomes, with the relationships between them is a great outcome from the Analysis stage of the process. It allows the Agile team to approach the problems in an Outcome Orientated way to provide the best business value. It also gives them the freedom to choose the technical implementation, which really should be their call, in association with the Architecture team if required. Once you have a Solution Outcome, you can then make the decision of how to implement this outcome, on a value centric basis, and then the truth can write the stories in association with the XP/Agile Coach in the 'Getting Your Stories Straight'. From this a Planning Game ensues and then you can cut the first iteration.

Upfront estimation of Budget

There still remains the problem of providing an upfront budget estimation. You know least about a project at the start, so it is the worst time to make any decisions about cost. Also, you don't know how you are going to implement each outcome - that should be decided later. However, the business need a guide so that they can make the go/no-go call. In another article, I propose that instead of an absolute budget, the output from the Analysis stage should be a project size rating (1-5) and a confidence rating of its accuracy (%). If an estimated budget is really required for the Analysis stage, then maybe it should work the other way round: how much is it worth for the business to achieve these outcomes? Then ask an Agile team whether they think they can achieve the outcomes within the budget provided.


Even though the business was unclear on what they want the system to do, they had already decided on an implementation. In the timesheets example, they knew they wanted a web application, written in .NET, writing data into a SQLServer database, the schema of which was already decided. They were also deciding how much it was going to cost and what resource they would need to allocate to implement their chosen technologies. However, they didn't really know what they wanted the system to do, or the best value way of achieving this. They were worrying about the screen design of the web page and the implementation of the user authorisation feature. This is all the wrong way round. To fully enable an Agile/XP project, it is necessary for the Analysis stage to undertake thorough Business Analysis, and identify the scale and risk of the project. They have to accurately define the benefits they want out of the project, and the outcomes that the solution will have to provide to support these. Then if they decide to press on with the proposed project, the Outcome Management and technical implementation should be in the hands of the Agile team who will work in association with Architecture, Security, Brand, etc to ensure that the solution is fit for purpose.

No comments: