I’ve been tracking down examples for project failure, mainly in the UK, and Tom “Bald Dog” Varjan contacted me with some reasons why he thinks projects are unsuccessful. His points are really interesting, so I thought I’d share them with you.
Tom’s business cards introduce him as “Bald Dog, Organisational Provocateur,” so I’m sure that gives you a mental picture…
“In my experience,” Tom says, “project management usually fails on people. They are subject matter experts, but they are not wholeheartedly in the project team.” It’s uncomfortable to hear that sometimes we are the problem instead of the solution, but we ought to acknowledge our role as project managers in the 71% of projects that fail.*
According to Tom, project managers have “amazing documents, Gantt charts and spreadsheets to track milestones and critical paths, but they often go down the drain for people.” Project managers “know what to do and how to do it, but there are commitment and accountability problems.”
Tom has seen plenty of project action. Since 1994, he has helped companies with business development issues, including how they manage their projects. He has worked with Boeing, Seagate and British Telecom, as well as on the challenges posed by Y2K in hospitals and with some 150 smaller companies. His journey has taken him from Hungary to the UK to Canada, where he now runs a consultancy company.
Tom believes that the problems stemming from unsuccessful projects are often caused by the fact that the project team is not a team but merely a collection of individuals with personal agendas.
He explained to me the four main reasons for this:
- There are expectations but no clearly defined consequences of not living up to the expectations. There are no implications for breaking accountabilities and commitments. These are just accepted as factors to delay the project. “When I manage projects,” Tom says, “failing accountabilities and commitments result in specific number of shifts at the local temporary labour agency doing hard contraction labour. I don’t believe in firing people but I do believe in punishing them for their broken commitments. Also, I believe in punishing people only for activities they can control.” He points out that in the army, people don’t get punished for losing battle. They get punished for refusing to fight.
- Rewarding the individual instead of rewarding the team. “For the project, the project team should receive a lump sum of money,” Tom explains, “which the project leader distributes among team members as s/he sees fit. Individual rewards create individualism and kill teamwork. I normally offer equally pay for everyone. The Project manager takes double.” I don’t agree with Tom on this point: financial rewards for project teams put people who don’t work on projects, but still contribute to the success of the business, at a disadvantage. However, I do agree that ‘rewards’ help motivate a team and at the end of a project can help achieve closure for the people who have invested time in the project. The end is a moment to celebrate successful delivery. Personally, I do this with food, but if your project has the budget for cash bonuses, it is something to consider.
- Most project managers are subject matter experts but don’t understand how to co-ordinate people to work together in a collaborative and collegial atmosphere. “They don’t know how to create a culture of energy, excitement, enthusiasm, passion and dedication,” Tom says. “What we have to understand is that we can manage project only with people who are ready and willing to play the game.”
- Instead of narrow specialists, Tom prefers to have cross-trained “deep generalists” on the team. “I want the project team operate with the effectiveness of a military commando,” he says. “If someone falls ill or has an emergency, almost anyone can jump in. The time frame will stretch, but there is no actual interruption in work.”
This is all food for thought for us project managers, and if you’ve found yourself saying, ‘Yes, I agree!’ you might enjoy reading his blog.
I think project managers are often quick to blame the team, the politics, the users or anyone else for project failure – except themselves. Perhaps we should start looking more critically at what we do, and really acknowledge the part we play in screwing things up.
*Standish Group figures