A recent (late 2010) “Linkedin” discussion started with: “I was at a live project manager networking event the other night and someone said, ‘Project Managers are Risk adverse by nature.’ Is risk adversion a quality of a successful project manager?” What are they really talking about? The discussion seems to conclude project managers are not anymore risk adverse or averse than any other person. What they do is manage their risk. I thought I would write this article about risk in projects, how risk is planned for (in the project plan) and how risk is managed during project implementation.
3. Management Practice “A resource standing idle is a major waste.”
This belief leads to a misuse of resources and consequently lost time in projects. Task and project time estimates must, of course, take into account that this belief is common and that it has a major impact. What follows explains why.
I suspect that no manager likes to see employees loafing – they should all be working all of the time. If they are not working (so it is believed) then the company is paying salaries and getting no results. Is this belief the case in your company?
Employees suffer from the same thing. If they have nothing or too little to do they feel their job is at risk. If they are not working then sooner or later their position (they believe) will be eliminated and they will be looking for a new job. Employees must therefore go out of their way to make sure they always have enough work on their desk. If there is not enough they spread work over time and make sure more work comes their way soon. Everybody wants to be (or at least must look) busy all the time.
In many project environments it is quite easy to keep everyone loaded with work. There are plenty of projects that need to be done. In fact, isn’t it true that many times there is pressure to start new projects before existing active projects are finished? It seems there is often pressure to start the next urgent and important project as soon as possible (maybe because it is well known that projects are generally late so starting as soon as possible seems to make sense).
Management, project managers and employees all have the same aim – have as many projects running concurrently as possible. In this way everyone is busy, no one is in danger of being fired and new (urgent) projects are started straight away. Is this common sense or common practice in most project environments?
Little’s Law (John D.C. Little; Professor of Marketing at the MIT Sloan School of Management - in operations research. He is best known for his proof of the queuing formula L = λW, commonly known as Little's Law). He tells us that the more work we have in the process, the longer the lead-time of the process. Little’s Law states that the common practice of keeping everyone busy and launching projects as soon as possible will cause projects to take longer than they could or should.
When many projects are implemented in parallel resources will be forced to work in at least several of them concurrently. Project managers pressure resources to work on their projects causing these resources to abandon a task before it is finished to satisfy the project manager concerned. Of course as soon as a resource does that, pressure will immediately mount for him to switch back to the original task. If three or more project managers are involved, it is easy to see that a lot of multi-tasking could be going on. Do we have any idea how much time is being wasted through multi-tasking? Just imagine how much time a resource loses every time he or she must re-familiarize himself or herself with what they have already done. The more complex the task the more time is lost. Consider also that these concurrent projects cause all projects to be finished later – focusing on just one would cause it to finish sooner. The sooner a project is finished the sooner it can earn a return. Maybe we have identified an area where time wasted could be reduced.
To get an idea of the impact of multi-tasking try the following:
- You have 3 projects in parallel. The first is to write the letters of the alphabet in a column. The second is to write the numbers 1 to 26 also in a column. The third is to write the Roman numerals from I to XXVI also in a column.
- To multi-task, write A, then 1, then I followed by B, 2, II until you reach the end of the alphabet, 26 and XXVI. Don’t forget to measure the time (T1) it takes to complete all three projects.
- Do the projects again, but this time do it the natural way write A, B, C … Z; followed by the numbers and lastly by the Roman numerals. Again measure the time (T2). T2 will be significantly shorter than T1. The time gained is time that could be used for a fourth project.
- Note the difference in time and calculate the capacity you could gain by NOT multi-tasking. The formula is: Capacity Gain=(T1-T2)/T2
- In reality a project organisation may not multi-task this much. However, consider the simplicity of the tasks in these projects and the complexity of tasks in normal projects. Is the impact you have seen reasonable? Consider also the opportunity that might be available.
Ignoring Little’s Law and multi-tasking have a major negative impact on project times and resource effectiveness. As long as organisations cause multi-tasking project managers and task owners must take this into account. In fact few people are actually consciously aware of the impact. However they do have the experience of how long tasks and projects usually take. The adjustment project managers make for multi-tasking is based on experience its “gut feel”.
At this point we do not know how big the opportunity we have. The little experiment is not a real project situation as only 1 resource is involved and the amount of multi-tasking is extremely high. However, as already mentioned, the lost time may be even greater in real projects simply because the ‘set-up’ a resource has to make when returning to a task is much greater. Shouldn’t the project manager population look at the consequences of multi-tasking? Shouldn’t senior management look at their behaviour that causes multi-tasking and maybe reconsider some management behaviour?
<
Technorati Tags: Critical Chain, Execution Management, Prject Execution, Prodct Development, Production, Project, Project Execution, Project Management, Project Manager, Project Plan, Risk Management, Theory of Constraints, TOC
/p>
Technorati Tags: Critical Chain, Execution Management, Prject Execution, Production, Project, Project Execution, Project Management, Project Manager, Project Plan, Risk Management, Theory of Constraints, TOC, Product Development
Technorati Tags: Critical Chain, Execution Management, Prject Execution, Prodct Development, Product Development, Production, Project, Project Execution, Project Management, Project Manager, Project Plan, Risk Management, Theory of Constraints, TOC, Multi Tasking
No comments:
Post a Comment