There seems to be fairly wide consensus that the modern practice of scheduling is not delivering the results needed to help projects succeed.
My feeling is that with a few notable exceptions the underpinning ideas of the Critical Path Method (CPM) of scheduling developed in the 1950s and 60s have been forgotten and most software and most scheduling practice uses ideas from the 18th century.
The concept of Bar Charts was developed in the 18th century (or possibly earlier). Joseph Priestley (1733-1804) published his ‘Chart of Biography’:
He is quoted as saying “…a longer or a shorter space of time may be most commodiously and advantageously represented by a longer or a shorter line.”
A few years later a full range of modern charts were published by William Playfair (1759-1823) in his ‘Commercial and Political Atlas’ of 1786:
By the end of the 19th century sophisticated barcharts appear to have been in general use (at least in Europe – the project below was built in 1910):
For more on the early development of scheduling see A Brief History of Scheduling.
Henry Gantt developed his production management systems for factories in the early part of the 20th century with a range of charts designed as production monitoring and control tools:
Importantly Gantt did not use simple bar charts and had no interest in one-off projects. He was focused on machine shop efficiency and production quotas:
For more on his work see: Henry L. Gantt – A Retrospective view of his work.
CPM and PERT were invented in 1957 as computer based analytic models:
Importantly, in both systems, planning the logic and entering the information into the computer precedes calculating the schedule. Both CPM and PERT used ADM networks:
The ‘precedence diagram’ (PDM) network was published in 1961 as a simplified manual process to make CPM available to people without access to expensive mainframe computer time – in the PDM system as published drawing the logic diagram also precedes calculating the schedule.
There is no question CPM offered significant advantages over the traditional bar charts that had been in use for more that 100 years. In my view, the major advance that generated the improved project outcomes was the need to think through the work logically, focusing on the activities and sequence of work before any attempt to schedule the project was possible. This was equally true of both the mainframe systems and the manual systems in use through the 1960s and 70s. James Kelley (co-inventor of CPM) had a very similar view.
The same concept of good practice is embedded in the PMBOK® Guide. The separate processes in the 5th Edition are:
6.1 – Plan schedule
6.2 – Define Activities
6.3 – Sequence Activities
6.4 – Estimate Resources
6.5 – Estimate Durations
6.6 – Develop Schedule
6.7 – Control Schedule
CPM was recognised as an improvement on bar chart planning! So my question is: If CPM scheduling is supposed to be a logical process why do so many scheduling tools default to, and planners work from, 250 year old Bar Charts? Is this the cause of scheduling failures?
There are tools around that default to creating the schedule logic in a network diagram but they are in the minority. I will be discussing one of these at the Construction CPM conference in New Orleans later this month (see: http://www.constructioncpm.com/). Micro Planner X-Pert is a true CPM System that supports the PMBOK® Guide schedule development process:
And lets you chose the networking style PDM or ADM:
For more on Micro Planner see: http://www.microplanning.com.au/
But back to the key question, is scheduling failing through lack of skills and training, a lack of knowledge, poor techniques focused on 250 year old bar charts or some other reason?
The 15,000 articles a month downloaded from our planning resource page, suggest a strong interest in planning and scheduling but this interest does not seem to be reflected in the status or planners or project outcomes. I look forward to the discussions….
Pat Weaver
Lynda Bourne
Aavssitedev's Blog
Hi Pat, I don’t believe the problem lies with the tool….. For “a fool with a tool is still a fool”…….
I think one of the root causes starts with the insane assumption that we can continually do things “faster, better cheaper”…….. As I tell my classes, it takes about 38 weeks to produce a healthy human child and give or take a week or two either way, both mother and child will not suffer any adverse affects. However, start to go less than 36 weeks and the babies health deteriorates while at more than 40 weeks and both baby and Mom are in jeopardy.
Project management is no different. There is some “optimum” time to do any project and IF we can find that optimum value, then projects can and should and DO finish on time. Same with cost budgets. The problem arises when management (intentionally or otherwise) dictates unrealistic time (or cost) budgets that we start to see “failures”…….
Again, using the pregnancy analysis, it seems to me there are far too many “clients” or “bosses” who tell the project manager to “find 9 women and produce a healthy baby in one month” and worse yet, project managers (or project schedulers) who don’t have the cojones to push back and tell these sponsors what they want is impossible.
My two cents worth….
BR,
Dr. PDG, Jakarta, Indonesia
http://www.build-project-management-competency.com
Hopefully the PTMC certification launched by CIOB and similar certifications from the Planning Planet Guild will at least qualify planners to ‘stand up for common sense’. For more on PTMC see: http://www.mosaicprojects.com.au/Training-CIOB-TM_Credential.html
Pat, another consideration….. NONE of the tools/techiques above allow for feedback loops…….
Which means if we want to create more realistic schedules, we have no choice but to recognize that those pesky feedback loops have a MAJOR impact on both time and money, and to ignore them because the software tool doesn’t allow them is no longer an acceptable excuse.
Which means the scheduling software of the future will be some form of simulation based on Systems Dynamics. (i.e. Sim City or Farmville) where we can not only add in those pesky feedback loops, but actually build in Boolean operators which give us the ability to program “IF > THEN” decision points.
When this happens (and sooner or later it must) then it will require that schedulers (and project managers) have some very solid real life field experience before they can possibly create a systems dynamics model which is realistic.
To see more on this topic, start here…… https://ceprofs.civil.tamu.edu/dford/dnf%20profesional/sdappliedtopm-sdr-published.pdf
BR,
Dr. PDG, Jakarta, Indonesia
http://www.build-project-management-competency.com
Proper resource optimisation would help as well: http://www.mosaicprojects.com.au/Resources_Papers_152.html
what is wrong with a linked bar chart. It has all the logic of CPM
Bar chart thinking is time focused – scheduling. CPM was supposed to be logic focused with the planning (logical sequencing) optimised before starting on the scheduling (time placement) of the activities. It is impossible to draw a pure logic diagram in a bar chart and therefore that aspect of thinking and understanding is reduced.
Filling in a bar chart table in Microsoft project or Primavera, dragging bars around to ‘look right’ and then linking them is a very different thinking process to developing a PDM or ADM network as a logic diagram.
Kelley and Walker were of the view sorting out the logic first improved the overall outcome.
This is a really great history of scheduling, especially the graphics showing its evolution. Thanks for sharing!
Fascinating history. I had no idea.
Dr PDG’s point about feedback loops is interesting because as he suggests it implies some form of conditional branching (otherwise thee feedback would amount to an infinite loop). And again as he suggests it implies simulation, since there will not be a single deterministic path through the network.
Pat, your point about proper resource optimization is also a good one. I am positively itching to do this, believing that computers are now fast enough to have a crack at useful-sized problems, though it remains a problem of combinatorial (N!) complexity. But I see little interest out there so it does not look like a commercial proposition.
And putting the two together, I have been ruminating lately about simulating the decisions a project manager may have to make and what information he has at the time. (e.g. he might have to book an expensive drilling rig a year in advance when he cannot know for sure when he will be ready for it, let alone what the weather will be like.) Actually, simulating resource allocation decisions using only information which would be available at the simulated time of the decision might not only be more realistic but also might ameliorate the combinatorial problem. (Seems pretty daft making decisions about resource allocations 3 years hence assuming all intervening tasks go to plan, which is basically what resource scheduling does — albeit badly — now.)
The CIOB Guide to scheduling complex projects has introduced the concept of ‘schedule density’ which addresses the need to manage what you know (and you don’t know resources well until very close to the time the work will occur. See: http://www.mosaicprojects.com.au/WhitePapers/WP1016_Schedule_Density.pdf
DCMA in the US has a similar idea, but only two levels. “Planning packages” have little detail and must not be nearer than 60 days away. Then when they get within 60 days they are generally turned into summary tasks and detail is filled in below them. While some over here use “schedule density for something entirely different (ratio of rels to tasks).
Guys, the weakness in all these linear (forward pass/backwards pass) models is no matter how “accurate” or “reliable” the logic, “shit happens” and unless you can model the probability of something happening (i.e. the locusts eating your crops in Farmville) that renders your schedule invalid, all you have is an approximation.
If you get the chance, Steve Warhoe did his PhD dissertation using Systems Dynamics to measure or model the cumulative impact of multiple change orders in traditional Design>Bid>Build contracting. For those interested in seeing his model, email me privately and I will introduce you to him.
Tony, the most common software packages for Systems Dynamics are Stella or iThink; VennSim and PowerSim. You may want to download a trial copy and play with them a bit…..
BR,
Dr. PDG, Jakarta, Indonesia
http://www.build-project-management-competency.com
Hi, Dr PDG.
You say to contact you privately but how? Please email me at twelsh@barbecana.com.
btw, I started my career in OR (after doing MSc at LSE under Ailsa Land and others) and am familiar with Forrester’s work. Right now I do not see an obvious connection with project management but will take a look at one or two of the software products you mention.
As another aside, my son lived in Jakarta for several years before moving on to KL. He is now living in Canberra and working in UlaanBaatar.
Pingback: The genealogy of project scheduling - Projectation | Project solutions realized
Pat,
I can remember during my first ever project management training having to go through logical networks to calculate durations in order to work out a critical path. In fact, this was repeated on many training courses and while it was tedious at the time it did reinforce what real scheduling was about. Unfortunately the concept of producing logical structures first off now seems to be a thing of the past and even experienced project professionals (or at least that’s how they see themselves) default to simple bar charts. The danger is that while a bar chart is a good representation AFTER all the calculations and hard work has been done it is almost worthless beforehand. What happens is that senior managers who think they understand project management and scheduling (how difficult can it be?) start working with the bar charts. My own pet hate is when senior managers start using the term Critical Path yet have no idea what that actually means in project terms. I once had to correct a client’s use of the phrase ‘Critical Paths’ when referring to their schedule!
It’s a great post you have put together Pat and one that should be widely shared.
Paul
Great discussion and I very much like the comment that a fool with a tool is still a fool. Personally I’m not sure if the actual tool is as important as many believe – most of the tools we have at our disposal today are quite good. In my experience part of the reason schedules fail is because far too many project managers treat them as a form of academic exercise. All fired up at the beginning of a project schedules are often developed only to be put on a shelf and glanced at occasionally. Exactly the same sort of problem we see with organisations that develop volumes of quality manuals which sit on the shelf and never get looked at until there is an ISO audit or something goes wrong. One of the most challenging aspects of managing any project is still to get all involved to integrate whatever tool / methodology is selected into day to day work practices. Techos typically hate completing the timesheets, paperwork, date entry etc which is needed by any good tool and is critical to the success of any project. Human nature also dictates that people don’t want to flag if they are running a little behind schedule. They justify this to themselves on the basis they will catch up the few hours they are behind this week over the next week. Then the day or two they are behind at the end of that week during the next month. Hence why it is so critical to identify deviations from schedule as early as possible – which sounds simple but is actually very difficult because it relies on relationships i.e. the doers trusting that if they flag a potential delay they are not going to get a kick in the backside rather they will receive support to help rectify the situation.
I also appreciate the comment about shit happening. It is certainly true that occasionally unexpected things happen, but again in my experience most shit that happens is as a result of a lack of project management discipline – in particular not having the scope sufficiently locked down with the customer at the beginning of the project. Mismatched expectations upfront and other forms of project creep during execution invariably lead to schedule failures and dissatisfied customers. I don’t know how many times I’ve heard Engineers and Programmers tell me they’ve given something away (scope creep) to help customer satisfaction when in fact such actions undermine customer satisfaction over the life of a project. The best way to manage customer satisfaction is in fact to deliver on scope, on budget and on time. All three of these things are so interrelated that you can’t change one without impacting the others.
@ Bill E,
Speaking as a “hard money” general contractor (CONTEXT is EVERYTHING) I have two schedules. The “contract” version which is necessary for me to win the bid and obtain my “notice to proceed” and then the “real” schedule, which shows how I actually intend to execute the project. The “official” schedule is designed to fulfill the contractual requirements while the second one is designed to protect myself against late delivery penalties by setting the stage for my “but for” defense and to establish the basis for my claims. (It contains all the scope I think was missed by the owner)
Again, speaking as a contractor, where cash flow is my biggest concern, I can absolutely promise you that I look at MY schedule (not necessarily the “official” or contract version) on a weekly if not daily basis. Why? Because with single digit EBIT margins, I cannot afford to lose money by inefficient/ineffective deployment of my resources. I must be getting 100% (or better) of my estimated productivity or else I will lose money.
Bottom line- what/how owners use schedules for vs how the contractors use them are quite different and I think in these discussion, it is vitally important that we establish the context or perspective, otherwise our observations or recommendations become less valuable or meaningful.
BR,
Dr. PDG, Jakarta, Indonesia
http://www.build-project-management-competency.com
I hope the work by the CIOB, particularly the new form of contract, removes the need for subterfuge and lets both parties focus on delivering a successful outcome…… but this does require an intelligent client! For more on the CIOB work see: http://www.mosaicprojects.com.au/Resources_Papers_163.html
I agree 100% Pat that what we need are “smarter” clients or maybe “more realistic” would be the better word?
I think there is something fundamentally broken with the traditional Design>Bid>Build (hard money or winner take all firm fixed price contracting) approach, but incentive contracting doesn’t seem to be gaining any real traction, at least not based on what I see.
In particular, I am seeing clients here putting out FFP or Unit in Place RFQ’s with only 60% – 70% scope defined. Then complain when they start getting outrageous numbers of change orders.
BR,
Dr. PDG, Jakarta, Indonesia
http://www.build-project-management-competency.com
@BR. As one whose projects have for the most part (95% plus) been paid for by external customers I agree your approach is a sensible one. Another way to achieve the same sort of thing is to ensure appropriate risk factors have been built into the schedule. One of the challenges with building risk into a schedule is of course managing who gets to know where the risk is embedded. Again if the doers believe there are risk factors built in they are likely to use it up which is not what you want on a tight margin project. One way to mitigate this is to offer them an appropriate project bonus at the end.
As I see it the two other challenges in using the risk factor approach are in the estimating stage:
1. In organisations where there are not solid disciplines between sales and delivery the sales guys will always want a project quoted with zero risk built in.
2. On the other hand if you ask the doers to estimate ie from the bottom up, what tends to happen is risk factors sometimes get added at each level and thus the final price becomes uncompetitive.
My approach has generally been to build a bottom up schedule and estimate asking people to add a risk factor and tell me how much they have added. I then have the option of deciding whether and where to leave the risk factors.
It is surely better to ask people for a range estimate rather than a point estimate. Estimating a range is actually easier. (By way of illustration, without seeing me most readers could estimate my height at between say 5 feet and 6 feet 6 inches, but you would not know I am actually 5 feet 9.)
And you need good tools to process this information because sometimes uncertainty tends to cancel out (when tasks are done in series) and sometimes they tend to compound (when in parallel), and most project networks exhibit a complex combination of these two effects.
The problem is most people think you need more information to make a range estimate than a point estimate… as mentioned in one of your posts (I think) ‘He saw no fundamental irony in his position: Because he believed he did not have enough data to estimate a range, he had to estimate a point’ This is discussed at: /2012/12/12/stakeholders-and-risk-2/
@Tony, I certainly agree that estimating a range is the best approach which I what I am suggesting above, however one also has to be very careful how parameters for the range are set and understood. As you are 5 feet and 9 inches the risk that was embedded in the rage was effectively 3 inches either way which represents 4.5% on the 5 foot 6 inch base figure. (0.25/5.5). So if you had quoted based on the 5ft 6in you would have lost money on the job. On the other hand had you quoted on the 6ft figure your quote may have been uncompetitive.
It is therefore important to try to get an understanding of the likely best and worse case scenarios so that a conscious decision can be made about the risk factor that should be embedded in a quote whilst at the same time remaining competitive.
Bill, I was merely illustrating that it is _easier_ to estimate a range than a point, but if you want to take the analogy further I would probably assume it was a normal distribution and that the limits I suggested were +- 3 sigma, so the sd is 3″. I assume that is what you mean in limiting the options to between 5′ 6″ and 6′, though 1 sd may not be an adequate protection from getting it wrong. But if the project depends critically on my height you would want to firm up on that range. Full Monte does very sophisticated sensitivity analyses (beyond what others do) do that you can identify those factors which are worth further investigation to narrow down the uncertainty. If you only estimated a point you could not do that.
Perhaps I should add that once you have narrowed down all the estimates which you think are worthwhile you will have a rational basis for deciding how much to bid. You might even be able to simulate what your competitors will bid; e.g. larger ones will probably require a smaller risk premium, some may have in-house skills that others need to subcontract, some may do risk analysis and some not, etc. All factors you probably have some, but not precise, information about.
Hi Pat, My opinion is that construction do start to early after placement of an order. It is expected from the client to start construction before design freeze and before all designs are complete. So no planning how good will or what method of planning was used can predict the correct end date. To many changes are made during design phase of a contract with a time loss but is still expected from the contractor to complete the project as been agreed on. This is the main reason why projects do not finish in time.