In spite of spending millions of dollars to deploy project management methodologies and tools, executives still sense a lack of control over the projects in their domain.

The CIO servicing the IT needs of a 75,000-user community complains that all he can get is summary-level green, yellow, red status reports and that the only thing he is sure of is that he does not have control.

The department manager responsible for the executive information system at one of the largest companies in the US says: “We keep breaking our projects into smaller and smaller packages to make sure something gets done, and at the end of each quarter we get lots of glowing reports, but I can’t tell what’s actually getting done. How do I get my projects under control?”

Discussing the dismal delivery record coming out of his organization, the CIO of a Fortune 25 company said: “I’ve got 110 people with the title ‘project manager’ and I don’t think I’ve got a real project manager anywhere in the bunch. How do I get my projects under control?”

One of the most common attempts to get projects under control is to break them into discrete smaller projects. Each major deliverable becomes its own project tailored to fit within a monthly, quarterly or semi-annual horizon.

This approach tends to create unnatural gaps between interdependent elements, in much the same way that an ice field connecting two landmasses becomes a dangerous ice floe if it is broken up. The openings squander the momentum toward achieving the target by burdening resources with a constant stop/start cycle. It is like trying to cross a gap in the ice by diving in the water, swimming and climbing onto a series of icebergs while they drift apart and often drift farther from the other side.

New techniques were created to manage the micro-projects along the way. Scrum, the limited-horizon, single-focus, daily-meeting-based, Agile methodology is such an invention. The key advantage a Scrum approach brings is the unchallengeable focus on a specific deliverable.

Just like any methodology, it is easy to find examples of both glowing successes and glaring failures in the Scrum community. And this is not a place to debate the merits either way. But there are two significant drawbacks to the Scrum approach.

First, there is a real risk of investing too much time in Scrum sessions. A good target for communication is 5 percent to 10 percent of the time. A project suffers when communication drops below 5 percent of the time, and the benefits drop off significantly around 9 percent to 10 percent.

Scrum sessions should take 30 minutes, about 6.25 percent of a day, which fits nicely into the optimum model — so far, so good. Theoretically, that should leave just enough time for other reviews and the management reporting that is necessary in an ideal world.

However, it is rare to find team meetings that last only 30 minutes. It is far more common to find the entire daily allotment of 48 minutes (10 percent), if not more, consistently consumed. By the time the coordination, the other the necessary reviews and reports are complete, team efficiency and effectiveness will have dropped significantly into the unproductive zone, squandering the assigned resources.

Secondly, Scrum-based implementations are subject to the same risks already highlighted above. Each iceberg becomes its own little world, drifting away and subject to tactical adjustments.

These tactical adjustments are often the result of environmental shifts like a shift in management, a key decision maker becoming aware of some new buzzword or concept, or economic and political changes. More often than not, these adjustments dilute the strategic impact that the original, overarching project was supposed to deliver.

Two decades of successful project management in IT, capital construction, engineering and aerospace have revealed three keys to getting projects under control: plug leaks, have an idea and go granular.

Plug Leaks

CIOs frustrated by project management pitfalls in Agile methodologies and techniques like Scrum will learn to plug leaks of time and costs that threaten deliverables

Projects are leaky creations. They leak time, money and specifications threatening deliverables. Those leaks have turned project management into a precious commodity. However, in reality, projects are frequently budgeted and tracked at a summary level that allows some significant leakage, both horizontally and vertically.

Horizontal leakage occurs when parallel tasks, similar to or related to their current activities, derail individuals. For example, someone working on authentication gets pulled into a series of meetings that are outside the project scope because he is an expert on enterprise security. Or a developer helps resolve an issue with the platform on which the code he is developing will run. Although these both yield a real value to the enterprise, their projects have experienced a horizontal leak.

Vertical leakage occurs when past or future projects divert resources from their funded project. An example of a forward vertical leak is project personnel taking time to prepare for the next round of funding and budgets, neglecting their currently funded activities.

Backward vertical leaks occur when current project resources are diverted to address leftover issues from previous projects. For example, an integrator diverts his attention to help track down and solve an issue with a package that will affect the reliability of his deliverable. He discovers that problems slipped in because there was no test or QA specified in the previous project plan and he takes the time to work on the remedy.

Both of these vertical leaks are the result of a poor project management methodology. A proper methodology includes pre-project planning and a rigorous test and QA suite before deployment into production. The second example also indicates either a nonexistent or an ineffective “lesson learned” process.

The key to plugging leaks is to clearly define and enforce acceptable ranges of diversion with a simple parameter like: “We believe in teamwork, so you may invest up to 15 minutes outside the scope of your deliverable; any more than that and you will need to refer them somewhere for funding.” That will protect the project from leakage and help the organization recognize and track it.