Monday

Monthly Archives: December 2016

The origins of PERT and CPM – What came before the computers!

The development of PERT and CPM as Mainframe software systems starting in 1957 is well documented with contemporary accounts from the key people involved readily available.  What is less clear is how two systems developed contemporaneously, but in isolation, as well as a number of less well documented similar systems developed in the same timeframe in the UK and Europe came to have so many similar features.  These early tools used the ‘activity-on-arrow’ (AoA or ADM) notation which is a far from obvious model.  Later iterations of the concept of CPM used the ‘precedence’ notation which evolved from the way flow-charts were and are drawn.

One obvious connection between the early developments was the community of interest around Operation (or Operational) Research (OR) a concept developed by the British at the beginning of WW2.  OR had developed to include the concept of linear programming by the mid-1950s which is the mathematical underpinning of CPM, but while this link explains some of the cross pollination of ideas and the mathematics it does not explain terms such as ‘float’ and the AoA notation (for more on the development of CPM as a computer based tool see http://www.mosaicprojects.com.au/PDF_Papers/P042_History%20of%20Scheduing.pdf).

A recent email from Chris Fostel, an Engineering Planning Analyst with Northrop Grumman Corporation (CFostel@rcn.com) appears to offer a rational explanation.  I’ve reproduced Chris’ email pretty much verbatim below – the challenge posed to you is to see if the oral history laid out below can be corroborated or validated.  I look forward to the responses.

Chris’ Oral History

I was told this story in 1978 by a retired quartermaster who founded his own company after the War to utilize his global contacts and planning skills.  Unfortunately the individual who told me this story passed away quite a few years ago and I’m not sure any of his compatriots are still alive either.  Regardless, I thought I should pass this along before I join them in the next life.  I do not wish to minimize the work of Kelly and Walker. They introduced critical path scheduling to the world and formalized the algorithms.  They did not develop or invent the technique.

The origin of critical path scheduling was the planning of the US Pacific Island hopping campaign during World War II.  The Quartermaster Corps coordinated orders to dozens if not hundreds of warships, troop ships and supply ships for each assault on a new island.  If any ships arrived early it would alert the Japanese of an imminent attack.  Surprise was critical to the success of the island hopping campaign.  The US did not have enough warships to fight off the much larger Japanese fleet until late in the war. Alerting the Japanese high command would allow the Japanese fleet to intercept and destroy the slow moving US troop ships before they had a chance to launch an attack. 

Initially the quartermasters drew up their plans on maps of the pacific islands, including current location and travel times of each ship involved.  The travel times were drawn as arrows on the map.  Significant events, personnel or supplies that traveled by air were shown as dashed lines hopping over the ship’s arrows.  The quartermasters would then calculate shortest and longest travel times to the destination for all ships involved in the assault. The plans became very complicated.  Many ships made intermediate stops at various islands to refuel or transfer cargo and personnel.  The goal was to have all ships arrive at the same time.  It didn’t take the quartermasters long to realize that a photograph of the planning maps would be a devastating intelligence lapse.  They started drawing the islands as identical bubbles with identification codes and no particular geographical order on the bubble and arrow charts. These were the first activity on arrow critical path charts; circa 1942. 

The only validation I can offer you is that by now you should realize that activity on arrow diagrams were intuitive as was the term ‘float.’  Float was the amount of time a particular ship could float at anchor before getting underway for the rendezvous.  Later when the US quartermasters introduced the technique to the British for planning the D-Day invasion the British changed float to “Slack”, to broaden the term to include air force and army units which did not float, but could ‘slack off’ for the designated period of time. 

You will not find a written, dated, account of this story by a quartermaster corps veteran.  Critical path scheduling was a military secret until declassification in 1956.  In typical fashion, the veterans of WWII did not write about their experiences during the War.  No one broke the military secrecy.  After 1956 they were free to pass the method on to corporate planners such as Kelly and Walker.  A living WWII Quartermaster veteran, should be able to provide more than my intuitive confirmation.

This narrative makes sense to me from a historical perspective (military planning has involved drawing arrows on maps for at least 200 years) and a timing perspective.  Can we find any additional evidence to back this up??  Over to you!

The Yin and Yang of Integrated Data Systems

Integrated project management information systems (PMIS) are becoming more common and more sophisticated ranging from ‘web portals’ that hold project data through to the potential for fully integrated design and construction management using BIM[1].  The benefits derived from using these systems can be as much as 20% of the build price on complex construction projects using BIM.

The advantages of this type of information storage and retrieval system include:

  • Ready access to data when needed via PDAs and ‘tablets’ significantly reducing the need for ‘push’ communication and the existence of ‘redundant data’[2].
  • One place to look for information with indexing and cross-referencing to minimise the potential for missed information.
  • Audit trails and systems to ensure only the latest version of any document is available.
  • Cross-linking of data in different documents and formats to assist with configuration management, requirements traceability, and change control.
  • Controls on who can ‘see’ the data, access the data and edit the data.
  • Workflow functions to remind people of their next job, list open actions, record actual progress, etc[3].
  • A range of built-in functions to validate data and avoid ‘clashes’, including locking or ‘freezing’ parts of the data set when that information has been moved into ‘work’.

These benefits are significant and a well-designed system reduces errors and enhances productivity leading to reduced costs, but the ‘yin’ of well-designed PMIS comes with a ‘yang’!

People increasingly tend to believe information produced from a computer system, this is true of ‘Facebook’, Wikipedia and flows through to more sophisticated systems. There also seems to be a steady reduction in the ability of younger people in particular to critically analyse information; in short, if it comes from the computer many people will assume it is correct. Add to this the ability of many of the more sophisticated PMIS tools to transpose and transfer information between different parts of the systems automatically or semiautomatically and there is a potential for many of the benefits outlined above to be undermined by poor data. This issue has been identified for decades and has the acronym GIGO – garbage in, garbage out.

The question posed in this blog is how many projects and project support organisations (PMOs, etc.) consider or actively implement effective data traceability.  Failed audits, overruns from scope oversights, and uninformed or ill-informed decision-making are just a few of the consequences project teams suffer from if they do not have full traceability of their project management data. This issue exists in any information processing system from basic schedule updating, through monthly reporting to the most sophisticated, integrated PMIS. If you cannot rely on the source data, no amount of processing will improve the situation! And to be able to rely on data, you need to be able to trace it back to its source.

Traceability is defined as ‘the ability to trace the location, history and use of each data element’. This sounds simple but in reality can be very challenging, and the results of poor visibility can be devastating to a project. Some of the key questions to ask are:

  • Where did this data or these actuals come from?
  • What is the authorizing document and when did it get signed/approved?
  • Has everyone approved the change request or action item?

Traceability does not happen by accident! Project management information systems have to be designed with traceability as a key element in each of its aspects.  As information comes into the system the author or the origin of the information has to be recorded (preferably automatically). Depending on the nature of the information it may need to be quarantined until appropriate checks have been carried out and/or approvals have been obtained and then there needs to be traceability of any subsequent changes. The foundation of traceability is the combination of processes (people) and data management.

Therefore, the ‘yang’ of a sophisticated integrated project management information systems is that as the systems become more integrated and sophisticated people will come to rely on the information provided and ‘trust it’ whilst the source and veracity of the data used becomes less obvious.

Resolving this is partly process and partly people. The Chartered Institute of Building (CIOB) has produced the Time and Cost Management Contract Suite 2015 focused on complex construction projects using BIM.  This contract defines a number of key support roles (largely independent of the parties) focused on managing the information flows into and out of the system to ensure its accuracy and validity. Similar roles and responsibilities are essential in any effective PMIS.

My latest post on the PMI ‘Voices blog’, From Data to Wisdom: Creating & Managing Knowledge highlights the importance of data as the underpinning of all reporting and communication.  So the question is, how much focus does your project team or PMO put on ensuring the data it is using is timely, complete, accurate and traceable?

____________________

[1] BIM = Building Information Modelling, see: http://www.mosaicprojects.com.au/WhitePapers/WP1082_BIM_Levels.pdf

[2] For more on planning project communication see: http://www.mosaicprojects.com.au/Mag_Articles/ESEI-09-communication-planning.pdf

[3] A discussion on how these capabilities can enhance project controls is at: /2016/11/26/the-future-of-project-controls/

New Articles posted to the Web #56

We have been busy beavers updating the PM Knowledge Index on our website with White Papers and Articles.   Some of the more interesting uploaded during the last couple of weeks include:

And we continue to tweet a free PMI style of exam question every day for PMP, CAPM, and PMI-SP candidates: See today’s question and then click through for the answer and the Q&As from last week.

You are welcome to download and use the information under our Creative Commons licence

USA moving to formalise project and program management capabilities

The concept of professional project management is gathering pace. The USA Government’s Program Management Improvement and Accountability Act of 2015 (PMIAA) was unanimously passed by the US Senate by in November 2015, and was passed by Congress in September 2016 on a 404-11 vote.  Because Congress made some minor changes, it now has to was returned to the Senate before it can be and signed into law by the President on the 14th December 2016 (see comment below).

The Act requires the Deputy Director for Management of the Office of Management and Budget (OMB) to:

  • adopt and oversee implementation of government-wide standards, policies, and guidelines for program and project management for executive agencies;
  • chair the Program Management Policy Council (established by this Act);
  • establish standards and policies for executive agencies consistent with widely accepted standards for program and project management planning and delivery;
  • engage with the private sector to identify best practices in program and project management that would improve Federal program and project management;
  • conduct portfolio reviews to address programs identified as high risk by the Government Accountability Office (GAO);
  • conduct portfolio reviews of agency programs at least annually to assess the quality and effectiveness of program management; and
  • establish a five-year strategic plan for program and project management.

The Act also requires the head of each federal agency that is required to have a Chief Financial Officer (other than Defence which has its own rules) to designate a Program Management Improvement Officer to implement agency program management policies and develop a strategy for enhancing the role of program managers within the agency.

The Office of Personnel Management must issue regulations that:

  1. identify key skills and competencies needed for an agency program and project manager,
  2. establish a new job series or update and improve an existing job series for program and project management within an agency, and
  3. establish a new career path for program and project managers.

And finally, the GAO must issue a report within three years of enactment, in conjunction with its high-risk list, examining the effectiveness of the following (as required or established under this Act) on improving Federal program and project management:

  • the standards, policies, and guidelines for program and project management;
  • the strategic plan;
  • Program Management Improvement Officers; and
  • the Program Management Policy Council.

When enacted the Act will enhance accountability and best practices in project and program management throughout the federal government by:

  1. Creating a formal job series and career path for program/project managers in the federal government, to include training and mentoring – PMP, PMI-SP and similar certifications will become increasingly important!
  2. Developing and implementing, with input from private industry, a standards-based program/project management policy across the federal government.
  3. Recognizing the essential role of executive sponsorship and engagement by designating a senior executive in federal agencies to be responsible for program/project management policy and strategy.
  4. Sharing knowledge of successful approaches to program/project management through an inter-agency council on program and project management.
  5. Implementing program/project portfolio reviews.
  6. Establishing a 5-year strategic plan for program/project management.

You can read the text of the Act here, and stay up-to-date on the Act’s progress here.  The approach USA is aligned with regulatory actions in both the UK and the EU to require government agencies to improve project and program delivery. If this trend continues hopefully the ‘accidental’ project manager / sponsor will be consigned to history and the use of qualified professionals will become the norm.

Follow these links for more on achieving your PMP credential of PMI-SP credential.