This is not a collection of articles about communication and documentation in general but rather in the context of planning and scheduling. The required article for this week is Article 5, Project Planning: a Great Communicator, by James Baar, even though Article 8 is really worth reading as well. It promotes this idea of “documenting the schedule basis”, which is actually not new. All other articles address various aspects of communication and documentation in scheduling.
- What Construction Management Seeks in Pictorial Documentation, R. Dennis Foster, 1982 AACE Transactions, A.5, AACE International, Morgantown, WV, 1982
- Meaningful Scheduling Summaries for Management, Robert R. Cook, CCE, AACE Transactions, 1983
- The Daily Report As A Job Management Tool, DA Pogorilich, Cost Engineering , 1992
- Developing an As-Built Schedule From Project Records, John R. Knoke, PE; Gary H. Jentzen, PE, AACE International Transactions, 1996
- Project Planning: A Great Communicator, James E. Baar, PE, AACE International Transactions, 2002
- Electronic Project Documentation: Legal and Practical Problems, James G. Zack Jr., 2002 AACE International Transactions, CDR.06, AACE International, Morgantown, WV, 2002
- Notes from your Technical Board: Construction Document Control, Edward E. Douglas III, Cost Engineering, Vol. 45, No. 04, AACE International, Morgantown, WV, 2003
- Documenting the Schedule Basis, Edward E. Douglas III, CCC, PSP, AACE International Transactions, 2005
- Retrospective As-Built Schedule Development, Anamaria I Popescu; Andrew Avalon, AACE International Transactions; 2005
Project Planning: A Great Communicator by Jame E. Baar, PE is an article where I clearly see the difference between engineers and architects. The engineers seem to be very meticulous when it comes to planning. His definition of interactive planning sessions (IAP), although I have never heard of this seems close to coordination meetings and kick-off meetings I have been a part of in architecture offices.
ReplyDeleteThe goals of IAP do not seem to be uncommon from the goals of most firms I have been a part of but what this article seems to indicate is that using post it notes on white boards (never have seen this), making sure everyone is on-board, openly communicating and being meticulous at every step is sometimes lost in architecture offices. Communication sometimes seems to be the biggest hurdle in architecture office do to personality differences, egos, or do not step on my toes or territory mentality. To be fair does every engineering office succeed in these areas all the time?
Early on in the paper the author states planning is key to any type, any size project. As he describes the IAP, I began to think it would work best for large scale projects. The three phases of IAP consist of 1) pre-interactive phases, 2) the IAP session, and 3) post IAP activities make sense. As I read further I imagined petrochemical plants, agribusiness facilities, infrastructure projects, etc. would benefit from this the most. On the other hand small scale retail facade renovations, new club house buildings, tenant up-fits, and a few single-family detached residential homes would not. As discussed in the mid-term presentation by a fellow classmate a cost benefit analysis of planning should be considered based on the size of the project. On some smaller projects I have done where I was starting out in design development and doing drafting, maintaining daily or weekly contact with consultants, owners, and contractor and in some cases doing the CA never really would have required the level of scheduling he discusses here. Right near the end of the article Baar states this discussion has focused on industrial projects. So I was right on my initial assumption.
I was unclear on what PFD/P&ID meant. I assumed it was related to engineering. I came across Process flow diagrams (PFD) and Piping and instrumentation diagrams (P&ID) on-line that seem to fit in on page PS.01.2? Funny you can do PFD/P&ID sheets on MS Visio 2007 from a site I came across. More slick software?
I was unclear exactly what Level II and Level III scheduling was, so I did an on-line search.
Would anyone agree or disagree with these definitions below?
Web-source 1
Level 2 : This normally is a Project Integrated Schedule - which includes all work broken down into manageable packages, where responsibility, time, cost and resources are embedded in the detail and interfaces between the work packages and functions identified.(Typically 250-300 activities depending on project size of course!)
Web-source 2
A level 3 schedule in planning is one of the 5 levels is common use. Level 1 is the "highest" and shows the main milestones to complete the project. Level 2 shows the scope of work to achieve the milestones, Level 3 shows the deliverables to achieve the scope of work, these three levels are the summary levels. Level 4 shows the tasks or work packs needed to complete the deliverables, and at level 5 the tasks will be fully resourced.
A Level 1 is typically 1 or 2 pages, Level 2 around 50 activities, Level 3 about 250. Level 5 on a large project will be many thousands of activities.
This article reminded me of the team concept review discussed in Owners Reviews of schedules – How Far Should They Go? (Topic 5)
DS
Part 1
ReplyDeleteDocumenting the Schedule Basis by Edward Douglas III, CCC, PSP starts off with a description of a far too common occurrence in the design and construction industry, pumping out a bunch of work that is underutilized, not used properly, or submitted with little or no explanation. In Douglas case he is discussing the Schedule. In my case, I am thinking about hastily thrown together architectural specifications, reiterations of the plan that the owner requests but never comments on, research and investigation into items that never were really intended to be utilized on the project. It is interesting to read that two of the most important elements are the cost estimate and baseline schedule yet the documentation of the schedule falls short in most cases. This is surprising to me when this provides a wealth of information in how to complete the project in a logical order and on time.
AACE International definition for a schedule is as follows, “the plan for completion of a project based on a logical arrangement of activities, resources available, imposed dates or budgets.” Odd contractors would invest less time in this, sounds important.
Douglas lays out clearly what the Format for the Basis of the Schedule is. I will hold onto this article in case I am ever working in a CM firm and I am tasked with doing this. This seems like a perfect example of all the items you might need to cover. I will take his word that this format is similar to the way the cost estimate is done. Reviewing the format makes me think someone with experience would be best suited to handle this?
His Information sources for the Basis of the schedule is a great way to provide additional information without cluttering the Format for the Basis of the Schedule
The definitions of assumptions and constraints under Schedule Impacts and Risks is another reminder of no matter how well you plan something can always unexpectedly go wrong that you do not control but how you react to that most likely defines how well of a manager you are. I think back to comments a former Defense Secretary made about 5 years ago who gave a speech and described known knowns, known unkowns and unknown unknowns.
DS (cont.)
Part 2
ReplyDeleteDouglas states the basis should discuss the software scheduling rules and the use of retained logic vs. progress override as well as logical relationships, lags/leads, and the use of constraints definitely seem to be key aspects not to forget. After reading the article about Boston’s big dig from Topic 5, and the debacle that it seemingly turned into, makes me wonder if they had used the Format for the Basis of the Schedule? If they did not I wonder if using it would have improved baseline vs. revised schedule issues and would recognition of the issue about electrical conduit and cabling in sections that were not done but glossed over when planning part of the dig that required these items beyond parts that were to be built later. Does the human brain have limitations to extremely complex scheduling?
Under Schedule Integration Process the schedule should reflect “engineering procurements, owner furnished fixtures and equipment (FFE), work by other contractors as well as the startup and commissioning by others”, which are all good points to remember. Does FFE differentiate between owner furnished, owner installed (OFOI); owner furnished, contractor installed (OFCI); contractor furnished, contractor installed (CFCI); and contractor furnished, owner installed (CFOI)? This seemed to be important aspect on a higher-end restaurant I worked on in NYC years ago and consumed quite a bit of time of the discussion in meetings but do not recall seeing a schedule even though one was probably made?
Overall the article is a good one that is well worth the read. A quote at the end of the article sums it up nicely, “Schedules are simply estimate of what can be done and (when) it will be done.” In addition the mystic surrounding schedules needs to be removed to make it an effective management tool by the entire project team is quite relevant. Getting people to understand what they are and how to read them might be the biggest issue?
DS
Project Planning: A Great Communicator: This article explains what the author considers to be the optimum method of planning a project. The key to the work process the author refers to is called an Interactive Planning Session or “IAP”. This is essentially a collective and interactive group effort by the client and key team members to develop an accurate and integrated schedule. This is a TEAM scheduling process.
ReplyDeleteIAP Session Goals:
• Realistic work process steps and timelines including milestones
• Facilitate “buy-in” from all team members – each member plans his own tasks with input from team
• Define significant risk issues
IAP Session concept requirements of participants
• True, honest commitment
• Mutual trust – say what you believe
• Interdisciplinary knowledge including technology, size, and complexity
• Listening to all participants so knowledge can be integrated in
IAP Session concept benefits to participants
• All team members share buy-in commitment
• Open communication among all team members
• Respect among team members of others’ expertise and opinions
In an Interactive Planning Session, it is generally the project manager who is charged with defining the goals, and establishing the who, what, where, when, why and how issues. The IAP session itself is a project and is made up of three major phases: the pre-interactive phase, the IAP session itself, and the post IAP phase. The planning phase of the IAP session itself is critical in having a successful IAP.
The overall length of schedule and timeline divisions, the sequence of presentations by each member, scope of the IAP itself, and making certain that deliverables are provided to all participants in an appropriate amount of time before the session are all important parts of the pre-interactive phase. The IAP session itself must foremost identify the client’s needs and only one discussion/focus at a time is discussed. This keeps everyone contributing to the project as a whole on one issue, as opposed to focusing on their own area of responsibility. Guidelines to a successful session include document review/approval times, outage plans, related issues, and maintaining an action item and critical issue list. The post IAP phase is essentially acting on the IAP based on the workflow process. Re-integrating the reality of the project in real time back into the workflow process and moving forward.
In theory, this sounds like the utopian model of a successful project schedule and workflow sequence framework. I have no experience with anything of this scale, but if all parties would actually cooperate in this manner, I can’t imagine a better process. I would be curious if anyone in our class has experience in IAP. I would suspect that egos, jealousies, and power issues can get in the way in the real world as they do in most endeavors. But even given these issues, it still seems like an extremely effective model.
Retrospective As-Built Schedule Development: This to me was a perfect analogy to the Monday morning quarterback analysis of scheduling. This was a breakdown of the as-built schedule for a refinery in Venezuela in support of an international arbitration, two years after the fact. When doing this type of second guessing it is important to distinguish between what was reasonable at the time, as opposed to what is reasonable given the benefit of a historical perspective. This project appears to have been mucked up from the beginning with an abundance of poor planning examples creating (in hindsight) an almost certain delay in project completion.
ReplyDeleteProbably the biggest contributor to the failure of this job to complete in a timely manner was the fact that the project documentation was contained in two separate sources which were not consistent with each other. One was an internet based system comprising more than 175,000 pages of documents with advance Boolean search capabilities and the other was a Microsoft Access database developed by the mechanical contractor. The internet based documentation was not complete and many coding errors were present. The mechanical contractor’s version had inconsistent data formatting between the database tables, meaning the same data would be entered differently in different tables leading to substantial confusion. Other issues were the glaring omissions of material delivery process and punch list process in the original schedule and man hour estimates on many things were extremely inaccurate. The original as-built schedule included only 282 activities whereas the revised schedule identified 1003 – an increase of 721 activities! This appears to clearly be an issue of poor planning contributing directly to the delay of this project.
I was disappointed there was no mention of the actual arbitration outcome as this was the purpose of this particular dissection. It would be interesting to know what the findings were based on the retrospective analysis. I can see how this type of analysis would be a good tool in quality control and production improvement for future projects for any type of contracting company (learn from your mistakes), but in my mind it always comes down to cost benefit analysis. Is the time and effort to break the job down worth the savings on future projects, or are enough lessons learned without it, to make a full breakdown not cost effective.
I browsed Meaningful Scheduling Summaries for Management, Robert R. Cook, CCE, AACE Transactions, 1983 and am not sure if the procurement periods, finish-start activities, and discussion on installation of plumbing, mechanical, and electrical are totally accurate anymore? I thought the Ten-Percent Rule which is “It is virtually impossible to accomplish more than 10 percent of any task per month for any sustained period of time” makes sense for that time period. I am going to disagree with this on the basis of today we have advanced computers and software, CPM has now been around for 30 years longer, and based on these items I would imagine productivity has improved and the ability to find flaws in the CPM. He mentions prior to the 1950s that CPM did not exist. What is still true is that managing time is complex and with projects only growing more complex due to additions to the building codes, LEED, buildings handling extreme weather, etc. the task cannot be left to novices.
ReplyDeleteDS
Response to Documenting the Schedule Basis:
ReplyDeleteOverall I thought this was a very informative article on the criteria that should be recognized in a schedule. Based on the scheduling experiences I’ve had over the years I’ve had the opportunity to work with different phases of the scheduling process which ultimately end up being what an experienced master scheduler’s job would entail. The author has basically taken a compilation of task/requirements that are essential to the success of a schedule and presented a check list. I personally haven’t had the format of a schedule broken down to this level of detail so it has allowed me to re-evaluate jobs from the past as well prepare for future jobs.
I. Job Info.
II. Scope of Work
III. Contract Performance Period
IV. Contract Change Order Process
V. Activity Durations
VI. Resources
VII. Procurements
VIII. Contract Submittals
IX. Safety and Quality
X. Testing and functional checkout
XI. Punch list/Turn-over/System Start-up
XII. Potential impacts and risks
XIII. Schedule Integrations
XIV. Schedule Reporting and Progress Updating
XV. Schedule Techniques and Software
Even though I have been exposed to some of this terminology the true meaning as well as having a practical explanation of what each item pertains to has been some what questionable until now. In doing so, the checklist will allow me to develop future schedules in more detail while still maintaining its effectiveness. From this article I have gained a more in depth approach to producing schedules.
Response to Electronic Project Documentation:
ReplyDeleteIn today’s construction environment the complexity of projects is constantly increasing. Therefore the need for accurate project record documentation is a must. The relevance that proper record documentation has on a project not only deals with its financial health but, it sorts out legal liability issues that often arise. As the author stated electronic data allows for the inner-workings of a project such as schedules, change orders, rfi’s, submittals etc. to be to accessible by all parties who are allowed access and the information is useful. Electronic data also can and will be used in a court of law to assign liability to a party in cases of delays, time extensions, assignment of responsibilities etc.
Based on past experience, I’ve had instances where time extensions were granted based solely on communications via email made between the GC and the sub-contractor. Without this electronic documentation there would be no record of the conversation and it would have been the “he said she said” argument. I have also had instances where submittal data which was electronically documented keep in house engineers accountable if they failed to complete there tasks on time.
The author also made a very important point about the preservation of information whether it’s from emails, spreadsheets, word documents etc. In the construction industry all communication and documentation should always be preserved. I couldn’t agree more with this simply due to the volatile nature of construction in general. It’s not if something will go wrong on a construction project it’s a matter of when and how well you were prepared.
This article also enlightened me on the more technical side of admissible emails in a court of law.
1. A witness or entity received the email
2. The email bore the email address of a certain individual
3. The body of the email specifically denotes the recipients name
4. Email contains data that is exclusive to the sender
5. Recipient has conversation with sender regarding data transfer
Basically electronic documentation is a double-edged sword. It can be of great value but, at the same time can be of great hindrance if not used correctly. Those that choose to maximize it potential will have the upper advantage in many situations that arise in the construction industry while those that are careless with the way they conduct themselves in the industry will be phased out in one way or another.
Electronic Project Documentation: Legal and Practical Problems, James G. Zack Jr.
ReplyDeleteThere is great information within this article concerning the issues with electronic project documentation.
Watch what you put in writing. An Electronic communication (e-mail) is a legal document. I did not know that any and all versions of the email are used. The author calls this “metadata”. I know through my experience that there have been e-mails I have written just to be deleted. If they had been mistakenly sent it would have produced a negative effect on the project.
Relying on one database seems to be a mistake. The fact that you may not be in control of such critical information would trouble me. I want to have direct control of this type of information. Having someone else in control of all of this information is risky because you do not know the level of professionalism of those in charge of the information.
Another major issue raised by this article is the idea of “instant liability.” I had not thought about it in this light, but I now see this crystal clear. The constant need for immediate information and answers to questions, does not allow time to properly think through the issues. Just like the e-mail that gets written just to be deleted, some responses to construction issues need to be expressed and then discarded.
The list of safeguards at the end of the article is important to know. Many of the safeguards are to be considered at the upper management level, but some can be implemented at the staff and mid manager level.
Project Planning: A Great Communicator, by James E. Baar, PE
ReplyDeleteInteractive planning seems to me like common sense. The major parts of the idea are be realistic, get everyone to “buy-in”, define the major issues, have knowledgeable people, listen trust each other and understand the scope. I do think several of the issues and techniques raised are worth using.
No sidebar conversations. This is an issue that happens all of the time when having large meetings. When this is allowed to happen it adds to the length of the meeting by having to go back repeat statements.
Having a different color sticky note for each discipline or stakeholder (including the owner) would produce an easily readable project flow diagram and illustrate the bottle necks in the work progress.
Setting time limits for the planning meeting is a very good idea. Some time it is difficult to set a limit because the project needs the answers from the meeting.
Repeating the meeting for each phase is also a god idea. This would allow for adjustments for newly acquired information of work progress adjustments.
Overall the article provided some useful techniques for me.