| nnccl wrote
Hi Craig,
I am interested to know your thoughts on the impact of Agile Development Methodology on cost/budget of a project. With evolving requirements in an Agile environment, I'm sure the project budget will also need to be revised depending on the extent of changes required. What is the best way to manage this especially when costs are agreed upon with the client prior to the start/awarding of the project.
Cheers
|
This is seriously one of the biggest implementation challenges I can think of. It is what I spend much of my time butting my head against.
There are 3 aspects of thsi question that I'll comment on. Anyone else have any comments we'd love to hear them.
- The effort to get to the end of the project
- The level of integrated analysis and supporting docs
- Change control/budget forecasting
1. Analysis effort
On the one hand the analysis effort of an agile project is about the same as usual. It's just spread over the life of the project so it feels like les at the peak points. (Same goes for testing.) On the other hand my experience is that the analysis effort is actuallya bit easier as you don't have to push your stakeholders to think beyond their comfort zones and you don't have so much of that negotiation for what is in and out of scope. But to begin with - asume the same efforts will be required for the same project.
2. Integration and Supporting docs
Firstly if you are using requirements maagement tools you have probably found some significant improvements in the integration, quality and maintenance effort on your requirements. Agile teams like to use automated tools where they can so from a cultural perspective you are likely to find some benefits here. Of course many companies already have good RM tools regardless of methodologies.
People talk about agile projects valuing working software over documentation. Sure, that's what most clients want also.
Of course the leel of documentaton is directly relevant to the size and complexity of the product. A small business website may be documented on one sheet of paper. Other laer systems need a room just to store all the printed docs. This isn't about agile-not agile. This is about the product you are constructing AND your professional skills. Don't create document artefacts for the sake of it- that is wasting the client's money. And don't just go checkboxing templates as they can mislead the project team into doing the wrong things. Instead write documents clearly and focus on what needs to be said.
That change may take some effort to start with, but eventually means leaner projects.
3. Change control and budget forcasting.
This depends on the method you adopt. If, like me, you adopt scrum you will have a product backlog. This is a lit of requirements. Estimate the size of each requirement. You can then use 2-3 iterations to measure how many requirements you get through at a time (a jargon term is story points). That is your velocity (ie rate of progress.) You can now divide your requirements scope by your velocity to work out when things will be completed. This is very similar to earned value.
There is actually a lot more avialable on the web that I can summarise here so let me start you off by referring you to these 3 sites;