In But I Need to Know When the Project Will Be Done, I talked about what you can do for estimating an agile project (do a gross estimate of the backlog, estimate your velocity, better your estimate every iteration and keep talking to your management). What if you have a contract? What if your managers really do need to know exactly when the project will be done? What if you don't have an agile project?
Let's take these one at a time. If you have a contract, that date is your release criterion. By definition, you will be done. What's the problem? If you rank your product backlog, get to done at the end of each iteration, or make sure each feature is really done when it works its way off your board, what is the problem? I don't understand the question. Really, I don't. When your date is fixed, your scope can change. If you have a fixed date, fixed scope where is the flexibility in the project? In Manage It!, I ask you to ask the sponsor, “If it's 3 weeks before the end of the project and we don't quite have everything in the project, and we too many defects, what decision are you going to make: keep going until we have everything in, fix the defects, or release anyway? Let me know now, and I'll know how to make tradeoffs.”
If your managers need to know exactly when the project will be done ask why. There is probably a good reason, such as there is an important project waiting to start right behind this one. This is a good thing, because it means your managers are managing the project portfolio. There might be another reason, such as a sale depending on this project. You want to learn why, because you might be able to help whatever that dependency is without a lot of drama. You might not, but you might. You can't help if you don't know why.
Now, the hardest one: if you don't have an agile project. This is hardest, because it's hardest to see progress as you proceed, so your estimates are likely to be wrong. And, if people are multitasking, your estimates are guaranteed to be wrong, and you will be maximally slow, and Murphy will not just visit you on this project, he and his extended family will live with you forevermore.
But, if you don't have an agile project, you still have options. You don't have to use a serial lifecycle. Sure, you can say you're using whatever lifecycle your organization says to use. But, they pay you to manage risks and be a project manager. So, if you say, “In order to manage risks on this project, I am going to iterate on the architecture three times to test the architecture with three features and then give you an estimate that we think is within 50% of reality” are they going to say No? No, they might say, “50%, we need to know with 5%!!” And then you can say, “Great, here's how I'm going to tell you that.”
The problem is that at the beginning of the project—any project—you have too much uncertainty to provide any exact estimate. An estimate is guess. You need to evolve any estimate over time. My favorite estimation technique for a non-agile project is to spiral in on a date. At the beginning of the project, you say, “Somewhere in this quarter.”For this example, let's call is Q1.
As you proceed, you say, “Somewhere around the middle of Q1.” Some smart manager says, “Oh, Feb 14?” You say, “NO, it's not a Valentine's Day present. There's a plus/minus here. Call it anywhere from late January to late March. That means the absolute earliest it could be is late January, but I have little faith it could be late January. And, even I think it will be before late March. But I don't know where in the middle of Q1 it will be. I can update you with a better estimate next quarter, when it's September, ok?”
The problem is you need that smart-aleck manager to listen to your entire paragraph. Otherwise, the manager only hears himself, and not you, which is a potential problem.
The key is you have to use iterative planning and tracking approaches, incremental development, and I recommend you use continuous integration, because otherwise you get to the end and you get surprised, which is a horrible feeling. I wrote an article about this a number of years ago, called Use All Four Parts of Project Estimation.
Exact estimates are an oxymoron. Estimates that you update? Those are useful. I can understand why any manager would want those.