Project Managers

The Project Management Social Network | Project Manager Jobs

All projects are equal but some are more equal than others (or was that animals?[1])!”

In reality each project is uniquely different and therefore project management cannot be a one-size-fits-all process or discipline. The PMBOK® Guide makes this clear in Chapter 1.

There are at least 4 dimensions of a project:

  • Its inherent size usually measured in terms of value;
  • The degree of technical difficulty (complication) involved in the work;
  • The degree of uncertainty involved in defining its objectives; and
  • The degree of complexity of the relationships within and around the project.

 

Project Size
The size of the project will impact the degree of difficulty in achieving its objectives but large projects are not necessarily technically complicated or complex. There are projects in Australia to shift millions of cubic meters of overburden from mine sites with expenditures rising to several $million per day but the work is inherently simple (excavating, trucking and dumping dirt), and the relationships in and around the project are relatively straight forward. The management challenges are essentially in the area of logistics.  Size is straightforward and most organisations have processes for assigning more experienced project managers to larger projects. What’s frequently missing is consideration of the other three aspects discussed below.

 

Technical Difficulty (degree of complication)
Complicated high tech projects are inherently more difficult to manage than simple projects. The nature of the technical difficulties and the degree of certainty largely depend on how well understood the work is. The important thing to remember with complicated work though is that systems can be developed and people trained to manage the complications. The work may require highly skilled people and sophisticated processes but it is understandable and solvable.

 

Uncertainty

The degree of uncertainty associated with the desired output from the team’s endeavours has a major impact on the management of the project. The less certain the client is of its requirements, the greater the uncertainty associated with delivering a successful project and the greater the effort required from the project team to work with the client to evolve a clear understanding of what’s required for success. This is not an issue as long as all of the project stakeholders appreciate they are on a journey to initially determine what success looks like, and then deliver the required outputs. Budgets and timeframes are expected to change to achieve the optimum benefits for the client; and the project is set up with an appropriately high level of contingencies to deal with the uncertainty. Problems occur if the expectations around the project are couched in terms of achieving an ‘on time, on budget’ delivery when the output is not defined and the expected benefits are unclear. Managing uncertainty is closely associated with and influences the complexity of the relationships discussed below.

 

Complexity: The People, the relationships and the degree of interconnectedness
Complexity Theory has become a broad platform for the investigation of complex interdisciplinary situations and helps understand the social behaviours of teams and the networks of people involved in and around a project as well as highly interconnected systems. A degree of complexity is inherent in small in-house projects as well as large complicated programs. In this regard, complexity is not a synonym for complicated or large. It focuses on the inherent unpredictability of outcomes in complex systems, including people’s actions and reactions to ideas and information within the network of relationships that form in and around the project team.  Complexity is very much an emerging area of thought and discussion. For a brief overview see: A Simple View of ‘Complexity’ in Project Management  and for some practical considerations of the impact of complexity theory on scheduling see: Scheduling in the Age of Complexity.

 

 

The interaction of uncertainty and technology (or process)

Knowing both ‘what to do’ and ‘how to do it’; or more importantly knowing how much you know about these two elements is critically important in establishing a framework to manage a project.  One of the more established ways of describing projects is a typology developed by Eddie Obeng in the Project Leader’s Secret Handbook.

 

 

The typology asks two questions:

  • Are you clear about what to do (the outcome to be achieved)?
  • Do you know how to do it (processes, methods, experience)?

 

From the answers, four options are possible:

 

Painting by Numbers
Traditional project management works well when both ‘what’s to be done’ and ‘how to do it’ are well understood by all key stakeholders including the client and the project team. Closed projects (panting by numbers) can be fully defined, estimated, planned, etc. There are low levels of uncertainty and ambiguity; risks are largely known and manageable. Value is largely achieved by delivering the requirements on time and on budget. A typical software project of this type would be installing an upgrade into an office where the same upgrade had been previously installed in several other locations.

 

