Recently, one of our Fapics partner’s study has caught all our attention.
This study establishes a dark picture of the situation in project management:
- increase in the number of projects to realise,
- rise in the complexity with resources being more and more scarce
- and an escalating uncertainty.
The conclusions seem to indicate that the situation will get even worse in the next few years with the increasing systems’ complexity level.
We can only agree with this conclusion. Especially as a Standish’s study from 1994 reveals exactly the same kind of information. This list of statements is for us a list of symptoms revealing a problem much deeper and anchored in our project management habits.
Indeed, we observe that most of the project managers are blocked in multiple inter organisational conflicts :
1° Reducing or Increasing task duration
How long should a project manager take to negotiate its tasks’ and projects’ realisation times? This approach is even proposed through games as Poker for example, to validate in group task duration.
The problem is as follows :
if you evaluate your teams on their capacity to finish every task on time, what is their only mean to fulfil their objectives ?
>> Increasing or negotiating the length of their tasks to protect themselves. Let’s not be surprised that tasks are judged to be unrealistic or that projects take longer.
2° Work or not by multitasking
What is multitasking ? The fact of beginning a task, not finishing it, start another task that we don’t finish and get back to the first one.
Despite the fact that it is a required skill on most of project manager’s job descriptions, the problem of multitasking is linked to its worrying consequences:
the individual must remember what has been done (set up time). It is highly probable that he must rework part of what has been done but mostly the length of the task will increase.
3° Begin the sooner or the later possible
It is the dilemma of each and every one that works on project mode:
beginning its task or project the sooner or the later possible.
The sooner, you increase the number of tasks in the pipeline and take the risk of loosing priorities and most of all of doing multitasking.
The later, you are not protected anymore of the risks and variability of the project.
4° Begin with or without all the elements to finish tasks
How often do you start tasks without having all the elements to finish it ? Often ?!
And when you receive the missing element, how often does it make that you do again the activity that you thought you had completed correctly ? Often ?!
Welcome to the world of the incomplete kit,
where beginning tasks without having all the elements to finish it is so common that it is part of the accepted environment in which we work.
If you go through the bold elements again, something might hold your attention with physical flow industrial environments :
- Evaluating teams on their capacity to finish each of their tasks on time.
>> Do we believe that the sum of local optimisations of a production flow will improve global optimum?
- Beginning a task, not finishing it, start another task, not finishing it and getting back to the first.
>> How would a production team react if we asked them to set up the machine, produce a bit, stop, set up again, produce a bit, stop, to finally set up as firstly asked in order to finish ?
- Increasing the number of tasks in the pipeline by launching the sooner or not launching but taking the risk that a problem arises on the last minute.
>> Increasing indefinitely the level of WIP generates long waiting times and increases the lead time at each operation.
- Start realising tasks without having all the elements to finish it.
>> Even though it is still a common practice in production, what is the pertinence of launching assembling orders without all the elements ?
These practices seem to ignore a fundamental principle : project management is a FLOW !!
If project management is a flow, then we must manage projects and tasks as a flow.
As a result, several flow practices can apply as for example an approach developed by the Theory of Constraints’ field in 1997 called critical chain project management.
The critical chain is defined as the longest sequence of tasks of a project without conflict of resources. Its principle is that multitasking as generated by Gantt diagrams hides the real criticality of a project.
Once this sequence identified, it proposes taking half of its times (50%) and positioning the other half (50%) at the end of the project in order to protect it as a whole and not by protecting each task.
This approach is ruled by the principle that local protections are consumed through Student’s Syndrome and Parkinson Law.
This approach, by definition, forbids multitasking. Teams focus on executing as fast as possible.
Therefore, it is out of the question to begin a task without having all the elements!
This also suggests that is less serious having an unoccupied person rather than one working on tasks it cannot finish!!
(If by any chance you believe that you can begin a task without all the elements and that you could stop it at a given point without the missing element impacting you; it is that you have two tasks and not one!).
In all projects one or two critical resources exist, the critical chain project management suggests to pull flow according to the throughput of this resource.
This allows to limit the work in progress of tasks and projects within a system.
AGILEA has developed this approach for several months now and results are disruptive for most of our clients.
From 60 people we trained during the last 6 months we collected the following feedbacks:
- « It’s easier and quicker to implement », Research Department Manager of a parapetrolic company.
- « It makes so much sense that I forgot how we did until now », Supply Chain Manager of a lamp supplier.
- « The approach is new on both technical and managerial aspects ! It is worth trying it », ERP Project Manager.
Speeches, but also results were obtained. A lamp supplier for manufacturers, one of our clients, recently won a public sector contract. This SME of 32 employees used to develop 4 new products per year with a growth form 3 to 5%. To win this contract, the company needed to develop 70 new products for its client in one year.
Six months after the implementation, no new product was available. They decided to call upon us with our critical chain approach to re-establish the situation in their company.
AGILEA applied its 20 days to change it all Program that, through progress induction, allows teams to implement critical chain’s methodological mechanics on all the organisation
(executive team, managers and operational teams).
This was in June, with summer holidays planned on August. Two weeks after we started the mission, the company proposed 4 new products to its client… As much as last year. At the of October, the company had finished all 70 new products.
The client was so surprised that the project ended on time that he even could have accelerated its implementation.
In this process, he managed to ask to the suppliers to finish their development tasks quicker.
Unfortunately, the client discovered that its other partners were late and would be eventually ready in 8 to 10 months after October!
Given that our client had finished its work AND that the contracts had rupture clauses, we proposed to take part of their products that weren’t developed.
The client was doubtful and tried on 5 new products that we delivered 2 weeks later..
Finally, it wans’t 70 new products that the company developed but 95 in 6 months ! Its revenue increased by 60%. And the company seemed little to absorb the integration of the new products, a new building is being considered.