A valid question that is often raised is “Agile emphasizes that the Software projects are highly unpredictable in nature and Agile principles enable you handle the unpredictability better from Engineering point of view. But, from the Business point of view, how do you deal with the cost factor for Fixed Cost (FC) assignments?”. ‘How much does it cost me?’ is what the customer wants to know and ‘How many engineers do we need to allocate and for how long?’ is what your organization wants to know.
While there are a few good books available on this subject, let me try to put together a few things that I have understood from my experience.
Project Estimation and Planning, for most of the projects, is something which you cannot start without but cannot stick with. This is because there is always a cost factor associated with whatever you do and nobody would be ready to start the job without a plan - neither your organization, nor the customer. End of the day, it is not just an engineering problem but a business problem as well. Whether you like it or not, you need to come up with a project plan and it would give you an approximate effort estimation, if not accurate. Not only that, it also helps you understand different variables involved. But, at the end of the project, what remains true is the BEGIN and the END of the project. Everything else would turn out to be a filling-space just like a play-ground with defined boundaries(time and scope) where you make on-the-field decisions. Only question is how far the plan has changed from the original version to the end - and it depends on - How predictable the project is? How stable the requirements are?
Here is one approach that we used to follow for the fixed cost assignments:
- Provide an up-front project estimation based on the initial Requirements Analysis and the Project Scope. Provide a 10-15% buffer to accommodate for the requirements and tasks that were not identified before, but within the scope of the project. I am not saying this is the best but at least it worked for most of the assignments that we handled.
- This also included the Incremental & Iterative development plan.
- This required that we had to do a decent high-level analysis of the System to get as much a closer as possible to estimate the SIZE of the effort. For example, missing a requirement like ‘Providing User Registration Form’ in the application cannot be something that is backed up by saying that we are following Agile.
- As we go with the implementation and as requirements and design evolve, we had the flexibility with the SHAPE of the effort to alter the size and sequence of the iterations being Agile. This way, we used to maintain the balance between ‘Shooting in the Dark’ and ‘Shooting on the Dot’.
- Agile is not a replacement for capturing the Scope of the project and documenting the Assumptions and Risks. Irrespective of the format and name of the document, they need mention so that the Customer and the Service Provider can handle the things better on the estimations and the cost parts. You need to know whether you are going to implements Bananas or Oranges, where you think Bananas might change to Oranges and how it affects the Estimation and Plan.
- For the projects with highly unpredictable requirements or where the requirements are being developed (R & D in nature), T&M (Time and Material) or a combination of T&M and FC models are more apt. It all depends on how you work out with the customer on arriving at a consensus on what part of the project is predictable and what part of the project is unpredictable and needs R&D. It is not required that everything needs to be fit-in-one-size.
Apart from the approach that is outlined above, there are other approaches as suggested on this blog post (mentioned below) to handle the Project Estimations and Cost factors better. End of the day, it also depends on understanding the project variables and getting to know your customer to devise a model which suits you the best.
Is your project management methodology addressing the Business and the Cost variables along with the Engineering variables?
Are you devising a right contracting method that is best suited for the project?
(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)
No comments:
Post a Comment