Project Management

Gathering detailed requirements is the first part of the project lifecycle

Project management guru Tom Mochal presents three solutions for estimating work to within 10% before you start.

Project managers are expected to present a detailed estimate of project work when the charter and schedule are created. However, since the detailed requirements have not been gathered yet, how are you supposed to estimate the work? It seems like a valid question. Yet when we talk about gathering detailed requirements, we're usually talking about the Analysts Phase of a project lifecycle, not the up-front project management work of defining and planning the project.

Tips in your inbox
Looking for expert IT project management? Get the help you need from TechRepublic's free Project Management newsletter, delivered each Wednesday.
Automatically sign up today!

However, it's not really practical to hold off committing to an estimate for the work until you have the detailed requirements. Here's why: Let's say you have a typical IT development project. The project might last six months and the requirements gathering process might last six to eight weeks (or more) of that overall timeframe. If you hold off on the project estimates until the requirements are gathered and approved, the project might be one-third complete before you're validating the overall project costs and deadline. If the project doesn't make sense from a cost-benefit perspective, you might have already spent a significant amount of money. In my opinion, this is much too late, and it's the reason most project management methodologies don't include the gathering of detailed business requirements

Also if you use this same argument, you might say that you still are not confident to estimate the work without first doing the design, and then you are not confident to estimate the work until you have the construction work done, etc. You see that this same logic can be taken to an extreme. 

To me, the following options make the most sense. (I am very aware of agile and iterative techniques where you gather the requirements in an iterative manner. But let’s assume for now that you are doing traditional waterfall project model where you are gathering the requirements up-front.)

  • Estimate the work to within 10% when you charter and schedule the project. To me, this is the traditional approach, and I believe in most cases it is still viable. However, there is an underlying assumption that the project manager and/or the project team have done this kind of work before and are therefore able to estimate the work within 10% based on the high-level requirements that were gathered a s a part of creating the project charter. The caveat to this approach is that if you discover that you have estimated incorrectly after the requirements are gathered, you have to raise a flag at that time and ask for more money. Of course this same check needs to be done at the end of every project phase regardless of the techniques used.
  • Break the work down into smaller pieces. If you don’t feel comfortable providing an overall project estimate within 10%, then you can break the larger project into multiple smaller projects. When you use this technique, you usually end up chartering a project for gathering the requirements. You should be able to estimate this requirements gathering project to within 10%. After this requirements project is complete, you can use the information to charter a second project to perform the rest of the work. Hopefully now you are able to estimate the remainder of the work to within 10%. When you're done, the final deliverables will have been created through two projects, each of which was estimated and managed to within 10% of budget and schedule.
  • "Guestimate" the schedule and budget first and then firm up after the requirements are gathered. This is a variation on the first technique above. In this approach, the project manager provides a "best guess" estimate of the work at the same time the charter and schedule are created. However, based on the rules of the organization, this is not the estimate for which the project manager is accountable (unlike the first option above). This estimate is just the best guess given the information at the time. After the requirements are completed, the project manager provides a more detailed estimate of the work within 10%. This is the number that the project manager is held accountable for.

As I mentioned earlier, many of you may think that the best approach is to gather the requirement iteratively. However, the iterative lifecycle does not provide the answer in terms of how you estimate the project to within 10%. In fact, iterative approaches might make this level of accuracy even harder to estimate, while Agile techniques usually refer to address the estimating at all--preferring instead to deliver working code in iterative sprints until the customer is satisfied with the end result or runs out of money.

The three solutions above provide a more viable set of techniques for estimating the work to within 10% before you start. Do you have other ideas that are effective in your organization?

13 comments
Donald Wood
Donald Wood

Having been both a developer and, later, a project manager I've seen many "methods" for determining time/cost. I've had PMs do an "off-the-hip" hourly shot based on a one-line emailed description that began with "It'd be nice if..." **I'm NOT kidding** and we were held to that estimate for the entire life of the project. Currently, I use a method very similar to the second bullet. Too often, our customers have a semi-half-dreamed-up notion of what they want and I work with them to help solidify their needs, which usually gives me the requirements I need to put into my Requirement Documents. To keep MY bosses happy regarding my time and expense, I "create" these as "Phase One" projects and everyone is happy. Should the project have merit and we continue, then I simply "roll into Phase Two". In the end, I have happy customers, happy IT management, and far less stress. I thoroughly recommend Bullet #2.

norris1976
norris1976

It has been proven that the development of new software is not best done reliably, on time and within budget using the waterfall process. Yes, software can be developed but the customer is usually unhappy, the quality is less than satisfactory and the developers are left in a mess after working so hard coming up to a release! People need to start thinking outside the box. Software is a creative process, not a mechanical one. It is also a complex process. Doing up front requirements and fixing them is the difficult way of doing things. As we all know, customers change their minds when they see the solution develop. They see that some things are needed and others are not. They think up knew ideas and new ways of doing things. With an agile methodolgy, we give the customer room to change by leaving decision making to the latest moment that we can. This way they end up getting what they really want and not what they thought they wanted at the start. I have just become certified in the use of Scrum, an agile methodology, and having working in waterfall and RUP, I think that Scrum really is the way to go. It causes you to think differently but once you make the break from the traditional ways of doing things, it is so obvious how beneficial it can be. But I would just like to say that Scrum is not a quick fix, winner all the time. It depends on the context. But the majority of the time it frees the development team to be creative and to fulfil its commitments to the customer, usually ahead of schedule and within budget.

maciej
maciej

