It is fairly well accepted that most engineering projects end up late, overbudget, or canceled. The root of all time and budget slips is the unknown coming 'round to bite us in the butt.
Unfortunately, we cannot eliminate the unknown - every project is at least a little new. Despite our inability to banish the unknown, some project managers are consistently on budget and/or on schedule. How do they do it? By:
Remember that project management is not simply an exercise in cracking the whip. Rather, management is an exercise in obtaining and deploying resources in a way that is most likely to obtain success.
At the start of any project, before putting together a budget and timeline, one must identify the project deliverable (design spec), and the major portions of the project. For example, to build a car, we must build an engine, a drive train, suspension, interior, and so forth. Each of these functional building blocks is likely to have its own group assigned to it, and its own milestones. Each of these will have a greater or lesser risk of failure, depending on:
The first critical job of a project manager is to look at the functional blocks and to honestly, accurately, and truthfully assess the relative risk of each block. This is not a casual task - it is one of the most important things that you will ever do in a project, and a bit of omitted work here can result in tremendous trouble down the line.
It is useful to think of risk as the opposite of predictability, and to rate each functional block based on how well you can predict the time, cost, and quality of outcome. You will end up with a spectrum of predictabilities, ranging from blocks that you could personally design and implement in your sleep, to things where you've not the foggiest idea of how to build 'em.
The next step is to attack each functional block, and see what can be done to increase its predictability. Do we already have something in a current product that does what we need, or almost does what we need? Do we have good people in hand that have built something similar? Do we have competent and controllable outside resources that have built something similar?
Customers always want stuff that works well, and is delivered on time and on budget. They rarely care about cool new technologies. Thus, it is best to avoid cool new technologies, in favor of old boring technologies, until the cool new technologies have been around long enough to become boring and old. Exciting products using boring technologies are the way to go!
In the event that there are some building blocks that cannot be reduced to minimal risk, try to build a list of possible mitigations (fallback plans) in the event of these blocks falling into mayhem. These mitigations might trade off increased predictability for reduced functionality, might be alternate solutions that cost more, or might even be alternate solutions that have lower predictability but just might work if we're really stuck. It's nice to have a list of possible mitigations at the start of a project - if and when something starts going awry, we can quickly get a feel for when we may need to go to a fallback plan.
Actually, in some markets, it is important to be fully buzzword compliant. So if your customers insist that they need a CORBA and/or DCOM interface to Java servlets running JDBC against Oracle, even though they don't really know what this means, and won't really use it, you're stuck on the bleeding edge — but good project management will still get you through, although with a bit more heartburn than if you were off of the bleeding edge.)
Once you've reduced the risk of failure, the next step is to manage the remaining risk. The key here is to sequence the project so that the riskiest steps come first: in the event that something is more difficult than anticipated, we'd have maximal time to surmount the obstacles and complete it. By contrast, if we waited until four weeks prior to scheduled release to tackle a risky functional block, we'd have little wriggle room.
Any serious trouble (schedule or budget slippage) will be known as early as possible, where it can be best managed.
It is very often the case that once we get going on a high-risk functional block, we determine that it should function in a way that is very different from what we initially envisioned. This may turn out to have fundamental repercussions to the project, which, in turn, may change the way much of the rest of the project is executed. Better to know this up front than to have to go back and redesign and re-implement later, which can slip schedule and budget enormously.
At a simple level, the standard model of a project has the following major phases:
By adding a phase between 1 and 2, which I call the risk mitigation phase, we can tremendously increase predictability and decrease stress. The risk mitigation phase is a less-structured period when the technical staff can be exposed to, and learn about, those parts of the project that they are less sure about executing. By the end of the risk mitigation phase, we should have a highly predictable project with well-defined timelines and budgets.
Our new simplified model:
The bottom line - by identifying the unknown parts of a project, minimizing their unknowness, and moving them to the front of a project, we greatly increase our chances of a successful project that is on-time and on-budget. We also sleep better at night, as all of the significant unknowns become understood early in the process, perhaps even before budget and timeline approval.