6

When starting a brand new project, no matter how well I try to consider all of the components I always end up with a rapidly expanding list of features and missed requirements by half way through.

How do I deal with these before or during the project without repeatedly blowing my milestones, or worse; "finishing" with a list of missed essentials taped to the side?

6 Answers 6

7

There are a few measures you can take to both prevent and deal with this kind of situation.

  1. Initial Estimate +- 100%: Make your initial estimates big (eg. plus or minus 100%) if you know that all the requirements are not captured. As you get more sure, start narrowing the range down. This keeps all stakeholders in the loop.
  2. Up-Front Design: If you keep missing requirements, do more up-front analysis and design of your product. Keep breaking items down until you reach the point where you feel the team can understand, estimate, and implement the work.
  3. Write Down the Risk: If you're not doing risk management, start. Write this down as your first risk, and make it a high probability and impact: "missing and incomplete requirements can jeopardize schedule." Come up with a mitigation plan (what to do if it occurs).
  4. Say No: Learn to say no to stakeholders. Great ideas always emerge partly through the project, especially with vague requirements. Your goal is to get the project done on time and within cost, not to get "everything" people want done.
  5. Buffer: As part of your mitigation plan, add some buffer days into your schedule.

If you miss something really big, it's OK to change timelines -- even experienced PMs in big companies do this often.

Finally, if your project is a software project, try to use the agile methodology. Since agile estimates in an arbitrary unit ("story points"), it already takes into account the fact that estimates can change, and depends on the actual team performance to calculate the schedule.

3
  • Good answer, but I'm not sure you mean +-100%: a 2 week project +-100% would be "4 weeks, or it's already done"...
    – Stu Pegg
    Feb 9, 2011 at 18:35
  • I meant to mention: risk is an interesting area that I haven't yet investigated. Thanks for drawing it to my attention.
    – Stu Pegg
    Feb 9, 2011 at 20:17
  • 1
    No worries. +- 100% means a two week project is 2-4 weeks. Always, always, ALWAYS give a range, because humans remember singular numbers and hold you to those.
    – ashes999
    Feb 9, 2011 at 20:28
4
  1. Do much smaller projects. Break things down into smaller bits and focus on getting those done on time and within scope.

2.Write down the process of how you plan on getting things done. Write down how you actually do get things done while the project is going on. Compare the two and start to isolate the specific factors that are tripping you up.

0
3

This is something that I have not done yet, because I'm not a professional yet and I'm just now trying to work on projects in a more professional manner (subversioning, development methodologies, etc).

I ran across evidence based scheduling. The basic premise is that we're really bad at estimating when an entire project will be done because we don't know how long every little thing will take. In evidence based scheduling, every little part of a project is broken down, making it easier to put estimates on. Also, the actual time it took for each part is recorded so a comparison between actual and estimated time to complete can be calculated, which allows for better estimates on the future, because it's likely that all of the times will be generally underestimated by a certain factor.

3

'rapidly expanding list of features'

This is one of two things:

1) If the features are really fine-grained details of larger requirements, then it sounds to me like insufficient planning, particularly the requirements analysis part. Capturing what the customer wants in the final deliverable is a long process of eliciting all the specific details that the customer wants. Once you've got all those details, you need to look through the impact of each, dependencies, risks, available resources to do the work, etc, and gauge the costs of the implementation. Once you have the costs (time or $$$'s), you can present these figures to the stakeholders to ensure they understand the costs and timescales they're about to commit to.

2) If you've definitely gone to this level of detail for all the tasks in your project, your project has already started and your timescales are ballooning, maybe the issue is that you need a change management process, so that the is dealt with formally and the impact on the timescale spelled out to the stakeholders. For every new feature that gets added, what not-done-yet feature gets removed? Have you considered switching to an iterative project management methodology?

1
  • Interestingly, I've found that it is often difficult to predict the many and various issues in advance, no matter how detailed the requirements document. With this in mind, I definitely agree with your recommendation of an iterative strategy.
    – Stu Pegg
    Feb 9, 2011 at 20:15
1

I think that what you have is an indicator of good communication between you and end-users/customers. You discover that requirements are missed, and you discover this situation right in time.

The question is how to keep your scope and schedule synchronized. Try to communicate schedule as frequently with customers as you communicate scope. In other words, every time you discuss new requirements - discuss changes to milestones. No matter how difficult it is.

1

Shortly after asking this question it occurred to me that I was suffering this problem more so recently than in my previous job. Then it struck me: Inexperience. I'm having trouble making consistent estimates because:

a) Some things take longer than they should due to my lack of knowledge of the tools

b) I don't yet know the framework well enough to consider the problem down to any level of detail

So my answer to people in similar circumstances is to gain more experience (or knowledge of the area), and/or consult someone who has relevant experience when making the estimates.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.