Hello, I would like to know what you think what should be the model of cooperation with client. Let's assume we (some software development company) have the software development project for external client and we plan to manage this project in "waterfall" model. When we sign a fixed price contract before the requirements gathering and analysis process are done, we can only guess what price should be on the contract. And this "guesstimate" could be far too low for us. On the other hand, after the analysis is done, the client will not want to pay more (he signed a contract, he has been given approval for project budget, and the requirements were not included in the contract, so why should he pay more). It could be especially the case when the contract is negotiated by one person (e.g. client's department manager), and the price is getting acceptance by some other person (e.g. client's member of the Board). Is the "waterfall + fixed price contract" really out of sense for software development projects or is there some way to make it work? I am especially interested in applying PRINCE2 (or similar) methodology for software development projects (in PRINCE2, management stages should be executed in sequence, like in waterfall model). Best Regards, M. Zarski

pmaina2000
pmaina2000

Maybe both - depending on final outcome... If you're a hobbyist developing a free address book with "audio visual perks" - it becomes more of an "Art". However for serious applications Software development is much better viewed as an Engineering discipline: Whatever the methodology (Waterfall/Agile etc)- if you've never done a similar project before, the cost and schedule estimation will be more of a rough guess than a dependable estimate. Whats the value of an initial guessestimate that is +-200% accurate? Gather requirements first (as a separate project if necessary) - then do your project sizing based on what you know - rather than what you think you know. Careless estimates mess up customer relations (unmet expectations) and dont make long term business sense for software vendors.

Wayne M.
Wayne M.

Of course, the text book definition of when to use an FFP contract is when the requirements are known beforehand. The reality is I have rarely seen an FFP software development request that had fixed requirements. The typical approach is to fill the proposal with as many assumptions and constraints as possible. This at least gives you a contractual argument later, though few agencies ever bother to read through the assumptions and contraints section. Once you are doing the detailed requirements, you need to define the requirments in the context of the agreed upon cost. Commit to only the bare minimum of capability to meet the letter of the contract within your proposed assumptions and constraints. If development effort drags on the requirements, call a CCB to further reduce the requirements. If you are actually ahead, call a CCB to add a few "good faith" capabilities, but hold most back for change orders. If you can break even on the base contract, change orders can provide your later profit margin. Remember in FFP, you have a fixed budget, so the only variable to adjust is scope. In the end, you are backed into the same trade-offs as in an agile approach, but done in a more confrontational style.

pmaina2000
pmaina2000

You can use PRINCE2 to manage the Waterfall methodology(SSADM?). Waterfall tries to take care of scope creep. In waterfall, Change is "bad". This is a good thing - if you're dealing with rigid sponsors/customers who want to squeeze in hundreds of new "small" features while expecting the schedule and cost to remain the same. However it becomes retrogressive in matured organizations where processes exist to justify changes in scope, budget and schedule is acceptable. Thats where Agile comes into play. In this situations - Change is Good. So dont write off Waterfall yet. Apply it where it helps you most!

Tony Hopkinson
Tony Hopkinson

x days of effort from x people. Options, phases, tech choices, hardware. Deliverable is a document. Use that to build up a relationship with the client. Going in cold with a fixed price and no spec is just a good way of flushing money, your reputation and repeat business down the toilet. For you and them. Or throw the waterfall approach directly in the bin (where it belongs 99.999999% of the time in my opinion).

onbliss
onbliss

Is it possible for you to split the work (contract) in two phases? The first one being the requirements phase and the second one being the design, development, testing and implementation. Once you get the project, you could sit with the client and explain your work flow. So you can "guesstimate" the price for the requirements/analysis phase. Once the deliverables for this phase are delivered, you will have a better idea and can work out the price for the phase 2 - design to implementation. 2 cents.

norris1976
norris1976

I think it is worthwhile to talk things through with the customer and let them see that giving a fixed price is not beneficial to either side. Adopt an agile approach and help them see how this will benefit them over time. Of course, you may need to put a rough estimate on things but you should let the customer know that you will be better able to give a better estimate once you get started and see the velocity of the team. Software development is not the same as a manufacturing process where each stage can be given a definite time for completion. We can and should give estimates, but these should not be set in stone. With an agile approach, after each iteration the customer is able to inspect and adapt and change direction if necessary. The development team can also bring to the customer's attention at an early stage if things aren't moving along as quickly as first throught. It is amazing how appreciative customers are if we are up front and honest with them. Have a look at some of the groups on scrum: http://groups.yahoo.com/group/scrumdevelopment/

prince2browser
prince2browser

waterfall is a lifecycle not a project management method. prince2 does not prescribe waterfall or any other standard lifecycle. prince2 does say you need at least two phases to a project: Initiating a Project (IP) and the rest of the project; so you can mix prince2 and agile if you need to.

maciej
maciej

Hello, Thanks for your answer. I am aware of agile methodologies like XP and Scrum and I know about their advantages and disadvantages. But I would like to know if there is any kind of process or methodology which could be used for managing successful software development projects with waterfall + fixed price contract. Is it possible to manage SDP that way (keeping customer happy and earning money at the same time)? Best Regards, M. Zarski

lsievert
lsievert

Do you have records from other projects completed by your team? One of the huge benefits of keeping good records and then having a formal retrospective is that you can learn from the past. You can track project performance with a good MS Project spreadsheet (see the awesome book "Dynamic Scheduling with MS Project"). This historical data can help you to do estimation for future projects. But if you can talk the customer into paying for requirements first and then negotiating the build contract, you're in a much less risky position. Lisa Sieverts http://project-tips.com

Tony Hopkinson
Tony Hopkinson

there's a very clear and proven way of doing it, teh resources to do it are available and none of that is going to change through the lifetime of the project. Hardly ever in other words.

Editor's Picks