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.

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.

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 per cent to 10 per cent of the time. A project suffers when communication drops below 5 per cent of the time, and the benefits drop off significantly around 9 per cent to 10 per cent.

Scrum sessions should take 30 minutes, about 6.25 per cent 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 per cent), 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.