Friday, July 9, 2010

Milestone Based Project Management

Proposal for Posadas
The world is at a loss to find a thoroughly satisfactory reason for the persistence of the German in forcing the fighting about Verdun. To the world the German had been defeated in the battle long ago. Two months have passed since a German gain of any importance has been chronicled. In that time there have been many heavy attacks, prepared by artillery fire and delivered by infantry in their final stage, but all have shattered themselves against the wall of the French defense. The German losses have continued to be heavy, indisputably heavier than those of the French, yet the attacks continue. It is no wonder that the neutral world looks on in amazement and asks why." (NY Times. May 14, 1916, Sunday).
The battle of Verdun in 1916 during World War I lasted nearly nine months and resulted in the deaths of about a quarter million soldiers and the wounding of another one million. Then, as tragic as this battle was, another battle, the battle of Somme, designed as a means to draw German forces away from Verdun, resulted in even more casualties than the battle of Verdun (speak of “remediation”!). In the end the Battle of Somme resulted in 1.5 million casualties (around 400,000 killed).  In the entire battle that took place from July to September of 1916, the British and French managed to perform an “impressive” drive of 8 Km (5 miles) from the original battle position.
While these battles remain the paragon of human stubbornness and stupidity, many large IT projects eventually face their own version of the Verdun battle (all human considerations aside!).  One can imagine the Verdun battle being run with one of those Task-Oriented project management tools: “Delivery of supplies? Check!” “Trench digging? Check!” Transfer another division of 5,000 men to the front to serve a cannon fodder? Check!”  
From a task-oriented project management perspective everything was probably on track. Now, imagine if instead, they had established a timetable for quantifiable milestones “By week five we should have advanced two miles”. Perhaps that approach would have served the Generals better in understanding their project was headed for failure.
Milestone based project management can also maintain the sanity of remediation efforts. What happened in Verdun is also typical of many failing projects: a sub-system falters and the management team expends resources and time in an effort to save it. When this fails, more and more resources are applied, until eventually the entire project begins to be measured by the bad press of this particular failure. This type of behavior has been well studied under the guise of the Gambler’s paradox (the more one loses, the more one continues to gamble in the hope of recouping losses, resulting in even greater losses).
If the project is managed by appropriately partitioning it into discrete modules and deliverables, and with quantifiable milestone targets, then things need not be so dire. Also, it’s important to understand that a transformation project is typically so complex that it is unrealistic to expect all of its components to immediately work as expected.  Good project management entails tracking down and detecting when a sub-project is being derailed and acting upon this issue with a clear understanding of the problem.  This means approaching the management of the project via well-defined milestones. Some of the milestones may be there to serve as a kind of “canary in the mine”—something like the delivery of a simple demo to test nothing is rotten in the Kingdom of Projectmark. The key is to understand whether the component in trouble is critical to the overall success of the project, or whether an appropriate do-over is in order.
Needless to say, the key to tracking and assessing the status and impacts of the project dynamics is the Project Management function. If the methodologies and lifecycle of project management in the context of IT projects are not clearly defined, this area quickly tends to become a hotspot of friction. Why? Because of a mistaken idea that anyone with working knowledge of MS/Project can become an IT project manager. A major transformation project is not the right place for copying the style of shows like “The Apprentice”, where contestants (usually celebrities) are given project management roles as a part of their challenge. In this show it does not seem to matter whether the contestant is “project managing” a challenge outside his or her area of expertise. 

In the world of IT, delivery managers with systems and software background have traditionally been more successful in the project management role. The role of generalist project managers in IT projects is better left for peripheral or support functions (managing a training track, for instance). Moreover, IT development artifacts can be extremely detailed and if micro-managed (something very easily done with task-oriented project management), can cause situations where you are not able to see the forest for the trees.  Traditional Gantt-chart management with day-to-day track assessment of projects via red-yellow-green color codes may look good on status reports, but does little to ascertain the true status of a project.
Secondly, there are projects and there are projects. . .  Smaller projects need to be handled in a way that assures the necessary ingredients for success are available to the team leader with a minimum of red tape. Smaller programs can benefit greatly from rapid application development methodologies and from early prototyping. Just remember that Agile methodologies should only apply to the actual software development steps; and not to the architecture and design phases. Using pseudo-Agile approaches under the mantra "Code now, Design Later" often results in failure. 

What defines a small project?  Well, I’d say one where no more than five people working on a deliverable for a maximum of four months is as good a metric as any.  We are also talking about something that will not cost over one million dollars including labor, hardware, and software capital costs.
Then there are the medium size projects. These are projects that can take up to a year, or even a bit longer if the executives in your organization are prepared to go on Prozac and give you more leeway. The core development teams for this type of project should never exceed the magic number of ten. These projects tend to fall in the ball-park figure of around three million dollars. A medium size project needs to be managed with a savvy combination of high-level project management controls and the appropriate placement of deliverable milestones.
Larger projects should basically not even exist. Why not? Well, a large project should be suitably broken into as many small and medium sized projects as possible. Ultimately, a large project should only exist in the talking points of the individuals responsible for your company’s public relations, and in the radar of the very small team responsible for integrating all the various moving parts.
So what is Milestone Based project management all about? Basically, it’s the definition and tracking of measurable, well defined milestones. The difference between a milestone and a traditional project management event is the fact that the milestone should stand on its own as a deliverable. Completing a piece of code is not a milestone. Completing a prototype or being able to demonstrate a complete sub-component of the deliverable, are examples of milestones. If the event is something that can be shown to anyone outside the development group, and is considered to be at least a partial success, then it qualifies as a milestone.
Tracking milestones has a number of benefits:
·         Missing a milestone is a clear signal that the project is not on track.
·         A successful milestone motivates the team by providing a clear partial result
·         Milestone deliverables can provide some benefits sooner
·         A successful milestone can motivate the project sponsors to continue their support of  the project, even when faced with budgetary constraints
More importantly, there is no way to sugar-coat a missed milestone. While missing one milestone should not spell gloom-and-doom, a project stringing along two or more missed milestones is a project that needs to be seriously reviewed.
In fact, you should always allow room in a large project to anticipate the failure of a specific component, and to adjust for the overall delivery because of this failure. The solution to the quandary might range from starting again from scratch (assuming the initial implementation was proven wrong), to completely eliminating the subsystem and remediating by providing a suitable minimum set of capabilities from other subsystems.
Milestone driven project management is superior to task-oriented project management in large projects because it focuses on what’s important while simplifying the view from the top.