Elements in Successful Decision Making in Project Management
Elements in Successful Decision Making in Project Management (#9 in the series Decoding the DNA of Failed Technology Projects)
By Robert Goatham
Perhaps the most critical question those leading projects need to ask themselves is whether or not they have created the environment within which effective decisions can be made. Making effective decisions requires a number of ingredients be present. Where one or more ingredients are missing many of the symptoms of dysfunctional decision making will quickly take hold.
When asked to evaluate a project I often start by using the model shown in figure 1 below. I call this model the “Decision Engine” because it captures many of the core elements necessary for project success. For each element the typical problems that arise if the project is “challenged” in that element are noted in the table.
For many projects, creating a team that has strength in all of the elements outlined in figure 1 is half the battle. My experience has been that once those elements have been established many of the other factors needed for success often fall into place. Unfortunately, most junior Project Managers aren’t directly aware of the elements and because of a lack of training and experience, struggle with the skills needed to assess their project in such a fundamental way.
In fairness to the Project Management community much of the problem lies in the broader context of the organization and the industry itself. Much of today’s Project Management training is skewed towards methodologies, managing schedule and budget and passing certification exams rather than looking at the practicalities of how projects work in the real world. That skew leaves an enormous gap between the training provided and the realities of the situation and once again those gaps are the breeding grounds for problems to sprout.
| Group | Element | Description | Effect if element is missing or weak |
| Knowledge Elements | Technical knowledge | The level of skill and knowledge the team has of the technologies and tools in use | Poor designs, low productivity, bad estimates, technical defects, technical omissions, undetected defects. |
| Business domain knowledge | The depth of understanding the team has of the business environment in which the system or project deliverables will function | Functional errors and omissions, incorrect assumptions, missing scope, undetected defects, missed opportunities, etc. | |
| Team Elements | Engagement and participation | The degree to which the right stakeholders, suppliers & team members have been engaged and their ability to put aside sufficient time to participate in the project effectively | Delays in project start up, sporadic and intermittent progress, delays waiting for key decisions to be made, volatility due to stakeholders getting involved too late. |
| Ownership and commitment | The level to which ownership of decisions is clear, the degree to which people accept that ownership and the willingness of people to make lasting commits to their decisions | Volatility, indecision, slow or intermittent progress, “not my job” syndrome, buck passing. | |
| Communications elements | Collaborative relationships | The ability of the team to work together as an integrated unit and the capacity for information to flow freely | Silos, isolationism, politics, misunderstandings, disputes, errors and omissions, gaps or duplication of effort. |
| Shared understandings | The level to which the team is able to build common understandings | Lack of clarity, confusion, rounds of “clarifications”, misunderstandings, gaps and duplication of effort. | |
| Awareness elements | Situational awareness | The ability of the team to perceive and understand their true situation and the full context in which the project is operating | Failure to see warning signs of trouble, lack of understanding of project’s true status, failure to take corrective action, simplistic perspectives. |
| Clear purpose and goal | The degree to which the team has a clear picture of what they are trying to achieve | Building the wrong product, conflicting or shifting priorities, missteps and false starts. | |
| Quality | Quality focus | The extent to which the team thinks from a quality perspective and their ability to bring that perspective to bear in the decisions they make | Poor quality, product recalls, software bugs, high levels of rework, extended periods lost investigating problems, loss of customer confidence |
| Leadership | Technical, business and organizational leadership | The effectiveness of the project’s leadership team | Lack of direction, inability or unwillingness to make the difficult decisions, lack of coordination, failure to see or address critical problems, general project breakdown. |
Many organizations also fail to build the necessary supporting infrastructure needed to ensure project success. Building a strong staff that has the communications skills, collaboration skills and background knowledge is not something that can be done the instant a new project begins. Instead, organizations need to be continually building those capabilities as an ongoing part of the organization’s management practice.
I refer to the processes organizations use to develop the skills, knowledge and capabilities projects need to succeed as the organization’s “Intellectual Infrastructure”. Building those capabilities is something that does not happen automatically and the most the most successful organizations are the ones who recognise that developing the needed capabilities requires active management leadership.
Although the temptation when a project fails is to look at the actions of the team, many failures are also strongly influenced by the practices used in the broader context of the organization.
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.
