« Power: The Functional Manager’s Meat and Project Manager’s Poison?
Scrum Product Developer Role and Responsibilities »

The Role of Decision Dynamics in Project Management Failure

February 6, 2009 | Author: PM Hut | Filed under: Project Management Musings

The Role of Decision Dynamics in Project Management Failure (#7 in the series Decoding the DNA of Failed Technology Projects)
By Robert Goatham

In large part the Project Manager’s role has traditionally been seen in terms of planning and control. While that is true at one level, the Project Management role is also about orchestrating the team’s decision making. By establishing the team, defining processes, planning roles and responsibilities, and facilitating meetings, the Project Manager plays a significant role in orchestrating the decision making occurring within the team.

Successful orchestration requires Project Managers to be in tune with the dynamics beneath the surface of the project. While Project Managers may not be experts in the technology in use and may not fully understand the project’s every detail, successful Project Managers are the ones who have developed a sense for whether or not the team are making effective decisions. By listening to how the team communicates and watching the interactions between individuals, groups and stakeholders effective Project Managers are able to keep their finger on the pulse of the project.

A contributing factor in many project failures is that no one is directly aware of this level of interaction. Project Management in many cases has unfortunately become the simple task of delegation. Tasks are doled out to team members, but there is no subsequent monitor of the project’s heart beat to see if the project is functioning in a healthy and sustainable way.

Preventing such failures requires Project Managers to be able to identify when dysfunctional decision making is taking place. Despite decision making’s central role, few training programs explore the dynamics that influence how decisions are made in real world settings. Affected by politics, personality type, culture, organizational structures, contractual obligations and many other factors, it’s something that can be a complicated story. However knowledge is everything and by training Project Managers (and all those who hold leadership roles in project environments), many of the most common dysfunctions can be not only identified, but also cured.

The starting point for recognizing dysfunction lies in learning to see the symptoms. Many of the floundering projects I’m asked to review are riddled with symptoms. Many are quite apparent, but oftentimes the Project Manager is either not aware of the symptom or doing little to find out what is causing the problems. Among the more readily identifiable symptoms are;

  1. Prolonged indecision
  2. Excessive volatility
  3. Extremely high numbers of open decisions
  4. Lack of clarity (resulting in confusion over the outcome of critical decisions)
  5. Decision fragments (decisions in which some of the who, why, where, when and how components have been made, but others have not, resulting in confusion, inaction or other secondary problems)

Other symptoms are more subtle and require an experienced eye. In many such cases, seeing what’s not happening is more important than seeing what is happening. Common examples include sensing when groups who ought to be collaborating closely are not communicating and seeing that questions that really ought to be asked are not being asked.

Another barometer of project health lies in looking at the number of options the team has considered when making critical decisions. As a general rule, better decisions come from evaluating a number of options and many blunders can be traced to a pattern of behaviour I call “first option adoption”. One of the hallmarks of expertise is the ability to rapidly generate alternative ideas about how to solve a problem. Unhealthy projects often lack that ability and rather than considering alternatives, the first option thought of becomes the only option thought of. Teams using such an approach are unlikely to be lucky enough to identify the best option first time, every time, and first option adoption is a pattern of behaviour that is deeply rooted in many project failures.

Robert Goatham is the principal of Calleam Consulting. Robert founded Calleam in response to the on-going challenges organizations face in developing the leadership skills necessary to successfully deliver today’s complex technology projects. Specializing in the study of failed projects, Robert translates hindsight from yesterday’s projects into the foresight needed to ensure tomorrow’s success. Robert has more than 20 years experience in the technology sector playing roles that include developer, technical lead, architect, quality manager, coach and senior project manager. As a public speaker, writer and trainer Robert provides audiences with insights that go beyond the theory of a text book and speak directly to the challenges people face in today’s workplace. Robert is passionate about helping organizations and individuals develop their skills. Visit www.calleam.com for more information.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Friday, February 6th, 2009 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Project budgets should allocate time for making decisions. If members of the project team take their time over making decisions, much of the “first option adoption” problems could be prevented.

Tony G wrote on January 17, 2012 - 9:15 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories