Introduction
Every organization has its share of “runaway projects”—some have more, some have less. Most runaway projects share common root causes for failure—an ill-conceived business case, an all-or-nothing “big bang” approach, and a tactical focus on incremental functionality rather than the long-term commitment necessary to make multi-year strategic initiatives successful.
Symptoms of runaway projects are easy to identify: late deliverables, budget overruns, angry customers, “need it now” attitude (without a clear definition of what “it” is), or demoralized staff working in “hurry up and wait” mode with no end in sight. Milestones get missed, budgets go “bankrupt,” and projects fail to deliver promised results. In most cases, there is no single problem, and no “silver bullet” solution.
Exhibit 1 – Causes of Runaway Projects
Rescuing runaway projects, or better yet, making projects successful from the get-go, is not difficult if project managers and steering committees stick to three basic principles: (1) micro-management of the project plan, (2) frugal management of the budget, and (3) ruthless management of scope (and quality).
Once it is understood why a project has gone south, steering committees can put in place a few simple measurements that will allow for early identification (and resolution) of problems. And by making clear the criteria against which project managers will be evaluated, steering committees can ensure that, at a minimum, the highest risk areas of the project are receiving enough attention.
In other words, “what gets measured will get done.”
Micro-Management of the Project Plan
Good project managers know how to build a project plan and understand the concepts of scope, schedule, and budget. But good project managers often cannot step back from the day-to-day details to see how the project is progressing in the broader context. Here is where steering committees can provide value to a floundering project. By taking a holistic, top-down approach to project oversight, they can reality-check project plans to ensure they are realistic, executable, and on-track.
Project managers will initially resist the “big brother” nature of this oversight as bureaucratic and unnecessary. However, with a small amount of structure early in the planning process, project managers can create a set of easy-to-report metrics that will engage steering committees to the right level of detail without their having to pour through dozens of pages of tasks and issues.
Four Dimensions for Better Project Governance
Better governance starts with standardization of project plans around four dimensions that will provide a structural framework across multiple projects (or sub-projects), regardless of how the detailed activities have been organized. These four dimensions are:
- Release - decomposes large projects into smaller releases that are easier to manage and deliver. Also can be used to roll-up several projects into one larger, coordinated release.
- Functionality Group - defines a logical piece of business functionality from the end-user's point-of-view. A sub-dimension for “functionality detail” can be added if more granularity is needed.
- Team - identifies groups responsible for delivering the elements of work, to allow managers to separate team-based project plans without losing the end-to-end view across all groups.
- Phase - maps individual tasks from each team and functionality group to phases of the project methodology being used (e.g., A-Strategy, B-Requirements, C-Analysis, D-Design, etc.)
Reporting on these four dimensions is simple with the addition of four (or five) similarly named custom text columns to a project plan. Project managers need to populate these dimensions for all tasks in all separate files that will be rolled-up into the overall plan. Admittedly, this will add administrative overhead to the project, especially during startup. Here it cannot be overstated the value of a good project administrator or project office (depending on project size) that will manage the detailed plans and turn them into managerial reports.
Beyond Gantt Charts
Functionality exists in Microsoft Project to do “critical path,” “late tasks,” and other traditional status reporting. However, experience has shown that Microsoft Excel, with its pivot tables and graphing wizards, provides far greater analytical and presentation functionality beyond the standard tools of Microsoft Project.
A custom export can be set-up to save the detailed project plan (including the four or five additional columns) as a comma-delimited file. Once in Microsoft Excel, project managers can use the full analytical toolkit to better understand the project holistically. New governance metrics, overlaid on the detailed Gantt charts and task-based reports, will provide managers and their steering committees additional tools to understand project complexities and, hopefully, resolve conflicts more quickly when they arise.
Project Planning Rules-of-Thumb
A few guidelines to help keep project plans from straying too far off-target:
- One Week Tasks – work-streams will vary in size and duration of tasks, making comparisons difficult. Setting a standard task size of, say one FTE-week, will help balance work across disparate activities.
- Rule of Thirds – well-balanced work plans are comprised of equal parts design (including business requirements), development, and testing (including rollout).
- Stage Gates – formal checkpoints set at logical milestones (e.g., end of phase, key thresholds met), with management sign-off and possibly even funding tied to completion.
- Work Backlog – the simplest and perhaps most accurate measure of project health. A large backlog indicates (a) poor planning, (b) poor execution, (c) greater-than-expected complexity, or (d) insufficient resourcing. All are risk factors that demand steering committee intervention if they persist.
Project Plan Governance Metrics
Here are some simple reports to help project managers and steering committees quickly identify where to focus attention. Using the four project dimensions allows for easy drill-down and reporting by release, functionality group, phase, team, or any combination of dimensions (Exhibit 2).
- Due vs. Done Backlog – amazing how frequently this fundamental concept of project management is overlooked. Managers cringe when first asked to report the number of tasks due each week vs. the number of tasks done. But backlogs can grow out-of-control in no time and must be monitored closely.
- Stage Gate Status – highlights the cascading nature of deliverables and their up-and-downstream dependencies. Stage gates identify risks to key milestones and encourage steering committees to bring additional resources to bear earlier in the process.
- Late Tasks – a simple drill-down report to identify tasks that are due, but have not yet been completed. Steering committees should regularly review this information (by team, functionality group, phase, and release) with project managers to ensure downstream dependencies are not hindered.
- Reality Check – most useful at the beginning of the project, these summary metrics analyze the thoroughness of the project plan across the four dimensions. Managers should look for deviations from the project planning rules-of-thumb, and drill-down as necessary where plans are lacking.
Exhibit 2 – “Due vs. Done” Project Schedule Graphs
Frugal Management of the Budget
Steering committees must accept fiduciary responsibility for how their investments are being spent. Plain and simple, it is this committee's obligation to ensure the project is meeting the “I” part of its “ROI” obligation. Those that fail to take action (e.g., escalate conflicts, adjust scope, remove project managers) when budgets are exceeded and key milestones missed are just as responsible for a project's failure as anyone else, and just as accountable for getting the runaway project back on track.
Budget variance is the most basic and objective measurement of how well a project is being managed, as budget anomalies usually foreshadow deeper managerial problems. The simple metric of project actuals vs. budget should be discussed and closely tracked at every steering committee meeting (if not more frequently). Variances in and of themselves are not necessarily bad, but unexplained variances are definite red flags that warrant more detailed investigation.
Seasonality – The “S-Curve”
Good budgets are derived from the ramp-up of resources and the timing of specific capital purchases as defined by the project plan. Bad budgets are “flat-lined” (equal monthly spending) and never revisited once the project has been green-lighted. With a good budget, variances become meaningful and give both the project manager and the steering committee an early warning to problems that may require their intervention.
Once the full team has ramped-up, delays or increases in spending for any particular area of the budget will signal unexpected changes to workload. Managers must be able to explain why resources are being drained from the project and what will be done to make up for lost progress. Failure to do so can send spending out-of-control as on-time teams find themselves waiting (at full “burn-rate”) for other teams to catch-up.
Exhibit 3 – The “S-Curve”
Resource-Based Project Planning
Another important budget variable, closely related to financials, is resource utilization. Hastily planned projects usually lack an appropriately balanced resource plan. Task lists get compiled—sometimes with resources, sometimes without—and critical dates established before resources are committed to the project. Then, with the task-based project plan promising delivery on a certain date, few project managers will have the gumption to inform their steering committee that they may have underestimated the workload by a long shot.
For team members to be effective, project managers need to give them well-defined tasks to work on. Failure to match workload with resource load indicates an unfocused team working towards unclear deliverables—basic ingredients for schedule slippage and budget overruns. Conversely, project plans with more tasks than resources in any given period are sure to miss their deliverables.
Where steering committees typically fail on this dimension is in holding managers accountable for explaining their variances. Project managers must not be allowed to justify early variances as “unplanned seasonality,” for this will ultimately result in budget overruns when delays are experienced later on. A simple metric comparing the resource plan (in FTE weeks) against the number of FTEs actually charging time to the project will help control this risk by forcing managers to adjust their resource and spending plans as the project evolves.
Staffing the Project
Resourcing depends on two criteria—(1) the project's importance, and (2) the depth of the talent pool. The biggest resourcing risk to a project is the number of simultaneous activities any given team member is working on. Those working on more than three projects at a time are likely to be a bottleneck rather than an asset, with switching cost (between projects) and administrative overhead cutting into value-added work and forcing schedule trade-offs to be made.
Managers should push for resources that can be separated, as much as is realistic, from their day-to-day work. To the steering committee, resourcing can seem like a major-league draft, with different managers vying for critical people and trading “future draft picks” to get the right folks on their projects at the right time. Unfortunately, no one ever seems to be available when needed. Project managers need to escalate, and steering committees need to support this escalation, any time outside influences ask for “a special favor just this one time.”
This doesn't mean that project managers shouldn't provide support for other company priorities; they just need to understand the impact that a couple of hours here and there will have on their delivery timeline.
Budgeting Rules-of-Thumb
A few guidelines to help keep budgets from straying too far off-target:
- Resource-Based Budget – make sure spend rate is tied to resource ramp-up and activities in the project plan can be mapped to the budget. Budgets should follow an “S-curve” as resources are added at the beginning and rolled-off at the end.
- Venture Funding – take a cue from venture capitalists and commit to funding the project in phases based on the team's success in meeting key deliverables.
- Managing The Variance – demand that managers give sufficient explanation for variances and investigate areas where variances are not well-understood
- Fluid Forecasting – forecasts need to be adjusted whenever changes are made or new information is uncovered that will impact spending vs. original budget.
Project Budget Metrics
The same four dimensions used to develop the project plan can be used to drill-down into the financials as well. Some financial metrics that steering committees should be tracking are:
- Actuals vs. Budget and Forecast – be able to explain spending variances by team, functionality group, and phase, as over- or under-spending in one area could signal a drain of resources from another area.
- Burn Rate – a good indicator of whether or not a project is progressing as it should. Large positive variances mean either the budget has been “sandbagged”, or worse, work is not getting done.
- FTE Utilization vs. Actual FTE – measures how well the project plan has been resource-balanced, and how well project managers are adjusting their plans to match actual workload.
- Resource Focus – measures the number of projects each team member is working on, by team and skill set. Managers need to make sure their team members are not getting pulled in too many directions.
Ruthless Management of Scope (and Quality)
“Scope Creep” and poor quality are the bane of project managers. Scope management is one of the few areas that steering committees routinely engage in, as scope is most relevant to them. People will be happy to argue endlessly about what is “in” and what is “out”, whether there should be “top bar” or “side bar” navigation, whether “horizontal scrolling” is better than “vertical scrolling”, and on and on. Ruthless scope management requires that project managers force stakeholders to pare their wish lists down to a bare minimum, and keep the project team focused on only that which will be implemented in any particular release.
100% of 30 Things is Better Than 30% of 100 Things
Project managers can use the “eye doctor approach” to prioritize scope. Eye doctors use their contraption with the interchangeable lenses to zero-in on a prescription. “Which is better—A or B? B? O.K., now which is better—B or C? Both? It can't be both, you have to pick one…” So it should be with scope management. “What do you need—A or B? Both? It can't be both if you want the project to finish on-time…”
Managers risk falling prey to scope creep if they are not ruthless in their prioritization and change control procedures. By taking on too much scope, they may not be able to finish everything on time and will end up delivering nothing of value by the committed date. Full functionality for a subset of items (if properly prioritized) will deliver value earlier in the process, whereas partial functionality for a larger set of items won't deliver value until all work has been completed.
Granular ranking and re-ranking of scope should be done on an on-going basis, but once scope items have been designated for a release, they should not be changed without formal review by a change control board. All stakeholders, no matter how senior they are, must respect this process.
The Impact of Poor Quality
People will forget when a project comes in late (as long as it is not too late). People will forget when a project is over budget (as long as it is not over by too much). People might even forget that they got less functionality than originally asked for (as long as what they get solves their needs). But people will neverforget, let alone forgive, a project that delivers a poor quality product which makes their jobs more difficult. Even after all the kinks have been fixed, projects will be long remembered for how well (or poorly) things work.
Quality rarely gets the same level of attention as scope, schedule, and budget. Because testing comes last in the development process, quality suffers from all the scope changes, schedule delays, and budget adjustments made earlier in the project. Project managers and steering committees need to ensure that quality is ruthlessly managed, and that corners do not get cut in the testing, training, and pilot/rollout phases to make up for scope creep and other project delays.
Scope and Quality Rules-of-Thumb
A few guidelines for ruthlessly managing scope and quality:
- Prioritize Scope – using the traditional high, medium, and low categories is not enough. Forced ranking of scope items from one to N allow managers to be specific when determining which items to cut.
- Give and Take – with a finite budget and strict delivery schedule, every addition of scope must be balanced with something else being taken off the plate.
- Test Coverage – important to track more than just the absolute number of test cases. Managers must ensure that all elements of functionality are sufficiently tested, and that defects can be traced back to business requirements.
- Prioritize Severity – prioritization is key here. Not every bug is a showstopper, and managers must be willing to accept some breakage (i.e., non-critical defects) to guarantee that all critical defects get fixed.
Scope and Quality Metrics
A few basic metrics will focus attention on quality management (Exhibit 4):
- Test Cases Planned vs. Run – tracks testing activity similar to the tasks “due vs. done” metric. Failure to execute test cases in a timely manner indicates either insufficient resourcing or poor initial quality, both of which will adversely impact the finished product.
- Failure Ratio – provides further drill-down analytics of where testing is finding errors and where additional development or rework may be necessary.
- Defects Backlog – new and open defects by severity for each team, functionality group, and release. Drilling-down by status of each defect (e.g., analyzed, constructed, resolved) and time-to-resolution will help managers understand how difficult it will be to get the defects under control.
These are easy metrics to track and report on. Project managers can compile meaningful reports on scope and quality from whatever requirements and defects tracking system they are using for their day-to-day work.
Exhibit 4 – Defects Backlog
Results
The author has used this methodology numerous times for different companies in different industries to help steering committees stabilize failed projects and launch new projects on the road to success. At first, the methodology can be intimidating, and project managers will typically go through a few stages—resistance, then compliance, then ownership—before ultimately embracing the methodology. Steering committees must commit to engage in the details and stick with the methodology until a metrics discipline has become second nature.
Once teams understand and accept the value of the metrics, they will work harder and more focused than ever before towards their goal. Success begets success, and with project success comes more focus, more pride, more creativity, more discipline, more momentum, and more excitement. Often, that's all it takes to rescue a runaway project.
End Notes
The opinions expressed in this paper are those of the speaker and do not necessarily represent the opinions or policies of Liberty Mutual Group.
All project data is sanitized for illustrative purposes only.