Author: Geri Schneider Winters
Alan Thompson wrote recently to ask, “How do we do a better job of estimating how long it will take to gather requirements?”
This is a question that often comes up, so I want to share my answer with all of you.
The bad news is that there is no good way to estimate the requirements gathering process in the general sense. You may be able to do a good job for specific projects, but there are too many variables to be able to have a good general purpose estimation method.
You can make some guesses based on the type of project it is.
If you are proposing a project that is a maintenance release, basically bug fixes and maybe a couple of new features, then requirements gathering is almost nothing. You just need to come up with the list of bugs that will be fixed in this release, and add details to the requested features. The amount of time for requirements gathering will be an estimate of how long it takes to detail the requirements for one feature (use your experience to estimate this) and multiply by the number of features. Determining the list of bugs to be fixed could be a matter of scheduling a one or two hour meeting of concerned stakeholders to settle the question of what is on and what is off the list of things to work on this release.
If you are proposing a project that is very well understood, then based on the number of requirements, you can do a fairly good estimate of the time it will take to document them and approve them. For example, I once worked on a project to automate the processes of loan application, loan approval, and loan buying and selling for a financial institution. The team knew their business very well, and we documented everything in 2 weeks. All the use cases, a basic business object model, a basic architecture, storyboards, and a draft of a plan to divide the work into 4 projects over 2 years. I had over 100 pages of documentation. The team was me and another 1/2 time person doing all the interviewing, documenting, and organizing of information, and about 10 people from the company who were involved part-time by being interviewed and reviewing documentation.
If you do have good, well-written, agreed on Business Use Cases, then then the time to write the detailed requirements should be the number of business requirements times the expected time to detail one of them. Which is basically a factor of the skill of the people interviewing and documenting the requirements. You may run into some cases where you find that the business use case was not as well thought out as you believed, and so the project use cases take longer to develop than expected. I would expect that situation to be the case fairly often the first couple of projects you try this approach, but the more experience you get, the better the Business Use Cases will be to begin with, and the less surprises you will find as you develop the detailed requirements.
Now you get to the hard projects – the ones that are not well understood or where the stakeholders disagree on the purpose of the project. In that case, any estimate of the time to develop the requirements is just a guess. You can look at past similar projects to find out how long requirements gathering took, and use those figures as a rough estimate. But I have watched stakeholders argue for months about the features and requirements for a project, not because the requirements were difficult to determine, but because they had a basic disagreement about the purpose of the project.
When I work as a consultant, the requirements gathering phase is always time and materials. I will not do fixed bids on that work, because my experience is that there is too much variation in that phase for me to be able to do a good job estimating it. All contractors I know who do this work feel the same way, though some have done fixed bids because that was the only way to get the contract. They have almost always been burned by it, because something happened to extend the requirements gathering phase well beyond what was expected.
Another approach to reduce risk is to go with a true iterative approach. In this approach, you identify and specify just a few requirements, write and test the code, and demonstrate it to the customer. Determine what works and what does not work. Make a list of fixes, add a couple of new requirements, and develop the next bit of code. This way, you are only working on a small piece of the project at a time, which is relatively easy to estimate. But then, you do not have an estimate of overall cost to give upper management. You can use historical records of similar projects to get an idea of overall cost for your project.
All estimation methods ultimately depend on your experience and an estimate of how long it will take to do some small task. Then various formulas are applied to turn the time to do a small task into the time to do the whole job.
In the book “Applying Use Cases”, I have a copy of a paper that shows a use case estimation method, but it is more designed for estimating the project after you have written the use cases. It is based on what are called Use Case Points, and is similar to the method of estimation with Function Points. But if you review that, you might get some good ideas for coming up with your own formula for estimating the requirements gathering phase at your company.
Do you have a need to estimate the requirements gathering phase on your projects? What method do you use to estimate that phase?