Going on a Quest
In these projects, the objective is clear but the way to achieve the objective is uncertain. At the end of the day, success or failure is clear cut; the objective has been achieved (or not). The challenge is optimizing the way forward. Process and system improvement projects tend to fall into this category. The objective is to reduce processing time by 20% - this is easily measured on the completion of the project. The difficulty is determining the best way to achieve the objective. Some of the options include improving the user interface, simplifying the work flow, speeding up network traffic and processing times or a combination of two or more of the elements? Ambiguity is low - we know what’s needed, uncertainty is high - we are not sure how to achieve it.

Before committing major resources to the main work of the project adequate time has to be allowed to prototype solutions and test options before a final design solution can be determined and then implemented. The project needs to be developed in phases with go/no go gateways as the design is firmed up. There are risks associated with any creative design process and most software projects are ‘quests’ requiring creative solutions to identified problems to achieve the desired objective.

 

Making a Movie

In these projects the tools and techniques are well known but the final outcome is uncertain. Only after the project is complete can the results be measured and the success or failure of the project determined. Most culture change projects and marketing projects (and making movies) are in this category. The tools to be used including: training, communicating, advertising, etc are well known and the traditional (if not optimal) mix of techniques understood for most situations. What no one can predict is if the ‘public’ will acclaim the final result, merely accept the final result or dump the final result.

 

Traditional project management is not enough in these projects; there is a continual need to measure results, feedback information and adapt the mix of activities to optimize the likelihood of success. The key value measurement is attempting to answer the question is it worth spending more or should we cut and run? Efficient stakeholder communication and relationship management is crucial. Whilst there will be some outstanding successes (block busters) and some total flops most projects in this category finish somewhere in the middle. The art is spending just enough effort to achieve an acceptable outcome – dealing with shades of grey.

 

Lost in the Fog
I actually prefer Prof. Rodney Turner’s version ‘a walk in the fog’. This type project is a journey towards a desired new state, usually in response to a recently identified problem; for example, “we are losing market share and profits are down in xxx”. We know the problem, potential solutions range from closing the business unit to re-pricing, to changing the offering or possibly increasing market presence.

 

No one is sure of the optimum outcome, or how best to achieve it. The only option is to proceed carefully, stop at regular intervals to check exactly where you are and re-plan the way forward. Exactly the way you navigate through a thick fog. Both ambiguity and uncertainty are high.

 

Project management is about making sure at each ‘stop point’ the value achieved to date is locked in and then refocus on the next increment. Agile software development is ideal for this type of project. Each iteration builds new capability and value and the learning provides a platform for the next iteration of development.

 

Management is both easy and difficult. It is easy because there is no point in setting fixed plans (you have no idea what to plan). It is difficult because decisions on value and whether to stop or continue are subjective and need to be made in a collaborative environment of trust.

 

Traditional measures of success such as on-time and on-budget are largely meaningless; typically there are no statistics to base this type of measure on. Consequently these projects are the realm of cost reimbursable contracts and partnerships; stakeholder relationship management, and a clear understanding of value are the only effective tools for building to a successful outcome.

 

Two final thoughts

  1. Both the client/sponsor and the project team need an understanding of the type of project and agree to configure the project management processes appropriately. The more uncertainty and ambiguity, the more important the project’s client is to achieving project success! If expectations are not aligned disaster awaits.

 

  1. The skills required of a project manager change from largely technical if the project is ‘painting by numbers’ to almost completely relational to manage a ‘walk in the fog’. Selecting the right person to lead the project and relate to the client and stakeholders is crucial.

 

So next time you think about setting up a project team remember projects aren’t projects, every one is different but there are frameworks for understanding the capabilities required.



[1] George Orwell:  Animal Farm, 1945.

Views: 376

Comment

You need to be a member of Project Managers to add comments!

Join Project Managers

© 2017   Created by Mike.   Powered by

Badges  |  Report an Issue  |  Terms of Service