Firstly, what is a Project?
When something needs to be done to resolve an issue or implement part of a strategy, it is best to establish a Project, that is a package of actions which happens once and has “deliverables”. The deliverables can be:
- a physical item, such as a prototype, installed and commissioned machine etc. This is common in manufacturing environments.
- a service, such as “everything needed to offer a new or revised process”.
An example from Supply Chain Management could be “all the information, authorisations etc and trained people to implement the new supply chain”.
When delivered, the new supply chain should be ready to go and have been tested.
- a change of state, for example obtaining a quality certification.
All projects contain dozens, or thousands, of little steps, each of which must be completed for the project to complete. If any of these steps are not done (or need to be repeated due to misunderstandings etc), then the project cannot be closed.
Traditionally this is represented by a PERT chart (also called Schedule Network etc) where each item represents a step that must be done.
This representation is not used to portray agile projects, but the idea is the same, even if the steps are much smaller and the priorities change according to progress. For example, if a password is needed to test a system and it is mis-communicated, then the work will be delayed.
The graphic shows this with, for example, duration estimates for each step (agile does not estimate the durations this way, but the tasks still have to be carried out in a certain sequence and need to be completed)
How do delays affect delivery dates?
Let us assume that a key decision cannot be made for several days because the person with that authority is not available. An example of this is shown with the same PERT chart example as above. Depending on how long the delay lasts, it can even dominate and cause late delivery of the project. The terminology for this is “critical path” and, as before, the effect also applies in agile project management, even though not portrayed in this way.
For the example given, the 10 day delay to get the managers’ input leads to an 8 day delay of project delivery.
Taking the example further, when 5 more days of delay happen because of a misunderstanding, such as the wrong part or document version was delivered and had to be corrected. In this particular case, the overall project delivery increases by 4 more days and the overall project suffers a 46% delay compared with the original estimate.
How accurate a model is the PERT Chart?
Bad.
For a start, it is only intended to be a model of how the work will take place and does not go into every minute detail.
But in all my experience in dozens of projects across a wide range of sectors and in several continents, I have NEVER seen one of these charts which explicitly added the (mostly human) non-physical actions which cannot be completed in zero time, such as:
- Waiting time for decisions
- Extra time to recover from errors
- Non-availability of key people
- Late deliveries
- Communication delays, eg several emails just to set up a 10 min call.
- Poor handover from one key person to another. The item being handed over may appear to be “not critial” but if, for example, an authorisation to go into a controlled area is not available when it should be, then the project is delayed.
- Misunderstandings due working in non-native language
- etc.
What is the effect of these delays?
Projects are “successful” if they meet the expectations of the stakeholders. If unplanned delays happen, as already illustrated, then the delivery date expectations will not be met and the project will be branded as “unsuccessful”.
Delays such as those listed are invisible, so “nobody” is responsible. But they still cause delays, for example:
- you want to select a supplier
- you make a call, but your number is taken down wrongly
- some days later you call again to be told that the person is out of office all week
- when you call again, the person you want to talk to is busy…
and so on, and so forth. Whe you make the connection, you may get an answer in minutes but it took weeks to get.
Why are these delays not usually shown not explicitly?
So why do the project plans rarely include these potential delay issues explicitly? I think that there is an unwritten (but outdated) assumption that the project consists of doing all the physical things, such as installing equipment, doing user acceptance tests etc.
In the “old days” these were seen as the entire project, but in our knowledge-driven, global, post-covid, virtual environment, the personal transactions BETWEEN the tasks are highly significant (at least as far as delivery dates are concerned).
Does this matter?
Yes. Take the example of the installation of a wind powered generator. Several of the project steps involve person-to-person communications which do not appear on the plan. To build the generator, the following steps might be followed:
- Draft the business case
- Carry out the environmental impact assessment
- Raise the finance
- Buy or lease the land
- Get planning permission
- Do the detailed design
- Order the materials
- Assign the construction company
- Build the wind generator
- Commission the generator
- Connect the generator to the electricity grid
- Finalise testing
- Train the users
- Handover to the client
- Close the project.
Particularly up to the physical construction, most of the work is knowledge work, developed by interacting with various partners, whether in the same design office, the bank or the local authority to authorise the construction. The scope for non-explicit communication delays, which do not appear in the plan, is enormous.
Taking this further, if the project is urgent, such as the thousands of development projects needed to achieve #climatechange targets before the system collapses, then the critical role of project management competence cannot be over-emphasised.
But even for shorter term objectives such as #digitalisation or recovery from the #pandemic, paying attention to the unseen causes of delay can result in very worthwhile project delivery improvements.
Scatterwork – the Effective Project & Process Consultancy
As your partner of choice, Scatterwork is a catalyst enabling individuals and organisations to achieve excellence through creative project & process solutions in challenging environments.
Helping clients with #projectdelivery on time and with reduced costs and risks is where Scatterwork excels. We leverage from our customer experience in over 40 countries, bringing it to you, the client, in whatever format (consultancy, mentoring, training etc) suits you.
To learn more about how we can help, please call the author Dr Ó Conchúir on +41 79 692 4735 or email him at info@gd.scatterwork.com.