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.
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:
- 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.
- Structural complexity this relates to the governance, authority, sign off processes that the project must comply with.
- 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.
- 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).
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:
- Is the technology unique, unique to us, or well known?
- Have we undertaken this type of work before, or engaged experts who have done this before?
- Is the solution new to our environment, something similar has been deployed before, or the actual solution has been deployed before?