(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.
Happy New Year!
My new blog “Project Success and Failure: Who’s the Impostor?” is just up.
Today’s blog explores a frequent topic on Internet discussion groups: What is the appropriate definition of “project success” and why is it important? The article gives an example of why the definition used in most studies is not just inadequate but counterproductive. Future blog posts will expand on this topic.
Fraternally in project management,
Steve the Bajan
www.TotalProjectControl.com
Printer-friendly version
Send to friend
Steve:
“That is what Business Analysts and estimating should be for. Pretty much everything on projects (as with all investments) is based on estimates. And frequently, time is so valuable that you can be off by a factor of three and the decision would still be clearcut.”
Not sure what your point is, or in reference to.
Most business decisions are based on forecasts (similar, but not identical to estimates) and used to evaluate alternatives. Unlikely the decision would be that clear-cut, but then I’m not involved at that level.
Current pricing for your book is not attractive to me.
Hi, Dennis.
That is what Business Analysts and estimating should be for. Pretty much everything on projects (as with all investments) is based on estimates. And frequently, time is so valuable that you can be off by a factor of three and the decision would still be clearcut.
Again, there is fairly extensive discussion of this in Managing Projects as Investments.
Fraternally in project management,
Steve the Bajan
Mike; Tell me what?
Hi Dennis
A short study of Critical Drag will tell you.
Best regards
Mike Testro
Mike:
Not the cheapest to build, but if a day of production is worth more than acceleration costs, then speed pays. Trouble is we seldom know what a product day is worth.
Hi Dennis
I disagree.
Fastest is not necessarily cheapest. An accelerated programme will always cost more to construct.
There may be a benefit to the Employer in an early completion and that is part of the overall project budget.
Best regards
Mike Testro
Mike:
“It is possible to create an easy slack programme or a tight hard one for the same project.”
Not really. It is always cheapest, fastest. You don’t get to choose one and ignore the other. In the London Olympics example, the cost of delay was ‘infinite’. Delay was not acceptable. So the cheapest, was the fastest. Or the fastest, was the cheapest.
Steve:
“Dennis, I honestly don't know how to reply. Is it your contention that any two (or three, or seven) project teams/contractors will come up with exactly the same plan for a project? Every project? Every industry -- construction, aerospace, software, new product development, pharma, nuclear outages? If this is true, let us eliminate the role of planner entirely and just select on the computer the activities we want done and Deep Blue will provide the schedule.”
In time, this may happen. It is conceivable a schedule could be developed from data contained within the model. Until that time, I would expect two, or more, competent planners using the same estimate to generate comparable plans. I’m assuming shared variables – unit rates, location, weather/time of year, and team competency. Remember, these are ‘identical’ projects. The goal for both is the same – do it as fast as possible, as cheaply as possible. I would expect both to come to the ‘same’ time/cost conclusion.
“Almost! That is how we should get at the value/cost of time on a project. That value/cost of time can then be used to justify the cost of additional resources on the critical path *based on the amount of drag that is being reduced and the cost of that drag*! Time is money, and the true cost of a critical path activity HAS to be seen as the sum of its resource costs plus its drag cost. And there are many, many places in most schedules where increasing an activity's resource costs can thereby lower its true cost through a greater reduction in drag cost.”
This is implicit within most projects – time has value. What’s missing is the actual value of a day. In your apple v orange analogy, this understanding was ignored. Only whether the project met the original parameters – easy v. hard was considered. My point is you never encounter and apple v. orange situation. Well, you do, but then it’s an apple v. orange comparison. The metric is cheapest, fastest, safest, operational. Failure in one aspect, spells failure.
BTW: I appreciate what you’re doing. Please add LinkedIn identities to your blog.
Hi Steve. Happy and prosperous new year to you.
The Contractor does not have the choice.
He tenders on the parameters set by the Employer who presumably has been advised by consultants who adver that they know what they are doing.
The consultants will be paid a fixed fee so the programme will be produced at Level 3 - best guess with no detail.
The budget will be on the basis of cost per M2 with a lot of provisional sums - that then becomes the Employers requirements.
With a rudimentary outline design the Contractor is then invited to tender on either an Engineer Procure & Construct or Design and Build - there is a fundamental difference between the two approaches that few contractors appreciate.
So the aspring Contractor can either plan a slack programme and lose the tender or a tight programme and lose anyway.
It is when the Employer is properly advised will your "Project Success or Failure" advice become normality.
Best regards
Mike Testro
Happy New Year, Dennis.
"Note: I tried posting this on your blog. It wouldn't let me. You might want to add LinkedIn as a possible login."
Thanks. I don't know anything about how to do this, but I have passed your comment on to my web designer.
"How can two identical projects have different durations? I assume we used the same unit rate, and the same crew loading, so we would have the same durations. Did one project use larger crew sizes/ over-time and therefore less/more productive? (congestion/fatigue). If so, why?"
Dennis, I honestly don't know how to reply. Is it your contention that any two (or three, or seven) project teams/contractors will come up with exactly the same plan for a project? Every project? Every industry -- construction, aerospace, software, new product development, pharma, nuclear outages? If this is true, let us eliminate the role of planner entirely and just select on the computer the activities we want done and Deep Blue will provide the schedule.
"Surely both teams would arrive at the same cost/benefit point. If not, why not?"
Not, for vast numbers of reasons:
And lots of other reasons. Surely your own company sometimes competes for contracts on the basis of schedule?
"We should have the same goal - product to market in the least time at the least cost."
Aren't "least time" and "least cost" often considered (admittedly, not always correctly!) to be in opposition to each other? Which is more valuable on a given project, least cost or least time? And how much are you willing to compromise on one for the other?
Also, time has different value for different customers, or even for the same customer on different projects. Weekly losses for a luxury hotel due to missed weeks in January in Barbados are likely to be quite different than for a quite similar hotel on Cape Cod.
"If your orange v. apple example is to highlight the inappropriate metrics,.."
Dennis, that's it exactly! And misplaced metaphors based on those inappropriate metrics, like "deadlines", especially when codified in contracts, lead to enormous inefficiencies.
"...then this could lead to your concept of TPC where the measure is how quickly to market with a competitive product. Here we agree - what is a day of production worth? The project which achieves the earliest production date without busting the budget ((original budget + (addition cost - no. of days X value of production day)) is the 'winner'. Is that your point?"
Almost! That is how we should get at the value/cost of time on a project. That value/cost of time can then be used to justify the cost of additional resources on the critical path *based on the amount of drag that is being reduced and the cost of that drag*! Time is money, and the true cost of a critical path activity HAS to be seen as the sum of its resource costs plus its drag cost. And there are many, many places in most schedules where increasing an activity's resource costs can thereby lower its true cost through a greater reduction in drag cost.
Projects are investments, undertaken to create maximum value for minimum cost (i.e., expected project profit). A contract which does not adequately align the best interests of customer and team can introduce huge moral hazard and waste. Yet contracts (and, per the blog post, SUCCESS and FAILURE binary judgements) continue to reflect inappropriate parameters and metrics.
Dennis, I can't tell from your comments whether or not we are approaching a "meeting of the minds". I am neither stupid nor inexperienced, but I sometimes think you feel that I am. (It's okay, I think that was Mike Testro's impression too for the first year we were on PP together.) By the way, for the record, it's clear to me that you are both smart and very experienced.
The trouble is, from my point of view, that you are smart enough to keep pulling bits and pieces that don't seem to fit, without having the big picture, out from the stuff I write. And then I spend hours going back and forth trying to explain how its all integrated. And all that information, in a much more coherent format, is covered in my books.
Dennis, I urge you to read Managing Projects as Investments: Earned Value to Business Value. Yes, it's about lots of concepts that are new to traditional project management -- but I believe that you will understand their validity.
And then any issues/questions you have may at least be stuff I haven't covered in the book,and maybe I will learn something.
Fraternally in project management,
Steve the Bajan
Hi, Mike. Happy New Year.
"My understanding of Steve's approach is that if you set a yourself a hard target and miss it that is classed as a failure... Take an easy target and hit it is a success... It is possible to create an easy slack programme or a tight hard one for the same project."
That's it, exactly, Mike. Said more succinctly and clearly than I did. Thanks.
I would add one point: all else being equal, guess which type of programme a contractor would rather have? especially if there is potential for LDs.
Fraternally in project management,
Steve the Bajan
Hi Dennis
My understanding of Steve's approach is that if you set a yourself a hard target and miss it that is classed as a failure.
Take an easy target and hit it is a success.
A classic recent example is the London Olympics structures - declared to be finished on time and on budget - but what a budget - completely open ended.
It is possible to create an easy slack programme or a tight hard one for the same project.
Best regards
Mike Testro
Note: I tried posting this on your blog. It wouldn't let me. You might want to add LinkedIn as a possible login.
Might as well start the New Year off right, Happy New Year, Steve. How can two identical projects have different durations? I assume we used the same unit rate, and the same crew loading, so we would have the same durations. Did one project use larger crew sizes/ over-time and therefore less/more productive? (congestion/fatigue). If so, why? We should have the same goal - product to market in the least time at the least cost. Surely both teams would arrive at the same cost/benefit point. If not, why not? If your orange v. apple example is to highlight the inappropriate metrics, then this could lead to your concept of TPC where the measure is how quickly to market with a competitive product. Here we agree - what is a day of production worth? The project which achieves the earliest production date without busting the budget ((original budget + (addition cost - no. of days X value of production day)) is the 'winner'. Is that your point?"Email: PPadmin@planningplanet.com
Replies