Practicing Safe PM
Inevitably, if we build our project schedule based on reasonable expectations of how long it will take to do the work and an initial cut at dependencies between activities, the resulting overall duration will be well beyond our hopes, goals, and promises. This is a challenge that will not go away, and there are different ways to deal with the issue.
Quite often, because this happens time and again, some organizations throw their hands up in frustration and give up on the scheduling approach altogether, in favour of the ‘make crazy promises and code like hell’ approach to getting things done.
Still others practices the ‘work backwards from the deadline and cram everything in’ approach, where estimates are simply dividing the available time into enough chunks to allocate to the various tasks on the schedule. Shortchanging our tasks forces us to cut corners, make mistakes, and end up taking longer than it would have if we took the time to do it right in the first place. This fallacy quickly degrades into the ‘code like hell’ approach, but with the backdrop of a pretty, outdated Gantt chart that provides the façade of reasonable management.
The reasonable approach is to recognize that the expectations that have been set and the original schedule of interconnecting activities are starting points to solving the problem. Depending on the context and the shape of the project, initial expectations can be tempered, scope can be cut, different resources can be applied, quality can be consciously reduced (in rare situations), and dependencies can be broken to bring activities parallel and reduce the overall duration. From most initial schedules, I have seen that the overall duration can be reduced by 50% or more without cutting scope or compromising the estimates of effort required to get the work done.
All this, though, only gets us to an initial schedule that fits expectations. Experience tells us that there will be changes along the way: added scope, missed deliveries ,things we hadn’t considered, task overruns, defects to address. A schedule with known work that fits our constraints is not enough.
We have to practice Safe Project Management.
On most projects, there are external dependencies that we rely on to get our work done. Outside contractors, equipment to be delivered, information we need to get. If we have less control or experience with these outside entities, the uncertainty that they can deliver increases. It is only reasonable that we should place a buffer of time between when we set expectations for getting that external stuff and when we need it on our schedule. The more uncertainty, the greater the buffer. We can reduce the uncertainty by taking the effort in-house, by working with a trusted source, or by emphasizing closer communication, but we can’t ignore it in the schedule. We actually can, of course, and we quite often do, but we get burned by it over and over.
Even for the tasks that we have internally, there is some uncertainty in how long it will take to get the work done. We address this in two ways.
First, we have to get away from scheduling based on optimistic expectations that everything will go perfectly. It never does, but we are still surprised by projects that don’t come in on time when we plan this way. If we recognize that estimates are probability curves, we can build schedules based on most-likely times. Experience tells us what is reasonable (excessive padding is just as bad as being overly aggressive), especially if we track our actual effort against original expectations.
And no, it does not cost us too much time to do this tracking of actual effort.
Secondly, for any string of activities, there will be a corresponding pile of uncertainty across these tasks. It’s a good practice to add a buffer of time at the end of this string to accommodate this uncertainty. This is the basis of the Critical Chain approach (why do we have to name these things?…), and these buffers need to be ruthlessly protected by the project manager, rather than be consumed at the whim of the team.
As we get started in projects in a new domain, there will be a number of activities that we know we’ll need to do, but can’t reasonably estimate how long they will take for this project. Typically in software projects, these are things like ongoing scope change, final test and bug fixing along the way. It’s good to capture these with your best guess for the schedule (and be careful to not whittle the down when other tasks overrun), but it is more important to measure how long they actually do take as the project progresses. If you have done several similar projects, or if you are on the n’th release of an evolving project, you should have a very good handle on how long these activities will take, even if you don’t know the exact tasks in advance. Having the data will help you defend the time estimates and protect these buffers as well.
All these buffers may appear daunting, but what they are is a way of capturing what we know happens on any project anyways. It is important to set firm expectations about why they are there with all stakeholders – they are not simply random padding of estimates with no basis in reality. If you are tracking your numbers reasonably, after a few projects you will be able to point to precisely why the buffers are there.
If we take all this into account in our original scheduling and ongoing maintenance of our schedule (our current expectation of how the project will play out), we have a much higher chance of meeting our expectations, and we have done nothing to whittle down our original estimates. If we can’t make adjustments to meet expectations after these buffers are in place, this is information that we can’t ignore. It is far better to know this in the early stages of a project than at the 11th hour, after we have pulled a few weeks of all-nighters in another attempt to perform a miracle.
Layered on top of this, of course, is the ongoing diligence to ensure that the schedule is adjusted as new information comes in. Lots of work, to be sure. It is effort that we can identify in advance, and it can be frightening, so it becomes easy to not do it. Compared to the effort involved in digging a project out of trouble, it is far less work and far less stressful.
The less of this you do, the more likely you are to be in a compromising and embarrassing position on your project. While you can practice PM without these safeguards, you do so with increased risk. – JB