(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?
(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.
Printer-friendly version
Send to friend
Hallo all, I would appreciate your opinion on the difference between duration without TRA and minimum duration for Quantitative Schedule Risk Analysis. In my opinion this is not the same but I am having trouble defining the difference.
Thanks in advance
Jerry Clarke
Hi, James Pope
The adage the customer is always right comes to mind here, however, I qualify this as being, as long as the overall time risk factor remains the same. Who cares what format it is in, as long as the time risk factor is accounted for. I would opt to total it up and put it on the whole project as I have outlined before in previous post.
The problem with allocating time risk allowances to task is that once the task is completed on or before time that risk factor benefit is lost but if the task is over time then the detriment is carried forward to the next task.
This is totally unfair on the project manager.
In all cases, you are the professional, stand your ground on what you believe to be right and in the best interest of the project.
If you do that, its very unlikely the customer will get someone else to do it. Unless of course, s/he is a complete fool.
And if that is the case, do you realy want to work for them.
Hi Stephen Devaux:
You present a good argument, however, my use of the Pareto law is not to add slack or a buffer at all, and it’s solely to establish a viable baseline on the timings of the expected effort provided by team members. Seeing as this is original input to the project there can be no valid arguments from executives.
Having established these work effort times one then needs to establish a project wide buffer that accounts for the over all risk. On the face of it, my previous post today regarding the critical chain as opposed to the critical path as expounded by the authors of the book 'the definitive guide to Project Management' seems to be a viable solution.
I wont republish what I have written there but the idea of producing a project wide buffer and applying the full buffer from the outset of the project makes sense. Doing it this way allows you to monitor the ratio usage of project buffer to project progress and if the buffer usage percentage is marginally higher than project progress percentage you have a clear indication that your project is dying slowly. If it is being used up at a greater percentage rate than the projects progress you know you are in deep trouble because your project is dying fast. Any sudden large steps upward in the buffer usage differential indicates that you have a considerable problem to handle while the opposite means you have a fantastic team that is on top of the job and you can look forward to a nice bonus.
As for anal-retentive executives, they are just spoilt bullies trying to make them selves look good and often just need a good spanking. When asked by them to do a project in such and such time and budget I just laugh at them and say 'I will tell you how long it will take and how much it will cost when I have produced the project plan'.
If they don’t like it, then fine, get someone else to do the project because I never set myself up for a fall, especially not out of ignorance.
But then again, I am a cantankerous old fart who is a professional that is not intimidated by authority, position or company politics. I am either right or wrong, if I'm right I wont back down, if I'm proved to be wrong then I wont argue the point.
Hi,
A great discussion has been brewing and that’s good for everyone however I think you are missing the point. I was not talking about task duration, which is another subject in its own right. I am talking about effort time on a task.
Most people when asked would like to assume that they work to 100%, but due to circumstances that is neither a true or practical estimate in real life.
I was suggesting that by using the Pareto theory of 80:20 one could assume that a well-motivated person will consciously produce no more than 80% of their target. So as a starting baseline one should divide their quoted effort time by 8 and then multiply that figure by 10. Therefore if the quoted effort time is say 36 hours or three days then 36/8x10=45hrs planned effort. Obviously, this should be the absolute minimum of effort time.
Nokes and Greenwood in their book 'The Definitive Guide to Project Management' focus on a methodology called Critical chain and activity durations. Their basic assumption is to create a project buffer by asking team members who are going to work on task first provide an estimate of how long the task will take with 90% confidence and then to ask them to an estimated time that provides a 50:50 chance of completing.
They then go on to say identify and sum up both columns of 50% and 90% effort durations that fall on tasks along the critical path. Having done this they recommend either adding both the 50% and 90% effort durations together and dividing by 2 simple less risky projects.
Or,
For larger, more complicated or risky projects to take the sum of the squares of the differences between the 90% and 50% estimates for the tasks that fall along the critical path.
I think the easiest way of doing this would be to use a spreadsheet such as Excel.
They then go onto say insert the feed buffers in the places where the non critical work streams join the critical chain (path) to protect the critical chain from any variability in the timings of non critical tasks.
Further, they suggest that one should calculate the feed buffers in the same way as for the project buffers by using the activities in each feeding work stream instead of the critical chain activities in calculations.
To make full sense of this method one would need to read the book, the full method is outlined in brief in appendix A.
My impression is that you add the whole buffer sequentially to the tasks and monitor how much is being used up over time. Lets say for argument sake that the project is 20 percent completed and you have already used 50 percent of your buffer then you know that your project is in trouble. While on the other hand if your project is 80% completed and you have only used say 30% of your buffer, you can be a little bit more optimistic.
I hope this helps.
Kind regards, Stephan Toth
Hi, Stephan, and welcome to PP.
That was a very thoughtful and interesting post. My two cents on the subject:
You wrote: "In real life, people never ever work to 100 percent of their capabilities and because of this on needs to make allowances for this in their plans... I believe that considering how many project go over time and over budget, using the Pareto law of 80:20 is not a bad starting point in allocating time and efficiency ratings. Using this law dictates that... A standard weeks work is expressed as 32 hours actual work, and so on. By utilising the Pareto law you take into account such things as toilet breaks, walking to and from work places, phone calls, discussions and a whole host of other non-productive activities that delay a project."
I work with many different industries. Other than in information systems project management (by far the least mature PM discipline. especially health care PM!), I know of no company that has been inbusiness longer than five years that would consider using a 40-hour week for planning purposes. Some use 36, but that's invariably for "overtime exempt" employees, who almost certainly normally work 45+ hours a week anyway. Thirty-two is certainly quite standard in PM-mature organizations.
"Also using the Pareto law, you do not need to build unnecesary slack into the project and are less likely to under estimate the time that tasks take."
The term slack (or float) has a specific meaning, and it probably shouldn't be used to describe schedule reserve, which is what I assume you are referring to here. Budget and schedule reserve (or buffers, to use the Goldratt term) are both necessary risk mitigation tools on any project, to account for risk due to unforeseeable problems ("black swans", in the term used by epistemologist Nicholas Nassim Taleb).
Project schedule reserve is qualitatively different from budget reserve, due to the importance of the critical path. To avoid using it up frivolously (per Parkinson's Law: "Work expands so as to fill the time available for its completion."), schedule reserve should:
1. Only be input at the end of the project or before key milestones (where missing them will be costly).
2. Always have their drag and drag cost estimated (e.g., on a contract bid, how much will including SR reduce the likelihood of winning the contract, or how much will it reduce the price you can bid on the contract -- the customer will often pay more for a shorter schedule).
SR represents the difference between the baseline schedule and the working schedule.
"Of course planning your project using this law will at the outset make your project appear to take longer and probably cost more. You would have to use all your powers of persuasion to convince the board that your estimates are reasonable and a fair representation of how long the project would actually take. Everyone knows that wishful thinking executives and bean counting accountants want to see very tight schedules with minimum cost but project managers have to operate in the real world and need to have the intestinal fortitude to stand their ground and always be realistic in their predictions."
Customers (e.g., US DoD clients) when they see SR in a schedule will often order the PM to take it out. In so doing, they demonstrate ignorance of good project management practices -- the way you meet a time commitment is by operating to a more aggressive schedule. Such customers should be asked if, when taking a flight somewhere, they always plan to arrive at the airport gate exactly a nanosecond before it closes. If they still refuse to allow SR, then there needs to be a much bigger final activity: TEST & INTEGRATE will take a lot longer (and cost a lot more!) under these circumstances, as the one thing that having no SR will guarantee is that the contractor will make bad decisions to meet schedule.
"The up side to this method is of course when you bring your project in, on time and budget or even under the expected time and budget that was predicted. In this case everyone is happy, smiling and congratulating themselves on a job well done."
Especially if there is a contractual incentive for early delivery, which is done far, far too rarely. Your earlier point: "In real life, people never ever work to 100 percent of their capabilities and because of this on needs to make allowances for this in their plans," is absolutely true, and is a well-known philosophical issue ("The Principal-agent Problem") analyzed extensively by, among others, political economist Max Weber. From the Wikipedia article: "The solution to this... problem... is to ensure the provision of appropriate incentives so agents act in the way principals wish. In terms of game theory, it involves changing the rules of the game so that the self-interested rational choices of the agent coincide with what the principal desires."
Projects are investments. Completion date almost invariably has a huge impact on the value of the investment. The critical path determines project completion date. Therefore incentives should be built into the contract to improve the completion date, and these incentives should be used by the PM to reward those working on CP tasks, so that "the self-interested rational choices of the agent coincide with what the principal desires." Ultimately, the contractor should work, not to often-arbitrary deadline and budget edicts ("Timeliness starts with timelines, but deadliness comes from deadlines!"), but toward expected project profit metrics aligned with the "Principal's" investment desires, for project profit. And the Total Project Control metrics for that are the DIPP and the DPI (DIPP Progress Index).
Fraternally in project management,
Steve the Bajan
Hi, I am new to project management but have been in production management for many years. Its been a long time since the advent of the discredited time and motion studies that expected people to work to a level expressed by a highly motivated executive hurrying for a bus while carrying a heavy brief case. In real life, people never ever work to 100 percent of their capabilities and because of this on needs to make allowances for this in their plans. Many people, and I may say, more experienced project managers than I am have expressed a wide variety of ways to account for this project/task time risk element.
I believe that considering how many project go over time and over budget, using the Pareto law of 80:20 is not a bad starting point in allocating time and efficiency ratings.
Using this law dictates that:
A standard hours work is expressed as 48 mins actual work
A standard days work is expressed as 6.4 hours actual work
A standard weeks work is expressed as 32 hours actual work
and so on.
By utilising the Pareto law you take into account such things as toilet breaks, walking to and from work places, phone calls, discussions and a whole host of other non-productive activities that delay a project.
Also using the Pareto law, you do not need to build unnecesary slack into the project and are less likely to under estimate the time that tasks take.
Of course planning your project using this law will at the outset make your project appear to take longer and probably cost more. You would have to use all your powers of persuasion to convince the board that your estimates are reasonable and a fair representation of how long the project would actually take.
Everyone knows that wishful thinking executives and bean counting accountants want to see very tight schedules with minimum cost but project managers have to operate in the real world and need to have the intestinal fortitude to stand their ground and always be realistic in their predictions.
When dealing with contractors one could reasonably say that 'In my opinion your predicted time scedule is too tight' and insist on building in the risk for your plan as outline above and still maintain the contract price.
The up side to this method is of course when you bring your project in, on time and budget or even under the expected time and budget that was predicted. In this case everyone is happy, smiling and congratulating themselves on a job well done.
Email: PPadmin@planningplanet.com
Replies