~ By Dan Patterson
After spending the past decade or more dedicated to project management, I noticed during the economic downturn last year a very surprising trend: despite the significant reduction in the number of major CAPEX projects being sanctioned and funded, the need for third party assistance with schedule analysis and risk assessments actually increased dramatically. After digging into this a little more deeply, I came to the following conclusion: savvy project schedulers are at risk of becoming a dying breed and as project management specialists, we need to do everything we can to reverse this trend.
The software tools available to planners, schedulers and estimators are more powerful today than ever with the likes of collaborative, web-based, multi-user capabilities and yet as a profession we still struggle to bring projects in successfully under the triple constraint of cost, time and scope.
A previous survey carried out by Bull Computer systems showed that 57% of projects failed due to inadequate communication and 39% failed due to poor scheduling. Similarly, well publicised reports such as the Standish Chaos Report all list pessimistic statistics and multiple causes of project failure.
From a project management perspective, my theory is perhaps somewhat more straightforward. I stand behind the belief that there are only two root causes of project failure:
While, perhaps these causes initially sound very obvious, in reality they are hard to dispute. It's really all about successfully "planning the work" and "working the plan"…
Let's now consider how to overcome this first cause of failure.
Critical Path Method (CPM) scheduling is the de-facto standard for scheduling projects. Estimating durations, sequencing work and assigning resources are all common steps in creating a CPM schedule. Yet all too often, the end result is a plan that is either unachievable or unrealistic.
One of the major pitfalls when creating a project plan is to jump straight into the development of the planned work (activities) rather than adopting a more formal, top down approach which tends to be more successful, of defining the project objectives, elaborating scope definition, expanding out the deliverables and Work Breakdown Structure (WBS) and then, and only then, start to detail out the work (activities and resources) required to satisfy these deliverables.
A well-developed schedule should be able to be rolled up through a WBS to show the entire scope of the project with the underlying work required encapsulated as activities. All too often, project plans omit this formal structure which then leads to inevitable scheduling challenges.
Scheduling has historically been a deterministic science. That is to say, activities have had definitive durations assigned, single-point cost estimates and so-forth. With the advent of risk analysis, such an approach is being replaced with non-deterministic estimates that combined with risk analysis techniques give not only forecasted completion dates, but more importantly give confidence levels as to how realistic these completion dates are.
The term "Risk Analysis" tends to portray impacts from risk events such as weather, mechanical failure etc. In reality though, most risk regarding project success is actually driven by poorly defined scope. In my experience, I have discovered that 75% of the risk exposure within projects actually comes from scope uncertainty and not discrete risk events captured in a risk register. While this is a huge percentage, it is actually good news from a planning perspective as scope definition is typically easier to handle and reduce than external risk events. Again, further proof that a sound project plan needs to be closely tied to a well defined scope definition.
Not only does this certainty-based scheduling help with pinpointing problematic areas within a project, it also gives the project execution team a range of dates to target rather than being setup for failure against a single date.
Sitting in a recent project review meeting, I experienced a project manager requesting a copy of the project plan. When the lead project scheduler provided their 5,000+ activity Gantt chart in a PDF file, the response from the PM was
yes, that's great but where's the one the team as a whole can understand. This is indicative of how schedule's can be overwhelming to project teams.
Project schedules are designed to capture as much information as possible but in doing so they quickly become hugely complex and unwieldy. Anyone that has tried to determine the paths between say two milestones in a schedule will know first-hand how difficult this can be. To compliment Gantt charts, what is needed is a means of summarising or grouping key activities, yet still retaining the underlying sequence of work.
Similarly, when analysing a project looking at cost, schedule, risk and performance, it is much more valuable to be able to do so by selecting groups of activities. These groups may be disciplines, locations and type of work as well as different phases within the project. Having an insight into the scope and associated performance of a project by time phase and by discipline is much more valuable than looking at these metrics averaged out at the project level. This matrix-type of project analysis is an area that is gaining significant traction and one that is hugely valuable to a project team.
The ultimate objective of developing a project plan is to have a target against which to track performance. Over the years, numerous types of analysis techniques have been developed to try and determine project performance. However, I still go back to the two fundamental causes of project failure. Wouldn't it be more useful if we could correlate the fact that poor performance in a specific area of a project was actually due to unrealistic planning? In other words, pinpoint the planning weakness so that it can actually be addressed!
Project metric analysis goes well beyond just applying formulas or calculations such as "Total Cost Overrun" or "Number of Activities with Missing Logic." Instead, metric analysis combines formulas with thresholds or trip-wires that give meaning and context to the results from the formulas. Does knowing we have "fifteen open ended activities" or "five missed deadlines" really tell us anything meaningful? Wouldn't it be more useful to know the impact of the open ended activities and the cost and schedule implications of the missed deadlines? What if all five missed deadlines were only a day late on a three year project? In this example, it's arguable as to whether such exceptions should even be reported.
The likes of the Defense Contract Management Agency (DCMA) are now publishing such metrics and trip-wires as a means of standardising schedule quality checks as well as setting standards for contractors to aim for. Such initiatives are a welcome breath of fresh air to scheduling and I expect to see similar initiatives across multiple industries in the near future.
Maintaining an up-to-date schedule is a difficult enough task during the planning phase of a project but it becomes infinitely more involved during execution.
During the planning phase of a project, scope invariably tends to be somewhat fluid which in turns results in the required work also being somewhat of moving target. During execution, even in an ideal world of locked down scope, keeping track of actual performance and reflecting remaining work in a schedule can be very challenging and often muddies the true picture as to how well a project is performing.
To overcome this reporting challenge, project trending can give a much more useful indication of performance than simply looking at a single snapshot in time. Knowing a project is ten weeks behind schedule tells us absolutely nothing regarding whether our performance is improving enough to claw the delay back or even worse, if our performance is deteriorating, how much further delay can we expect? With the proper use of a comprehensive metrics analysis tool, this can easily be overcome.
Many projects have done a good job of tracking performance trending during execution, but few actually track trending during the planning phase. Relating back to the first root cause of project failure, project planning is often an iterative process and as such, there is massive value in also running trending analysis against the quality of a plan during the planning phase.
The second identified cause of project failure was the inability to execute according to a given plan. I believe the solution for the second identified cause of project failure is actually more tied to solving the first identified cause! If indeed we can successfully plan and forecast the work that is required for project completion and this plan then accurately accounts for uncertainties, complexities and risks that may occur during project execution, project failure will then be a thing of the past.
Such a scenario is of course the perfect case, but by adopting the practices described above, we are aligning ourselves more for project success than accepting project failure.
With over fifteen years of experience, Dr. Dan Patterson, PMP is recognised as a global thought leader and visionary within the project management industry. With a focus on project analytics and risk management, Dan has a highly impressive track record with a unique combination of product management skills combined with extensive commercial and technical project management experience.
Dan specialises in the areas of project analytics, risk management, scheduling, estimating, earned value and artificial intelligence. This experience has been used to lead and manage business development, sales teams and corporate growth within the PPM industry for several PPM companies.