This might have been the place to recount several successful war stories, but I will spare you that pain and, anyway, I don't want to take the risk of the projects being recognized.

In an interview last year, Dr. Martin Barnes, Executive Director, of The Major Projects Association (MPA, UK), explained why many projects fail.[1]

"There are projects where failure is obvious and cannot be denied. On close examination, the chances are that they will contain at least one of four main causes of failure:

• Lack of clarity about what is to be achieved

• Too much complexity, too many interfaces to manage

• Too much technological innovation in the project

• Poor relationships and using the wrong kind of contracts between those who contribute to the project

Any one of these introduces a good chance of failure. If you have all four writ large, there is no project manager, however competent, who stands a chance of finishing the project on time and on budget and so that the finished thing works."

Well, you would think that having identified one or more problems like this it would be possible to go about fixing them. But such is not the case unless you fix the underlying causes. In 2002, Sanjiv Augustine, Director, Technology at CC Pace Systems in Fairfax, Virginia, was faced with the recovery and stabilization of a large project of over 120 people spanning multiple locations. The project was several months behind schedule with frustrated customers and dispirited developers. He and his advisory team applied six practices he designed to fix such situations.[2]

These are:

Practice No. 1 - Guiding Vision: Ensure a shared guiding vision for all team members

When a project vision is translated into a statement of project purpose and communicated to all members of the team, it serves as a shared internal model that has a powerful effect on their behavior.

Practice No. 2 - Small, Dynamic Teams: Enable interactions and adaptation through close relationships and clear responsibilities

Organizing the project into small teams implies a low interaction penalty. A team size of seven, plus or minus[3] two maintains optimal channels of communication on the team, and minimizes the effect of an interaction penalty.[4]

Practice No. 3 - Light Touch: Loosen stifling control

With traditional development approaches, everything is seen through the prism of control: change control, risk control and most importantly - people control. In the zeal to imposing more and more control, managers may forget the original purpose of control - to create order. Skilled professionals don't adapt well to micro-management.

Practice No. 4 - Simple Rules: Establish and refine the team's set of practices

[Practices] are stated and agreed to by all members of the team at the outset, [but] the team has the ability to adjust [those] that aren't working or to add new practices. [Following simple rules results] in complex behavior emerging from the bottom up over time.

Practice No. 5 - Open Information: Provide free and open access to information

The richness of the interactions between [team members] depends in large part on the openness of the information. [When] information flows freely, team members benefit from the power of knowledge.

Practice No. 6 - Vigilance: Continuously monitor and tune process structure

Leading a team by establishing a guiding vision, nurturing small, dynamic teams, setting simple rules, championing open information, and managing with a light touch is extremely challenging. With this new, powerful model of team interaction comes the risk of the team veering off the edge. In a project context, non-linear behavior can be either positive or negative and controls placed on the system can have unintended outcomes.

Sanjiv is a strong proponent of Agile Project Management, a currently favored approach to managing software development projects. However innovative these six practices might seem to the software development community, it seems to me that the value of such practices is already well established and they should be applied in every area of project management application.

Apparently, the unfortunately reality is that it isn't and they aren't.