This Guest paper was originally published on LinkedIn in May 2016.*
It is reproduced here with the permission of the author.
Copyright Craig Imlach © 2016.
Published here April 2017

Introduction | Project Tradition | Elements of Change
Validation of Assumptions and Estimates | Constraints and Business Rules | Postscript

3. Elements of Change

At the most basic level a business change has three elements that need to be considered: People, Process and Technology. In a business process reengineering project the driver is "process"; in an organizational restructure or new team the driver is "people"; and in a technology refresh the driver is "technology". Basically these projects are evolving the current known environment and therefore clarity of requirements can be achieved. An "evolution" project has one element that drives the change with the other elements adapting to driver requirements.

A "transformation" project has two elements trying to drive the project; hence achieving clarity of requirements is difficult early in the project. An example is the introduction of new or significantly changed business process supported by the introduction of a new technology. One leading indicator of a high risk of failure is where a "transformation" project is following the "engineering" tradition of seeking clarity in the early stages of the project.

4. Complexity

Complexity in a project is one of the most significant factors in determining the likelihood that a project will experience considerable difficulties, and is a primary candidate to be a "black swan" project. There are fours areas of complexity that must be assessed:

  1. Organizational complexity — this is assessing the organization structure that the project will be deployed into, if there are multiple areas that reports to differing managers the environment is complex and will require careful management.
  2. Structural complexity — this relates to the governance, authority, sign off processes that the project must comply with.
  3. Project complexity — the project is made up of a large number of elements, work packages, and work streams with a number of cross dependencies between them.
  4. Technical complexity — whether the technical environment and technical design is straightforward and easily understood or that they are complicated and not well known.

A project can easily cope with a single element of complexity and possibly two elements, but in excess of two you can almost guarantee problems. Complexity works as a multiplier of risk. For example, say each element of complexity has a failure risk factor of 5%, then one complexity element in a project will increase the likelihood of project failure by 5%; two elements will increase the likelihood of failure by 25% (5 x 5); three elements of complexity will increase the likelihood of failure by 125% (5 x 5 x 5); and four elements will increase the likelihood of failure by 625% (5 x 5 x 5 x 5).

5. Uniqueness

Uniqueness is simply about: "Have we done this before in this environment?" The more unique the solution the greater is the risk of failure. The three areas for assessment are:

  1. Is the technology unique, unique to us, or well known?
  2. Have we undertaken this type of work before, or engaged experts who have done this before?
  3. Is the solution new to our environment, something similar has been deployed before, or the actual solution has been deployed before?
Project Tradition  Project Tradition

* http://www.linkedin.com/pulse/project-failure-my-leading-indicators-craig-imlach?trk=mp-reader-card
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page