Check the Technique

Davidson Frame, in his 2003 book Managing Projects in Organizations: How to Make the Best Use of Time, Techniques, and People, argues there is good reason for a preoccupation with technique: It is readily teachable. But he too warns that this focus on technique distorts our view of what happens on projects. After all, projects seldom fail because people do not know how to employ advanced project scheduling and budgeting techniques, he says. Rather, they come unglued thanks to unrealistic deadlines imposed by top management, or because project staff lack necessary skills, or because lack of leadership led to aimlessness in project implementation.

Worse, an over-reliance on a stepwise methodology can be dangerous. In fact Bruce Webster, principal at US-based Bruce F Webster & Associates, fears that some organizations have adopted a kind of "cargo cult" mentality about project methodology. There are plenty of tools and procedures for project administration, but too few organizations recognize that these can only help detect problems and failure, not ensure success. So everyone sits around and "worships" the various diagrams without realizing the gulf between the map and the territory or between the methodology deliverables and the working software, he says.

There is in fact no shortage of books on how to get people to do the things that need to be done, Webster notes. On his shelves alone are Peopleware by DeMarco and Lister, Constantine on Peopleware by Larry Constantine, On Becoming a Technical Leader by Gerry Weinberg, The Journey of the Software Professional by Luke Hohman, and numerous others. Yet most IT project managers have never read these books and do not understand the principles involved, Webster believes. And even where they have, there is a big gap between theory and practice.

Webster should know. He was thrust into the position of project manager 15 years ago, and says he "struggled horribly", both because he did not have the team-leading skills he needed and also because he was trying to serve as chief architect at the same time. "While I grew into it and developed many of those skills, though not without some struggles along the way, I received help from two different sources," he says. "First, I had some critical help from several of the developers. Second, about 18 months into the project, we hired a VP of engineering who had excellent project management and personnel skills."

Webster says one key problem is that the project manager is typically either a developer who has been promoted out of hands-on development into project management, as if one set of skills translates into the other (it doesn't, he says, speaking from personal experience), or a manager with no real IT background or team-leading skills. As such the newly inducted project manager can do the charts and graphs but cannot actually lead and motivate the development team, nor verify the truthfulness of developer's claims.

Just as typically, roles and responsibilities are neither clearly defined nor signed off, and many people drafted to project teams still have functional responsibilities, with implications for stakeholder management, says project management consultant Lizz Robb.

"When we look at projects - we've worked in a major pharmaceutical group, working across global sites - the people involved often had functional work to do as well. So what would get done would depend on where the rewards were coming from," she says. Where a person's performance bonus was based on functional work, which was clearly sponsored by the business, that sponsored work would inevitably get done ahead of the project work, she says.

Yet while awareness of the weakness in project management is growing, so far there is little evidence of things getting much better. In CIO's State of the CIO survey 2006, CIOs said they spent almost half their time leading projects. Project management was the number one skill set they believed they would need from new hires, while the biggest barrier to their effectiveness was an overwhelming backlog of requests or projects. Yet project management improvement came only fifth of their top five technology priorities for 2006, behind integrating systems and processes, strategic planning and alignment, external customer service and relationship management, and lowering costs/meeting budgets. And asked their top five IT management priorities for 2006, improving project management discipline did not even make the list, coming only ninth on a long list.