PROJECT MANAGEMENT REFERENCES

PROJECT MANAGEMENT REFERENCES IGNACIO MANZANERA

2011

Foreword The US Navy, the US Department of Defense (USDOD) and the Software Engineering Institute (SEI) are responsible for giving the project management community most of the available project management skills are helping us so much these days, but from the originally documented steps required to make them work, unscrupulous professionals have intentionally dropped that concerted effort between consultants, contractors and subcontractors which render available project management systems handicapped right at the start. Although project owners and investors are always paying for state-of-the-art consultancy services, they are not getting them mostly due to false premises such as: • • • • • • • •

Lack of executives training on the subject; Lack of knowledge on required consultants and contractors' deliverables; Poor contracting practices; "Lack of time" statements; "it is not needed for this kind of project" statements; "I experienced it in another project and it does not work" statements; "It will add unnecessary costs to the project" statements; and "Paper work can handle everything and it is very different from real life" statements.

When NASA, the largest contracting organization on earth, back in the early 1980's, was in a bit of pickle due to corruption scandals on how they conducted projects, they call on IBM and McDonnell Douglas to design a system able to control contractors and subcontractors properly and more importantly providing the institution with the right to know about its investments. As a result, a program called the Master Scheduling and Control System (MSCS) was implemented for computer mainframes. Later on, computers lap and desktop adopted the MSCS (a.k.a. earned value analysis) approach to come up with outstanding programs like Primavera and MS Project which represent the current project management state-of-the-art reinforced with the use of powerful web-based databases such as Oracle and SQL. They are here to protect your investment and protecting it has been a clear goal since we started working on this book. We certainly hope the book will provide project owners, contractors and any kind of project stakeholders enough knowledge on tools and techniques that most likely will save them a lot of trouble and more importantly a lot of money.

2

Table of Contents (1 OF 5) Subject

Page

Chapter I Phases of the Engineer’s Work Engineer’s Obligations to the Owner Engineer’s Liability to third Parties Engineer’s Inspection Responsibility Engineers Role in the Claims Process

8 10 18 22 31

Chapter II Projects Planning Project Management Structure Project Life Cycle

39 43 44

Chapter III Detailed Planning and Scheduling Critical Path Method (CPM) Network Analysis of Engineering Projects The Original Schedule Analysis The Network-Based Approach

48 51 58 59 64

Role of Networks in the Engineering Management System Network Construction LAG Factors Networks Level of Detail Scheduling Expressions

65 65 66 67 71

3

Table of Contents (2 OF 5)

Subject

Page

Chapter IV Project Scope Management Project Scope Statement Project Objectives Project Scope Definition Project Configuration Management Requirements

75 76 78 79 81

Project Scope Statement Approval Process WBS How to Decompose a project Progressive Elaboration WBS Dictionary Controlling Scope Creep

82 86 95 96 97 101

Chapter V Procurement Management Project Procurement Financial Implications Procurement Engineering Value Analysis Procurement Measurement

104 107 108 111

Chapter VI Contracting Management Parties to a Contract Contract Strategy Successful Contracting Attributes Contracting Clauses

114 115 116 117 120

Forms of Contract Typical Contracts used in the UK and the USA Recommendation for Additional Contract Clauses

125 130 132

4

Table of Contents (3 OF 5) Subject

Page

Chapter VII Cost Management – Cost Estimating Estimating the Total Cost of Ownership Cost Estimating and the Project Life Cycle Rolling Wave Planning Who is responsible for Cost Estimates

140 142 143 147 148

Common Estimates Errors Cost Drivers Analogous Estimating Parametric Estimating Bottom-up Estimating

149 150 154 155 156 157

Supporting Tools and Techniques of Cost Estimating

Chapter VIII Cost Management – Cost Budgeting Baseline Spend Curve Cost Budgeting Process Tools Management Reserve

166 167 169 174

Chapter IX Cost Management – Cost Control Project Cost Control Process Performance Measurement Analysis Earned Valued Management System (EVMS) Analyzing Cost and Schedule Variances

180 181 181 186 194

EVMS diagram Importance of early Analysis Other Performance Measurement

196 199 200

5

Table of Contents (4 OF 5) Subject

Page

Chapter X Project Quality Management Quality Assurance and Quality Control Quality Assurance Examples Five Steps to Free Quality Project Managers Competency Model

204 206 207 209 212

Why Project Management? The Objectives of PM Direction

217 217

Chapter XI Risk Management Typical Risk Categories Risk Management Plan Checklist Qualitative Risk Analysis Quantitative Risk Analysis Expected Monetary Value Analysis Strategies for Negative Risks or Threats PM Risk Mitigations Strategies Organizational Risk Mitigation Strategies Technical Risk Mitigation Strategies

220 222 238 243 246 249 253 255 256 257

Risk Register Worksheet Sample Minimum Requirements for Managing Project Risk Risk Monitoring and Control – Best Practices Technical Performance Measurement

260 261 263 265

6

Table of Contents (5 OF 5) Subject

Page

Chapter XII Project Communications Management The Communications Planning Matrix Communications Plan Checking for Completeness Information Distribution Meeting Management

267 276 282 283 288

E-mail Communications Tips Performance Reporting Process Tools Common Performance Reporting Formats

291 299 303

Chapter XIII Project Human Resources Management Maslow’s Hierarchy of Needs Theory Herzberg’s Motivation-Hygiene Theory Mclelland’s Acquired-Needs Theory McGregor’s X and Y Theories

312 314 315 316 317

Ouchi’s Theory Z Leadership, Collaboration and Technical Skills Human Resources Planning Acquire Project Team Process Virtual Teams Five-step Model for Team Development Team Building Activities Myers Briggs Type Indicator (MBTI) Wilson Learning Social Styles Profile Managing a Project Team Conflict Management

318 320 321 326 327 333 337 337 339 342 345

Attachments: Disk 1: 134 Project Management Forms (in excel, ready-to-use), Capital Projects Components Checklist (60+ worksheets with Project Components in Civil, Mechanical, Electrical, Instrumentation, etc. in excel), Project Management Workbook with useful project management Tools, 12 templates for project management processes development, PM 600 questions and answers Presentation in Power Point, Planning & Scheduling 250 questions and answers presentation in Power Point. Feasibility Study procedure including forms in excel to complete it.

7

Chapter I Construction Process Phases of the Engineering Work As design professionals, architects and engineers (engineers) play a unique role in the construction process. On a typical project, the engineer is the only party other than the project owner who is actively involved from beginning to end. The engineer’s responsibilities typically span the three project phases described below. It is important to note, however, that it is not unusual for engineer’s to be retained for only one or two of the project phases. Planning Phase The planning phase of the project usually involves an examination of the general feasibility of the owner’s desires as well as an examination of where and how the project will be constructed. Central to all these considerations is the issue of project budget. The engineer’s design expertise enables him or her to advise the owner of whether certain sites under consideration can physically accommodate the intended structure. Additionally, there is the question of land use regulations and other necessary permits and licenses. In conjunction with evaluation of potential sites, there is an evaluation of the various ways of designing and constructing the facility. Developers usually have rather specific ideas about what they want the facility to be capable of, but they look to the engineer for advice on how to accomplish this. The three competing considerations are function, appearance, and cost. The engineer is best equipped to assist the project owner in arriving at a design and a site that will satisfy the owner in all three considerations. Sometimes the owner is committed to a single site and the design must accommodate the site. Other times the owner has a number of site options and can be more rigid in its design scheme, seeking out a site that will accommodate the design. One of the engineer’s most important planning phase responsibilities is to estimate the total cost of certain designs under consideration. This is difficult, as these designs are extremely cursory and conceptual at this point. The owner cannot start to make intelligent decisions, however, until it has an idea of how much a particular project might cost. Furthermore, construction financing will not be available unless the owner is armed with reliable estimates of construction cost. An estimate of the necessary construction schedule goes hand in hand with the cost estimate, as time truly is money in the construction industry. When a project has been thoroughly planned, the owner should have a designated site and be familiar with the physical characteristics of the site, including subsurface conditions.

8

The owner should know that the intended project complies with all land use regulations and other permit requirements. The owner should also have cost and schedule estimates for construction of the facility as conceptualized. The owner is then in a position to go to a lender and seek construction financing. The owner will typically look to its engineer to pull this entire package together. Frequently, the assistance of other professionals such as attorneys, scheduling experts, estimators, and geotechnical specialists is required. The engineer is usually the party responsible for coordinating their efforts, however, in order to come up with a project plan. Design Phase The design phase of the project usually progresses from preliminary design to detailed working drawings sufficient to put out to bid. As this process unfolds, the twin considerations of cost and schedule are always present. Very few project owners start out with an ironclad view of what they want. Most owners are subject to budgetary and/or scheduling restrictions. As the plans progress from the conceptual or preliminary stage to the final stage of working drawings, these considerations come into play. A detailed description of the design process is outside the scope of this book. Two issues, however, must be stressed at this time. One is the engineer’s responsibility for the work of consultants and the other is the definition of the engineer’s design responsibilities. It is customary for the prime design professional, be it an architect or an engineer, to utilize the skills and knowledge of a number of experts from specialized disciplines. Sometimes these disciplines are available within the prime designer’s own firm. Other times they are hired as “consultants” or subcontractors. Just as the prime construction contractor is fully responsible for the work of its subcontractors, the prime design contractor is fully responsible for the adequacy and competency of the work of its consultants. If a consultant makes a mistake, the prime design contractor will be just as liable to the project owner as it would be had it made the mistake itself. This fact points to the need to be very cautious in selecting consultants to use in the design process. It also points out the need to see that consultants carry adequate levels of professional malpractice insurance and agree to indemnify the prime designer in the event of a claim involving the adequacy of the consultant’s work. The improper selection, monitoring, and coordination of consultants is a major source of problems during the design phase.

9

The other important issue to keep in mind regarding the design phase is the definition of the engineer’s scope of work. The agreement between the project owner and the engineer should precisely spell out the engineer’s responsibilities. If the engineer is being asked to rely on certain information such as a survey, the agreement should so state. In fact, any time an engineer is asked to utilize data which the engineer is not being hired to verify independently, the agreement should indicate that the engineer is relying on the accuracy and adequacy of this owner-furnished This concern should always be paramount in preparation of an engineer agreement. If the scope of work is not detailed and precise, how can anyone determine if a particular item is extra work? More important, if a problem develops, how will it be determined whether the engineer was responsible for dealing with this particular matter?. A well-conceived, detailed scope of work can save the engineer a world of trouble as the design phase progresses. Construction Phase The engineer’s responsibilities during the construction phase of the project vary greatly. It is therefore important again to have a detailed scope of work, as this will be relied on to determine responsibility and liability if a problem arises. The engineer’s construction phase responsibilities usually begin with preparation of bid packages. These consist of the final plans and specifications, the construction contract, the general conditions, bid forms, and instructions to bidders. Bids are solicited by advertisement or otherwise, and bid packages are given to prospective bidders. Prior to bid opening, the engineer may be responsible for issuing amendments to the bid package and conducting pre-bid site inspections and pre-bid construction meetings where bidders’ questions are answered. When bids are opened, the engineer frequently serves as the owner’s representative, determining the low bidder and announcing the contract award. Once work begins, the A/F usually monitors the contractor’s performance. This is the riskiest and most controversial aspect of the engineer’s construction phase services. It will be addressed in detail later in this chapter. When work is complete, the engineer conducts a final inspection, prepares a punch list of remaining items, authorizes release of final payment, and otherwise assists the owner with the tasks of closing out the project. If all goes reasonably well, the engineer has the satisfaction of guiding and participating in the project from its earliest conceptualization through detailed design, construction, and completion. The engineer has been instrumental in turning vague ideas into a functioning physical facility.

10

Engineers obligations to the owner A engineer on a typical project is wearing several hats. First and foremost the engineer is usually functioning as an independent professional, providing services for a fee. The engineer also functions from time to time as an agent of the owner and as an arbitrator of disputes between the owner and the contractor. The engineer’s role as agent and arbitrator will be discussed in the claims process section at the end of this chapter. This section of the chapter will focus on the engineer’s professional obligations to his or her client, the project owner. Standard of Care The engineer’s obligation is to exercise the degree of care, skill, and knowledge that is generally expected within the profession. This is true during all three phases of the project. It is the same standard applied to doctors, lawyers, and other providers of professional services. An engineer’s service or advice need not reflect superlative brilliance in the field, but it must meet a certain minimum level of expertise that is vaguely defined as “acceptable” or “average.” When performing design calculations, for instance, the engineer must follow certain procedures that are generally accepted in the profession. The failure to do so will probably be considered negligence or professional malpractice. It is important to note that an engineer who holds himself or herself out as possessing particular expertise in a field will be held to a standard of care applied to such experts. For instance, if a civil engineer takes it upon himself or herself to evaluate subsurface data or perform structural calculations, the civil engineer will be expected to possess and exercise the same degree of care, skill, and knowledge expected of a geotechnical engineer or a structural engineer. Once an engineer undertakes a particular endeavor, it is no excuse to later argue this was really outside the engineer’s field of expertise. This explains the widespread use of technical consultants and subcontractors. Over the years, a few court decisions have held that an engineer extends an implied warranty that its design documents are complete and accurate and suitable for their intended purpose. Although doctors and lawyers have never been asked to warrant the successful outcome of their services, some courts have reasoned that the design professions are more empirical and more subject to perfection. These court decisions have been greeted with alarm in the design professions. It must be stressed, however, that these decisions are anomalies. They do not represent the mainstream of judicial thinking regarding the engineer’s standard of care. In the absence of contractually assumed liability, which is discussed below, the engineer is held only to a

11

standard of due care and that standard is measured by the skills and knowledge of the average practitioner. This is the rule that is applied in virtually every jurisdiction in the United States. Cases imputing an implied warranty have been overruled, discredited, or limited in their effect. CASE STUDY1 Owner awarded Contractor a contract for construction of a sewer project. The contract stated that neither Owner nor Engineer assumed responsibility for Contractor’s ability to meet the specified infiltration limits and if Contractor felt the design was inadequate to meet the limits, Contractor must notify Engineer in writing. Contractor was unable to meet the infiltration limits. Contractor sued Owner for breach of implied warranty of the specifications and sued Engineer for negligent preparation of the specifications. Defendants relied on the disclaimer in the construction contract. The Appellate Court of Illinois ruled that all owners extend an implied warranty to contractors that the plans and specifications are accurate, complete, and suitable for the completion of the project. The engineer in turn assumes a duty to prepare design documents that meet this standard. These fundamental obligations cannot be disclaimed or shifted to the contractor. The language in the contract was unenforceable.

1

W.

H. Lyman Construction Co. v. Village of Gurnee. 403 N.E.2d 1325 (Jll.App. 1994).

12

Engineer’s Contractual Obligations In addition to the engineer’s general obligation to exercise due care, the engineer has a number of specific contractual obligations established in its agreement with the project owner. An architectural or engineering services agreement bears little resemblance to a construction contract. To begin with, it is always negotiated, not competitively bid. Additionally, there are not the large number of contingencies that need to be addressed in a construction contract. A typical engineer agreement addresses the basic issues of fee, schedule, insurance and use of consultants. The agreement then devotes most of its space to defining the scope of the engineer’s work. As mentioned earlier, the definition of the scope of work is crucial in defining the engineer’s contractual obligations. Without a detailed, complete, and understandable scope of work, it is impossible to determine where the engineer’s responsibilities began and where they ended. It is also impossible to identify and recover payment for extra work items not included in the original scope. Most engineers use a standard, preprinted form of agreement for their contracts with project owners. This may be a form prepared by their attorney for their use, or it may be one of the forms published by the professional organizations. Both the American Institute of Architects and the Engineers’ Joint Contract Documents Committee publish such forms. These forms have been officially approved by their respective organizations, and they avoid the serious pitfalls of engineer agreements that are described below. There are two serious pitfalls that should be avoided by engineers when entering into agreements with project owners. They are two forms of contractually assumed liability: warranties and indemnification clauses. As described earlier, courts have refused to read an implied warranty into an engineer agreement. The engineer has a duty to exercise due care in carrying out his or her professional responsibilities, but the engineer does not impliedly warrant to the owner that the work product is flawless or will accomplish everything the owner wanted.

13

CASE STUDY2 Owner retained Engineer to design wastewater treatment plant. Engineer based design on use of cement-bentonite slurry wall. Engineer relied on Supplier’s representations regarding the compressive strength of the product and conducted no independent investigation into the properties of the product. The wall failed and caused extensive damage to the treatment plant. Owner sued engineer for professional malpractice. The U.S. District Court ruled that Engineer failed to exercise the skill and judgment expected of a design professional. And engineer does not guarantee the sufficiency of its design. Nor is an engineer expected to conduct and extensive independent testing program on every product it specifies. It was negligent, however, for this engineer to blindly rely on Supplier’s representations without checking some independent verification. Even though courts have refused to find an implied warranty, it is still possible for the engineer to extend an express, or written, warranty to the owner. This is seldom labeled as a warranty in the engineer services agreement, but it occurs nonetheless. For instance, the designer of an industrial facility may be asked to guarantee that the facility as designed will be capable of meeting certain performance standards. This would be considered an express warranty. The problem with warranties is twofold. First of all, an engineer may exercise due care and even professional excellence at all times, and still have a project fall short of expectations because of variables beyond the engineer’s control. With a warranty, the engineer is liable nonetheless, and this greatly expands the engineer’s liability exposure.

2

City of Columbus v. Clark-Dietz & Associates—Engineers. Inc..550 F.Supp. 610 (N.D.Miss. 1989).

14

The second problem with warranties is insurance coverage. There simply isn’t any. The insurance companies who write ‘errors and omissions” or professional malpractice policies for engineers are alarmed at any contractually assumed liability. They are only willing to cover the risk that the engineer will fail to meet the required professional standards. The policies invariably exclude coverage for liability resulting from warranties. It is therefore in the best interest of the owner and engineer that warranties be kept out of the agreement. The second form of contractually assumed liability is the indemnification clause. Again, the problems are the expansion of liability exposure and the lack of insurance coverage. An agreement to indemnify another party is an agreement to protect them, pay them, and otherwise make them whole in the event a claim is asserted against them. To the extent the indemnification clause is limited to claims against the owner arising solely out of the engineer’s negligence, this is not a problem, as the engineer would be liable for its negligence anyway. The problem is that indemnification clauses are frequently written in such a way that the engineer’s liability is contractually expanded to include claims not arising out of its own negligence. The most common example is the indemnification clause referring to claims arising “in whole or in part” from the engineer’s services. In other words, the engineer may be 10 percent responsible for the problem, but it has agreed to fully compensate the project owner. As with express warranties, insurance companies are not willing to cover expanded liability resuting from indemnification clauses. There are almost always exclusions in the insurance contracts, although these exclusions can sometimes be removed or reduced through the purchase of indemnification riders. While on the subject of contractually assumed liability, there is one other topic which should be addressed. This is the engineer’s effort to contractually limit its liability for its own negligence.

15

These “limitation of liability clauses” typically state that the engineer’s liability to the owner shall not, under any circumstances, exceed a certain stated amount. The use of these clauses, which are legally enforceable, has been pushed by some engineer insurance carriers and professional associations. Just as engineers and their insurers have been reluctant to agree to a contractual expansion of engineer liability, project owners have been reluctant to agree to the contractual limitation of the engineer’s traditional liability. It is fair to say that the use of limitation of liability clauses is not gaining widespread acceptance in the industry.

Sufficiency of the Plans and Specifications Probably the single most important obligation the engineer has toward the project owner is the obligation to prepare a complete, accurate, and unambiguous set of plans and specifications. It was stated earlier that implied warranties are not read into engineer service agreements. It is so well established, however, that an engineer has a professional obligation to produce sufficient plans and specifications that it almost raises to the level of an implied warranty. The plans and specifications should not omit anything that is necessary or include anything that is redundant. They should be free of conflicts and ambiguities. They should be accurate regarding existing site conditions. And it should be possible to construct the project as designed using commercially acceptable construction methods in order to end up with a functioning facility. As will be seen later, the sufficiency of the plans and specifications is crucial regarding the engineer’s liability to the owner, the owner’s liability to construction contractors, and the engineer’s liability to construction contractors.

16

Liability for Cost Estimates It is common, at the planning stage of a project, for the owner to tell the engineer that there is a certain maximum budget for the project. This is obviously a crucial consideration throughout the design phase of the project. The engineer must estimate the construction cost of the facility he or she is designing. This is difficult, because it involves assessing such intangibles as the local competitive bidding climate. The question arises, what happens when all the bids or quotations come in and the project, as designed, is over its budget? What are the engineer’s responsibilities in this situation? To begin with, the engineer is expected to use ordinary professional skill in estimating construction costs but is not expected to predict costs with dead accuracy. It is unusual for a construction cost overrun to be successfully asserted as a malpractice claim against an engineer. Most engineer service agreements address this issue. Typically, they state that the engineers so1e responsibility if bids come in over budget is to provide redesign’ work at no additional charge in order to bring the project within budget. The engineer cannot be held liable for monetary damages. Sometimes the agreement will state that the engineer’s obligation to provide free redesign services will accrue only if the low responsive, responsible bid exceeds the budget by a certain stated percent. In any event, the engineer’s obligations in this situation should be expressly established in the engineer service agreement.

17

Engineers Liability to third Parties Traditionally, the engineer’s only responsibilities were owed to the project owner, the client with whom the engineer did business. Evolving legal trends have changed all that. Along with every other participant in our economy, the engineer now finds itself exposed to liability to third parties with whom the engineer never did business. The Demise of “Privity” “Privity of contract” means that a direct contractual relationship exists between two parties. They have entered into an agreement. Traditionally, the law held that an engineer could not be sued by a construction contractor or any other third party not in privity with the engineer. The engineer’s professional obligations were owed strictly to its client, the project owner. It was the owner that the engineer contracted with and the owner who paid the engineer. Therefore, the engineer need consider only the interests of the project owner. The past 40 years have seen the near total demise of privity as a requirement for maintaining a lawsuit for commercial damages. The trend began in the context of product liability litigation and spread to every area of law including engineer liability. Today, it is safe to say that the lack of privity of contract will rarely protect an engineer in a suit alleging the negligence or professional malpractice of the engineer. As a result, engineers are being sued by contractors, subcontractors, bonding companies, construction lenders, and other parties on the construction project with whom the engineer has no contractual relationship.

18

Foreseeable Harm With the demise of privity the new operative phrase is “foreseeable harm.” Today’s rule can be summarized as follows: In carrying out its professional responsibilities, the engineer has a duty to exercise ordinary ski1l and due care. This engineer’s duty is owed to all parties who could foreseeably suffer economic harm as a result of the engineer’s failure to exercise due care. If one of the parties is harmed, as a result of the engineer’s lack of due care, that party may maintain an action against the engineer for negligence. CASE STUDY3 Mechanical Engineer prepared drawings pursuant to agreement with Owner. Contractor later complained that the drawings were inaccurate and sued Engineer for the increased cost of performing the construction work. Engineer responded that its only obligation was to its client, the Owner. Engineer said it had no contract, and therefore no legal obligations, with regard to Contractor. The Superior Court of New Jersey ruled that Contractor could sue Engineer for its increased costs. Privity of contract is no longer required in order to maintain a suit of this nature. engineers may be held liable to any party for the economic consequences of their professional negligence if it was reasonably foreseeable that the injured party would be affected by the engineer’s performance of its professional duties. Common Claims against Engineers The most common source of third-party claims against engineers is the engineer’s inspection and certification role in the construction process. This is discussed in detail below. The other two common sources of third-party claims are design deficiencies and delayed response to request or submittals.

3

Conforti & Eisele, Inc. v. John C. Morris Associates, 418 A.2d 1290 (N.J.Super. 1992).

19

Design deficiencies would include inaccuracies or conflicts in the plans and specifications, as well as any insufficiencies in the design documents. The plans and specifications must be complete and sufficient so that if they are adhered to by a construction contractor, a complete, operational project will result. Contractors are entitled to rely on the plans and specifications when bidding and planning a job. To the extent design deficiencies increase the cost of the contractor’s performance, the engineer may well be held liable to the contractor. An engineer’s delayed response to requests or submittals is another source of claims by contractors. When a contractor seeks clarification or direction from the engineer when faced with an unanticipated problem, the engineer has an implied obligation to respond within a reasonable period of time. If the engineer does not and the lack of a response delays the contractor or extends its total performance time, the engineer may be held liable to the contractor for its delay damages. Submittals typically involve product catalogs, shop drawings, and other things that must be approved by the engineer before the contractor incorporates them into the project. Sometimes the construction contract stipulates that these documents will be turned around in a certain minimum time. Even if the contract contains no such provision, there is an implied obligation for the engineer to make a decision within a reasonable period of time. Prompt decisions on these matters are frequently crucial to the contractor’s ability to maintain its schedule. Engineers are also called upon to make decisions regarding contractors’ change order proposals. This will be discussed at the conclusion of this chapter.

20

CASE STUDY4 Engineer prepared plans and specifications for wastewater treatment plant pursuant to agreement with Owner. The specifications required certain internal components in the sludge pumps. Contractor prepared its bid in reliance to a quotation from Supplier. Engineer refused to accept the particular model pump being offered. Supplier had to furnish Contractor with a more expensive pump in order to obtain Engineer’s approval. Supplier then sued Engineer for the increased cost, arguing that Engineer had negligently drafted and incorrectly interpreted the specification. Engineer responded that it owed no duty to an equipment supplier. The Court of Appeals of Minnesota ruled that Engineer did owe Supplier a duty to exercise due care in the drafting and interpretation of specifications. An engineer’s obligation to exercise appropriate professional skill and judgment extends to all parties who may foreseeably rely on the engineer’s services.

4

Waldor Pump & Equipment Co. v. Orr-Schelen-Mayeron & Associates. Inc.. 386 N.W.2d 375 (Minn.App. 1996).

21

Engineer’s Inspection Responsibility During the construction phase of a project, it is common for the engineer to inspect the contractor’s work on behalf of the project owner. This gives rise to questions regarding the scope of the engineer’s inspection responsibilities and the engineer’s liability for shortcomings in carrying out those responsibilities. Scope of Responsibility The scope of the engineers inspection responsibilities is primarily established in the written agreement between the engineer and the project owner. A very precise and well-considered scope of work is therefore necessary in order to avoid misunderstanding on the owner’s part and unintended liability exposure on the engineer’s part. Very few owners are willing to pay an engineer to station personnel at the job site 50 or 60 hours a week to observe every move of the contractor. Nor are owners willing to pay to have every piece of material used by the contractor laboratory-tested. Most owners are seeking periodic inspection of the work. The owner-engineer agreement should reflect this. The scope of work should be explicit as to how many times a week or a month the engineer is expected to visit the site. If particular materials or installations are to be tested, this should be clearly spelled out. The agreement should then make it clear that the engineer’s inspection and testing responsibilities do not extend beyond those specifically listed and the engineer does not guarantee the sufficiency of the contractor’s work.

22

CASE STUDY5 Contractor awarded purchase order to Fabricator for exterior metal stairway. Fabricator submitted shop drawings to Contractor, who in turn submitted the drawings to Architect for approval. Architect was slow reviewing the shop drawings. The delay increased Fabricator’s costs. Fabricator sued Architect for unreasonably withholding approval of the shop drawings. Architect argued that its only duty in reviewing shop drawings was to protect the interests of its client, the Owner. The Court of Appeal of Louisiana disagreed. It was foreseeable that subcontractors such as Fabricator would be economically affected by Architect’s performance of its functions. Architect therefore owed a duty to those parties to exercise due care in carrying out its responsibilities. In recent years, a somewhat semantical debate has arisen regarding the use of the term “monitoring” rather than “inspection.” The rationale is that if an engineer “inspects” the work, the engineer will be liable for failing to detect problems, whereas if the engineer only “monitors” the work, it will be held to a lower standard of observation. This distinction has its genesis in several arcane court decisions, but it is generally lacking in validity. It is unlikely that a modern court would allow the question of an engineer’s liability to turn on the use of the verb “inspect” rather than ‘monitor.” There is certainly no harm in the cautionary use of the term “monitor.” Many engineers influenced by their liability insurers, have become more comfortable with this parlance. This is fine, but engineers should not be lulled into believing that the use of the term “monitor” will excuse the failure to meet professionally accepted standards or otherwise lessen their obligations. Even if the owner-engineer agreement calls for the engineer to monitor the contractor’s work, the engineer will still be required to authorize release of payments and acceptance of the work. This authorization requires an affirmative determination on the part of the engineer. The engineer will not be able to hide behind the somewhat passive connotations in the term “monitor.”

5

Gurtler, Hebert & Co., Inc. v. Wevland Machine Shop. Inc.. 405 So.2d 660 (La.App. 1991).

23

CASE STUDY6 Owner awarded architectural agreement to Architect using the AIA Standard Form of Agreement between Owner and Architect. Architect prepared specifications requiring liquid mortar to be poured in a particular fashion. Contractor had trouble with the pours and poured mortar in a manner that deviated from the specifications. Architect observed these pours but did not object. When the walls developed problems Owner sued Architect for failing to inspect Contractor’s work in the manner required by the AIA architectural agreement. The Supreme Court of Arkansas noted that the AIA agreement does not require the architect to make continuous or exhaustive inspections and does not make the architect the guarantor of the contractor’s compliance with the plans and specifications. However, the agreement does require the architect to “guard the owner against defects and deficiencies in the work.” If Architect observed nonconforming work being performed and failed to object, Architect breached its inspection duties under the agreement. Engineers who are concerned about the liability exposure arising from construction activities should focus their attention on the preparation of a detailed, explicit scope of work in the owner-engineer agreement. This is the best precaution to take against expansive liability exposure. Conformance with Plans and Specifications One of the engineer’s primary inspection responsibilities is to determine whether the contractor is conforming to the plans and specifications for the project. The owner is entitled to strict conformance with the plans. This is what the owner is paying the contractor for. If the contractor is deviating from the plans and specs, it is important for the owner to know so that the owner may take protective measures such as withholding payment.

6

Dan Cowling & Associates, Lnc. v. Board of Education of Clinton District School, 618 S.W.2d 158 (Arkansas 1981).

24

When inspecting the contractor’s work for conformance to the plans and specifications, the engineer is expected to use the skill and care generally accepted within the profession. The engineer is not expected to perform material tests or take other elaborate measures unless this is called for in the agreement with the owner. There are two common pitfalls for engineers when inspecting the work. The first is a lack of familiarity with the contract requirements. This is particularly inexcusable, as the engineers usually have prepared the plans and specifications themselves. If the A/F is not thoroughly familiar with the detailed requirements of the construction contract, it will be impossible for the engineer to determine whether the contractor is conforming to those requirements. The second pitfall is the failure to inspect work before it is covered up. Most construction contracts prohibit the contractor from covering up work before the owner or its representative has inspected it. engineers must be alert to strictly enforce this provision. It is impossible for an engineer to reach a responsible professional opinion regarding the sufficiency of the work if the work is now under 4 feet of backfill or concealed by a new wall. Frequently, the plans and specifications require a certain amount of interpretation. Plans that require a great deal of interpretation are probably sloppy or incomplete. Nonetheless, it is inevitable that questions will arise regarding the intended meaning of the plans and specs or their application to particular field conditions. In rendering these interpretations, the engineer is expected to be objective and to avoid an expansive reading of the contract requirements. Because plans and specifications require a certain amount of interpretation, it is customary for the owner to hire the same engineer who designed the project to perform construction phase activities. The rationale is that the designer is in the best position to interpret the design and judge the contractor’s conformance to that design.

25

There is a countervailing school of thought, however. Some large institutional project owners, including several agencies of the federal government, prefer to hire a separate engineer for construction phase activities. The concern is that the engineer who designed the project will have a vested interest in defending the adequacy and integrity of the design. If there are problems with the design, the engineer will not be objective in arriving at an appropriate solution. Still, the prevailing practice is for the project owner to hire the designer to inspect the contractor’s work. Occasionally, matters of artistic interpretation arise during construction. For instance, this could involve the approval of a particular shade of paint. Construction contracts typically give the architect broad discretion to make these determinations. Engineers should not confuse the unfettered discretion they have in making artistic determinations with their role in interpreting the plans and specifications. Properly prepared design documents should speak for themselves and require a minimum of elaboration. The engineer’s inspection responsibility is to render an opinion regarding the contractor’s conformance with those objective requirements. The engineer is not allowed to embellish the design as the work progresses. A final issue involving conformance with the design has to do with the engineer’s approval of shop drawings and other submittals. Shop drawings are drawings submitted by construction contractors to project owners depicting the way certain aspects of the work are to be performed. Shop drawings typically address such matters as the fabrication or assembly of a particular item or the form and fit of a particular aspect of the work. Shop drawings are necessary, particularly on large or complex construction projects. It is impossible for even the most complete set of plans and specifications to depict every detail of every installation throughout the project. Furthermore, there are certain aspects of the work where the owner and engineer look to the contractor to provide expertise in fabrication or installation of an item or even selection of a particular proprietary product.

26

In reviewing and approving shop drawing submittals or submittals proposing the use of a particular product, the engineer should be guided by a desire for conformance with the expressed intentions of the plans and specifications. This is what the A/F’s approval of a shop drawing submittal indicates. The work as depicted in that drawing will conform to the plans and specifications. Much has been made of the choice of language used in approving shop drawings. Engineers are concerned that when approving shop drawings, they will inadvertently waive or alter contract requirements, thereby exposing themselves to a liability claim by the project owner. They therefore use very equivocal, noncommittal language in “approving” shop drawing submittals. One typical statement, found on a stamp affixed to a shop drawing submittal, reads as follows: “Review is only to check for compliance with the design concept of the project. Approval does not indicate the waiver of any contract requirement. Changes in the work may be authorized only by written change order.” The use of this language does little to protect the engineer but a great deal to create confusion. Under the terms of the typical contract documents, the contractor cannot proceed with the work until it receives approval of submittals. Either the submittal was approved or it wasn’t approved. Once it was approved, contractors are entitled to act in reliance on that approval. Courts are not sympathetic to an engineer’s after-the-fact, self-serving explanation of what he or she really meant to say when he or she approved a shop drawing submittal. Engineers who are concerned about inadvertently waiving contract requirements can take solace from one basic legal principle. If a contractor submits a drawing which entails any deviation from the plans and specifications, this deviations must be prominently noted on the drawing itself. If the drawing involves a change which the contractor fails to flag, the engineer’s approval of the drawing will not constitute a waiver of the contract requirements.

27

Contractor’s Percentage of Completion Another of the important inspection functions of the engineer during the construction phase of the project is to determine the amount of progress the contractor has made. This is crucial, as it relates to the owner’s release of payment to the contractor. Most construction contracts call for periodic progress payments from the owner to the contractor. Typically, payment is to be made based on the contractor’s percentage of completion, as measured by the value of the work. For instance, if the total contract price is $1 million and the contractor has completed work at the site with a value of $150,000. the contractor is entitled to be paid the $150,000 less the stipulated “retainage” (usually 10 percent). The job would be said to be 15 percent complete. It should be apparent that the determination of percentage of completion involves a fair amount of subjective judgment on the part of the engineer. Additionally, the A/F is subject to conflicting pressures from the owner, who wants to make sure the contractor is not receiving advance payment for work not yet performed, and the contractor, who is hungry for maximum cash flow. It is far easier for the engineer on a unit-price contract, where an objective measurement of quantity or number of items can be applied. When determining percentage of completion, engineers should rely on any schedule of values established in the contract between the owner and the contractor. Progress payment issue is a very good reason to insist a schedule of values to be agreed upon in advance. Without such a schedule, the engineer must apply its subjective judgment to a matter that is fraught with potential litigation. The legal ramifications of an engineer’s authorization of release of a progress payment are significant. If the engineer fails to exercise due care in determining the Contractor’s percentage of completion and the contractor is paid in excess of the value of the work in place, the engineer could be held liable.

28

If the overpaid contractor becomes insolvent or disappears, the engineer could held liable to the owner, the owner’s construction lender, and the contractor’s bonding company. It was foreseeable that all these parties would rely on engineer’s determination to avoid overpayment. And all these parties would foreseeably be harmed if the contractor was overpaid and then defaulted. Funds exceeding the value of the work in place would have been irretrievably disbursed. The engineer could be held liable for the difference between the value of the work in place and the total payments to the contractor authorized by the engineer. CASE STUDY7 Owner awarded Contractor a lump-sum construction contract. Contract called for Owner to make monthly progress payments to Contractor based on Architect’s certification of Contractor’s percentage of completion. Architect certified a particular percentage of completion, but Owner refused to make a progress payment for that amount unless certain changes were made in the terms of the contract. Contractor sued Owner for breach of contract. The Missouri Court of Appeals ruled that Owner did breach the contract. When a contract establishes Architect as the party responsible for determining Contractor’s percentage of completions that determination is binding on both Owner and Architect. Owner was not entitled to ignore Architect’s certification or to impose additional preconditions before making the progress payment.

7

Hart and Son Hauling, Inc. v. MacHaffie, 706 S.W.2d 586 (Mo.App. 1996).

29

Certification of Completion The conclusion of a construction project is marked by two significant milestones: substantial completion and final acceptance. Each carries certain legal ramifications. When the contractor has achieved substantial completion of the project, the project is suitable for its intended purpose. The project owner can take occupancy of the project and make use of the project. The risk of loss due to casualty is shifted from the contractor to the owner. Typically, the contractor is entitled to receive payment of the contract balance except for enough retainage to cover the cost of any “punch list,” or last-minute completion items. Once the punch list is completed by the contractor, the owner is ready to finally accept the project. The contractor is paid the remaining contract balance. Upon final acceptance and final payment, the owner waives the right to bring any claims against the owner for defective work unless the defective work was “latent,” or hidden, or was covered by a warranty. Conversely, the contractor loses the right to assert any claim for additional compensation if it was not asserted prior to final acceptance and payment. Not surprisingly, it is the engineer who is called upon to certify that the contractor has achieved substantial completion or final completion of the project. This certification typically is issued to the project owner. It is also common, however, for the engineer to certify to public authorities such as a building inspector that a project is substantially complete in accordance with the plans and specifications and the applicable building codes. If construction defects are discovered after the engineer’s certification of completion, litigation may result. For instance, in recent years there have been a rash of lawsuits by condominium associations against engineers who certified to public authorities that the project had been completed in accordance with the plans and specifications.

30

There is not a great deal engineers can do to avoid this problem. Public authorities, construction lenders, and others customarily require an architect’s certificate before issuing an occupancy permit or authorizing the release of a final construction loan disbursement. The only thing the engineer can do is to try to convince project owners to use certification language which accurately reflects the engineer’s limited role during the construction phase of the project. Rather than blankly certifying that the contractor’s work complies with all plans, specifications, and ordinances, engineers could more appropriately be asked to certify that to the best of their knowledge and belief this is the case. engineers might also want to state that they are not and cannot be guarantors of the sufficiency of the contractor’s work.

Engineer’s Role in the Claims Process Considering the engineer’s intimate involvement with a typical project from beginning to end, it is not surprising that engineers become very involved in the claims process. The claims process refers to the process whereby the construction contractor requests additional compensation or other benefits under the contract from the project owner. The engineer’s responsibilities during the construction phase make it almost inevitable that the engineer will get involved in claims situations. Many construction contracts recognize this reality and specifically delineate a certain role for the engineer. This section examines the role of the engineer in the claims process. Engineer as Agent of the Owner If the A/F is given responsibilities during the construction phase of the project, the engineer carries out those responsibilities as the agent of the owner. This is a crucial factor, as the agency relationship has a number of legal ramifications. A construction contractor has the right to rely on the words and actions of the engineer if the engineer is acting within its actual or apparent authority on the project. An owner cannot designate an engineer as an on-site representative and then disown the remarks or directives of that representative. The law recognizes this by holding that the project owner, as “principal,” will be bound by the acts of its agent, the engineer.

31

Engineers must constantly keep this in mind during the construction phase. Every directive and every interpretation must be consistent with the terms of the contract the construction contractor agreed to. If the engineer’s directives are inconsistent with the terms of the contract, the contractor may very well be entitled to additional compensation or some other remedy under the contract. The owner will pay for this remedy, as the owner is bound by its agent’s actions. Conversely, any information that comes to the attention of the engineer during the construction process will be imputed to the project owner. If a contractor points out a differing physical condition at the site to the engineer or informs the A/e of a problem that is delaying progress, the engineer has a duty to promptly inform its principal, the owner. Even if the engineer fails to transmit this information to the owner, the knowledge will still be imputed to the owner because of the agency relationship. The contractor has the right to assume that anything said or given to the owner’s designated representative will be transmitted to the owner. The legal impact of this agency doctrine is significant. An engineer, as agent of the owner, has the ability to inadvertently waive contract rights possessed by the owner or grant certain contractual remedies to the contractor. CASE STUDY8 Owner solicited bids for construction contract. The contract drawings contained a conflict regarding responsibility for relocation of a gas line. One bidder telephoned Owner’s Engineer and asked for a clarification. Engineer said the utility would take care of it. Bidder was awarded the contract. Owner then required Contractor to relocate the gas line. Contractor sued Owner for additional compensation. saying it had been entitled to rely on the pre-bid oral statement by Engineer. The Court of Special Appeals of Maryland acknowledged that under similar circumstances, it had held project owners accountable for the pre-bid statements of engineers functioning as agents of the owners. In this case, however, the bid documents expressly stated that all clarifications must be in writing and oral explanations would not be binding. Therefore. Engineer was acting outside the scope of his agency authority in giving an oral explanation and Contractor was not entitled to rely on that explanation.

8

Mass Transit Administration v. Granite Construction Co., 471 A.2d 1PI (Md.App. 1994).

32

It is crucial that any change in the legal relationship between owner and contractor result from a thoughtful, deliberate decision which the project owner has expressly authorized. An owner which discovers that its engineer has inadvertently waived certain contractual rights will not be pleased. In order to protect itself and its client the owner, an engineer must be thoroughly familiar with the construction contract. This includes not only the technical aspects of the contract but the general provisions and other “legal” aspects as well. If the engineer is not familiar with the rights and responsibilities of each party, how can it appreciate the ramifications of its actions or directives’?

CASE STUDY9 Construction contract specified a particular product “or equal.” Contract also stated that Engineer was responsible for determining Contractor’s compliance with the plans and specifications. Contractor proposed an alternate product and Engineer approved the substitution. Owner later refused to allow Contractor to install the approved alternate product. Contractor installed the more expensive product named in the specifications and sued Owner for the increased cost. The Appeals Court of Massachusetts ruled that Engineer was the authorized agent of Owner in matters of compliance with the specifications. Once Engineer had approved the product in accordance with the procedure established in the contract, Owner was bound by that determination and could not rescind the approval.

9

E. A. Berman Company v. City of Marlborough. 419 N.E.2d 319 (Mass.App. 1991).

33

While discussing agency, it is necessary to note the importance of the scope of the engineer’s authority. Frequently, the engineer is not designated as the owner’s on-site representative. The engineer’s construction phase responsibilities may be limited to monthly inspections and a final certificate of completion. The engineer’s agreement with the owner should make this clear. So should the construction contract. There is nothing worse for an engineer or an owner than working with a construction contract which implies the engineer has broad job site authority when in fact the owner has given the engineer very little authority. All the contract documents should accurately reflect the engineer’s scope of authority. All parties will know where they stand, and there will be no problem with the contractor relying on apparent authority which the engineer actually does not possess. Engineer as Arbitrator It is common for construction contracts to state that any claim for a price increase or extension of time must first be presented to the engineer for a decision. When presented with such a request, the engineer is expected to make an independent judgment as a professional, not a parochial decision based on the engineer’s loyalty to the project owner. This is a difficult task, as the engineer is being asked to function simultaneously as agent of the owner and as a neutral arbitrator. Furthermore, the engineer may be faced with a direct conflict of interest if the claim relates to the sufficiency or accuracy of the engineer’s work product. For instance, a contractor may claim that the drawings inaccurately portrayed site conditions or failed to address the fit of particular components. The Sufficiency of the engineer’s professional work product is called into question. It is difficult for the engineer to be entirely objective, knowing that a favorable recommendation on the contractor’s claim will raise questions from its client, the project owner. Nonetheless, the engineer has an obligation to make an objective determination and give the contractor that which it is entitled to under the contract.

34

The effects of this conflict are mitigated by the fact that when the A/F functions as an arbitrator during construction, it is usually just dispensing a preliminary administrative remedy. The contractor must, under the terms of the contract, seek the engineer’s decision first, but it is not ultimately bound by that decision. Typically, the decision can be appealed to an administrative board or a court. Frequently, an arbitration clause calls for formal, binding arbitration of the dispute. This is separate from the engineer’s “arbitration” role during the construction phase, and the engineer would never serve on a panel of arbitrators if the engineer had been involved in the project. In the past, some public contract documents purported to give the engineer final authority to resolve all claims. These so-called engineer decision clauses stated that there could be no appeal from the engineer’s decision on a claim. Courts were hostile toward these clauses, recognizing the inequity of allowing the owner’s agent or employee to make unappealable decisions. Although the clauses were considered enforceable, courts were resourceful at finding ways to limit their effect. Today, engineer decision clauses are rare in public construction contracts. Most jurisdictions have established administrative boards to decide contractor’s claims. While the engineer’s opinions and the engineer’s initial response to the claim will certainly be considered, the board will have authority to make independent findings of fact, rulings of Law, and a decision on the claim.

35

CASE STUDY10 Construction contract stated that Engineer “will decide all questions which may arise.. . as to the acceptable fulfillment of the contract on the part of the contractor.” Owner and Contractor got into a dispute over late completion of the project. Engineer made a determination regarding the amount of liquidated damages that Owner could withhold from Contractor’s final payment. Contractor sued to recover the money withheld. Owner argued that the terms of the contract made Engineer’s decision final and binding on all the parties. The Court of Appeals of Arizona ruled that an engineer’s resolution of a dispute will be final and cannot be appeal only if the construction contract expressly states that the engineer will be the final arbitrator. In this case, the contract contained no such statement. Engineer’s authority was limited to interpreting the contract documents and making decisions during the performance of the work. Engineer was not the final arbitrator of disputes.

10

New Pueblo Constructors, Inc. v. State of Arizona, 696 P.2d 203 (Ariz.App. 1985).

36

The Claims Process In concluding this chapter on engineers and claims, it is useful to summarize the process by which claims are usually asserted. Typically, a contractor will orally convey a problem to the owner’s representative, precipitating a certain amount of give and take. If the owner agrees that a change order is appropriate, the contractor will be asked to submit a change order proposal putting prices on the changed or additional work. There is frequently extensive negotiation regarding the price of changed work. Once this has been resolved, the change order is executed by both the owner (or its representative) and the contractor. A contractor who proceeds with changed or extra work without a signed change order proceeds at its own risk. If the owner does not agree that a particular work item or a particular directive is a change in the original scope of work, the owner may direct the contractor to proceed with the work. The contractor is obligated to proceed but will proceed under protest and later submit a claim for the increased cost. A court, board, or panel of arbitrators will ultimately decide whether this was a change and whether the contractor is entitled to additional compensation. A similar process occurs regarding requests for an extension of time. The owner’s representative will be called on to determine whether a particular delay is excusable, nonexcusable, or compensable under the terms of the contract. Typically, excusable delay is beyond the control of both owner and contractor, entitling the contractor to an extension of time. Compensable delay is the fault of the owner or its agents, entitling the contractor to an extension in the schedule and an increase in the contract price to cover the increased costs of performance resulting from the delay. If an agreement is reached regarding any extension or price increase the contractor is entitled to, a change order is issued and executed. If the parties can’t agree, the contractor will be forced to submit a formal claim.

37

REFERENCES J.T. Brown, "THE HANDBOOK OF PROGRAM MANAGEMENT", McGraw-Hill Companies 2008 T.J. Esque, " NO SURPRISES PROJECT MANAGEMENT", ACT Publishing 1999 PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008 PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008 “MASTERING PROJECT MANAGEMENT BASICS” Boston University, 2005 R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007

38

Chapter II Projects Planning One of the most exciting things in life is to change our ideas into tangible achievements using whatever means are available to us. Every time ideas are transformed into facts an elementary process called project execution has taken place. Projects may be developmental as in the case of a new idea or well-known when all the parameters involved in its execution have been experienced before. Projects are omnipresent in human activity. They may be simple things such as : • • • • • •

Studying for an examination; Saving for buying a favourite thing; Making travelling arrangements; Transforming a bathroom; Repairing an electric appliance at home; and Assembling your own personal computer.

They can be medium size propositions as: • • • • • •

Designing a new house; Building a house; Investing in a new idea; Developing a new consumer product; Writing a book; and Introducing further education courses.

They may be large and super large sized ideas such as: • • • • • •

Building a multi-storey facility; Developing a new airplane; Designing a new petrochemical complex; Building an oil refinery; Designing and building a dam; and Designing and building a nuclear plant.

39

Regardless of their nature, projects invariably follow a common disciplined approach comprising the following stages: 1.-Getting well informed about the subject 2.-Establishing a plan of action 3.-Cost estimating the plan of action 4.-Finding out the time required to develop the project 5.-Instituting the means of accounting for all expenses 6.-Generating a system to measure progress and revise plans accordingly 7.-Organizing a system to store all data concerning the project 8.-Executing the plan of action For small projects the above-mentioned procedure may be developed without the help of sophisticated management science procedures. For medium and large projects the situation changes dramatically due to the fact that it is almost impossible to keep in mind the amount of information that may be accumulated by the number of activities included in these kinds of undertakings. Management and computer science provide the means to handle projects: Getting well informed about the project by using: Historical information databases, economic indexes, brain storms, statistical information, market research and learning curves. Establishing a plan of action using: Work breakdown structures, organization breakdown structures, planning tools and scheduling procedures. Cost estimating the plan of action management by using: • • • • • •

Index estimating; Cost factors estimating; Cost capacity estimating; Unitized cost estimating; Parametric cost estimating; and Range cost estimating.

40

Finding out the time required to develop a project by using: Critical path methods or Project evaluation and review techniques Instituting the means of accounting for all expenses by using: Code of accounts to facilitate gathering of all expenses incurred in an organized manner. Generating a system to measure progress and revise plans accordingly by: Clearly specifying how progress and productivity measurements will be certified periodically as a percentage of the total project and procedures to be followed when the project: • • • •

Has to be accelerated; Falls behind schedule; Has to include changes; and Productivity is lower than expected.

Organizing a system to store all data concerning the project: Specifying computer and management science applications to be used to store, organize, and report all relevant information to the project. After recognizing all the above elements, a definition for project management may be drawn as an organized effort dedicated to the attainment of a goal. The goal usually is the successful completion of a product or service when it is required in time, within a previously approved budget and in compliance with performance specifications. Project management may be seen as planning, organizing, directing and controlling an engineering effort to achieve an objective. The essential function of every human endeavor is planning and it consist of deciding what to do, setting goals, determining strategy and selecting alternative courses of action. Planning involves: • • •

Determining short- and long-term objectives; Formulating programs, policies and procedures; and Reviewing information from periodic reporting systems and adjusting plans accordingly.

41

Once things are planned they need and organization breaking down the work required and structuring it to facilitate its achievement. Organizational principles give projects the capability to: • • • •

Divide the work to allow better productivity and control; Group related jobs; Delegate authority; and Develop coordination mechanisms to reduce complications.

Plans and organizations need motivation and guidance that is brought to project management by directing. Directing means understanding human behavior at work, communicating properly, motivating and using leadership to achieve planned productivity levels. Directing is a management compromise among autocratic, democratic and free-rein leadership styles to influence others to behave as required by project requirements. Finally, measuring performance against planned objectives gives project management the controlling function that feeds facts back into the system to make it react and adjust. Controlling basic functions are: • • • • • •

Establishing of planning standards; Scheduling of work; Budget reviewing and adjusting; Supervisory action; Productivity measurement; and Corrective action activity.

42

Project Management Structure Projects are typically organized by task or vertical structure instead of by function or horizontal structure. Project management uses a vertical structure in which control and performance associated with autonomous management are maintained for a given project. (see Figure No.1)

PROJECT MANAGER

FIELD CONSTRUCTION M ANAGER

SENIOR PROJECT ENGINEER

CONSTRUCTION ENGINEERS

PROJECT ENGINEERS

START UP ENGINEER

PROCESS ENGINEERS

BUS INES S ADMINISTRATOR

QA/QC ENGINEERING

COST/SCHEDULE ENGINEERS

CONTRACT SUPERVISOR SURVEYORS

PROCESS SPECIALISTS

JOB ACCOUNTANT

PROCUREMENT SPECIALISTS

COST ENGINEERS

Figure No. 1

Essential to the project management concept is a clear delineation of authority and responsibility. The project manager knows that his basic responsibilities consist of delivering a product: • • •

As designed; Within budget; and Within the time scheduled specified by his customer.

Project managers delegate by tasks giving subordinate managers the same three basic responsibilities for subprojects. Successful project management depends on the ability of the manager to perceive fine variations of performance, budget and time schedule and to resolve continuous conflicts among them. The project management first line of supervisors is by hierarchy the ones who play the key roles in guiding the daily progress of a project.

43

Such supervisors bear a wide range of burdens such as: • • • • • • • • • •

Manpower control; Contractors control; Design and specifications control; Schedule compliance; Cost compliance; Resolution of contract/design interpretation disputes; Reporting; Invoicing and payments; Material procurement; and Change-order administration.

Typical first line supervisors are: Cost engineers; Project engineers; Planning and scheduling engineers; Estimating engineers; and Design engineers.

• • • • •

Project Life Cycle Most capital projects are generated by either one of the following reasons or a combination of them: • • • • • •

New product development; Market pressure; Natural resources exploitation; Business expansion; Business ventures; and Personal initiative for business opportunities.

Whatever the reason, they all follow what may be called a project life cycle. The project life cycle may be defined as the organized number of activities needed to develop a project from its proposition or inception to its full implementation or completion.

44

Figure No.2 shows a typical summary schedule network depicting the main activities involved in such a development.

CEP

DBP

P.P.

CEP= CONCEPTUAL ESTIMATE PAPER DBP= DESIGN BASIS PAPER PP= PROJECT PROPOSAL PEP= PROJECT EXECUTION PLAN DD= DEFINITIVE DESIGN LLIP= LONG LEAD ITEMS PROCURE EFA= EXECUTION FUNDING ASSURED

EFA

D.D. 40-60%

D.D. 100%

PEP LLIP

CONSTRUCTION

MC COMMISSIONING

COST ESTIMATE PROCUREMENT

Figure No.2

When a project is proposed a very elementary procedure based on personal experience, historical data, project analogy, incipient design or a combination of them is set on the table in the form of a package usually called Conceptual estimate paper.(CEP) The conceptual estimate paper is a description of the project in question. It is required as part of the initiation review package before a budget item is incorporated into the company's business plan. The CEP usually contains the following kind of information: • • • •

Purpose of the proposed project; Description of the project; Milestone schedule for the project main activities(duration estimate); and Order of magnitude cost estimate.

It gives management a first rough idea about the size of the project, its financial commitment and timing for the execution. This document is developed in-house by the interested party and it is usually inexpensive but at the same time its accuracy is very limited. It really serves as a basis to proceed to further development when circumstances justify it.

45

Once the CEP is approved, additional activity is generated by starting an Engineering study which in time will be the base line to develop a project proposal for expenditure approval. This engineering study along with other related information outlines is called the design basis paper (DBP). The DBP clearly defines the project scope and supports the technical development of the project proposal later on in the project life cycle. It encourages completion of a planning study before a project team is given the responsibility for the item. The DBP makes emphasis on what has to be done rather than how it will be done. The design basis paper should incorporate: • • • • • •

The purpose of the proposed project; The relationship of the project to existing plans; The description of the proposed project; A review of the alternatives studied; An order of magnitude estimate (-40, +40 % accuracy); and The scheduled dates for major milestones.

If the DBP is approved the cycle continues with a selection of a contractor to proceed with a more elaborated design that will support a better cost and time estimate and seeking of funds for project construction. This more elaborated design is usually called the project proposal and it usually provides the final design basis and scope of work for the proposed project. The Project Proposal usually contains: • • • • • • • • • • • • • •

The project location and layout; The process design basis; The on-plot and off-plot facilities; Major mechanical and electrical needs; Instrumentation needs; Needed modification to existing facilities; Operating variables; Corrosion control parameters; Project impact on related facilities; Environmental impact assessment; Fire protection and safety requirements; Equipment and material needs; Project milestone schedule; and Engineering studies if applicable.

46

Along with the production of the Project proposal the following documents should be developed before asking for project funding: • • •

Project execution plan; Updated cost estimate (-15, +10 % accuracy); and Financial feasibility studies.

If project funding is granted a definitive design contractor has to be selected, long lead time procurement has to be started and a slate of construction contractors updated. When definitive design has been completed enough, according with the type of project, the construction contract is awarded and the last phase of the project will be on its way.

REFERENCES Manzanera I., “PLANNING AND SCHEDULING REFERENCES”, Aramco Saudi Arabia, 1991 Lasser's, J.K.,"BUSINESS MANAGEMENT HANDBOOK", McGraw Hill Book Company, 1998 Joseph J. Moder, Cecil R. Phillips, Edward W. Davis, “PROJECT MANAGEMENT WITH CPM, PERT AND PRECEDENCE DIAGRAMMING”, Van Nostrand Reinhold Company, 1995 Duncan W.R., A Guide to the Project Management Body of Knowledge, Project Management Institute, 1996

47

Chapter III Detailed Planning and Scheduling The lack of adequate tools, techniques, and system design knowledge has been primarily responsible for the historical difficulties with project management. Most of the traditional scheduling techniques are based on the Gantt or bar chart, a tool which has been in common use for over 50 years. Although it is still a valuable tool, its use is limited in the scheduling of large scale operations. In particular, the bar chart fails to delineate the complex interactions and precedence relationships existing among the project activities. In addition, it does not lend itself to mechanization through the use of a high-speed electronic computer and thus cannot utilize many of the scientific management techniques that computers make feasible. The process of detailed planning is simply an application of the thought process that must be developed before the actual scheduling or event-timing can begin. Planning is determining what has to be done, when and by who in order to accomplish an objective. The preliminary process of planning should include answers to the following questions: Material procurement: • •

Are materials needed for the project been researched for local availability? Have vendors established there procuring conditions according to the project conditions?

Time for construction: •

Is the time allowed to complete the project adequate for the location and the seasons, or will it require increased crew sizes or premium time?

Special construction equipment: • •

Will special equipment be required for construction? If so, is it off-road equipment that will require special haul routes? What are the load limits and bridge clearances for roads in the area?

Interdependence of the tasks: •

Are some of the tasks in this project dependent upon the completion of another contractor or utility owner before they can be started?

48

Work and storage areas: •

Have provisions been made for contractor's work and storage areas?

Manpower availability: Have studies been made about local availability for different labor trades? and if so, how will the results impact the manloading of the project? Temporary utilities: •

•

Will temporary utilities lines be required during the construction period?

Local by-laws: •

Have local by-laws been researched and understood? If so, what regulations have to be followed and what permits required?

Once these questions and the additional ones drawn from the natural business process, have been answered and satisfied the task of planning can begin. There are three kinds of planning: Strategic Planning It is a planning effort considering activities to be implemented looking at a long-term horizon, usually, it should look at more than five years ahead. Tactical Planning It is a planning effort regarding activities to be performed in the medium-term future, usually, between 1 and 5 years ahead. Operational Planning It is a planning effort regarding activities to be performed in the immediate future., usually, between 1 and 12 months ahead.

49

Planning Elements A structured planning procedure should include the following elements: Objective: goals/target/quota to be accomplished Program: strategy to be follow Budget: Resources and expenditures organized logically Forecast: Projections of what is going to happen Policy: guidance for decision making Procedures: detailed methods for carrying out a policy Standard: Define accepted performance level

Planning Tools Engineering management science has always helped to provide the needed tools for good planning practices. Some of the tools are enumerated here: • • • • • • • • • • • • • • • • •

Historical Information; Engineering capital projects checklists; Local time and cost estimating data; Project Management Software; Estimating methods; Work breakdown structures: Network scheduling; Statistical analysis; Optimization techniques; Learning curves; Responsibility matrix; Safety regulations; Security regulations; Contracting administration; Resource allocation techniques; Accountability check lists; and Computerized simulation techniques.

Planning Primary Objectives Planning engineers primary objectives are concerned with getting things done within the shortest available period of time, minimizing cost and risk, and complying with the required technical specifications.

50

To achieve these primary objectives, resources utilization, communications, and project controls must be optimized and team spirit fostered at all times. Misunderstanding of corporate goals, lack of discipline, poor financial estimates, plans based on insufficient data, schedules neglected are only a few of the parameters that can go wrong.

Scheduling Engineering Scheduling engineering is a management tool providing time and other resources allocation to a plan, time-cost trade-offs for all activities involved, and expenditures control. As may be seen from the above definitions scheduling is the heart of good cost control. Unfortunately, it is usually neglected by management due to the level of complexity that is normally achieved and the consequent lack of understanding. Scheduling is one of the simplest and less sophisticated tools available for cost control, yet it only requires a good team effort at the beginning of the task and good management support to have a powerful tool working for all. When scholars talk about different methods of scheduling they mention: • • •

Bar charts scheduling; Velocity curves(S curves) scheduling; and Network scheduling.

True scheduling engineering is only concerned with network analysis practices such as critical path method (CPM), program evaluation and review technique (PERT) and similar developments. Bar charts and velocity curves (S curves), are good tools when used along with network analysis, but they should not be considered as stand-alone means to control capital expenditures.

Critical Path Method (CPM) CPM is a network analysis technique providing management with: • • • • • •

Estimates of time and resources required to accomplish plans; A sequence of events and responsible personnel; Time-cost trade-offs for all activities involved; Resource allocation for all phases of the plan; Activity completion and cost compliance control; An organized, clear, concise way of documenting plans, programs start and completion dates and cost performance;

51

• •

Easy training and indoctrination of new management personnel; and A comprehensive, psychological communication resource to foster team unity and delineation of responsibilities.

Critical Path Method Development To properly understand the CPM procedure, the reader should introduce himself to the scheduling engineering jargon shown in Attachment 1 at the end of this chapter. Once you have familiarized yourself with the scheduling terms it will be easy for you to follow the next discussion.

Basic Rules for Drawing Networks Rule 1. A complete network should have only one point of entry (a start event) and only one point of exit (a finish event). Start

Finish

Rule 2. Every activity must have a preceding or tail event and a succeeding or head event. Many activities may share a tail or a head event but not the same tail and head event. Rule 3. No activity can start until its tail event has been reached. Rule 4. An event is not complete until all the activities leading into it are complete. Rule 5. A series of activities leading back to the same event are not allowed. (Looping)

52

Convention for Drawing Networks Convention 1. Networks proceed from left to right. Convention 2. Networks are not drawn to scale. (convenient but not mandatory) Convention 3. Events or nodes should be progressively numbered.(convenient but not mandatory) There are several ways of identifying activities on a network and they are: • • •

Shortened description of the job; Alphabetic or numeric code; and Identification by the head and tail events.

There are two widely used methods of diagramming networks: • •

Arrow diagram method (ADM); and Precedence diagram method (PDM).

ADM represent activities as follows: Activity name Resources needed

PDM represent activities as follows:

Activity name Resources needed

Activity name Resources needed

53

Preliminary Steps for Processing a Network Step 1 Establish what activities are involved in the project at hand and make a list of them disregarding timing and logic. For example: Survey, fabricate forms and rebar, excavate, grade, pour concrete, install forms and rebar Step 2. Establish the logical relationship among all the activities listed in step 1. (What has to go first?) A B C D E F

Survey Grade Excavate Fabricate forms and rebar Install Forms and rebar Pour concrete

Step 3. Make a diagram showing activities as arrows and depicting the logic established in step 2. Grade

Install F&R

Excavate 3

4

Survey 1

2 Fabricate Forms & Rebar 3

54

Pour Concrete 5

6

Step 4. Estimate the time needed for the completion of each activity and depict them for each activity on the diagram drawn in step 3.

Grade

Install F&R

Excavate 3

2

4 5

Pour Concrete 5

2

6 1

Survey 1

2 1 Fabricate Forms & Rebar 3 4

Earliest Start Time Calculations (FORWARD PASS) The earliest start of a head event is calculated by adding the earliest start of the tail event to the duration of the linking activity. Where more than two or more routes arrive at the same event, the longest route time must be taken as the earliest starting time. (highest number) The earliest starting time for the finish event is the project duration and it is the shortest time in which the project can be completed. The figure next page shows the forward pass calculations for the example at hand. Activity names have been changed by initials and node numbers eliminated to avoid congestion.

55

3

0

8

10

11

B

C

E

F

2

5

2

1

1 A 1

5 D 4

Latest Start Time Calculations (BACKWARD PASS) Starting at the last event for which the earliest start time and the latest start time is the same, work backward through the network deducting each activity duration from the previously calculated latest start time. When the tails of activities join the same event, the lowest calculated late start time is taken for the event. The figure below shows the backward pass calculations.

3

0

0

1

3

8

8

10

10

11

B

C

E

F

2

5

2

1

1

A 1

5

8

D 4

56

11

Once early start and late start for each event within the network has been established, it is easy to proceed calculating the early start, early finish, late start, and late finish for each activity as follows. For each activity the calculated numbers of its tail event represent its early start, late start. Similarly, calculated numbers of its head event represents its early finish, late finish. The following graphic illustrates it:

ES

LS

EF

(tail)

LF

(head)

Where, ES = Early Start

LS = Late Start

EF = Early Finish

LF = Late Finish

The critical path is established by following the activities where early start and late start are the same and early finish and late finish are the same. There may be several critical paths although this situation is not desirable.

Total Activity Float (slack) Total activity float or slack is equal to the difference between the earliest and latest allowable start or finish times for the activity in question. The total float calculation shows the amount of time that an activity has before it becomes critical. Project team members are always interested in this calculation during planning and scheduling updates for the duration of the project since they do not want surprises from critical path deviations or more than one critical path. There is another kind of float that is called free float and it is defined as the difference between the earliest start of the activity's successor activity minus the earliest finish time of the activity in question. This concept of free float is not widely used today perhaps because it does not provide immediate management information and is often misunderstood.

57

Network Analysis of Engineering Projects Schedule analysis should start with careful and detailed planning of each activity and this mean that every resource needed to accomplish the activity must be clearly consolidated and supervised. Let us considered the activity "Install Pumps" shown in the figure below. It is imperative to know more about resources other than time needed to perform this activity.

INSTALL PUMPS 4 DAYS

For instance, we should know: • • • • • • • • • • • • • •

Who is supposed to provide the pump? How the pump is going to be installed? What kind of crew is needed to install the pump? Where the pump is going to be installed? How much does the pump cost? How heavy the pump is? How much equipment if any is needed to install the pump? Does the equipment need a certified specialist? What tools are needed to install the pump? What kind of inspection should be carried out before and after pump installation? How many tests are necessary to commission the pump? What kind of working permits are needed to install the pump? Do we need additional electrical installations to provide power to the pump? How many instrumentation connections are needed?

As it may be noticed, the job is not as easy as just scheduling the activity by determining the time it will take to accomplish it. It does require a great deal of additional planning and scheduling if we are to attain the desired objective. The figure next page shows how resources should be loaded to an activity in the master schedule.

58

INSTALL PUMPS 4 1 1 2 1 3 3 5 1 1

DAYS MECHANIC ELECTRICIAN HELPERS MASON PUMPS BREAKERS MTRS OF CABLE DOUBLE O CRANE SET OF SMALL TOOLS

FIGURE No.2

Therefore, the question now is to decide how much information should be enough input for the schedule and how it should be handle to avoid confusion while at the same time certifying that the schedule may go as planned by communicating all requirements to all interested parties within the project team. The answer to the first question is an easy one, all information related to the activity must be made available to the schedule. As for the second question, however, it would be very confusing to present everyone within the project team with information other than that concerning their responsibilities. The best solution is to produce additional schedules out of the master one to communicate with the corresponding trades and trigger action from them when required. The Original Schedule Analysis Once all activities in the original approved schedule have been loaded with resources and responsibilities as explained before, the original schedule analysis can start. This task is mostly performed by charting resources against time during the project duration as shown in the figure next page. . These charts will help the planners/schedulers in their job to create resource pools with enough anticipation to avoid production bottlenecks and low productivity areas.

59

JAN

FEB

MAR

APR

M AY

JUN

JUL

AUG

SEP

JUN

JUL

AUG

SEP

JUL

AUG

SEP

10

5

MECHANICS

JAN

FEB

MAR

APR

M AY

10

5

ELECTRICIANS

JAN

FEB

MAR

APR

M AY

10

5

HELPERS

60

JUN

Cash flow analysis for the project is one of the immediate results of this analysis. Regardless of the procedure used for time distribution of the activity cost the planners/schedulers can calculate the amount of cash needed for each project period just by adding the expenditures of the activities following in that period as shown in the figure below. Planning a company's cash flow is an important part of good financial management and its purpose is to identify cash shortages or surpluses and to deal with them in the most efficient manner. Project management must supply the company with all required information about the projects needs with enough anticipation to allow company's cash flow planning accordingly.

JAN

FEB

MAR

APR

M AY

JUN

JUL

AUG

SEP

100,000

50,000

DOLLARS

The concept of cash flow is not an obscure one. Either the company has a certain amount of cash or it has not. And a lack of cash is critical. A company can sustain losses for a time without suffering permanent damage, but a company that has no cash flow is insolvent and in imminent danger of bankruptcy, no matter what profit picture the future may be showing. Projects may be significantly affected if cash flow planning is not given the necessary attention. From the project management point of view there are three major concerns when dealing with cash flow planning: 1.- Project cost must be scheduled according with company's cash flow capabilities.

61

The project financial representative must establish his cash flow needs according to the Projects consolidated budget and schedule. The company's finance department will come back with the financial constraints ruled by the company's cash flow. Company's priorities will play an important role in deciding what project must be developed first. 2.- Approved projects' cash flow variances may affect the company's overall cash flow by the lack of return in cash not expended or by the cost of meeting unplanned cash requirements. 3.- Projects’ cash flow analysis is the foundation for capital investment appraisal and management decision-making. The standard method of evaluating potential investments is the cash flow analysis, which provides the timing and the amount of all projected capital and operating expenditures and related revenue. Annual net cash flow equals revenues minus expenditures calculated for each year of the economic life of the project. The reliability of the projects evaluation depends on the accuracy and completeness of the cash flow analysis, so it is important to include all related costs, including direct support costs. Economic evaluations of investments involve comparison of some alternatives including taking no action. The figure in the page before is a summary of the cash needed for each period of time during the project duration. If there are several projects needing control by the same planners/schedulers, they will be able to establish the cash flow needs for the group of projects by just adding the individual cash flow need for each project. The figure next page shows and instance of this. The lack of adequate tools, techniques, and system design knowledge has been primarily responsible for the historical difficulties with project management. Most of the traditional scheduling techniques are based on the Gantt or bar chart, a tool which has been in common use for over 50 years. Although it is still a valuable tool, its use is limited in the scheduling of large scale operations. In particular, the bar chart fails to delineate the complex interactions and precedence relationships existing among the project activities. In addition, it does not lend itself to mechanization through the use of a high-speed electronic computer and thus cannot utilize many of the scientific management techniques that computers make feasible.

62

JAN

FEB

MAR

APR

MAY

JUN

JUL

AUG

SEP

JUN

JUL

AUG

SEP

JUN

JUL

AUG

SEP

100,000

50,000

DOLLARS

JAN

PROJECT A

FEB

MAR

APR

MAY

100,000

50,000

DOLLARS

JAN

PROJECT B

FEB

MAR

APR

MAY

200,000

100,000

DOLLARS

TOTAL A+B

63

The Network-Based Approach In recent years, the problems of project management have received concentrated attention. The work of several independent investigators led to a family of techniques that represents a major breakthrough in project planning and scheduling techniques. The complexity of the systems required for military projects has given great impetus to this development. The Polaris missile program led to the development of PERT, Program Evaluation and Review Technique by Lockheed Aircraft Corporation along with the US navy special projects office and a consulting firm called Booz, Allen and Hamilton. PERT is a probabilistic approach specifically designed for new projects or projects involving a high degree of uncertainty. However, the normal activities of industry also involve work which fits into the project concept quite naturally. DuPont and Remington Rand Univac interest in optimization of such projects as routine plant overhaul, maintenance, and construction work led to the design of CPM, the Critical Path Method in the late 50’s. CPM is a deterministic approach requiring not only a high level of professional discipline but a complete commitment of top management to become a useful management tool. Known by these and hundreds of other acronyms, these techniques share a large number of common elements. Chief among these is the use of a network flow diagram as a model of the project's precedence relationships. The network represents all the activity paths or sequences that must be accomplished before the project's objective can be achieved. The longest of these sequences is the "critical path," the identification of which permits management to focus its attention on the progress-pacing activities of the project. Much of the early success of PERT/CPM were based on the explicitness of the project plan, this explicitness being essential to the construction of a network. Being explicit about what was to take place at some much later time was a new experience for many. Improved communications among those concerned with a given project was the result most frequently cited by the individuals involved in the early attempts at networking the project plan.

64

Role of Networks in the Engineering Management System The project management system requires the existence of means for the description and evaluation of alternative project plans. The network models described here are means of depicting a particular project plan in such a manner that evaluation is not only possible but is in fact a logical extension of the model. A given model of this basic type will describe one alternative. Other models will be required if other alternatives are to be examined. The modeling process will be described on the assumption that the project management consultant is preparing the network based on information he extracts from the project manager and others selected as sources of information. It will further be assumed that the project management consultant knows little of the technical details of the project and the project managers know little of the network concept being used. Network Construction The network concept involves the graphic representation of activities and their precedence requirements. Activities are elements of the project representing logical subdivisions of the work to be done. If you considered preparing breakfast as a project, pouring a cup of coffee could be an activity. The level of detail used depends upon the degree of control desired. Precedence requirements indicate which activities must be completed before a given activity can proceed. The project network may be formed in several ways. One of these is to start at the realization of the end product or objective and work backwards in time in a step-by-step fashion, determining what work must be completed in order to start a given activity. Another approach is to list randomly all the jobs having a bearing on the project and to determine their technological relationships as the diagram is developed. We want to be able to identify each activity by a work item number for use in a computer analysis of the network. Activities may be numbered in any fashion, as long as a number is not repeated, without creating any logic or identification problems. Computer processing of networks depends upon such numbering, but most computer programs have the capability to take any activity numbering and renumber with predecessor less than successor for internal usage, reverting to original numbers in the output.

65

The belated discovery of activities is an inherent property of the network design of a project plan. The fact that such activities may cause substantial redesign of the network not only slows down the networking, but also tends to inhibit the project planners in their search for activities overlooked previously. An important psychological factor in the planning stage is inertia. The networking system should be capable of maintaining an up-to-the minute graphical representation of the project plan as it is being formulated. PDM precedence diagramming system is quite effective in this respect when compared to the ADM arrow diagramming approach. Planners sitting around waiting for the networker to incorporate their latest disclosure into the ADM network tend to lose the enthusiasm with which they may have started. LAG Factors There are situations in which establishment of the proper precedence relationship gives an erroneous representation of the project. Consider the following portion of a project: PAINT ROOM

INSTALL CARPET

While it is true that carpeting should follow painting, it is not true that all painting must be completed before carpeting starts. The proper representation could be obtained by representing the activities as follows: PAINT ROOM

INSTALL CARPET 2

Indicating that carpet installation can start 2 days after painting of the room has started.

66

Networks Level of Detail A general guideline for determining the level of detail is that it must be keyed to the level of management using the network. Hierarchies of networks will be employed in more complex, large scale projects. A major aircraft design project, for example, might have three levels of networks. The top-level network might summarize the ten major subdivisions of the project into 300 activities. The next level might involve describing each of the ten major project subdivisions with a network of 1,000 activities for a total of approximately 10,000 activities used in this intermediate level. Each intermediate network could break down into ten l,000-activity networks employed at the actual operating level, resulting in a total of 100,000 activities being used at this most detailed level. At any given level of management, there is always the question of how much detail is appropriate. Some organizations attempt to control level of detail by specifying that the network shall consist of a total number of activities ranging between X and Y. This approach applied to projects of varying complexity can produce networks with widely varying levels of detail. A more sound approach to obtaining a consistent level of detail involves specifying that no more than X percent of the activities shall have a duration of more than Y or less then Z time periods. Some more specific approaches to making level-of-detail decisions are: 1. For the resource entities being controlled by this management level, one activity should end and another start at the point where a different resource comes into use on a given work item. This might be the basis for deciding to use the three activities, Layout Site, Clear Site, and Grade Site rather than the single activity, Prepare Site. 2. If some other activity is dependent on the first portion of the activity in question but is not dependent on its full completion and the overlap amounts to as much as one of the time periods used in duration assignments, the activity in question should be divided into two activities at the point of dependence. 3. If there is considerable doubt left as to whether or not an activity should be broken down into more detail, one should remember that the network analyst can later combine activities without the project manager's assistance, but will require assistance to further subdivide activities.

67

Combining Sub-networks No matter how involved and complex the project, the rules for combining activities and precedence information into a network still hold. Often with very large projects, whole subprojects are performed independently but simultaneously as a part of the overall project. It is then possible to network the subprojects to reduce the complexity and then combine these sub-networks. Contractors or managers in charge of the subprojects may then have their responsibilities scheduled separately. Overall management's total network can correspond precisely to the sub-networks without requiring an overall network to be constructed separately. Under these circumstances, responsibilities are split out before the network is constructed instead of after, and the complexity of the network generation is reduced rather than increased. Any interface activities are identified with unique symbols to mark the points where the networks rejoin. These activities on the overall network contain the corresponding activity numbers from all sub networks.

CPM Implementation Recommendations The project management consultant must acquaint himself with the project objective before starting the construction of the network model. He may do this in any or all of the following ways: 1. 2. 3. 4. 5.

Reading the specifications Revising drawings Looking at artists' concepts of finished product Discussing the function of the end product Seeing a similar end product in use.

Then, he determines the management objectives, discussing with the project manager the question of which of the following objectives should govern the project management system operation to: 1. 2. 3. 4. 5. 6. 7.

Meet a deadline for project completion Minimize project length Minimize the sum of direct and indirect costs Minimize the variation in resource requirements Limit the maximum resource requirements of one or more resource types Communicate project information to various levels of individuals concerned Co-ordinate the project with interface groups

68

The consultant is now ready to undertake the networking of one of the alternative approaches to the project. Subdividing the project as discussed earlier is the first step which should be attempted. After either arriving at subdivisions or determining that no reasonable basis for subdivision exists, the planner should obtain a summary narrative from the project manager describing the approach to this portion of the work. This narrative should be in the order of 5-15 minute discussion of the intended project plan. The consultant is now ready to start networking. It is possible to proceed by eliciting responses from the project manager to the question, "What other activity must take place?", and putting the response on paper as an activity node. In general, one should put activity descriptions, abbreviated if necessary, in the nodes rather than code letters or numbers referring to some separate list. The network should be a document that can be read directly. Reference to a coded list destroys the flow of logic that one should perceive when examining a network. Precedence can be ignored at this time and the result will be a sprinkling of unconnected activities over the worksheet. Some activities are obviously near the start of the project and will likely be placed to the left of the sheet, just as activities likely to have few successors will be placed toward the right. It is not necessary, however, that any location rules be followed. Worksheets containing pre-printed or predrawn nodes will speed up the network building process. There is reluctance on the part of many individuals to commit to even the most preliminary network. It must be emphasized that this first network will be re-drawn and eventually change forms and that the original network will be discarded. Even then, however, some project managers respond more readily if their tentative descriptions are placed in a list first, then put into the network format. The network planner may well invest some time in listing activities purely for the purpose of getting the modeling process underway. The network planner should never attempt to indicate predecessors on the list, however. Precedence information is much more easily obtained by directly incorporating each bit of information into the network as it drawn. When the process of discovering activities begins to lag, it is desirable to turn to precedence identification, rather than try to identify 100% of the activities on the first pass. Precedence may be determined by asking this question with reference to the predecessor: "What activities cannot start until this activity is completed?" In the process of establishing precedence connections, additional activities will be discovered and redefinition of existing activities will become necessary.

69

This process should be continued until the project manager is unable to readily find additional precedence relationships. There will usually be some precedence relationships that are not found in this first phase, but these remaining ones can best be discovered during the duration/resource assignment phase. Network planning differs from bar charting in that no time/resource concerns restrict the construction of a network. This time-free model tends to encourage the consideration of more alternatives than does the bar chart. When the planners begin to have difficulty in thinking of additional activities to place on the network, however, it is then time to consider activity durations and resource requirements. As the activities are reviewed for time/resource requirements, additional activities and precedence relationships will be discovered and some existing ones changed. At this point it will be helpful to have a draftsman or clerical assistant redraw the network, attempting to have predecessors to the left of successors and attempting to minimize the crossing of arrows. It is impossible to avoid having some arrows crossing others, but a sense of flow of the work is best attained when these are minimized. The revised network is then ready for use in estimating time and resource requirements of each activity. For some individuals and groups, the process of obtaining this basic network model will give new understanding of the nature of the project. In fact, an organization may find it desirable to go no further on its first attempt at network project management. Such an approach might involve posting the network where the project manager can refer to it during meetings and shading in each arrow as the activity is completed.

70

ATTACHMENT I Scheduling Expressions Activity: Work item represented by an arrow when using arrow diagramming or by a box when utilizing precedence diagramming. Actual completion date: The date an activity is actually completed. Activity duration: Time allocated to complete an activity. OD stands for original duration and RD stands for remaining duration. Arrow diagram: A logical plan to accomplish a job where all the activities required to complete the job are represented by arrows organized and interconnecting in sequential order of execution. As of date: The calendar date equivalent of time-now for statusing purposes. Bar chart: Graphic representation of items of work displaying duration of item as a bar whose length is proportional to the time allocated to perform the item. Calendar days: Scheduling time units for measuring activity durations which includes weekends and holidays. Concurrent Activities: Activities which can be performed at the same time Constraint: Any factor which exerts a time or sequence effect upon the plan activities. Critical Path: The shortest time in which a plan can be performed. Cut-off date: The assigned date on which accumulation of data for a reporting period must be completed. Data base: A collection of records for the project which allows management's information requirements to be drawn from it. Direct cost: The portion of total cost which takes into account only material, labor and equipment assigned to a project or activity. Early finish (EF): Computed value for the earliest possible time at which an activity can be completed.

71

Early start (ES): Computed value for the earliest possible time at which an activity can begin. Event: The starting or ending point of the activities. Float: The difference between the computed time available in which an activity may be completed and the estimated duration time previously assigned to the task. Fragnet: Any area of a network that has been expanded into more detail and definition for analysis. Forward pass: Procedure to calculate early event times for all activities in a network. Gantt chart: Synonym of bar chart Hammock activity: Summary of a entire subset of activities utilized to reduce the number of project elements to track or for analysis of a portion of the plan. I-node: The number assigned to the beginning event of an activity arrow. J-node: The number assigned to the ending event of an activity arrow. Lag factor: A ratio or quantity used in precedence diagramming (PDM) which numerically indicates when a dependent activity can start relative to the duration of the predecessor. Lag time: A time delay required by a sequential connection in a network. Late finish (LF): Computed value for the latest possible time an activity should be completed according to CPM calculations. Late start (LS): Computed value for the latest possible time an activity should begin according to CPM calculations. Lead time: a) Time between the ES and schedule start for an activity. b) Time period acting as a constraint for the beginning of an activity. c) Time in overlapping related activities between the start of one and the start of the second.

72

Loop: A networking drafting error situation in which activities are so arranged as to cause a sequence of work to return to the originating point. Leeway: Synonym for float Logic diagram: The network plan without quantification time data. Milestone: Planned date to start or to finish a special event. Merge: To combine or relate two or more networks at any level to form a single network. Node: A circle graphically depicting the beginning or the ending event of an activity. Normal cost: Direct cost estimate for an activity based on the normal time to perform it. Normal time: The estimated duration time allocated to an activity according to established standards. Operational planning: That aspect of planning that relates to how things will be accomplished. Original schedule: The user approved schedule at the time, or immediately following project award. Output: Material coming out of the computer which results from processing input data Precedence diagramming: A network diagramming technique for showing the relationships of activities in a project with rectangular boxes symbolizing the activities. Print out: A document usually produced from a computer that translates data into usable, readable form. Remaining Duration: Time required finishing an activity once it has been started. Revised schedule: Original adjusted schedule after actual data and /or new change decisions have been introduced. Resource leveling: The process of scheduling activities within their available float so as to control fluctuations of resource requirements. Status: Activity completion level at a given point in time.

73

Sorting: The selective arranging of data to provide a needed pattern of information. Strategic planning: That aspect of planning which evaluates what must be done within a reasonable period of time.(usually 5 years or more) Target: A copy of the original plan saved to compare it against performance in the field. Time compression: A scheduling technique by which project duration is shortened by resource allocation speculation. Updating: Revising the monitoring plans and documents to reflect current performance, needed changes on logic, durations, and physical resource allocations as of a given date. Work Breakdown Structure: Breakdown of a project in activities and sub-activities to allow better planning and control. Working days: Scheduling time units for measuring activity durations which excludes weekends and holidays.

REFERENCES Manzanera I., “PLANNING AND SCHEDULING REFERENCES”, Aramco Saudi Arabia, 1991 Lasser's, J.K.,"BUSINESS MANAGEMENT HANDBOOK", McGraw Hill Book Company, 1998 Joseph J. Moder, Cecil R. Phillips, Edward W. Davis, “PROJECT MANAGEMENT WITH CPM, PERT AND PRECEDENCE DIAGRAMMING”, Van Nostrand Reinhold Company, 1995 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007

74

CHAPTER IV Project Scope Management Scope Definition is one of the most important processes in any project, because effective Scope Definition provides a common understanding of the project scope among all project stakeholders and describes the project's major objectives. It involves developing the project scope statement that will be the source of future project decisions, including the criteria to determine if the project is successful. Scope Definition involves the expansion and further definition of project deliverables, constraints, and assumptions that were initially documented in the preliminary project scope statement during the Develop Preliminary Project Scope Statement process of the Project Integration Management Knowledge Area. Scope Definition is one of the most important processes in any project, because effective Scope Definition ensures an understanding of the business case. It involves developing the project scope statement that will be the source of future project decisions, including the criteria to determine if the project is successful. During Scope Definition the team will analyze the product, identify alternative methods for performing the project work, and perform further stakeholder analysis to document their needs, wants, and expectations. This will also result in a clearer definition of project requirements, and might even lead to the discovery of new requirements that must then be converted into requested changes. The result of this analysis and discovery work is documented in the detailed project scope statement. Purpose of the Scope Definition Process The purpose of the Scope Definition process is to define all project work in a written document called the project scope statement. This document is used to confirm a common understanding of the project scope among all stakeholders, and to describe the major objectives of the project. Inputs, Tools and Techniques This section introduces the inputs, tools and techniques, and outputs of the Scope Definition process.

75

Project Scope Statement The project scope statement describes the project's deliverables and the work needed to create those deliverables. The project scope statement guides the project team in making decisions about which requirements from stakeholders are within the approved scope, and which must be treated as change requests. The project scope statement is a concise document describing the project and the value it has for the company. The detail used in defining the project's requirements and deliverables will exert tremendous leverage in controlling the project's scope and the accuracy of the remaining project planning deliverables. However, excessive detail can even be counterproductive as project participants become overwhelmed with the level of work required to compare related and interdependent project requirements, and to maintain them as changes are incorporated. The project scope statement defines boundaries by answering the following questions about the project: •

What does the project consist of and not consist of?

•

Why is the project necessary?

•

What business value will the project provide when it is done?

One of the greatest challenge project teams face is determining an accurate scope and budget. Through progressive elaboration, project teams often develop progressively more sophisticated versions of the project scope statement that are appropriate for the next stage of project work. Requested Changes The Scope Definition process may result in requested changes to the project scope management plan or the project scope statement upon an iteration of this process. The requested changes are directed to the Integrated Change Control process, where they are approved, amended, or rejected. Project Scope Management Plan (Updates) There may be a need to update the project scope management plan during an iteration of the Scope Definition process to incorporate any requested changes that were approved from the Integrated Change Control process. Project Scope Statement Contributors Having a project scope statement ensures that the project manager, management, and customers have the same understanding of the project. The project scope statement is also valuable for briefing the project team.

76

A number of individuals (the project stakeholders) participate in the drafting and approval of the project scope statement. These include the following: •

Project team members;

•

Project manager;;

•

Resource managers

•

Functional managers;

•

Customers; and

•

Senior management.

Project Requirements The project requirements define what standards and specifications the deliverables of the project must satisfy, including how the work is performed. For example, the organization may be governed by ISO9000 quality standards, in which case all processes used by the project team must conform to strict process documentation, test, and audit requirements. The specifics of the product's capabilities are also documented as requirements; these are the minute elements of the project scope. Later, the deliverables will be evaluated to determine whether they adequately address the defined requirements. Any requirements that are not addressed by one or more deliverables are evaluated as "missing," and any elements of the deliverables that do more than the requirements stipulate are assessed as "extra," and must be eliminated. Those that were incorrectly implemented are defined as "wrong," and must be corrected before the deliverable can be accepted. Project Objectives The project objectives are specific, measurable criteria that help determine project success. Common practice requires cost, schedule, and quality criteria to be explicitly identified and agreed upon by the key stakeholders. Success criteria are defined as early as possible in the project's life cycle. Failure to document complete project objectives often leads to scope creep, and ultimately, project failure. Project objectives must include at least these three items: •

Cost;

•

Schedule; and

•

Quality measures.

77

Project objectives should include: •

An attribute; e.g., cost;

•

A metric; e.g., United States (US) dollars; and

•

An absolute or relative value; e.g., less than 1.5 million.

The best type of objective clearly states the project's impact on the bottom line. This may be expressed in terms such as: •

Increased margins;

•

Higher net revenues;

•

Reduced turnaround time; and

•

Reduced cost of sales.

For a number of reasons, it may not always be possible for the objectives to impact the bottom line. Other criteria to be considered include the impact the project will have on: •

Efficiency and effectiveness;

•

Error rates;

•

Reduced turnaround time to service a customer request;

•

Reduced cost of providing service;

•

Quality impact; and

•

Improved customer satisfaction.

Objectives are stated in tangible, measurable terms that should leave no room for disagreement as to whether or not the criteria have been met. Some project managers use the SMART criteria to help define project objectives. These guidelines indicate that project objectives should be: •

Specific;

•

Measurable;

•

Assignable;

•

Realistic; and

•

Time-framed.

78

Product Scope Definition The product of the project is the final deliverable or outcome of the project. This item must be explicitly described so that all stakeholders know what is to be accomplished and what the product will do. The form and substance of the product's characteristics may vary, but the detail must be sufficient for effective planning. For example, when a team develops a new satellite, they must deliver a product that meets certain design limitations and performance capabilities. It will usually have to fit within a defined volume, have a center of gravity within a small tolerance of a specified point above the launch vehicle, and be able to tolerate a large range of operating temperatures as it travels through the atmosphere and then orbits through arcs while alternatively exposed to sunlight and then complete darkness. Project Boundaries The project scope statement must explicitly define what is included in the project. But, it must also specifically state what will be excluded, so as to avoid future misunderstandings or the risk of scope creep. Major Project Deliverables The project deliverables are a list of summary-level sub-products whose full and satisfactory delivery marks the completion of the project. It lists the specific, tangible deliverables the project produces. The project deliverables may be interim or final deliverables. For example, a design specification is an important interim deliverable for a software development project, while the software product itself is the desired final deliverable. Product Acceptance Criteria The product acceptance criteria stipulate how the final product will be evaluated for acceptability. These criteria are of particular importance in subcontracted work, and are valuable to ensure that projects close when their objectives have been met. Product acceptance criteria are also important, to avoid the tendency to "declare victory" when, in fact, major objectives have been missed. Project Constraints A constraint is an applicable restriction that will affect project options. This includes any factor that affects when an activity can be scheduled, or how work must be performed. For example, a constraint may specify that the project must not interfere with the progress of another project that is competing for the same resources, or that it must await the development of a component that another project will produce, and re-use it.

79

Another example of a constraint might be the stipulation that the project must complete within the current fiscal year in so it will not require another round of funding. Contractual provisions are also generally considered constraints in that they can limit the project team's options. The number of constraints listed in the scope statement is typically greater than the number of constraints identified in the project charter, as more information about relevant constraints is uncovered through progressive elaboration. Project Assumptions Project assumptions are factors that, for planning purposes, are considered true, real, or certain. Assumptions affect all aspects of the project planning and are part of the progressive elaboration of the project. Project teams frequently identify, document, and validate assumptions as part of their planning process. Assumptions generally involve a degree of risk. The number of assumptions listed in the scope statement is typically greater than the number of assumptions listed in the project charter, as more assumptions are typically uncovered during the early stages of planning and progressive elaboration. Initial Project Organization The major players and participating organizations who will become (or are already part of) the project team are now known. Documenting them here ensures that their allocation is secure and cannot be easily undermined by competing initiatives. The project's stakeholders are also listed here. This ensures that they will not be overlooked as the project progresses, particularly when tradeoffs must be negotiated to cope with changing circumstances or new discoveries. Initial Defined Risks This section lists any risks that could impact the success of the project so that senior management is aware of them. Items of interest to senior management include those that they must directly address, or those that are out of their control but may result in project failure and diminish the expected project's net value. Several areas affect the project's success, including the following: •

Technology;

•

Environment;

•

Interpersonal relationships; and

•

Cultural factors.

The project team should use a method of categorizing project risks to ensure that all possible sources of risk are considered.

80

Schedule Milestones Often the project must conform to externally imposed milestone dates. These may be the result of constraints such as fiscal year-limited funding or interdependencies with other projects. The team might identify key milestones events during planning. Fund Limitation Funding limitations are of major significance to the project sponsor and the supporting accounting and budgeting functions. Projects are usually performed within the limits of a total portfolio of projects whose total investment is capped for a specific period, so both the individual projects and their related investment periods must be capped and tracked. Cost Estimate The initial cost estimate is a major factor in determining whether the project will proceed. Management must always govern projects with an eye on their cost-effectiveness, and take prompt action when the expenditure pattern of a project demonstrates that it will not meet its initial estimate. All estimates provided at this stage should be preceded by a modifier that provides an indication of the level of accuracy. Project Configuration Management Requirements The project's deliverables and project management work products must be kept under careful control if the project itself is to remain under control. The project configuration management requirements will describe how the project's work products will be controlled. Project Specifications Project specifications identify any specification documents that the project must comply with. These are particularly common in projects that belong to a program, where there may be numerous interfaces that the project's product will be required to implement in order to function with other products. Examples might be weapons systems for aircraft, where carrying pods and arming and launching circuitry have already been specified, while the munitions may be new and completely different from previous types. Another example might be the branding requirements for packaging a new perfume, where bottle type, color, label bordering, font, and background may already be part of a product family specification. Approval Requirements Approval requirements describe how the project's deliverables will be accepted, and include the participation of supporting organizations that must adopt and support the product after its implementation, or interface with it.

81

Attachments to the Project Scope Statement While the scope statement should, preferably, be as concise as possible, some organizations require additional detailed information which should be included as an attachment. The most common project scope statement attachments are: •

Risk analyses;

•

Feasibility studies;

•

Financial analyses;

•

Cost/benefit analyses;

•

Break-even analyses; and

•

Return on investment analyses.

Project Scope Statement Approval Process Approval of the project scope statement is a significant event that requires input from: •

Senior management: Stating that the project makes enough business sense to move to the detailed planning stage;

•

Customer: Concurrence that the project has been correctly described and that they are in agreement with the solution being offered; and

•

Project team: Indication that the project has been clearly defined at this high level of detail.

Approval is not authorization for the project. Rather, it is a commitment of resources to complete the detailed plan. Project Sponsors Level of Commitment Approval of the project scope statement is a significant action on the part of the project sponsor, and reflects their commitment to the project. A project sponsor is likely to ask a number of questions, such as: 1. Does the project solution relate directly to the business need? 2. Are the project deliverables clear representations of the solution? 3. Is there sufficient business value to warrant further expenditures on the project? 4. Is the relationship between project deliverables and project objectives clearly established?

82

5. Are initial risks too high and business value too low? 6. Can senior management mitigate any identified risks? The project manager should pay close attention to the questions most important to the project sponsors. This helps the project manager understand the sponsors' criteria for success.

Scope Planning Scope Planning involves deciding how the scope will be defined, verified, and controlled, and how the WBS will be created. The project team creates a project scope management plan as the main output of the Project Scope Planning process. Successful project management begins with a plan to provide an effective approach for managing the scope of work on a project. Scope Planning is the most important phase in any project, because effective scope planning ensures an understanding of the business case. It involves developing the project scope management plan that will be the source of future business decisions, including the criteria to determine if the project is successful. The purpose of the Scope Planning process is to document Scope Management decisions such as the tools, data sources, methodologies, processes, and procedures that will be used during the Scope Management processes to influence the outcome of the project. The outcome of this process is the project scope management plan that determines how the team will: •

Define the project scope;

•

Develop the project scope statement;

•

Define and develop the WBS;

•

Formalize the completed project deliverables for Scope Verification;

•

Determine and manage the monitoring and controlling processes; and

•

Control and make refinements to the existing project management methodology for controlling changes to the project scope.

Enterprise Environmental Factors The infrastructure and tools may support particular implementations of the Scope Planning process through: •

Virtual team meetings;

•

Electronic workflow; and

83

•

Pre-existing change control boards with established processes to support an entire program of projects.

The organizational culture might also affect Scope Planning by either encouraging or discouraging certain Scope Management practices, such as formal sign-offs or structured change control mechanisms. Organizational Process Assets These may include specific policies and procedures regarding scope, such as how great the impact of a scope change may be before approval to move forward must be obtained by the project sponsor. They may also include templates and historical information from past projects, including lessons learned. Project Charter, Preliminary Project Scope Statement, and Project Management Plan These may all specify particular objectives, requirements, or standards that the processes described in the project scope management plan must follow. An example might be the creation and use of a new repository for controlling the project requirements. This will later be extended for eventual use by the entire organization as another tool, with its own new set of organizational process assets in the form of templates and procedures. Expert Judgment This is useful in setting up the project's Scope Management processes, and in reusing practices and tools that have effectively supported similar projects in the past. It is particularly important when determining how rigorously and formally to apply all project management practices (which can overwhelm a small project or be overwhelmed by a large one, if not sized and tailored properly). Templates, Forms, and Standards Templates, forms, and standards will often save large amounts of effort when setting up and using Scope Management processes. They may also increase accuracy and even compliance with usage policies if they are familiar to the participants. Reinventing the wheel is a major cause of lost productivity and unnecessary errors in project management. Existing templates, such as WBS, scope management plan templates, and project scope change control forms existing within the performing organization may be used or modified to meet the requirements of a project.

84

Scope Planning Process Outputs Project Scope Management Plan The project scope management plan is a document that provides guidance for the team in specifying how the project scope will be defined, documented, verified, managed, and controlled over the course of the project. The project scope management plan clarifies change procedures and forecasts the stability of the project scope. As a component of the project management plan, it describes how the project scope will be managed, and how scope changes will be integrated into the project. It is important to document all decisions the team makes in the project scope management plan. The project scope management plan typically includes: •

The process of preparing a detailed project scope statement (based on the preliminary project scope statement);

•

The process of creating the WBS from the detailed project scope statement and the method for maintaining and approving the WBS;

•

The process of specifying how formal verification and acceptance of the completed project deliverables will be obtained;

•

The process of controlling requests for changes, including a clear description of how scope changes will be identified and classified; and

•

An assessment of the expected stability of the scope.

85

WBS The WBS is a deliverable-oriented, hierarchical breakdown of the work to be executed by the project team, and is used to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project. In order to successfully direct and manage the work of a project, the project management team must break the project deliverables down into manageable segments of work. Each segment must be small enough to be accurately estimated for effort and cost, and must be small enough to monitor and control effectively. The decomposition technique is used for breaking down the work of the project for these purposes. It can be performed using a number of techniques, and is used in conjunction with other project management deliverables to fully define what will be produced, how it will be produced, by whom, and for what investment of effort and cost. In order to create a plan to accomplish project work, the work must first be defined and organized in small elements that are: •

Manageable;

•

Independent; and

•

Measurable.

Work Breakdown Structure (WBS) Definition Once the scope and deliverables have been identified, the project work can be successively subdivided into smaller and smaller work elements. The outcome of this hierarchical decomposition process is called the work breakdown structure (WBS). In effect, the WBS is a map of the project's scope. A WBS helps project managers ensure that all products and work elements are identified, and helps establish a basis for planning the work. WBS as a Basis for Planning The WBS is an essential element of a project because it defines all the work elements which must be planned. It is important to give special attention to designing and developing the WBS, because it will be used as a basis for: •

The activities which must be carried out to produce the deliverables;

•

The sequence in which the activities must be performed;

•

The project schedule for the activities;

•

Budget and costing estimates;

•

The project team's organization structure;

•

Work assignments;

86

•

Risk management;

•

Procurement; and

•

Monitoring and controlling the project scope.

WBS Applications There are two fundamental applications for the WBS: 1. It can used as a thought process tool; and 2. It can be used as a tool for summarizing information. Thought Process Tool Similar to creating an outline for a paper or book, the work breakdown structure aids the project manager and planning team in decomposing the project into manageable "chunks." The phrase "structured decomposition" is sometimes used to describe the process. It is structured in that the project is first broken down into major categories, known as elements. Each level of breakdown is numbered, with the project itself being level zero. The sum of all the elements of level one must describe the project scope in its entirety. When level one has been fully defined each of its elements is then broken down. Again, the sum of the subelements must describe the entire project scope. The process continues until sufficient detail has been achieved, so that the schedule activities can be created with a reasonable degree of accuracy. In addition, the detail must allow progress to be accurately measured, so that the project can be managed and controlled. This is a top down process that is intended to ensure that no element of work is overlooked by starting with the top-level deliverables and progressively detailing the work required to produce each one. On occasion it may be tempting to try a bottom up "brainstorming" method. This involves trying to think of all the detail level activities that would need to be performed to meet the project goal, and then organizing those detailed activities into groups or categories for reporting purposes. This approach is used quite often in basic research environments but it is labor intensive and usually requires formal facilitation. The majority of the time, a top down approach is the time and cost effective approach to project decomposition. Still, after completing a topdown decomposition of the scope, a bottom up approach can be used to validate the resulting WBS and test it for necessity and sufficiency.

87

Summarization Tool The second of the two fundamental uses is summarizing information for performance reporting. One of the more familiar formats for this is the Gantt Chart, which is easily created in most project management software. The Gantt Chart can display a comparison of the project plan versus the project actual performance. Other types of information, such as resource work and cost, can also be summarized and reported in this manner, and the WBS remains the principal device used for doing this. Its principal use as a thought process tool and its use for performance reporting could potentially be in conflict. Those creating the WBS must take this into account when designing its hierarchical architecture. Organizing it to aid in thinking of all the deliverables may not provide logical groupings of deliverables, so that various levels of management can accurately assess and manage progress. Therefore, a compromise between its two uses will sometimes be necessary. WBS Hierarchy Each descending level represents additional detail of the project deliverables. The deliverables at the lowest level of the WBS are called work packages. Each item on the WBS is assigned a unique identifier which can provide a structure for a hierarchical summation of costs and resources. There is no one correct approach to creating a WBS. The nature of the project work to be performed, the preferences of the project manager, or even organizational policy will often determine the approach taken. Additionally, subject matter experts will have input on WBS preparation. The project manager decides on the architecture of the WBS and the level of detail that best meets the project's needs (since he is ultimately accountable for the success of the project). In designing the WBS, the project manager considers both the need for managing the work itself, and the best method for reporting information so that management can receive it in the form that is the most useful to them. WBS Elements The diagram below illustrates that the top level of the WBS, level zero, is the project itself. At the first level below the project, it is divided into the necessary major deliverables. When every deliverable is completed, the project is complete. If any deliverable at the first level is still too large to be accurately estimated, it is further decomposed to become several major components at the second level. This process continues until all deliverables meet the completion criteria.

88

WBS Organization A WBS can be organized in two ways, by product or process. Product-Oriented WBS In a WBS organized by product, the deliverables are at the first level below the project goal. Deliverables are then broken into components and subcomponents. If all deliverables are identified at the highest level, the project management team is less likely to omit work required to successfully complete the project. The product-oriented WBS places the deliverables related to subcomponents of the project's product, or related to its multiple products, at the top of the WBS. The diagram below is an example of a project with multiple deliverables. It is a software release, which requires the software itself, documentation, and training for various groups. These deliverables are then broken into components and subcomponents, but each component is another portion of the product or sub-product above it. For example, in developing a prototype for a new light switch, this breakdown would be completed down to the lowest level, which must be developed, such as the switch faceplate, or purchased, such as a screw. This is a pure product-oriented work breakdown structure, and it is rare.

89

Process-Oriented WBS In a WBS organized by process, the project phases are at the first level below the project goal. These phases are then subdivided into more detailed processes. In the diagram below, the Test phase shows the software being tested three times, in Build 1, then in Build 2, and finally as a complete system. However, it also shows the documentation being "tested", which likely involves a desk-check of the key procedures it describes against the tested system. That is why some of this phase's work breakdown structure is process-oriented, while another is product-oriented. This is the most common situation.

If the process method is preferred, it is suggested that first a WBS is created using the product method. In this way, work is broken down from the deliverables stated in the project scope statement, improving the chances of capturing all the work required. If all the deliverables are identified, the project manager is less likely to miss work required to successfully complete the project. A WBS can be organized by phase, geography, subsystem, or by other criteria, as long as the goal and objectives of the project are met. Once all the elements are identified, the WBS can be rearranged in any number of ways to more efficiently organize or represent the work of the project for a specific stakeholder group.

90

WBS Formats There are two widely used formats for depicting the work breakdown structure during the Create WBS process - graphical and outline. The table below lists important characteristics of each WBS format. Graphical

Outline

Familiar organizational chart format - Easily created - most standard PM software some software tools available will create it Requires more space to present

Requires less space than graphical method

Best for visualizing structure - adequate Good for facilitated team planning (in for facilitated team planning modified form) Graphical Format The graphical representation of the WBS is intuitive and easy to follow. It is very clear which components are required for each deliverable and which subcomponents are required for each component. The numbering system and placement in the tree facilitate this ease of understanding. The lines in the WBS show the relationships between the components. This makes errors in the development or reading of the WBS rare. The graphical format has the advantage that it is very easy to scan and to locate components. This makes it extremely efficient during the Create WBS process, as the different components and subcomponents are identified and re-arranged to suit the project manager's purposes. It is also the easiest and most efficient to use during review and validation of the work breakdown structure.

91

Many project managers and their project management teams simply use 3 x 5 cards or sticky notes during the development of the WBS, rearranging them as necessary. They then link them using a marker on a whiteboard background to facilitate frequent changes. Once the teams are satisfied with the breakdown, organization, and placement, they can convert the result to another format that is more efficient for random accessing and minor editing, such as the outline format, which is discussed next. Outline Format The WBS outline format uses the same outline mechanism used for general documentation, with headings and subheadings to reflect grouping of elements. The advantage of the outline representation of a WBS is that it does not require a lot of space or special software to create. Indenting each descending level of the WBS in the outline method facilitates reading the document. The disadvantage of the WBS outline format is that its primary orientation is at the lowest element level. This can make it difficult to read top-down, which is the primary approach to creating a WBS. Most project managers use one of the other methods to create and validate the work breakdown structure, and then convert it to this format for readability during project execution and for minor changes. If major restructuring is required later, for example, due to a large-scale scope change, project managers may revert the affected portions to another format first, make the changes, and then return to the outline format.

92

Create WBS Process Inputs Organizational Process Assets The organization process assets include WBS templates that can be used to rapidly assemble the project's final WBS. Project Scope Statement The project scope statement defines scope. Major project deliverables approved in the project scope statement are used as a starting point for creating the WBS. Project Scope Management Plan The project scope management plan describes how the WBS will be constructed. Approved Change Requests Any approved requests involving changes to scope are reflected in the WBS as a result of the Scope Control process. Tools and Techniques to Create a WBS WBS Templates Many organizations perform projects in a specific application area. Therefore, the projects are similar in nature, but have unique characteristics. For example, a pharmaceutical company will typically not have a bridge construction project in their portfolio, and likewise, a construction company typically will not have the development of a new drug in their portfolio. Because organizational projects are similar in nature, they will more than likely have common areas, such as communications or procurement. This resemblance makes it possible for projects to reuse part or all of a prior project's WBS. When a project's work breakdown structure is determined to be valuable for reuse more than once, it usually makes sense to create a standard WBS template. In some cases a mandatory WBS structure or template may be provided by the contracting organization or as part of an enterprise project management governance model. This is done to promote consistency and commonality across projects. Many projects may be managed or reviewed by the same oversight board or manager. This greatly improves productivity and reduces errors during the Create WBS process.

93

Benefits of Using WBS Templates Using WBS templates provides many benefits, including: •

Helping to ensure that the same activities are performed each time the project evolves;

•

Giving the performing organization a consistent approach;

•

Providing efficient use of subject matter experts' (SME) time: o

Only have to customize the template instead of starting from scratch to develop the activities

o

Project team can create project plans more quickly

o

Cost and duration estimates do not need to be developed from scratch.

Decomposition Decomposition is the technique used to create the work breakdown structure by analyzing the project product(s). It involves partitioning the work into successively smaller units until they can be reasonably: •

Estimated for work effort and cost;

•

Monitored and controlled for progress; and

•

Assigned to an individual for accountability.

Different deliverables have different levels of decomposition. The goal is to arrive at a manageable work effort (i.e., work package). The work for some deliverables may need only to be decomposed one level, while others may need to be broken down to many levels of decomposition. The project team must have a keen sense of knowing when a deliverable has been subdivided enough. The purpose of decomposition is to subdivide the project deliverables into smaller, more manageable components. Decomposing the WBS enhances the ability of the project manager and team members to improve the planning, managing, and controlling of the work. However, part of the "art" of project management is to balance the level of decomposition in such a way that its detail does not decrease efficiency and productivity.

94

How to Decompose a Project The flowchart shown below can be a useful tool for decomposition.

Start: Project Goal Start with the project goal stated on the project scope statement. The project goal may also be referred to as the product description. Condense the goal into a three to five word description of the project; for example, New Safety Program, Virtual Project Office, Product X Launch. Place the description at the very top of the WBS. Step 1: Identify Major Deliverables •

The major deliverables should also be stated on the project scope statement;

•

Transfer these deliverables to the first level of the WBS below the project goal;

•

There are two questions to ask at each level of decomposition: 1. Are all these items necessary for the item above them to be successful? If the answer is no, then remove any unnecessary items and ask again. 2. If only the items identified are successfully completed, can the item above them be considered completed? If the answer is no, then add any required item(s) and ask again.

•

Once the two questions are satisfied, move on to the next step.

95

Step 2: Develop Adequate Estimates? •

Decide if adequate cost, duration, and resource estimates can be developed for each item previously identified; and

•

For each item that can be answered yes, move to Step 4. For each item that is answered no, move to Step 3.

Step 3: Identify Constituent Components •

Subdivide each item from Step 2 into its constituent components. (Ask: What are the necessary components that make up this item?);

•

List each component below the item from Step 2;

•

Ask the same two questions from Step 1 of each item entering Step 3. When finished, carry all the appropriate components back into Step 2 and repeat Step 2 on each component; and

•

Repeat this process until all items entering Step 2 can be routed to Step 4.

Step 4: Correct and Complete? •

Verify completion of the decomposition with three questions: 1. Are all lower-level items necessary and sufficient for completion of the decomposed item? 2. Is each item clearly and completely defined? 3. Can each item be appropriately scheduled, budgeted, and assigned to a specific organizational unit (department, team, or person) who will accept responsibility for the satisfactory completion of the item?

•

If each of these questions cannot be answered yes, then the item must be moved from Step 4, returned to Step 2, and decomposed further;

•

Once these questions can all be answered yes, then the item is completed; and

•

Continue this process for all items.

Progressive Elaboration It is normal for decomposition to be detailed only for the upcoming phase of work for which management must approve detailed plans. Often, there is not sufficient information about work later in the project to break that work down beyond only the highest levels. Hence, the portions of project planning deliverables related to the immediately upcoming work are detailed and specific.

96

Those related to later work may be more general, however, and may be presented with a margin of variation within which the project management team expects the project to perform. As each phase of work concludes, the next phase's WBS will be further decomposed to the necessary level of detail to offer management accurate enough estimates of cost to assure them that the project's value still merits further investment, and to give them a standard against which the project's actual performance during that phase can be compared. That way, they know whether the project will hit its targets.

WBS Dictionary This is a catalog of all the entries in the WBS which provides descriptive information for each work package, such as: •

A statement of work (SOW) describing the work content;

•

Schedule or milestone data;

•

Budget estimates and how the estimate was derived; and

•

Team member who is responsible for the work package or deliverable.

Scope Baseline Scope baseline is simply the aggregate of the: •

Project scope statement;

•

WBS; and

•

WBS Dictionary.

Updates to the Project Scope Management Plan This process involves any changes to the processes for creating and updating the project scope statement or WBS that have been approved through the Integrated Change Control process. Requested Changes Requested changes to the project scope statement and its components may arise from the Create WBS process. These changes are processed for review and approval through the Integrated Change Control process.

97

Scope Verification Scope Verification is the process of obtaining the stakeholders' formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily. Scope Verification requires the team to review deliverables and work results to ensure that all were completed correctly. As the deliverables reach completion, it is just as important that the stakeholders agree that these products fulfill the expectations defined at the start of the project. During the Scope Verification, key stakeholders confirm that these expectations have been met. If the project is terminated early, the Scope Verification process should establish and document the level and extent of completion. Quality Control vs. Scope Verification Quality Control may require that, before external release of the product to the customer for acceptance, certain procedures/processes relating to quality management for both the product and project, such as Quality Planning, Quality Assurance, and Quality Control, are included as part of the project scope statement. Scope Verification differs from Quality Control in that it is primarily concerned with acceptance of the work results, while Quality Control is primarily concerned with the correctness of the work results (validation). These processes are often performed in parallel to ensure both correctness and acceptance.

98

Gaining Stakeholder Acceptance Once the project is defined, the project manager should seek validation that it has been defined properly, i.e., that the deliverables will meet stakeholder expectations. When the project is complete or when particular deliverables are complete, then the project manager will seek formal acceptance of the deliverables. Formal acceptance is obtained from the project sponsor, customers, and other key stakeholders through the Scope Verification process. This process, including inspection procedures and identification of the approval authorities, is defined in the scope management plan. Verifying the project scope entails reviewing deliverables to ensure that each is completed satisfactorily. Some of the stakeholders who do not have this level of approval authority must still be engaged by the project manager to ensure their continued commitment to the project, and to minimize the risk that they will object to some aspect of a key deliverable at a later date. These stakeholders and their interests are initially identified in the project charter, and are subsequently analyzed through ongoing stakeholder analysis. They may have the ability to influence the project outcome, and their support (or, at least, neutrality) is essential to the project's success. An Acceptance Process The graphic below illustrates a sample product and deliverable acceptance process. The process begins by identifying the high-level Scope Verification process and approval authorities in the project scope management plan, as well as the product acceptance criteria in the project scope statement. If these elements require refinement (based on changes that occurred during project execution), those refinements to the scope management plan should be processed through Integrated Change Control.

99

Tools and Techniques used during the Scope Verification Process Inspection Inspection is the general term used in the PMBOK® Guide, Third Edition, to refer to verifying whether a project deliverable meets the allocated requirements and related product acceptance criteria. It can include any or several of the following techniques: •

Measurement;

•

Testing;

•

Review;

•

Walk-through;

•

Desk-check; and

•

Audit.

It is important to note that practice varies widely between application areas regarding the meaning and details of implementation of each of these techniques. In manufacturing, however, an inspection is usually a quality control check of a subcomponent, usually involving test equipment and measurement of the component against a specified target with limited tolerances for variation. The intended result of the Scope Verification is to get a documented acceptance of the deliverable. As a result, all inspection techniques must result in the documented approval of the deliverable by the affected stakeholders, or their designated reviewers.

100

Scope Control Project Scope Control is concerned with influencing the factors that create project scope changes, and controlling the impact of those changes. The Scope Control process includes activities to review the project team's progress against the schedule of deliverables. The biggest challenge to the project manager/team is to resist adding changes to project deliverables after they have been formally approved in the project scope statement. Controlling Scope Creep Scope Control is the process used to prevent scope creep by: •

Formalizing how modifications are managed;

•

Regulating and managing the impact of changes to project scope;

•

Assuring all proposed changes, approved changes, and recommended corrective actions are processed using integrated change control; and

•

Minimizing, detecting, and correcting unauthorized changes to scope.

The Scope Control process includes activities to review the project team's progress against the schedule of deliverables. The biggest challenge to the project manager/team is to resist adding changes to the list of project deliverables after they have been formally approved in the project scope statement. Scope Control also manages the actual changes when they occur, and ensures that they are integrated with changes to other project management deliverables. It must be recognized that changes to project scope are almost inevitable, both because business domains undergo continuous change themselves, and because new and more effective means for performing business operations are continuously being developed and introduced. Neither of these dynamics can be ignored during the project; they must be continuously evaluated for their potential impact, both positive and negative, on the project scope. Scope Change Impacts Allowing the project's scope to change mid-course usually means added costs, quality, greater risks, and longer duration. Many projects fail due to poor scope management. Very often it is a large number of small scope changes that do the damage, rather than the big, obvious ones. The successful project manager has learned that rigorous scope control is essential to delivering projects on time, on budget and with expected quality. Standard IT development models are requirements-driven. They assume that the project team will be delivering a final product with characteristics that can be clearly defined up front. These methodologies provide a disciplined, sequential process for defining the schedule, budget, resources, risks, quality and scope. This process assures all requested changes and recommended corrective actions are included as part of the process.

101

An important rule of thumb to remember is: The later a change is addressed, the greater the cost, risk, and duration of the project. Scope Control occurs throughout the life of the project (the processes are iterative) and the inputs change based on the phase of the project. How Stakeholders May Think About Scope Changes Project team members should be alert to how stakeholders and team members think about scope change. For example, during reviews and other audits and walkthroughs, listen for and watch out for the use of scope change as defensive or aggressive behavior. Performance Reports The performance reports indicate how the project is progressing, and specifically, which deliverables have been completed and specifically whether project performance is adequate within ongoing activities. Approved Change Requests The approved change requests are received from the Integrated Change Control process in Integrated Change Management, and must be accommodated in the project scope baseline. Work performance information Work performance information indicates the extent to which quality standards are being met, estimates to complete on the schedule activities that have started, and documented lessons learned. Recommended Corrective Actions Recommended corrective actions may be necessary to bring future project performance back into line with the project management plan. They do not require a change to a project baseline, but represent minor alterations in work processes or resources utilization.

102

REFERENCES PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008 PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008 R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010 M.Crouhy, R. Mark, D. Galai, "RISK MANAGEMENT", McGRAW-HILL, 2001 M. Effron, M.Goldsmith, "HUMAN RESOURCES IN THE 21st CENTURY", John Wiley & Sons 2003

103

Chapter V Procurement Management Procurement management may be defined as the combined functions of purchasing planning, vendor’s qualification, purchasing, inventory control, traffic control, quality control, and salvage operations. Procurement management is a concept originally introduce by governments whereby the purchasing function is expanded from merely exchanging money for goods to one of total responsibility for acquiring goods. From the project management point of view, procurement functions vary according to the job progress within the project life cycle. Since material supply for projects is usually one of the main components of the total construction effort, special attention should be given to the functional organization that will be handling the procurement operation. Procurement during conceptual estimate paper and design basis paper, is limited to consulting services from the engineering department about: • • • •

Vendor availability; Market conditions; Order of magnitude estimates; and Delivery time estimates.

This consulting service is a simple but vital function considering that project procurement cost is usually found to be 40 to 60 percent of the total cost of the project. During Project Proposal (PP) development the main function of the procurement organization should be the creation of an acquisition schedule for long lead time materials according to the project milestone schedule implemented within the project execution plan. The acquisition schedule is usually called the Long Lead Time Material (LLTM) and equipment schedule and it is always a commanding element for the total project duration. Additionally, during the project proposal phase preliminary materials take-off (TO) is carried out and a program for procurement of items other than LLTM is established. Materials 'take-off' (TO) is an engineering function that consist of reading design drawings and producing material and equipment schedules required for supporting construction of the project. Once the material/equipment TO's are completed, purchase requisitions are generated.

104

Purchase requisitions (PR) usually contain the following: • • • • • •

Engineering drawings; Engineering specifications; Inspection requirements; Contracting terms and conditions; Shipping requirements; and Required ex-plant date.

Once the project is funded, definitive design generates more detail information and purchasing functions become more involved in the project development. The already started vendor consultation and qualification will be complemented with new information resulting from the design team and purchase requisitions will be consolidated. Long lead time material and equipment purchasing orders will be generated immediately after funding if prior provisions for this issue have not been made. This phase of procurement development requires a great deal of bidding and contracting before the total project requirements are committed. When all purchase orders have been placed and the contract awarded, the procurement organization has some of the most important tasks within the project life cycle, they are: • • • • •

Expediting; Quality assurance; Quality control; Shipping; and Delivering to site.

Expediting: Vendors and sub-vendors have to be closely supervised to avoid unnecessary delays and ascertain delivery according to technical specifications. Expediting requires: • • • • •

Original vendor production schedule; Original buyer milestone schedule; Establishing a progress measurement system; Reporting progress according to the above; and Analysis of performance to date and recommending action if necessary.

105

Quality assurance & Quality control: Quality assurance and quality control are procurement activities dealing with the accomplishment of design specifications. A quality assurance program is run by the vendor and control by the buyer at production time. Planning and scheduling for testing and checking are established at purchase order issuance. A quality control program is run by the project owner to ascertain that received and installed equipment and material comply with designed specifications and quantities.

CONTRACTORS QUALITY CONTROL

REGULATE PRODUCTION PROCEDURES TEST M ATERIALS AND EQUIPM ENT INSPECT WORKM ANSHIP

OW NER QUALITY ASSURANCE VERIFY THAT CONTRACTOR'S QUALITY CONTROL FUNCTION IS PROPERLY PERFORMED ENSURE THE RESULTS OF ANY OF THE COMPLETE FUNCTIONS ACCORDING TO SPECIFICATIONS

106

Shipping & delivering to site: Materials and equipment transportation is an extremely delicate task and requires extensive planning. Adequate planning includes consideration of: • • • • • • • • • •

Insurance coverage; Proper packing; Local and foreign custom requirements; Lead times; Cost analysis; Local transportation to site capabilities; Local traffic restrictions; Project schedule required delivery dates; Financial implications; and Temporary storage arrangements.

Project Procurement Financial Implications The cost of project material and equipment represent an important part of the total budget, big enough to cause serious financial damage if good cost control is not exercised. Decision-making for procurement organizations essential role in project management is based on: • • • • •

Purchase records; Specifications files; Vendors' performance records; Price historical information; and Exhaustive research.

With today's computer aids these tasks have become less of a load for the purchasing organizations and quick management information related to purchasing requirements data may be retrieved from data files if they are kept adequately updated. Projects cash flow are very much concern with timely acquiring materials and equipment and avoiding unnecessary expenses tied to transportation expediting or temporary storage. The procurement organization purchasing plan must follow the construction approved schedule and its periodic revisions. Material procurement has to be concerned with: • • • •

Market studies; Trend analysis; Make-or-buy studies; Price-cost analysis;

107

• • • • •

Supply sources investigation; Value analysis; Value engineering analysis; Latest purchasing innovations; and Computer advances.

Only then, it will be able to provide management support in its financial decision-making activities. Procurement Engineering Value Analysis Procurement engineering value analysis is a disciplined examination of the project procurement requirements to eliminate unnecessary costs brought up by: • • • •

Over design; Lack of original ideas; Insufficient information; Temporary business pressures and the like.

Value is defined as the relationship between price and worth of the function of a particular element. Value = price / worth The primary concern of any design is the function. Too frequently, the subject of cost is pushed into the background and then forgotten. A value engineering program will not let the team forget about cost and it will generate a healthy relationship between function and cost. Value engineering may be applied to the procurement functions as follows: 1.-Set up a plan. Before starting any procurement activity, ascertain that the procurement team has a plan of action. Follow the value engineering plan approach by breaking down the plan in phases as follows: • • • • • •

Feasibility; Information; Creativity; Evaluation; Proposal; and Implementation.

108

2.- Get all the facts. Become familiar with the procurement elements by factually reviewing them. Find answers to the following questions: • • • • •

What is the lead time required for fabrication? How many units will be needed? When are the units needed? How many suppliers are there? How much does it cost?

3.-Know about costs. To make a complete analysis of any procurement element, it is essential to know not only the total cost, but the breakdown of the total cost. This breakdown should include logistics, trade trends and the like. 4.- Set a currency value on each main idea. Rank your cost reduction ideas and start working on those offering a better return. 5.- Update your information continuously. Keep good information about vendors’ activity and materials market developments. Participate in procurement related professional associations for they are continuously updating information and presenting new approaches and ideologies. Procurement and IT Purchasing and materials management is one of the project areas that have benefited most from the introduction of sophisticated yet easy to master computer applications. Computers applications have brought along: • • • • • • •

Reduction of paper work; Ready access to collected data; Communications improvement; Fast response to changes in purchasing variables; Automated data analysis; Virtual elimination of filing; and A host of other intangible benefits.

109

Some specific project procurement tasks improved due to computer activity are: At project proposal phase: Creating and maintaining vendors' data, creating and maintaining quotations' data, evaluating suppliers, reviewing quotations, processing planned items requirements, generating cash requirement reports, maintaining a master data base, and generating materials take-offs. At preconstruction phase: Computers technological advances are helping at generating requisition and purchase orders, reviewing and approving requisitions, updating cash flow requirements, monitoring and controlling suppliers, and monitoring project management interface. At construction phase: Altering purchasing orders, answering order inquiries, estimating time of arrival, closing purchase orders, updating historical data bases, consolidating cash flow requirements, and providing instant information and communication Additionally, computers provide real time processing capabilities. The new available data is entered on line into the computer and information systems are updated forthwith. Computers hardware configuration may be designed according to the customer needs and expanded as business expand without losing flexibility, quality or money. Software is found galore for all kind of business activities or may be designed in-house following friendly, easy-to-learn, powerful, computer languages. Computers have changed the face of materials management and procurement activities as much as they have done with any other business. Vital functions as statistical information for the formulation of purchasing policy, can be updated as new data is entered and reported as: • • • • • • • • •

Historical purchasing activity; Prices variance; Purchasing order analysis and evaluation; Purchasing evaluation by vendor; Vendors’ delivery records; Purchasing economic indicators; Purchasing backlog; Rejections by vendor; and Cash flow updates.

110

All of the above mentioned are always available and revised to the latest trends thanks to computers. Computers let you sort your information, summarize it, break it down into components, present it in alternate formats, and highlight business most relevant areas at incredible speeds. Procurement Measurement Normally for a major project, the procurement of long lead technical equipment and materials is a function of the engineering effort and it is included in the engineering budget as a separate item. The procurement effort consists of three major functions: • • •

Material Take-offs; Purchase Requisitions; and Purchase Orders

To measure physical progress of the procurement effort, each of the three major procurement functions should be weighted as a percentage of the total procurement effort. This weight factor should be based on the budgeted man-hours for each function relative to the budgeted man-hours for the total procurement effort as shown in the table below.

FUNCTIONS MAT. TAKE-OFF PR’s PO’s

ESTIMATED QUANTITIES

ESTIMATED MANHOURS

150 200 100

400 700 400

Procurement

FUNCTION % WEIGHTED VALUE 26.6 46.7 26.7 100

Material Take-offs Physical progress measurement for material take-offs is based on the estimated number of drawings requiring material take-offs versus the number of drawings for which take-offs have been completed. For example: The estimated drawings requiring take-offs = 150 Drawings with take-offs complete = 75 Physical progress would be: (75/150)(100) = 50%

111

Purchase Requisitions Physical progress measurement for purchase requisitions is based on the estimated total number of purchase requisitions versus the number of requisitions approved for purchase. For example: The total estimate of Purchase Requisitions = 200 Purchase Requisition approved for purchase = 50 Physical progress would be: (50/200)(100) = 25% Purchase Orders Progress should be based on both the quantity of purchase orders placed and the cumulative dollar value of materials shipped from the manufacturer's plant (explanted). The quantity of purchase orders placed will contribute 50 percent progress and the dollar amount of total material value explanted will contribute the remaining 50 percent. For instance, the purchase order quantity is 100 with 28 purchase orders placed. The total cost of purchase materials is estimated at 50 million dollars and from this amount approximately 1 million dollars of materials has been explanted. Progress would be calculated as follows: 28 PO's placed out of 100 = 0.28( 0.5 )100 = 14% $ 1 MM of materials explanted out of $50MM= 0.02 x 0.5 (100) = 1% Progress to date for purchase orders: 14+1=15% Total Procurement Progress By evaluating the physical progress of each major procurement function, the total procurement progress can be determined as shown in the table below. FUNCTIONS

TAKE-OFFS PR’s PO’s

PERCENT COMPLETE

WEIGHTED VALUE

50 25 15

26.6 46.7 26.7

Procurement Progress

PROCUREMENT CONTRIBUTION 13.3 11.7 4.0 29.0

112

REFERENCES Hodges, H.G.,"PROCUREMENT HANDBOOK", Harper & Brothers publications, 1991 Duran, J.M.,"QUALITY CONTROL HANDBOOK", McGraw Hill Book company, 1944 Dobler, D.W.,"PURCHASING AND MATERIALS MANAGEMENT", 1997 Lasser's, J.K.,"BUSINESS MANAGEMENT HANDBOOK", McGraw Hill Book Company, 1998 T.J. Esque, " NO SURPRISES PROJECT MANAGEMENT", ACT Publishing 1999 PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008 PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008 R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010

113

CHAPTER VI Contracting Management It is essential that the administration and management of contracts results in reducing risks, maximizing cost savings, minimizing claims, and improving economic return. These results can only be achieved through effectively managing contract risks: developing tough but fair contract documents, engaging in aggressive negotiating practices, and employing outstanding communication skills. The process of reaching a contract requires a specific sequence of steps. In taking these steps, the Project Manager must make a series of choices between priorities for project objectives, degrees of risk to be assumed by the contracting parties, control over project activities, and the cost of achieving selected goals. This process must first be fully understood by the Project Manager, then be tempered by experience, and finally be expanded into the ability to reach a contract through the exercise of negotiating and communicating skills.

What is a Contract? A contract is a mutual business agreement recognized by law under which one party undertakes to do work (or provide a service) for another party for a previously agreed sum of money. Owner contracting arrangements would cover: • • • •

Contract Conditions; Commercial Terms & Pricing Arrangements; Scope of Work (Technical); and Project Execution Plan.

Why have a Contract? A written contract provides the document by which the risks, obligations, and relationships of all parties are clearly established, and ensures the performance of these elements in a disciplined manner. In the Owner situation, the contract is the means by which the Contractor can be controlled and ensures that the work and end product satisfy the Owner’s requirements.

114

Parties to the Contract Most projects are executed under a three-party contractual relationship: •

The Owner, who establishes the Form of Contract and the General Conditions;

•

The Engineer, who can have the following three roles: 1. Designer - carrying out the detailed engineering work, and purchasing equipment and material on the Owner’s behalf 2. Arbitrator - acting as the Owner’s agent in administering the contract and deciding, impartially, on certain rights of the parties under the contract 3. Project Manager – on the owner’s behalf handling design, procurement, and construction or construction management/services; and

•

The Contractor, who executes the work.

The normal contractual relationship among these three parties on a single project is for the Owner to have one contract with the Engineer for design, procurement, and other services, and a separate contract with the Contractor for the construction work. No contractual relationship exists between the Engineer and the Contractor. This is usually referred to as a “divided or split responsibility” arrangement. In an alternative arrangement, called “single responsibility”, a General Contractor is awarded total responsibility for the engineering, procurement, and construction. The Project Manager must carefully decide on a specific contracting arrangement. Contract Responsibility The Project Manager is essentially responsible for the contract strategy, which is developed as part of the project strategy. However, the proposed division of work, contracting arrangements, forms of contract, and bidders’ lists should be developed in conjunction with the company’s Contracts Department. This combined responsibility of the Project Manager and the Contracts Department in the contracting process can lead to inefficiencies, delays, and disagreements and can negatively impact the project cost and schedule when there are organizational conflicts.

115

Close coordination and effective communications must exist between all groups to ensure complete agreement and commitment to the proposed contracting program. This is particularly important in all submissions to Contract Committees and/or senior management. The Project Manager must obtain agreement from the company’s Contracting Department and Insurance Department before committing to contractual language regarding liability, indemnity, or insurance. Contract Strategy The following would be major considerations when developing a contract strategy for the project: •

When and how will the work be divided up?

•

How will the division of work affect Client/Project Team/Main contractor/ Vendor/Subcontract or interfaces? (This division enables the Project Coordination Procedures to be properly prepared.);

•

What type of contract should be used? Segment the project into discrete work packages to facilitate management, and subject the work packages to available resources. Consider the contract philosophy, the type of contract best suited to the project, contract interfaces, bid evaluation techniques, and bid documentation. This enables the contract strategy to be produced in liaison with the Contracts Department;

•

What roles are licensors and consultants expected to play? This allows arrangements to be made for prequalifying suitable contractors, issuing invitations to bid, evaluating bids, and making award recommendations;

•

Are there potential conflicts of interest with other Owner projects in contractors’ offices, in vendors’ workshops, or within fabrication yards? Such conflicts can have an impact on the bidder’s list;

•

What is the availability of skilled labor? What is the industrial relations climate local to fabrication yards and local to the construction site? Lack of labor can delete a contractor from the bidder’s list; and

•

What is the quality and availability of personnel to develop, evaluate, and administer the required type of contract/contract conditions?

116

Generalities about Contracting Contracting differs from others disciplines in the degree of uncertainty. The contractor must deal with difficult variables, such as adverse environment, weather, terrain, interference, personnel qualifications and tempers, different types of jobs, different specifications and widely fluctuating costs in addition to an unknown future market for his services. Generally speaking, contractors are men of integrity for those who are not eventually do not survive. Profit is the contractor's incentive and no one should expect a contractor to perform at cost. The point is that a healthy contractor is a solid performer and a good businessman, knows its costs and what he can or cannot do, and realizes that his reputation is built upon his past performance. Success breeds success. A contractor may overbid or underbid any given project, but on the whole, at year end, he should show up reasonably in the black. This is the motivation and makes his efforts worthwhile. While an established contractor tries to provide steady year-round employment for a fixed group of people he has found reliable, he must deal with multiple factors affecting his potential. Some of these factors are: • • • • • •

Level of economical activity in his area of business; Specialized personnel available to perform; Ever-growing competition; Difficult-to-deal-with customers; Internal organization problems; and Adverse weather conditions.

Successful Contracting Attributes Successful contractors outside of attributing their good fortune to esoteric business skills, suggest the following general precepts as particularly important in operating a profitable contracting firm: • • • • • • •

Well-trained, experienced personnel; Sound job selection; Effective cost-control and reporting procedures; Careful analysis and cost/time estimating; Good labor and public relations; Alertness to improvements; and Sound financial policies.

117

Well Trained, Experienced Organization The secret of success in any endeavor has been defined as organization. This is certainly true in the case of a contractor. His success and reputation depend on the effectiveness of the organization he directs. The contractor, his management, and his staff must be well qualified for their positions by reason of education, experience, and demonstrated ability, with capability in organizing and directing men to accomplish jobs in minimum time with quality workmanship, not an easy task by any means. Contractor failures are by and large due to managerial inability, lack of experience, and incompetence. These, of course, are linked to organizational incapability, which results in ineffectiveness in other areas as well. Sound Job Selection A contractor usually has an opportunity to bid many jobs each year; many more than he has capacity to perform. From these solicitations he must be astute enough to select only those he can perform and which offer him a reasonable opportunity for profit. He cannot afford to be indiscriminate, since bidding is a costly process. If he were not selective, he might find himself overextended with disastrous results. Of course, he would prefer a cost-plus or a negotiated contract, which minimizes this risk and assures a profit. Effective Cost Control and Reporting Procedures The importance of this item should be quite obvious. It is necessary to report and record costs effectively so that the contractor can keep on top of his job. these guide him in the control of the job, provide the data on which he can base future estimates, and bring to light opportunities for savings on jobs he performs. Careful Analysis and Estimating This is vital to the successful contractor. Knowing and understanding thoroughly all facets of the job being bid and providing for possible unknowns he must now be able to estimate accurately his costs for performing the job including a reasonable profit. An estimator actually plans how the work is to done taking into account all pertinent factors. This is true on firm or cost-plus contracts. All plant engineers and other top management people have a need for accurate estimates; these are the basis for approval or disapproval of proposed projects. A pet peeve of most plant managers and plant engineers is the inaccuracy of an estimate as compared with the final cost of the project.

118

Good Labor and Public Relations The contractor is a businessman in a community and he needs to attain and reinforce a positive favorable image in that community. By this image he becomes known, and his reputation becomes enhanced. Certainly this is more desirable than the alternative. Perhaps of greater importance is his ability to deal with the people he has on his jobs. His success or failure depends on the accomplishment of his jobs at a profit through the people he employs. The management skill of his organization is tested almost constantly in coordinating and motivating various crafts involved in a job. Certainly each supervisor should have a working knowledge of the limits of craft responsibility, as well as an understanding of the working class environment, union or otherwise, and should be able to control and guide a project effectively and wisely to a successful conclusion. This proficiency, on the part of the contractor, is very important to a plant engineer; it assumes an even greater importance when plant craftsmen are involved since disputes resulting in costly delays can readily develop between plant craftsmen and outside craftsmen. Alertness to Improvements Every businessman, including contractors, must be aware of developments and methods improvement, which may make it easier and less costly to perform his tasks. He needs to be flexible, willing to change and not married to the old way of job performance. Many new types of material and labor-saving devices are being developed in the present competitive environment. The contractor must keep abreast of and utilize these advance if he is to remain alive. Sound Financial Policies Most contractors who have failed seem to have met their doom because of ineptness in financial management. It is important at all times to have sufficient cash reserves and working capital. Excessive investments in fixed assets may result in insufficient working capital, burdensome fixed charges and a high breakeven point. Inventories should be held to a minimum, since having cash tied up in inventory may result in insufficient cash available to cover current liabilities. Working capital should be adequate to avoid becoming overextended financially. Many different financial ratios, compiled by various associations from balance sheets and profit-and-loss statements, are available. Some of the more meaningful ratios which may apply to a contractor's business are: • • • •

Working capital to sales 10-15% Cash to current liabilities 25-30% Net profit to net sales 5-10% Current assets to current liabilities 1.5-2.5 times

119

Contracting Clauses Contracting is basically an agreement between two parties, one called the contracting party or owner and the other the contracted party or the contractor, to perform a previously determined scope of work for a previously determined amount of money. It is the contractor's duty to perform the scope of work for which he (she) was contracted according with the clauses stipulated in the contract related to: • • • • • •

Job specifications; Level of quality; Safety requirements; Cost control services; Reporting requirements; and Labor laws.

Contracting usually follows a cycle as the one depicted in the figure below. This plan shows all the usual pre-contracting activities, the bidding process and after bidding contract development. The discussion that follows will speculate on each area with more detail.

Type of Contract

A pprove Technical Specs

Internal Review

Bid Package

Approve Bidding Draw ings PHASE I

Invitations to bid

Job ex meeting

Bid Closure

PHASE II Post-Qualif ication

Technical Package PHASE III

120

Commercial Package

Aw ard

Pre-contracting Activities The owner contracting representatives usually rank the contractors in the area with special qualification requirements well either in anticipation of starting any specific contracting activity (pre-qualification) or asked for credentials along with the bid offer (Postqualification). Whatever system is chosen contractor’s qualification is usually carried out taking into consideration a number of parameters as: • • • • • •

Financial capabilities; Supervisory staff; Manpower availability; Equipment; Previous experience; and Workload.

Supervisory staff should be qualified by name and resume. A team of ten is essential: • General superintendent; • Superintendent assistant; • Chief engineer; • Civil engineer; • Mechanical Engineer; • Electrical engineer; • Accountant; • Quality assurance supervisor; and • Security & safety supervisor. Equipment should be measured by maintenance state and reported success based on historical data. So when a project comes by the contracting people have clearly established in anticipation the slate of contractors available to perform the job. Once the job is ready for contracting, a bid package has to be put together. This bid package usually contains the following: • • • • •

Instruction to bidders on how to handle their proposals; Contracting general conditions; Contracting special conditions; Technical specifications; and Drawings and schedules.

121

Instruction to Bidders The instruction to bidders should contain: • • • • • • • • • •

Project description, parties involved and schedules; Type of contract to be followed; Deadline for proposal submissions; Number of copies for offer; Sealed proposals and a one-time opening after due date; Payment routine; Procurement needs; General safety requirements; Inspection regulations; and Bond requirements.

General Conditions Contract general conditions will depend on specifics about every project in particular but it usually includes: • • • • • • • • • • • • • • • • • • •

Definition and interpretation; Contract documents; Responsibilities; Duties; Performance bonds; Site inspection procedures; Project cost and schedule controls; Safety regulations; Security regulations; Compliance with company bylaws; Patent rights and royalties; Cleanliness requirements; Hold owner harmless clauses; Labor relation matters; Quantity assurance and quantity control clauses; Project modification and changes procedures; Unit rates; Owner rights; and Contractor default clauses.

122

Special Conditions Special conditions usually refers to those related to the kind of contract at hand which sometimes makes the job specifically different from run-of-the mill contracts. They usually include: • • • • • •

Special work hours; Extensive insurance coverage; In-depth definitions of responsibilities; Extra safety precautions; Highly confidential issues; and National security involvement.

Technical Specifications Technical specifications are the heart of the job definition and as a minimum they should contain the following: • • • •

Written description of what is to be built; Interfaces with drawings to show details and with procurement schedules to establish real needs; Work breakdown structure; and Organization breakdown structure.

Drawings and Schedules Drawings and schedules are the complement of the technical specification and they depict the total scope of the job and material quantities required to be installed. They are usually marked "For quotation only" (FQO) as opposed to drawings and schedules later issue marked "Authorized for construction" (AFC). Once the bid packages are distributed to bidders, a job explanation meeting is prepared to allow prospective contractors to consult the owner design team representatives. A physical visit to the construction site will follow and bidders are usually asked to present certification of attendance to this procedures along with their proposals.

123

During the period between bid distribution and bid closing a great deal of consultation activity takes place between bidders and owner representatives to clear: • • • •

Bid errors; Bid omissions; Additions; and Deletions.

At bid closing time, contractors are requested to deposit commercial and technical proposals in different envelopes in specially locked boxes belonging to the owner. Owners usually have an internally developed proposal to be able to compare bids against it. The technical proposals go to the owner's technical team where their compliance with bid technical requirements is established and returned to owner contracting representatives. The owner's contracting representatives along with the owner's auditors open and analyze commercial proposals and establish the best offers with matching technical acceptance. A management executive committee then decides where the award goes based on the previous analysis by other groups mentioned above. Once the award is communicated to the successful contractor, a meeting is set up to ultimate details and analyzed the contract document to be signed. The contract should establish clearly the owner and contractor representatives and their respective duties throughout the contract. After contract signature, the contract performance starts by securing approval of the contractors planning and scheduling of the activities involved and mobilization of contractor's equipment and personnel. Performance measurement procedures are set up and followed and accountability reports based on the project breakdown structure and the previously establish code of accounts are started. During the first construction site meeting, daily, weekly and monthly report needs are organized and enforced. Inspection and safety from the owner's office will keep close attention to field developments and highlights of inappropriate work produced. Close analysis of the data collected by the above mentioned reports and schedule updates will generate decisionmaking activities within the project management team to keep the contract running under budget and on schedule.

124

Planning and Scheduling As mentioned above Planning and scheduling starts at contract signature with the approval of the contractor's schedule. The contract should have specific provisions to deal with: • • • • • • •

Lack of progress; Project design changes; Manpower allocation; Original schedule updates and revisions; Reporting needs and frequency; Material procurement interface; and Tools and equipment allocation.

Contracting Arrangements Engineering and construction contracts can be drawn in a great variety of forms, depending on the contract strategy and the financial resources of the Contractor. The most successful contracts have at least one element in common: thoughtful and thorough preparation before the contract is let. Contractual arrangements in construction are becoming increasingly more involved, which leads to the potential for significant added costs. Project complexity and the changing and increasingly costly legal and insurance environments, are major reasons for considering whether better contractual arrangements are possible. Contracts, of course, must be made early in the life of a project. To do this while simultaneously providing for the risks of uncertainties and gaining improved performance and innovation presents major challenges for Owners and Contractors alike. Forms of Contract There are three principle types of contracts: reimbursable, measured (unit price), and lump sum. The following forms of contract are typical of these types: • • • • • • •

Cost Reimbursable (Time & Material); Cost Reimbursable with Percentage Fee; Cost Reimbursable with Fixed Fee; Cost Reimbursable Plus Cost/Schedule Bonus – Penalties; Measured Unit Price (Mostly Construction); Guaranteed Maximum Price; and Lump Sum/Fixed Price.

The objectives of cost, time, quality, risks, and liabilities must be analyzed and prioritized, since trade-offs will probably be necessary in deciding the type of contract to be used.

125

Reimbursable Cost Contracts These require little design definition, but need to be constructed in a way that allows expenditures to be properly controlled. The major advantage of a reimbursable cost contract is time, since a contract can be established during the early stages of a project. This type of contract does present a disadvantage to an Owner, however, since poor Contractor performance can result in increased costs, and the final costs are the Owner’s responsibility. Additionally, the final/total investment level is not known until the work is well advanced. Reimbursable cost contracts can contain lump sum elements. e.g. the Contractor’s overhead charges and profit, which is usually preferable to a percentage basis for calculating these costs. Reimbursements may be applied to salaries, wages insurance and pension contributions, office rentals, communication cost, etc. Alternatively, reimbursement can be applied to all-inclusive hourly or daily rates for time spent by engineers on the basis that all office support costs are built into these rates. This form of contract is generally known as a fixed fee/reimbursable cost contract and can be used for both engineering and other office services as well as for construction work. Such arrangements give the Owner greater control over the Contractor’s engineering work, but the effect of reducing the lump sum content of the Contractor’s remuneration is to reduce its financial incentive to complete the work economically and speedily. It also reduces the ability to compare/evaluate competitive bids, since the comparison that can be made between Contractor bids involves only a small percentage of the project cost. It is possible that the “best” Contractor may not quote the lowest prices. Requirements • • •

A competent and trustworthy contractor; Close quality supervision and direction by the Owner; and Detailed definition of work and payment terms covered by lump sums and by “all-inclusive” rates.

Advantages 1. Flexibility in dealing with changes (which is very important when the job is not well defined), particularly if new technology development is proceeding concurrently with the design. 2. An early start can be made. 3. Useful where site problems such as Internal Review (IR) delays and disruptions may be encountered. 4. Owner can exercise control on all aspects of the work.

126

Disadvantages 1. Final cost is unknown. 2. Difficulties in evaluating proposals--strict comparison of the amount tendered may not result in selection of the “best” Contractor or in the lowest cost of the project. 3. Contractor has little incentive for early completion or cost economy. 4. Contractor can assign its “second division” personnel to the job and may make excessive use of agency personnel and/or use the job as a training vehicle for new personnel. 5. Owner carries most of the risks and faces the difficult decisions. Target Contracts (Cost and Schedule) Target contracts are intended to provide a strong financial incentive for the Contractor to complete the work at minimum cost and time. In the usual arrangement, the Contractor starts work on a reimbursable cost basis. When sufficient design is complete, the Contractor produces a definitive estimate and project schedule for Owner review, mutual negotiation, and agreement. After agreement is reached, these become targets. At the end of the job, the Contractor’s reimbursable costs are compared with the target and any savings or overrun is shared between the Owner and the Contractor on a pre-arranged basis. Similarly, the Contractor qualifies for additional payment if it completes the work ahead of the agreed-upon schedule. The main appeal this form of contract has to the Contractor is that it does not involve competitive bidding for the target cost and schedule provisions. Requirements • •

A competent and trustworthy contractor; and Quality supervision by Owner (both technical and financial).

Advantages 1. Flexibility in controlling the work. 2. Almost immediate start on the work, even without a scope definition. 3. Encourages economic and speedy completion (up to a point). Disadvantages 1. Final cost initially unknown. 2. No opportunity for competitive bidding for the “targets”. 3. Difficulty in agreeing on an effective target.

127

4. Variations are difficult and costly once the target has been established--Contractors tend to inflate the cost of all variations so as to increase profit potential with “easy” targets. 5. If the Contractor fails to achieve the targets, it may attempt to prove that this was due to interference by the Owner, or to factors outside the Contractor’s control; hence, effective control and reporting is essential. Measured Contracts (Unit Price) These require sufficient design definition or experience in order to estimate the unit/quantities for the work. Contractors then bid fixed prices for each unit of work. The advantage is that the time and cost risk is shared: the Owner will be responsible for the total quantities, and the Contractors will have the risk of the fixed unit price. A quantity increase greater than 10% can lead to increases in the unit prices. Requirements o An adequate breakdown and definition of the measured units of work; o A good quantity surveying/reporting system; o Adequate drawings and/or substantial experience for developing the Bill of Quantities; o Financial/payment terms that are properly tied to the measured work and partial completion of the work; o Owner-supplied drawings and materials must arrive on time; and o Quantity-sensitivity analysis of unit prices to evaluate total bid price for potential quantity variations. Advantages 1. Good design definition is not essential-“typical” drawings can be used for the bidding process. 2. Very suitable for competitive bidding and relatively easy Contractor selection, subject to sensitivity evaluation. 3. Bidding is speedy and inexpensive and an early start is possible. 4. Flexibility - depending on the contract conditions, the scope and quantity of work can be varied. Disadvantages 1. 2.

Final cost is not known at the outset since the Bills of Quantities have been estimated on incomplete engineering. Additional site staff is needed to measure, control, and report on the cost and status of the work.

128

Lump Sum/Fixed Price Contracts In this type of contract, the Contractor is generally free to employ whatever methods and resources it chooses in order to complete the work. The Contractor carries total responsibility for proper performance of the work although approval of design, drawings, and the placement of purchase orders and subcontracts can be monitored by the Owner to ensure compliance with the specification. The work to be performed must be closely defined. Since the contractor will not carry out any work not contained in the specification without requiring additional payment, a fully developed specification is vitally important. The work has to be performed within a specified period of time, and status/progress can be monitored by the Owner to ensure that completion meets the contractual requirements. The lump sum/fixed price contract presents a low financial risk to the Owner, and the required investment level can be established at an early date. This type of contract allows a higher return to the Contractor for superior performance. A good design definition is essential, although this may be time-consuming. Further, the bidding time can be twice as long as that for a reimbursable contract bid. For Contractors, the cost of bids and the high financial risk are factors in determining the lump sum approach. Requirements • • • •

Good definition and stable project conditions are essential; Effective competition is essential; Several months are needed for bidding and appraisal; and Minimal scope changes.

Advantages 1. 2. 3. 4. 5.

Low financial risk to Owner; maximum financial risk is on the Contractor. Cost (and project viability) is known before commitment is made. Minimum Owner supervision - mostly quality assurance and schedule monitoring. Contractor will usually assign its best personnel to the work. Maximum financial motivation of Contractor - maximum incentive for the contractor to achieve early completion at superior performance levels. 6. Contractor has to solve its own problems - and quickly. 7. Contractor selection (by competitive bidding) is fairly easy, apart from deliberate low price.

129

Disadvantages 1. Variations are difficult and costly - the Contractor, having quoted keenly when bidding, will try to make as much as possible on extras. 2. An early start is not possible because of the time taken for bidding and for developing a good design basis. 3. The Contractor will tend to choose the cheapest and quickest solutions, making technical monitoring and strict quality control by the Owner essential; schedule monitoring is also advisable. 4. The Contractor has a short-term interest in completing the job and may cause long-term damage to local Internal Review (IR) relationships, e.g. by setting poor precedents/union agreements. 5. Bidding is expensive for the Contractor, so the bid invitation list will be short; technical appraisal of bids by the Owner may require considerable effort. 6. Contractors will usually include allowances for contingencies in the bid price and they might be high. 7. Bidding time can be twice that required for other types of contracts.

Typical Contracts used in the UK and the USA United Kingdom • • •

Institute of Civil Engineers - ICE - mainly for civil and construction-only contracts; Federation Intemationale des Ingenieurs-Conseils, FIDIC - primarily for offshore and overseas work; and Institute of Mechanical Engineers - IMech E - primarily for design and erection of mechanical plants

United States •

•

•

American Institute of Architects - AlA -mainly for engineering work and project/construction management; the A/E usually functions as the Owner’s “agent” on a fee/reimbursable basis; The Associated General Contractors of America - AGC - mainly for construction work and construction management; the Contractor usually functions as an “independent contractor” on a lump sum/fixed price basis; and The Engineers Joint Council (EJCDC) forms of contract documents (issued jointly by the NSPE, ACEC, ASCE. and CSI and approved by the AGC), are often used by many engineering firms.

130

Contracting Summary 1. It is possible to devise a Form of Contract with appropriate terms and conditions to suit many different circumstances. Some basic considerations leading to the best choice are: 2. Clear definition of each party’s contractual responsibilities. Shared responsibilities are unsatisfactory, although they are unavoidable in some circumstances. 3. The Lump Sum Form of Contract provides the best financial risk for the Owner, gives the Contractor the maximum incentive for early completion, and produces the greatest benefit of competitive bidding. Conversely, Reimbursable Contracts provide no such incentives. It is dangerous, however, to attempt to use a Lump Sum Contract if the essential conditions are not satisfied - notably, a clear and complete definition of the scope of work. 4. The Owner must have the contractual right to exercise adequate control to ensure the success of the project, but the temptation to assume excessive control should be resisted. 5. Control and responsibility go together - the greater the Owner’s control, the less the responsibility carried up by the Contractor.

131

Recommendation for Additional Contracting Clauses The following is a contract supplement covering the minimum requirements for project schedules to be prepared and maintained by the contractor. Scope. The contractor representative shall attend planning, scheduling and coordination meetings to interface with the COMPANY and other contractors to identify and resolve critical scheduling issues. Proposed revisions to previously agreed schedules shall be submitted to the COMPANY at least 48 hours prior to the meeting where they are suppose to be discussed. These revisions shall be accompanied by complete documentation related to the proposed variations. The meeting shall be held at the work site or as designated by the COMPANY representative. Types of schedules Project milestone schedule. The contractor shall submit to the COMPANY, within 60 days of contract award, for its review and approval, a proposed project milestone schedule showing definitive plans for execution of the contract. This approved schedule shall be the contractor project milestone schedule and shall be used to plan, organize and execute the work, record and report actual performance and progress, and show how the contractor plans to complete all remaining work as of the end of each progress report period. The schedule shall be in the form of an activity oriented time scaled network diagram ( critical path method) and the principles and definition of the terms used herein shall be as set forth in THE INTERNATIONAL COST ENGINEERING COUNCIL (ICEL). Subcontracted activities shall be identified by the name of the subcontractor. The project milestone schedule shall identify critical milestones mentioned in other part of this contract. The project milestone schedule shall be updated and reissued on monthly basis. The project schedule shall reflect working within operating plants and the construction sequencing, tie-ins and the shutdown as generally described in the job specifications.

132

Summary schedule The contractor shall develop an Engineering, procurement and construction (EPC) summary schedule within 60 days of contract award. These schedules will establish the control points reflected in the project milestone schedule referred to in a paragraph above. The format for the EPC summary schedule shall be that of a time-scaled network containing 75-100 lines and 200-500 activities. Major restraints and interdependencies shall be shown. As a minimum the following should be identified: 1. Start and completion dates for each engineering discipline and release of critical drawings for procurement and construction. 2. All long lead critical material, major equipment and bulk materials, showing the procurement of these items and how they support the construction schedule. 3. The contractor site mobilization and start and completion dates for all major construction activities. 4. All activities to be performed by subcontractors including the contract award dates. 5. Man-hour weightings against each line item and man-hour weightings for engineering, procurement and construction works . The EPC summary schedule shall be updated monthly. EP schedules Engineering/Procurement schedules by major facilities shall be prepared to expand activity detail represented in the project milestone schedule and other schedules. Construction mobilization schedule. The construction mobilization schedule shall be prepared 60 days prior to arriving at jobsites. The plan shall consist of a full layout of all temporary facilities and the utilities required. Manpower and equipment required to complete mobilization shall be identified. In addition organizational charts are required for key personnel along with appropriate experience CVs. Construction summary schedule A construction summary schedule shall be submitted at least 60 days prior to arrival at jobsite to cover the overall duration of the construction segment of work and show the interface with engineering, procurement and fabrication via issue of drawings and delivery of equipment. The construction summary schedule shall be time-scaled and shall be developed within the parameters of the milestone schedule and the engineering/procurement/fabrication/construction schedules

133

90-day construction schedule The construction 90-day schedule shall be prepared from the criteria established by the construction summary schedule. It shall be prepared as a time-scaled bar chart format with major restraints shown. It shall be inclusive of work planned in a geographical area during the time span designated. The 90-day schedule indicates all resources required meeting the plan, including manpower allocation by craft, heavy equipment, materials, equipment deliveries, and engineering drawing interfaces. Construction weekly work plans The weekly work plan (WWP) shall be prepared in detail for all the resources required and quantities of work to be completed to achieve interim milestone dates. The activities on the weekly work plan shall be consistent with those on the 90-day schedule. The forecast work for the week is broken down by day, showing the total weekly quantity and total manpower required. Each week a construction meeting shall be convened to discuss the upcoming week’s work and review progress of previous week. The weekly work plan shall form the basis for all discussions and therefore shall be presented in a bi-weekly format. Construction equipment schedule The contractor shall prepare a construction equipment schedule identifying each type of major equipment and the quantity by month over the life of the contract. The submission shall be correlated to each activity of the construction summary schedules. The construction equipment schedule will be updated monthly by the contractor and include equipment actually used as of the report period and the equipment required to complete the remaining work. Equipment shall adhere to jobsite safety requirements and any required certificates shall be recorded with each piece of equipment. Tie-in schedule, Hot-Tap schedule and shutdown schedule The contractor shall prepare detailed schedules showing how these activities will be accomplished. These schedules shall be submitted for COMPANY review four weeks prior to commencement of work activities.

134

Progress Reporting Curves Each progress report should include a minimum of the following: 1. Highlights of significant accomplishments during the report period, expressed in relation to the total of work to be done in each category. 2. Current status of the work, Project progress information shall be provided in the form of a monthly project update report as instructed by the COMPANY representative and graphs showing actual versus scheduled progress for: •

Detailed engineering;

•

Requisitions issued;

•

Materials commitment;

•

Materials received at site; and

•

Field construction

3. Explanation of deviations from the target schedules, their consequences and corrective actions to be initiated shall be given. 4. Problems, along with actions taken to solve them. 5. Highlights of significant work items anticipated to be completed in the succeeding month. 6. Execution of action items as identified for the reporting period. 7.

Status of subcontracts

8.

Photographs of the site to indicate construction progress.

9.

Status of claims

10. Input for manpower reports. 11. Areas of concern Management review report The management review presentation should cover the up-to-date status of the project scope, schedule, project interface, detail engineering, procurement, construction, precommissioning and start up. The presentation should be depicted graphically and shall include a minimum of the following: 1.- Major milestones and major milestones schedule These two charts highlight the overall schedule. The major milestones chart is a listing of the project milestone with a tabulation of the scheduled, actual and forecast dates for each. The major milestones schedule chart lists the key engineering, procurement and construction activities and duration required to support the milestone.

135

2.- Engineering percent complete This chart represents the engineering progress by month. It is a series of ‘S’ curves denoting scheduled, actual and/or forecast progress. 3.- Status of major engineering office functions. This is a bar chart presenting the status of the following items: •

Drawings production;

•

Material requisitions issued for bid; and

•

Purchase order placed.

4.- Procurement status This chart represents, in percentage, the status of material requisitions issued for bid and purchase orders placed. it is a series of ‘S’ curves denoting schedule, actual and/or forecast progress. Progress should reflect design, manufacturing, and transportation activities or stages of material procurement. 5.-Fabrication and construction status This is a bar chart representing the key fabrication and construction activities and duration. The activities included are major disciplines e.g., civil, structural, piping, electrical and subcontracts. 6.-Overall plan/progress/forecast for engineering, fabrication and construction. This chart represents the total project plan. It relates engineering to construction progress and indicates the major milestones. It is a series of ‘S’ curves denoting schedule, actual and/or forecast progress. 7.-Contractor concerns. This chart is a listing of contractor concerns regarding the contractual responsibilities such as: scope variations, man-hour/manpower control, productivity, schedule variations/delays/recovery, etc. Manpower requirement forecast The contractor shall prepare a construction manpower requirements forecast in the form of a series of graphics displays depicting manpower by the following categories and in accordance with the construction summary schedule: •

Non-manual;

•

Manual;

•

Manual and non-manual summary; and

•

Manual by craft.

136

The graphs shall display the number of men by month, over the life of the contract. This submission shall be correlated with the manpower assigned to each activity of the construction summary schedule. A computerized analysis is required unless the contractor can demonstrate to the COMPANY representative’s satisfaction that a manual system will give acceptable control. The manpower requirements forecast will be updated monthly by the contractor and include manpower actually used by trade as of the report period and the manpower required to complete all remaining work. Schedule variation approval A.-Revisions to the project milestone schedule shall only be made to reflect the impact of variation orders and addenda. All proposed revisions to the project schedule shall be clearly identified and highlighted, and the reasons for each revision proposed shall be detailed by the contractor. All such proposed revisions shall be subject to approval by the COMPANY representative. The COMPANY representative shall review and approve or disapprove any request for such a revision within ten (10) days after submission of a documented request by the contractor. B.-When variation orders or addenda impact the project milestone schedule, or delays are experienced by the contractor, the contractor shall submit to the COMPANY representative a schedule analysis depicting the influence of each such variation order, addendum or occurrence of delay on the critical milestone date(s) and the schedule completion date. Each analysis shall include a network demonstrating how the contractor proposes to incorporate the variation order or addendum into the project milestone schedule and how delays no directly attributable to a variation order or addendum is proposed to be overcome by the contractor. The analysis shall demonstrate the time impact based on the: •

Date the variation order is issued, the addendum agreed or delay encountered;

•

Status of the work at that point in time; and

•

Event/time computation of all affected activities.

This shall agree with the latest update copy of the contractor’s detailed progress report. Networks of proposed revisions which result from variation orders and addenda and which are approved by the COMPANY representative shall be incorporated into the project schedule during the first revision after agreement is reached.

137

C.- If a variation order does not set forth the agreed time impact of a variation because this impact is “to be negotiated”, the contractor shall use its best efforts to estimate the time impact in its proposed revision to the project schedule and, subject to COMPANY’s representative concurrence, the contractor’s estimate shall be used on a provisional basis for project scheduling purposes. However, such use shall not constitute agreement as to the definitive time impact of the variation, and shall in no way prejudice the right of either the COMPANY representative or the contractor to negotiate the agreed time impact for that variation thereafter. Schedule control A monthly analysis of the project milestone schedule shall be made by the contractor and submitted to the COMPANY representative with particular emphasis on the critical and sub-critical paths. The conclusions of this analysis shall be covered in the monthly progress report to be prepared by the contractor and this report shall, as a minimum include: •

Narrative highlights of any variations over the status of the previous month;

•

Special actions recommended or being implemented to maintain or improve schedule; and

•

Outlook for activities to be started or finished.

Reporting In addition with the reports outlined above, the contractor shall maintain progress curves (planned versus actual performance) for each engineering discipline (project, process, instrument, electrical, piping, civil, etc.) and for each field craft (millwrights, pipefitters, welders, etc.) by major area of work. Progress shall be measured by physical measurements of work completed. The progress curves shall be available for review by the COMPANY’s representative on request. Schedule submission non-compliance If the contractor fails to submit the project schedules or manpower requirements forecasts, or revisions thereof within the required time, the COMPANY shall be entitled to withhold payments otherwise due until the contractor submits the required information. Schedule coordination The contractor shall coordinate work under this contract with other contractors working in the same general area. prior to developing the schedule and continuing throughout the time frame of the work, the contractor shall plan and coordinate all work activities directly with all other contractors and determine concurrent activities which may impact the work. The contractor shall throughout the performance of the work make every effort to coordinate activities so as to minimize interference and delays.

138

The schedule and all revisions thereto shall clearly indicate such areas of interference and/or delays which have not been resolved between the respective contractors. The contractor shall submit with the schedule an analysis of alternatives, cost estimates of each interference and/or delay situation, and complete documentation demonstrating impact on present schedules, future work events and on other contractors as well as sequence sketches illustrating the problem areas. These documents shall include minutes as approved by the COMPANY’s representative of all meetings between contractors whereby the situations and their alternatives were discussed. REFERENCES J.T. Brown, "THE HANDBOOK OF PROGRAM MANAGEMENT", McGraw-Hill Companies 2008 T.J. Esque, " NO SURPRISES PROJECT MANAGEMENT", ACT Publishing 1999 PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008 PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008 R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 “MASTERING PROJECT MANAGEMENT BASICS” Boston University, 2005 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010 M.Crouhy, R. Mark, D. Galai, "RISK MANAGEMENT", McGRAW-HILL, 2001 M. Effron, M.Goldsmith, "HUMAN RESOURCES IN THE 21st CENTURY", John Wiley & Sons 2003 J.Fitz-enz, "THE ROI OF HUMAN CAPITAL: MEASURING THE ECONOMIC VALUE OF EMPLOYEE PERFORMANCE", AMACOM 2000

139

Chapter VII Cost Management – Cost Estimating The essence of project management is the management of human resources, material assets, and other capital, toward the successful completion of a project's goal. Every decision to initiate a project should be based at least in part on the expectation that an important strategic goal will be accomplished by committing limited financial resources, and that the project will deliver value to the sponsor that exceeds the planned cost by an adequate margin. Cost management processes, interacting with each other and with processes of other project management areas, create accurate estimates and use objective, quantitative methods, such as Earned Value Management (EVM), discussed later in the book, to help monitor and control costs. Cost Management Plan The work involved in the Project Cost Management processes is preceded by a planning effort by the project management team. The Develop Project Management Plan process produces a cost management plan which sets out the format and establishes the criteria for planning, structuring, estimating, budgeting, and controlling project costs. Cost Management Plan Components A cost management plan can establish the following: •

Precision level - Cost estimates for schedule activities will adhere to a rounding of the data to a prescribed precision, for example, hundreds of dollars (00) or thousands of dollars (000), based on the scope of the activities and the magnitude of the project, and may include an amount for contingencies;

•

Units of measure - Each unit of measurement, such as staff hours, staff days, staff weeks, or lump sum, is defined for each resource;

•

Links to organizational procedures - The work breakdown structure (WBS) component used for project cost accounting is called a control account (CA). Each control account is assigned a code or account number that is linked directly to the performing organization's accounting system. If cost estimates for planning packages are included in the control account, then the method for budgeting planning packages is included;

•

Control thresholds - Variance thresholds for costs or other indicators, for example, person-days or volume of product at designated points in time during the project, can be defined to indicate the agreed amount of variation allowed;

140

•

Earned Value rules - These are the rules the project management team sets for computing earned value, discussed in more detail later in the course: 1. The formula for determining the estimate to complete are defined 2. The criteria by which earned value will be recognized according to the completion status of the work package (0-100, 0-50-100, or other) 3. The WBS level at which earned value analysis will be carried out

•

Reporting formats - Formats for the various cost reports are defined; and

•

Process descriptions - Descriptions of each of the three Project Cost Management processes are documented.

Defining the Value of a Project Using Total Cost of Ownership (TCO) Of special interest when considering cost management is the difference between the cost of the project life cycle and the cost of the product life cycle. As an illustration, consider the example of an electric power plant. The product is the gas-powered electric plant. The initial project is to build the plant. After this first project has been completed, the plant is turned over to the operators, who now use the plant to produce electricity over the plant's lifetime. At the end of the economic life of the plant, the plant will be shut down, and the salvageable components disposed of. The Total Cost of Ownership (TCO) is a financial estimate that reflects not only the cost of the project but also all aspects in the further use and maintenance of the product produced by the project. The decision to initiate a project to create a product, service, or result requires an understanding of the total life cycle cost of the product in order to compare the total costs required to achieve this benefit to the benefits that are expected. In other words, the value of the project, or in some business and marketing contexts, the value proposition, may be stated as follows: Annual VALUE = (BENEFITS - TCO - Tax) / (1 + R)T

141

Value = Benefits =

The total value of the product The gross return from the use of the product, in increased revenues or reduced costs, or a combination of both

TCO =

The total cost of all outlays for development, operation, support, and maintenance of the product

Tax =

Taxes paid by the organization on the gross benefits received

R=

Discount rate applied to benefits received in later periods, to reflect the cost of capital and the risk of not receiving the full benefits

T=

The number of periods during which the product generates benefits

Estimating the Benefits The sponsor of the project or the user of the final product must determine the value of the benefit of this new product, service, or result. The project sponsor must strive to express the benefit in terms of revenue less costs, or cash flow, for each time period the product is in service. Estimating the Total Cost of Ownership (TCO) The explicit methods for computing and analyzing the TCO exceed the scope of this course, but the following highlights are presented in order to provide a general understanding. The TCO consists of a number of costs, specifically the development, operating, and maintenance costs of the item over its lifetime. Disposal cost may also need to be considered. According to some data, the initial cost of developing the item may comprise only 3% to 5% of the Total Cost of Ownership. Accounting for Tax Assuming that this product is generating revenue, such revenue is subject to taxation. This must be taken into consideration by diminishing the total benefit.

142

Discount Rate for Risk and Time The risk that the product, service, or result will not actually deliver the intended result should be factored into the denominator as a reduction in the overall benefit. In addition, benefits received in the future are not as valuable as benefits received now. To reflect these effects, a "discount rate" is applied to reduce all future benefits. The rate is applied once for each year into the future the benefit accrues, so it applies three times for a benefit received three years in the future. The discount rate "R" is determined by financial analysts. For example, a relatively low risk project might use a rate of 10% to 20%. For high-risk ventures, the opportunity might be discounted at 50% or higher. Furthermore, the number of time periods, "T", should be considered. Over how many years is this product expected to be used? The benefit is computed for each year over the total number of years in the forecasting model. In the first year or so, it is likely that a negative cash flow will be realized, since development costs overwhelm the initial benefits. To arrive at the total value of the business proposition, the annual benefit must be computed for each year of the product's life cycle. The sum of all the years gives a total view of the profitability of the venture. Cost Estimating and the Project Life Cycle The previous section explored the importance of the differences between the product and project life cycles. Understanding the total cost of the product life cycle is important in the decision to initiate the project and in making design decisions. The project manager's main focus, however, is on developing estimates of project life cycle cost, meaning all costs related to producing the product, service, or result of the project. Estimates evolve and are refined as the project proceeds through its phases. Accuracy of Estimates It is the project manager's responsibility to communicate to the project sponsor the degree of accuracy in the estimates. A single point number cannot provide sufficient understanding of the uncertainties at the beginning stages of the project. The accuracy of estimates varies significantly based on the information available at the time the estimating process is performed and the method used to generate the estimate. Preparing cost estimates is an iterative process, performed throughout the project life cycle. As more information is discovered, the cost estimate should be revised to reflect the most current and accurate cost data available. Each time a cost estimate is revised, the project manager should review and evaluate the cost estimate to ensure that the proper technique was applied, based on the information available.

143

The information presented below suggests the characteristics of estimates as the project unfolds and the appropriate accuracy at that point. The subsequent sections further map these characteristics of estimates to the project phases.

Rough Order of Magnitude (ROM) When done Very early in the project life cycle, during initial planning Why done Provides estimate of cost for selection decisions How accurate -25% to +75%* Very little information is available to the cost estimator * The percentages of accuracy indicated for these types of estimates vary within industries and application areas. The general theme is that the range of accuracy is quite broad for ROM estimates, even up to -50% to +100% in the initiation phase as noted in the PMBOK® 4 Edition, and the accuracy range is tightened as one moves through the project to develop budgetary and definitive estimates.

Budgetary When done Early, during the project definition phase as scope is defined and agreed upon Why done Puts dollars in the budget plans and establishes a baseline commitment to the project sponsor How accurate -10% to +25% More project information is available, but changes may still occur

Definitive When done Later in the project, during project development/execution Why done Provides details for purchases, estimates actual costs How accurate -5% to +10% Estimates are done to predict revised project completion dates/costs

144

Cost Estimates over the Project Life Cycle Planning Estimates Planning estimates are normally created for a proposed project before the conceptual design is completed. Planning estimates are used to set cost estimates for early project work involving scope determination and feasibility study efforts and for a preliminary budget estimate of the total project costs. Planning estimates are based on drawing analogies from past cost experience with similar projects, where available. Rough Order of Magnitude estimates are planning estimates used in the absence of previous cost experience. Planning estimates are typically only approximations. It is imperative that the estimator fully describe and document the basis of the estimate, including how the estimate was prepared and any items specifically excluded from the estimate. Budgetary or Conceptual Design Estimates The fundamental purposes of a budgetary or conceptual design estimate are: •

Ensuring that the project offers sufficient benefit for the estimated cost;

•

Developing a reliable project cost estimate consistent with the proposed schedule;

•

At a minimum, establishing baseline project costs at the phase summary level; and

•

Serving as the basis for project funding

In a software engineering project, the conceptual design estimate tells the customer approximately what it will cost to complete the project within the scope defined in the project scope statement. The conceptual estimate will be based on any available conceptual design information, such as sketches and specifications. Preliminary Design or System Design Estimates The preliminary design and system design estimates are intermediate estimates created for these purposes: •

Verifying that the newly available design details still support the conclusion that the revised cost budget remains less than the total project funding; and

•

Breaking down the cost budget to the work package level for the upcoming phase, to facilitate more complete and accurate cost monitoring and control.

Preliminary design estimates are based on the specifications that have just been developed.

145

Upon approval of system design and during subsequent execution phases, system design estimates become definitive estimates. They are updated during project monitoring and control to predict revised project completion dates and costs. Life Cycle Costing Rough order of magnitude, budgetary, and definitive estimates are calculated during the project life cycle as the project proceeds through its phases. Life cycle cost estimates evaluate costs estimated to be incurred over the product life cycle that includes the life of a project and its product. Types of costs estimated during the product life cycle include: •

Direct costs - Incurred directly by the project;

•

Indirect costs - Incurred as part of the organization's cost of doing business and shared among all current projects;

•

Recurring costs - Repetitive elements of development and investment costs that may vary with the quantity being produced during a product life cycle. Recurring costs include items such as engineering required for redesign; maintenance, modification, rework, and replacement; training personnel to operate and maintain a product; and

•

Non-recurring costs - Elements of development and investment costs that generally occur only once during the product life cycle. Non-recurring costs include items such as design, development, and testing activities through the first release of a product.

Key issues for management when developing and refining product life cycle cost estimates include: •

Ensuring that the project budget encompasses all development and production costs;

•

Adjusting the project's present value to reflect the future costs;

•

Anticipating operations and maintenance costs that are frequently not considered in the decision-making process;

•

Understanding that the lowest bid is no longer an acceptable criterion if the lowest bid is defined as the development and production cost, not the total life cost of the product; and

•

Ensuring that life cycle cost estimates reflect the time value of money (net present value).

Life cycle costing lets you see the big-picture view of the cost of a product throughout its life cycle. Life cycle costing considers the total cost of ownership, including both the operational and maintenance costs and the development costs of the product.

146

Project managers should perform a product life cycle cost estimate at the outset of every project when evaluating the needs of the project. A life cycle cost estimate should be required for all programs and projects at each point where a major decision/scope change will affect life cycle cost. Benefits of Life Cycle Costing The benefits of life cycle costing include: •

Evaluating the competing options in purchasing;

•

Improving the awareness of total costs;

•

Providing accurate forecasting of cost profiles;

•

Forecasting future resource needs; and

•

Supporting strategic planning and budgeting.

Fundamentally, life cycle costing is important because it helps to ensure that the least expensive alternative that will meet a project's functional requirements is selected. Initial design and development costs may constitute only a fraction of a project's overall life cycle costs. Setting Expectations about Estimating Estimating is challenging, especially in the early stages of planning a project. As noted, cost estimating, like all of the planning processes, is iterative. Initial estimates for some tasks may have to suffice until later in the project, when more specific information becomes available. This new information allows a more detailed estimate to be generated. The evolution of the estimate as the project unfolds mirrors the refinement of the work breakdown structure; initially, WBS components are listed at a relatively high level, and they are further decomposed as the scope is defined. It is important for project managers to manage senior management and stakeholder expectations regarding estimates. Far from commitments, early in the project estimates may be little more than approximations, but these approximations will become more precise as the team learns more about the details of future work from completing more elements of the definition of the project's product or service. Rolling Wave Planning The evolution of estimates is one of the ways in which progressive elaboration takes place on a project. In particular, the first time each phase is estimated, it may be at a very high level due to the lack of detailed information, and because no further detail is needed for the decision-making at that point. However, as the project phase approaches, it becomes necessary to create detailed schedule and budget baselines in order to measure the performance effectively.

147

This results in the current phase having detailed estimates and all future phases having coarse estimates, until the current phase nears completion. At that time, the next phase is planned in detail. This cycle repeats each time the current phase nears closure. Because the level of detail spreads into each phase separately, this is known as rolling wave planning. What is an Estimate? An estimate is not the same as a random guess or a bid, but is the derivation of an approximate value based on one or more rational methods. An estimate uses available data for comparable activities, components or events, and extrapolates or interpolates to the current situation being estimated. In contrast, a guess is a value arrived merely by intuition. A bid may contain one or more estimates, but it is not an estimate and may vary because of factors independent of time, cost, and quality. Most activity duration and resource requirement values will be estimates. The very definition of a project implies a unique initiative, one that has never been done before. In a limited number of instances, duration or resource requirement values may be a given. For example, a test procedure may be defined as always running for a set number of hours. Another example is that concrete takes a known amount of time to cure before construction can begin on it, based on the environmental temperature and the mixture used. In these examples, the values are givens, not estimates. Estimates are approximations. Who is Responsible for Cost Estimates? In some organizations, the project manager is not responsible for developing the cost estimates. A qualified cost-estimating department may develop these instead. In other circumstances, the costs of certain types of resources, for example, in-house staff labor, are not factored into the project costs. Within the general practice of project management it remains the responsibility of the project manager to understand and be able to justify the estimated project costs, whether or not he actually developed them. Prior to the completion of an activity, it is not possible to know what the exact cost, duration, or resource effort will be. The project manager will not be able to account accurately for some factors, such as large changes in requirements that were not factored into a project's original assumptions.

148

Estimate Accuracy Estimates will have varying precision over the life of the project. The precision necessary for an estimate depends on its context. For example, the earliest estimate for a project's cost at the concept evaluation stage may be a rough order of magnitude estimate, which is good enough to determine whether the project should be pursued or not. Additional accuracy would not affect the decision, so making the effort to obtain it is not costeffective. On the other hand, as an upcoming phase of a project is being planned, the phase's activities are defined at sufficient levels of detail to ensure that estimates of duration will have the necessary accuracy, and that the resulting project baselines will be effective in measuring performance. Without this level of detail, the project management team would not have the ability to detect and correct problems in a timely manner. As estimates are refined further and at increasing levels of detail, the effect of diminishing returns comes into play. The project management team must determine when the estimate's accuracy is not improving sufficiently to justify further analysis. Common Estimating Errors Influence of scope on estimating errors Perhaps the most significant factor contributing to errors in estimates is the failure to encompass the entire technical scope. This comes primarily from two sources: failure to elicit, analyze, and maintain the requirements properly, and incorrect decomposition of the work breakdown structure. The first is the reason that poor requirements are cited so often as a cause for poor project performance. The second leads to overlooked work, which often appears later as a scope change request when it was actually an error, and the scope did not change. Influence of assumptions on estimating errors The assumptions about the estimate must be documented. If significant assumptions are not tested, the estimate may involve substantial error. For example, assumptions regarding productivity, resource availability, vendor capabilities, and technical feasibility should be reflected in the resource and duration estimates and spelled out in the basis of estimate (BOE) for the activity. The BOE describes how the estimates were derived and the information on which they were based. Influence of risk on estimating errors When known risks are under- or overestimated, the amount of time or cost allocated to the estimate will be wrong to some degree. Experience can reduce this kind of error, but it cannot eliminate it completely.

149

Influence of time on estimating errors Estimates must accommodate the budgeting and funding cycles of the performing organization. When an estimate approaches or spans a boundary between two funding cycles, there is the inherent risk that during the project the activity may slip at least partially out of the cycle in which it was planned. This means the cost for the slipped portion will be incurred in the wrong cycle, and the available funds in both cycles will no longer match the revised cost forecast. Other factors affecting estimating accuracy Some other factors that contribute to the error of an estimate include: • Novelty of the activity and lack of experience estimating it; • Novelty of the technology used to carry out the activity; • Unknown skills and productivity rates of the team; • Unexpected impediments to the progress of the activity; • Mistakes and/or misunderstandings in the inputs to the activity; • Changes in the inputs to the activity, particularly in the requirements; • Uncontrolled changes in working environment that impair productivity; • Effects of geographic location of work; • Locations of team members relative to the work; • Available methods of team communication; • Quality of support services; • Availability of appropriate tools; and • Availability of subject matter experts. Cost Drivers Cost drivers are project cost elements that heavily impact the overall project costs. They will either inflate or moderate the base cost estimate that resulted from the measure of the project's scope. Small changes in cost drivers result in large changes in the overall project costs. Parametric cost estimating, a technique of the Cost Estimating process discussed further in the course, relies on an understanding of these cost drivers. They result in additional estimating measures that must be used to adjust the cost estimates upward or downward to account for these factors. Project managers should be concerned about cost drivers because they represent specific elements of the project that could potentially become budget busters. Cost drivers are the areas worth spending extra time on when developing the estimate in order to get more accurate data on quantity required and unit costs.

150

When reviewing a cost estimate, recognizing and focusing on cost drivers is more productive than trying to accurately forecast cost for all project elements. Some examples of cost drivers: •

Volume and cost of concrete when building a hydroelectric dam; and

•

Effects of development tools and work environment factors on the productivity rates of programmers in software development

•

The Cost Estimating process requires the project management team to consider the following enterprise environmental factors:

•

Marketplace conditions - This involves the products, services, and results that are available in the marketplace, their sources, and the terms and conditions of their use. These conditions will affect the choice of resources, and their prices will then serve to establish their cost estimates. In addition, if fluctuations in these conditions are expected, prices may change during the project. These price changes will also affect the cost estimates.

•

Commercial databases - Resource cost rates are often available from commercial databases that track skills and human resource costs and standard costs for material and equipment. With adjustments for local variation, these may serve as the base prices for the cost estimates.

•

The organizational process assets include policies, procedures, and guidelines about cost estimating. Other process assets include:

•

Cost estimating policies - If the organization has established mandatory approaches for cost estimating in various circumstances, the project management team must comply with them;

•

Cost estimating templates - Often the finance function or previous project teams have developed templates that are based on previous projects. These templates can be reused and tailored for use on new projects to suit their characteristics;

•

Historical information - Often the performing organization maintains a repository of information about work that has been performed in the past that was similar, or that used the same resources planned for the current project. In this case, there may be available historical information that the project management team can leverage in developing the cost estimates;

•

Project files -Records from prior projects that have performed similar work can help with developing cost estimates;

151

•

Team knowledge - Frequently the team members will have been selected because of their previous experience with similar work. This usually provides a base of knowledge about similar efforts that can be used to guide cost estimates; and

•

Lessons learned - If previous cost estimates are available from a previous project that was similar in scope and size, there will often be lessons learned about how to (and how not to) generate and tailor the estimates to be even more accurate than those used on the previous project.

The project scope statement describes the business need, justification, requirements, and boundaries for the project. It also documents constraints, specific factors that can limit cost estimating options. On many projects, a common constraint is a limited project budget. Other constraints can stem from required delivery dates and available resources. Often the project approach, assumptions, and acceptance criteria that are described in the project scope statement will require that the project team tailor their estimates. For example, if the project is required to use inexperienced in-house resources in order to bolster the development of a performing organization - competitive advantage, this will cause the estimates to be different than if expert resources had been procured. The work breakdown structure defines the relationship among the components of the project and the project deliverables. In this manner, the work breakdown structure also defines how the cost estimates will be rolled up for summary reporting and control purposes. The WBS dictionary is the companion document to the WBS. It contains all the details for each component. Each component includes a code or account identifier, statement of work, responsible organization, and a list of milestones. Other information can include a list of associated schedule activities, resources required, and an estimate of cost of the component. The project management plan is a document that specifies how the project is executed, monitored and controlled, and closed. The project management plan can be a summary level or detailed document, and can contain one or more subsidiary plans or other components. Other planning outputs that may be used are: •

Schedule management plan - The type and quantity of resources and the amount of time those resources are applied to complete the work of the project are major parts of determining the project cost. The Activity Resource Estimating and Activity Duration Estimating processes that contribute to the schedule management plan are closely coordinated with Cost Estimating. The schedule management plan also defines how the schedule will be managed, and will influence how cost

152

•

•

•

estimates will treat the boundaries of fiscal cycles when the activities cannot be funded within the funding cycle in which they were originally expected to occur; Staffing management plan - This describes the resources with which the project team will be staffed and when they will be made available. These factors drive both the size of project cost estimate (through the resource rates) and the timing of planned outlays in the cost budget (through information about availability); and Risk register - This describes the risk response plans for identified project risks. Each risk response plan has associated activities and may entail contingency reserves. The costs of the activities and reserves are affected by the results of ongoing risk assessment, which may change over the course of the project. Developing Cost Estimates

There are various methods used to develop cost estimates, including: •

Analogous estimating;

•

Parametric modeling; and

•

Bottom-up estimating.

Other tools and techniques used during the Cost Estimating process include: •

Project management software;

•

Vendor bid analysis;

•

Reserve analysis;

•

Cost of quality; and

•

Determine resource cost rates.

The project manager should be aware of the estimating methods that were used to develop the cost estimates because the method chosen dictates the overall accuracy of the estimate, known as the confidence level, and should meet these criteria: •

Consistency with the stage the project has reached and the quality and detail of the available information; and

•

Degree of accuracy needed at that stage of the project's life cycle.

It is sometimes possible (and appropriate) to employ a combination of Cost Estimating techniques to produce a more reliable estimate. If two methods can be shown to produce estimates that agree, the project management team can have more confidence that the underlying data was consistent, and of high quality, and that no errors were made in the estimating process.

153

Analogous Estimating An estimating technique that uses the values of parameters, such as scope, cost, budget, and duration or measures of scale such as size, weight and complexity from a previous, similar activity as the basis for estimating the same parameter or measure for a future activity. Analogous estimating requires historical data from completed projects. It predicts estimates based on the experience from the previous projects. The accuracy of the estimate depends on the degree to which the current project's characteristics match the historical data. Analogous estimating takes the previous project's actual results and adjusts them by a multiplier based on a number of possible factors: •

Comparative complexity and design;

•

Differences in the way portions of the work will be performed;

•

Additions to or omissions from the work of the previous projects; and

•

Geographical and economic data.

This estimating technique is suitable for early stage estimates, such as planning or feasibility studies, initial project duration and cost estimates, and product life cycle costing. Analogous estimates are used in these circumstances: •

The project's process is generally known but substantially undefined or subject to change.

•

There is very little engineering design information;

•

Historical information or organizational process assets contain incomplete information, for example, when published cost rates omit information about health and safety requirements;

•

There is very little technical data; and

•

Special factors must be taken into account, such as specialized requirements related to health, safety, or security.

The accuracy of analogous estimating is +100% to -50%. Recall that for analogous estimates, a few similar projects are used as a base, and the estimated costs are then produced by increasing (or decreasing) the historical project's costs by multipliers that depend on factors such as the differences between the projects in comparative complexity, resource types, and optional elements of scope.

154

For example, if a 100,000-square-foot building was built at a cost of $110 per square foot, and a similar 200,000-square-foot building had been built at a cost of $105 per square foot, an analogous estimate may determine that a similar 150,000-square-foot building could be built for approximately $107.50 per square foot. Parametric Estimating An estimating technique that uses a statistical relationship between historical data and other variables (e.g., square footage in construction, lines of code in software development) to calculate an estimate for activity parameters, such as scope, cost, budget, and duration. This technique can produce higher levels of accuracy depending upon the sophistication and the underlying data built into the model. This method relies on the fact that the quantity of work to be performed is directly proportional to some underlying measure of the deliverable. This is often the case for construction projects involving conventional buildings, where the total cost and even the costs of specific materials and labor can be gauged as a price per square foot of the final building. This method can be used in industries that use standard estimating units for work such as: •

Feet of pavement for a highway;

•

Number of storyboards per person for computer-based instruction;

•

Lines of code or function points for a software developer; and

•

Square feet of roofing per roofer.

Parametric modeling requires historical data based on similar projects and reasonable measurements of the quantities or elements of work to be performed. Parametric modeling is suitable for conceptual or system design phase estimates, when some of the final scope and the project approach have been defined. Its accuracy is between +75% and -25%. Examples of parametric cost estimating measures include: •

Cost per square foot of building floor space[ and

•

Cost per function point of software code written in the Java language.

Differences between Analogous and Parametric Estimating The major difference between analogous estimates and parametric estimates is that the parametric estimate uses estimating rules to approximate the likely final estimate of either the entire project or several major components of a larger project.

155

The parametric estimating method is substantially more accurate when using a database of many completed projects, while the analogous estimate can use data from only a few completed projects. Bottom-Up Estimating A method of estimating a component of work. The work is decomposed into more detail. An estimate is prepared of what is needed to meet the requirements of each of the lower, more detailed pieces of work, and these estimates are then aggregated into a total quantity for the component of work. The accuracy of bottom-up estimating is driven by the size and complexity of the work identified at the lower levels. Generally smaller work scopes increases the accuracy of the estimates. Bottom-up estimates use a detailed project design to list all the materials and labor required to complete the project. Costs for individual work packages or individual schedule activities are estimated at the lowest level of detail available, and then summed up to higher levels for reporting and tracking purposes. For example, activities associated with installing material and equipment are estimated using detailed cost estimating relationships for each lowest-level activity (e.g., the cost per linear foot to install twenty-four-inchdiameter steel pipes), which are then summed up through higher levels. The schedule activities that are estimated should be complete, measurable, and quantifiable lowest-level activities. Benefits and Disadvantages of Bottom-Up Estimating The benefits of using the bottom-up estimating method are: •

It provides the most accurate estimates of all of the available techniques; and

•

It establishes an accurate estimate for each activity or element of work, providing the most detailed level of monitoring and control.

The disadvantages are: •

It is the most time-consuming method of estimating; and

•

It requires the most kinds of information, and the most detailed data, of all of the estimating methods. Specifically, it requires:

•

A completed WBS for the portion of the project being estimated;

•

A list of the associated project activities;

•

Historic actual data; and

•

Productivity rates and pricing information.

156

The accuracy of bottom-up estimating is +/- 20%. This method is appropriate for estimating construction, testing, and deployment work once the detailed design has been completed. When you use bottom-up estimating, the cost can be expressed as: •

Labor costs;

•

Material costs;

•

Equipment and software costs; and

•

Subcontracting costs.

Supporting Tools and Techniques of Cost Estimating Analogous, parametric, and bottom-up estimating are cost estimating techniques used to develop cost estimates. Additional tools and techniques of the Cost Estimating process include: •

Project management software;

•

Vendor bid analysis;

•

Reserve analysis;

•

Cost of quality; and

•

Determine resource cost rates.

Determining Resource Cost Rates Regardless of the estimating technique used, the person determining the rates or the group preparing the estimates must know the unit cost rates, such as staff cost per hour or bulk material cost per cubic yard, in order to estimate schedule activity costs for each resource. Fully Loaded Rates A fully loaded rate considers not only the cost of a staff member's hourly rate but also includes the costs of benefits and vacation time, facilities costs, and other costs associated with employing an individual. These factors that contribute to resource cost rates are classified as direct costs, indirect costs, and fixed overhead costs.

157

Direct Costs Organizations often calculate a rate for the project team labor that begins with the hourly equivalent pay. Whether the team member is a contractor or an employee only the method for determining this pay rate is affected; unlike a contractor, who is paid an hourly rate, a salaried employee's hourly rate is calculated as his salary divided by the expected annual hours he must work. This is the labor's direct cost per hour. Indirect Costs In addition, however, there are other costs that each hour of labor entails, including various worker benefits, and telecommunications costs. These costs are considered indirect costs and are added to each labor hour's rate in proportion to the direct cost of that labor rate. For example, if the direct rate for a particular staff person is $100 / hour and the indirect costs amount to 40% on top of salary, the indirect cost that must be added to the direct labor rate per hour for this staff person will be $40. This additional cost is known as the indirect cost burden. Fixed Overhead Costs Finally, many organizations that charge clients for their staff services also factor in a portion of the organization's total fixed overhead costs. These costs include the facility cost, utilities, and the cost of administrative staff support. These costs are called fixed because the amount of work the organization performs does not affect the organization's annual cost for these items. Traditional cost accounting calculates an hourly rate per person for total fixed overhead costs by dividing total overhead costs by the organization's total planned hours of work (headcount x hours per person). The hourly rate for fixed costs can then be added to each project team member's hourly rate, or it can be multiplied by the number of hours of work planned for the project, and charged to the project as a lump sum. For example, an organization calculates that its fixed overhead costs for the year are $500,000 and the total number of hours worked by everyone in the organization that year will be 100,000 (2000 hours per person multiplied by a headcount of 50). The hourly charge per person for overhead is thus $5.00 per hour ($500,000 / 100,000), regardless of the person's salary. The hourly cost for each member of the project team will be increased by $5.00. Since this cost is based solely on headcount, and not on the staff person's underlying direct labor rate, it might be, for example, as much as $25 per hour even for a team member making $18.00 an hour. This is the fixed overhead burden.

158

Blended Resource Cost Rates Many industries use a blended cost rate for all the resources that will be consumed for each unit of scope. When the parametric cost estimating measure is expressed in terms of cost per unit of scope (e.g., dollars per square foot of hotel space for construction cost), all the resource cost rates are already factored in through this blended rate. The advantage of this approach is that it eliminates the need to understand the impact of the scope measure on all the types of resources. In hotel construction, these resources would include labor, equipment, and materials. If no blended rate were available, each resource's costs would need to be calculated separately and all their costs added together. If the parametric cost estimating measure is expressed in terms of work effort, (e.g., labor hours per square foot), the estimator must know the unit cost rates, including staff cost per hour and the bulk material cost for each resource in order to estimate the schedule activity costs. Fully Burdened Labor Rate The fully burdened labor rate is the sum of all these kinds of costs: the direct rate, indirect cost burden, and the fixed overhead burden. In our example, the total hourly cost for the staff person is $165 per hour ($100/hour direct rate, indirect cost burden of $40, and fixed overhead burden of $25). The outputs of Cost Estimating are: •

Activity cost estimates;

•

Activity cost estimate supporting detail;

•

Requested changes; and

•

Cost management plan (updates).

Activity Cost Estimates An activity cost estimate is a quantitative assessment of the likely costs of the resource required to complete schedule activities. Costs are estimated for all resources applied, including labor, materials, facilities, equipment, services, information technology, and special categories such as inflation allowance or cost contingency reserve. Activity cost estimates should: •

Be traceable to the WBS work package items;

•

Show all unit costs, pricing factors, and quantities of resources required for each calculation;

•

Include and distinguish between direct costs and indirect costs;

159

•

Include methods for applying indirect costs to the project;

•

Document all assumptions used during estimate development; and

•

Be prepared in a clear, consistent, comprehensive format.

Activity Cost Estimate Supporting Detail The information that describes the methods and information that were used to arrive at an estimate is often referred to as the basis-of-estimate (BOE). It includes all the supporting elements for a cost estimate that provide a justification for the resulting estimate, including: •

A description of the logic behind the estimate;

•

The method used to calculate the estimate;

•

Assumptions and uncertainties associated with the estimate. Examples of assumptions to be documented include specific exclusions, such as: 1. Equipment and management facilities are not part of project cost; 2. Research and development will not be required; 3. Work will not be performed during holidays; and 4. Only a total of five rain delays are assumed.

•

Constraints associated with the estimate. Examples of constraints on project activity that should be documented include specific exclusions, such as: 1. Security clearances and access restrictions will be necessary; 2. Daily storage and inventory of tools and materials will be required; and 3. Operations will be continuing while the project is underway, and must not be disturbed.

•

Any special conditions that are incorporated into the estimate;

•

Identified risks that affect the estimate; and

•

The range within the estimate falls, also known as a confidence level for the estimate.

The documentation for the estimate must include enough detail so that the estimate can be reproduced, and it must include a way to identify which work package it originates from. This is known as traceability. Traceability ensures that current project planning documents were used as the basis for the cost estimates. Traceability is typically provided through codes or cost element structures. These include the WBS, organizational breakdown structure, resource breakdown structures, and code of accounts.

160

The basis-of-estimate, or cost basis: •

Helps reconcile funding with the project budget;

•

Allows comparison to estimates for other similar projects;

•

Allows for consistent application and revision of the estimate throughout the project life cycle; and

•

Ensures that any changes from an earlier phase of the project can be traced. As the estimate evolves during the project life cycle, the basis should include the reconciliation between the previous version and the current version to account for any changes.

Managing Changes to Activity Cost Estimates The two remaining outputs of the Cost Estimating process include requested changes and updates to the cost management plan. Requested Changes When changes to the project cost estimates are needed, they are first recorded and evaluated as requested changes. They are then passed to the Integrated Change Control process within the Project Integration Management Knowledge Area, where they may be approved, amended, or rejected. This process ensures that any other Project Management deliverables that are affected will also reflect the necessary changes, in accordance with the Triple Constraint principle.

161

Cost Management Plan Updates The cost management plan describes how cost estimates will be managed. The cost management plan may be simple or complex. It is a subsidiary of the project management plan. Changes to the cost management plan can modify policies, procedures, and cost or budgets, and they should be documented and authorized. The project team implements the approved changes. The approach to the Cost Estimating process may vary depending on specific project requirements, the type of project life cycle chosen, and specific industry and company requirements. The diagram below shows the steps of one approach to process cost estimates.

162

The diagram below is a representation of the whole estimating process.

163

General Estimating Techniques The ten-step estimating process presented is one approach used to develop detailed cost estimates. Other general cost estimating techniques include expert judgment, alternatives analysis, and published estimating data. Expert Judgment Subject matter experts (SMEs) can be used to select appropriate estimating techniques, evaluate the appropriateness and quality of estimating inputs, and to select, locate, and prepare other information that may be useful in comparing or tailoring the estimate. The expert may be involved in creating the estimate or in reviewing it and recommending adjustments. Experts should have specialized knowledge both in the application area being estimated, whether cost or duration, and in estimating techniques. They may be available within the organization, or their services may be procured as consultants to the organization or the project. Alternative Analysis Alternatives analysis is a technique used to explore different options to carry out the work. It is usually necessary to look at a number of factors to determine an estimate. When evaluating the cost or duration of the activity, the project management team may have more than one option for which kind of resource to use, and where to obtain it. They will need to consider how long they will have to wait to secure the resource, factors that affect the cost and speed of the resource (such as tools and expertise), and whether there are other project objectives or organizational factors that drive the choice. Published Estimated Data Published estimating data can be used to determine estimates. For example, the construction industry uses published rates to estimate the amounts and costs of required materials and equipment based on certain factors. This data is often specified for different regions. Another example is the productivity rate of software developers in various software languages or using different software development productivity tools.

164

REFERENCES S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010 “MASTERING PROJECT MANAGEMENT BASICS” Boston University, 2005 M.Crouhy, R. Mark, D. Galai, "RISK MANAGEMENT", McGRAW-HILL, 2001 M. Effron, M.Goldsmith, "HUMAN RESOURCES IN THE 21st CENTURY", John Wiley & Sons 2003 J.Fitz-enz, "THE ROI OF HUMAN CAPITAL: MEASURING THE ECONOMIC VALUE OF EMPLOYEE PERFORMANCE", AMACOM 2000 NDIA, "EARNED VALUE MANAGEMENT SYSTEMS INTENT GUIDE", NDIA, 2005 J.T. Brown, "THE HANDBOOK OF PROGRAM MANAGEMENT", McGraw-Hill Companies 2008 T.J. Esque, " NO SURPRISES PROJECT MANAGEMENT", ACT Publishing 1999 PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008 PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008 R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005

165

Chapter VIII Cost Management – Cost Budgeting Introduction Cost Budgeting involves aggregating the estimated costs of individual schedule activities or work packages to establish a total cost baseline for measuring project performance. Although the project manager may be able to calculate a total budget based on assigned resources early in the project, it is important for the project manager to determine when money will be spent during the project life cycle. The timing of these planned costs will require other parts of the organization to coordinate so that the costs can be properly funded and paid for on a timely basis. Cost Budgeting occurs after Cost Estimating. Many projects start with a total budget before the specifics of a project are defined, but in many cases, these preset budgets may be reconsidered after cost estimation occurs. Cost budgets are also frequently adjusted in response to other Project Management processes, illustrating the iterative nature of the project management process. On some projects of smaller scope, cost estimating and cost budgeting are so tightly linked that they are viewed as a single process that can be performed by a single person over a relatively short period of time. There are distinct processes being applied, however, as the inputs, tools and techniques, and outputs for each are different. Early scope definition is critical to both processes, as the ability to influence project cost is greatest at the early stages of the project. Cost Budgeting involves summing the estimated costs of the work activities at the work package level or higher, depending on the needs of the project and the policies of the performing organization. If bottom-up estimation was used to estimate activity costs, a time-phased budget at the activity level can be produced by allocating the activities' costs to the time periods in which the project schedule says the activities will take place. Rolling activity costs up to the work package level is then straightforward. Baseline Spend Curve The baseline S-curve shows the total planned cumulative expenditure, period by period throughout the duration of the project. At the planned end date of the project, the cumulative cost reaches the full budget amount, known as budget at completion (BAC). In the simplified example below, a project consisting of 6 tasks is shown. Tasks are labeled A through F, and each is associated with a cost. The network diagram at the bottom illustrates the dependencies among the tasks.

166

•

At the end of time period 1, task A has completed, so the cost expended after period 1 is $10.

•

At the end of time period 2, tasks B and C have also completed, so the cost expended after period 2 is ($10 + $25 + $20) = $55.

•

At the end of period 3, tasks D and E have also completed, so the cost expended after period 3 is ($55 + $15 + $45) = $115.

•

At the end of period 4, task F has completed, so the cost expended after period 4, the end of the project, is ($115 + $25) = $140. This is the budget at completion, as it represents the planned cumulative costs to be expended on the project.

As project performance information is periodically collected, the comparison of actual costs to the planned budget baseline will provide vital information concerning the health of the project. Summarizing both values using this cumulative cost graph technique provides a quick visual indicator of any problems in managing project costs. This will be discussed further in the context of the Cost Control process.

167

Cost Budgeting Process Inputs Project Scope Statement The project scope statement describes any funding constraints, such as required fiscal year boundaries and other funding cycles that limit the acquisition and expenditure of funds. Work Breakdown Structure The WBS provides the relationship between project components and project deliverables. This provides the structure for the aggregation of costs used for budgeting, monitoring, and control. WBS Dictionary The WBS dictionary, the companion document to the WBS, contains the details for each component, includes a code or account identifier, statement of work, responsible organization, and a list of milestones. Other information can include a list of associated schedule activities, resources required, and an estimate of cost.

Activity Cost Estimates The activity cost estimates represent the cost data that will form the basis of the amounts in the cost budget. Activity Cost Estimates Supporting Detail The supporting detail for the activity cost estimate describes how the estimates were formed and provides the basis for determining the accuracy of the estimates. The degree of uncertainty in the estimates will be used to gauge how much additional funding may be necessary to cover estimating errors. Project Schedule The project schedule includes the planned start and finish dates for the activities, work packages, planning packages, and control accounts. These dates are used to allocate estimated costs to the calendar periods in which they are planned to occur. Resource Calendars The resource calendar shows holidays and the availability of specific resources. It defines calendar periods within an activity's duration during which costs can or cannot occur, due to the availability of key resources. This prevents funding requests and cost expenditures from being scheduled on holidays or during the absence of the authorizing stakeholder or project manager. Contract A contract can be a complex document or a simple purchase order. Regardless of the format, a contract is a binding legal agreement. The contract supplies information about what products, services, or results have been purchased, along with their costs.

168

Cost Management Plan The cost management plan, a component of the project management plan, defines how cost budgeting will be carried out.

Cost Budgeting Process Tools Cost Aggregation To make monitoring and controlling costs easier, schedule activity cost estimates are aggregated by the work packages that comprise the WBS. The work package cost estimates can then be aggregated at higher levels of the WBS, if needed, to reach the summary level needed for the performing organization's financial control method.

The above example illustrates the concept of cost aggregation. The first column shows the WBS number for the work package that the activity will produce. Here, the WBS numbering system uses an outline scheme to indicate which components fit into others. The names of the schedule activities and their summary elements appear in the second column. The use of the bottom-up estimating technique has resulted in a cost estimate for each Level 4 (lowest-level) work package. In the example, only the work packages 1.2.5.1 through 1.2.5.3 are shown at this level. The sum of these three Level 4 is work packages is $6,960. This total amount is considered the aggregated cost for these work packages and is shown as the estimate for the Level 3 control account 1.2.5, "Technical Feasibility Analysis." The values of each Level 3 control account are also aggregated. In this case, only the control accounts 1.2.1 through 1.2.5 are shown. They aggregate to $15,200, which is shown as the Level 2 cost estimate for control account 1.2, "Preliminary Investigation Stage."

169

Finally, while not explicitly illustrated on the diagram, the aggregated amounts for each Level 2 control account are summed or aggregated to produce the total project estimate, shown as the Level 1 Cost of $623,816 for the Product Development Project. The process that the project management team and sponsor use for monitoring and controlling the costs will generally specify a level of detail at which costs should be budgeted and tracked, and variances reported. This makes it easier to locate where significant variances are occurring without reviewing potentially large amounts of insignificant detail, and provides the most control for the minimum effort.

The level of aggregation may also vary from one part of the project's work to another, if some activities run more significant risks of cost overruns than others. In the example above, the Technical Feasibility Analysis (WBS 1.2.5) costs are being budgeted at the detail level of the work package, but the Initial Product Screening Stage (WBS 1.1) was budgeted only at the highest ("stage") level. The risk of a significant overrun in the Initial Product Screening Stage was deemed too low to break down the costs further.

170

Cost Budgeting Process Techniques Parametric Estimating When specific schedule activities have not been defined and estimated, parametric estimating can be applied to the planning components to provide a high-level budget for the affected work. This will generally be necessary when the project is in the conceptual stage of development and the details of the work are not known. It is also true in rolling wave planning for later phases. In this case, the later phases are not planned in detail, pending the availability of missing information. For the next phase, the necessary detail will be produced only as an outcome of the current work. In these situations, using parametric estimating at the phase or other planning component level can set the budget. For parametric estimating to be most effective, the following should be considered: •

The model that is used should be based on accurate historical information;

•

The model should work for different sizes of projects (in other words, the model should be scalable); and

•

The parameters used in the model should be quantifiable.

Reserve analysis sets aside reserves to be used for unplanned changes. The changes might be due to anticipated risks and thus involve the cost of the contingency plan, or they might be due to an anticipated rate of errors and rework ("known unknowns", or contingency reserves). On the other hand, they might be the result of unexpected events that require workarounds, and for which no contingency plan exists ("unknown unknowns", or management reserves). Management reserves are not part of the project cost baseline, but they are included in the budget for the project. Cost budget reserves are discussed in more detail in a subsequent section. Funding Limit Reconciliation The timing of funds and planned costs for projects must solve two problems: solvency and fiscal timing. For a project to be solvent, funds must always be available to meet planned costs. This means that, for any given period, the level of available funds will always be slightly higher than the amount required by the total time-phased budget baseline. The principle is the same as the funding requirement for a personal bank checking account.

171

Funds must also match the timing of the planned costs within the organization's fiscal cycles. This is the case even if the planned costs shift due to schedule changes. Funds are authorized for disbursement to the project in cycles that are set by the customer or organization to follow their fiscal cycles. The funds can then be spent only for work performed in the same fiscal cycle. Example: Funds for work in a company's fiscal year 2007 will be disbursed shortly before the start of the fiscal year. They can then be used only to pay for invoices that relate to work that was completed in the same fiscal year. Unused funds expire at the end of the fiscal year, and, conversely, if there are overruns, they must be accommodated through additional funds disbursed in the same fiscal year. Because work may accelerate or slip across fiscal cycle boundaries, every time the schedule changes, the funds made available must be reconciled with the actual budgeted costs. When the disbursed funds cannot cover the additional costs, or when there will be excess funds in one cycle and a shortage in the next, the usual technique is to shift other portions of the work between the fiscal periods. This maneuver reduces the overrun or consumes the excess. This is done by imposing date constraints on some work packages, schedule milestones, or WBS components in the project schedule. Reconciling the funding limit is normally performed by the finance function within the organization. It is unusual to simply request changes in the fund disbursement schedule, because the planned expenditures on a given project must be balanced with the total available cash flow in the organization, taking into account the priorities of other projects and business operations. If funding were constantly being shifted, managing the cash flow would become extremely difficult. The Cost Budgeting process produces the following outputs: •

Cost baseline;

•

Project funding requirements;

•

Updates to the cost management plan; and

•

Requested changes.

Cost Baseline The primary goal of the Cost Budgeting process is to determine the cost baseline. Once the cost budget is approved, it becomes the cost baseline. The cost baseline will be used to measure and monitor cost performance on the project. As noted earlier, the cost baseline is developed by summing estimated costs by period and is usually displayed in the form of an S-curve.

172

Some projects may have multiple cost or resource baselines to measure different aspects of project performance. For example, internal labor costs may be tracked separately from external costs of contractors or from total labor hours. Project Funding Requirements Funding requirements are derived from the cost baseline and must exceed the cost baseline in every period by an amount that will cover expenditures associated with both early progress and cost overruns. Funding occurs in incremental amounts. Each increment must be sufficient to cover all expenditures in every period between the posting of the first increment and the posting of the next increment. The diagram below shows the comparison of the funding levels to the cost baseline results. The funding requirements are always higher than the project cost baseline's S-curve, as the total funds include the cost baseline plus the management contingency reserve. Some portion of the management contingency reserve can be included incrementally in each funding increment or funded when needed, depending on organizational policies.

173

Cost Management Plan Updates The cost management plan is updated with approved change requests that resulted from the Cost Budgeting process if those approved changes impact the management of costs. Requested Changes When budgets are allocated to fit within constraints, some control accounts may not have funding that is sufficient to accomplish the required scope. A change request is then necessary to request additional funding, reduce the scope, or perhaps adjust other planning documentation such as the risk response plan. Requested changes are processed for review and distribution through the Integrated Change Control process. Cost Budget Reserves As noted previously, reserves analysis is a Cost Budgeting technique used to identify the areas in need of reserves. Typically, budget allocations provide challenges to individual control accounts. In order to mitigate the risk of insufficient funds, it is appropriate to establish a cost reserve. Types of Reserves Contingency Reserve A contingency reserve is an amount set aside to account for known risks or uncertainties identified in the estimates. For example, during the estimating process, an estimate for the likely amount may have been established, but a more pessimistic or conservative amount was considered plausible. The budgeting strategy in this case could be to set the budget at the lower amount and to reserve the difference in a special contingency amount. The project manager's strategy will be to actively monitor the planning component that the reserve covers so that the costs are controlled within the lower amount. The reserve is available as a safety net, but can be released if it is not required. These contingency reserves are estimated costs to be used at the discretion of the project manager to deal with estimating errors and with risk events that have been identified in the risk register (the catalogue of identified project risks). These risk events are called "known unknowns," because although their size cannot be predicted with certainty and they may not occur at all, their causes are familiar, and their impacts tend to follow similar patterns on similar projects. Their risk response plans and associated contingency reserves are part of the project scope, schedule, and cost baselines. Management Reserve In some cases large, unexpected risks that impact the project budget may materialize. These risks are referred to as "unknown unknowns," because their size, cause, and likelihood are all impossible to predict. An example might be a labor strike in the middle of a long construction project.

174

In the case of these unknown unknowns, the project manager may need to draw on additional funding that was not part of the budget. For this reason, the sponsor's management may agree to set aside an additional reserve called the management reserve that may be drawn upon to deal with unplanned events, but only with their specific approval. Since such events by definition cannot be foreseen, the project management team may perform a reserve analysis based on the experiences of prior, similar projects. This management reserve is excluded from the cost budget, but is part of the total funding request. Appropriate Use of Reserves Reserves should not be used to accommodate scope changes. Any addition to project scope must be formally initiated with a change request, and corresponding adjustments to budget and schedule baselines must be negotiated. Mature project management cultures understand the benefits of identifying uncertainties and establishing a reserve mechanism to actively manage risks and uncertainties. Less mature organizations may treat reserves with skepticism and may automatically disallow any budget category identified as a contingency. Often these same organizations wonder why they are constantly struggling with projects that cannot be completed within their budgets. The uncertainty of cost estimates and the occurrence of risk events are unavoidable. Because they are not certain, they should not be factored into the base estimates for the project work. To shield the project from the turbulence that would result when these estimating errors and risk events surface, the project management team should put in place the appropriate reserves, and carefully control their use to meet only the intended purposes. Reserve Analysis and Estimating Methods To develop and establish the appropriate cost reserves, the project management team must use the reserve analysis technique, defined earlier. The method that should be used to establish cost reserves for a planning component or work package depends on the type of estimating method that was originally used to establish the budget. Recall the estimating methods previously discussed: •

Analogous (also known as Top-down);

•

Parametric; and

•

Bottom-up.

In addition, range estimating, also known as three-point estimating, may be used. Threepoint estimates for activity durations are based on three types of estimates:

175

•

Most likely: The duration of the schedule activity, given the resources likely to be assigned, realistic expectations of availability for the schedule activity, dependencies on other participants, and interruptions;

•

Optimistic: The activity duration is based on a best-case scenario of what is described in the most likely estimate; and

•

Pessimistic: The activity duration is based on a worst-case scenario of what is described in the most likely estimate.

An activity duration estimate can be constructed by using an average of the three estimated durations. That average will often provide a more accurate activity duration estimate than the single-point, most likely estimate. In the diagram below, a weighted average has been used to determine the estimate, as more weight has been given to the most likely estimate.

176

The following table describes how one might establish the cost reserve based on the estimating method applied.

Estimating Method

Establishing the Reserve

Analogous/TopDown Estimating

Evaluate the degree to which the historical project(s) used as the basis for the analogous estimate differ in terms of complexity, resource types, and optional elements of scope. Establish a general contingency percentage based on the accuracy level predicted of the estimate, e.g., 30%, and apply that percentage contingency to each control account.

Parametric Estimating

Evaluate the sensitivity of the parametric measures and devise a contingency. For example, for material, if measurements were accurate within 10%, use a 10% contingency. Also, consider adding a contingency for scrap or wasted material, or expected product defect rates.

Bottom-Up Estimating

Collect the contingencies estimated for specific activities or work packages into a common contingency account.

Range, or ThreePoint, Estimating

Establish a contingency based on the difference between the "Most Likely" estimate and three-point estimate, as illustrated on the following page.

177

The diagrams below illustrate the calculation of contingency for three-point estimates. It is important to establish a reserve proportionate to the amount of uncertainly represented by the range of the estimate. In the diagram below, using statistical analysis one can determine that the confidence of achieving M is about 30%, which is not high.

By adding a reserve represented by the difference between the three-point estimate and the most-likely estimate (E M), the confidence of success is closer to 60%.

Confidence intervals are a statistical concept that is beyond the scope of this course. However, given an estimate that was generated using the three-point estimating technique, a project manager should be able to determine an appropriate contingency amount proportionate to the amount of uncertainty represented by the range of the estimate.

178

For example, if the supporting detail of a work package estimate noted that the Three-Point Estimating technique was used with the optimistic estimate being $2,500, the most likely estimate being $3,000, and the pessimistic estimate being $5,000, then the project manager would calculate an estimate E = (O + 4M + P) / 6, or [$2,500 + (4 x $3,000) + $5,000] / 6 = $3,250. The project manager could then establish a reserve amount based upon the formula of E - M, or $250 ($3,250 - $3,000). Similarly if the supporting detail of a work package estimate noted that the Three-Point Estimating technique was used with the optimistic estimate being $100, the most likely estimate being $1,000, and the pessimistic estimate being $10,000, then the project manager would calculate an estimate E = [$100 + (4 x $1,000) + $10,000] / 6 = $2,350. The project manager could establish a reserve amount based upon the formula of E - M, or $1,350 ($2,350 - $1,000). Note that in the two examples above, the amount of the reserve changes to reflect the amount of uncertainty represented by the range of the estimate. In the second example, there is a greater variance between the optimistic, most likely, and pessimistic estimates, so the reserve amount is greater to reflect this uncertainty.

REFERENCES PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 “MASTERING PROJECT MANAGEMENT BASICS” Boston University, 2005 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010

179

Chapter IX Cost Management - Cost Control The primary purpose of the Cost Control process is to influence the factors that create cost variances and to control changes to the project budget. One of the most common problems in project management is overrunning the project budget. There are a number of plausible explanations for this. People may be more focused on the technology and making sure that the project requirements are met, literally at the expense of the budget. In other situations, the need to define and observe a budget constraint is not recognized; therefore cost performance is running "open loop," until the sponsor or customer calls attention to the problem. Project Cost Control includes: •

Influencing the factors that create changes to the cost baseline;

•

Ensuring that requested changes are agreed upon;

•

Managing the actual changes when they occur;

•

Assuring that potential cost overruns do not exceed the authorized funding for a particular phase and the total funding for the project;

•

Monitoring cost performance to detect and understand variances from the cost baseline

•

Recording all appropriate changes accurately against the cost baseline;

•

Preventing incorrect, inappropriate, or unapproved changes from being included in the reported cost or resource usage;

•

Informing appropriate stakeholders of approved changes; and

•

Acting to bring expected cost overruns within acceptable limits.

180

What information you need to implement cost control? Cost Baseline The cost baseline, also described as the time-phased budget or S-curve, was created in the Cost Budgeting process. Once established, the baseline serves as a constant reference for measuring and monitoring cost performance on the project. Project Funding Requirements Funding requirements are derived from the cost baseline. Fund flow should be positive; it should exceed the cost baseline in every period by an amount that will cover expenditures associated with both early progress and cost overruns. Funding occurs in incremental amounts. Each increment must be sufficient to cover all expenditures in every period between the posting of the first increment and the posting of the next increment. Funding sources include payments from the customer, revenue from sales, loans from a bank, or appropriations from the organization's financial authority. Performance Reports Performance reports organize and summarize information gathered; present the results of any analysis performed; and provide information and the level of detail required by stakeholders. Common performance report formats include: •

Bar charts;

•

S-curves;

•

Histograms; and

•

Tables.

Performance reports generally should be short documents (one to two pages for a monthly report) that relate the relevant facts of the project performance. Although formats can vary significantly to address different stakeholder needs, many common elements are included in most performance reports; for example: •

Reporting period;

•

Work accomplished in reporting period;

•

Schedule and cost status and performance;

•

Problems experienced or approaching;

•

Corrective actions, or plans;

181

•

Summary of accomplishments planned for the next reporting period; and

•

Detailed quantitative reports, included as attachments (such as earned value analysis data).

Work Performance Information Work performance information provides data on the status of project activities, for example, if project deliverables are not being completed on a timely basis and at or below the planned cost. Information includes, but is not limited to: •

Costs authorized and incurred;

•

Estimates to complete the schedule activities;

•

Activities completed or incomplete, or percent complete of the schedule activities; and

•

Deliverables that have been completed and those not yet completed.

Approved Change Requests Approved change requests from the Integrated Change Control process are documented, authorized changes that can modify terms of the contract, project scope, cost baseline, or cost management plan. Changes are usually implemented by the project team once they have been approved. Project Management Plan The project management plan is a document that specifies how the project is executed, monitored and controlled, and closed. The project management plan can be a summary level or detailed document and can contain one or more subsidiary plans or other components. The cost management plan component and other subsidiary plans are considered when performing the Cost Control process.

182

Cost Control Process Cost Change Control System A change control system is a formal documented process that describes when and how project documents may change. It describes the people who are authorized to make the changes and the paperwork needed to make the changes. Assuming that a variance from the plan has been identified and a course of action has been determined, the change control system is employed to coordinate an integrated change to the project baseline. Normally the change control system is a single, integrated mechanism for controlling changes. The cost element of that change control system should be just one additional aspect of the overall system. Details on controlling cost changes should be described in the project's cost management plan. Performance Measurement Analysis Performance measurement analysis is a mechanism for quantifying the current level of accomplishment of the project management plan. Any deviations from the plan (i.e., over or under budget) are to be reported as variances. Variances exceeding a prescribed threshold must be clearly identified and managed to reduce the impact to an acceptable level. The Earned Value Technique (EVT) is an example of a performance measurement technique, discussed further in its own section. Forecasting In assessing current project performance as well as the impact of known variances, forecasting is a technique for extrapolating current performance data to an estimate of future performance. In other words, will the project continue to operate at, under, or over budget and by how wide a variance? Forecasting is one of the functions performed by the EVMS. Trend analysis is a forecasting technique that involves examining project results over time to determine if performance is improving or deteriorating. Key functions of trend analysis include: •

Evaluating a project's results over a period of time;

•

Identifying a pattern of performance; and

•

Showing improvement, stabilization, or decline.

183

Proper trend analysis requires: •

A controlled baseline;

•

Correct and timely data; and

•

Comparison of recent and long-term performance.

Trend analysis looks at performance to date and identifies a pattern of results that indicates a trend. The trend is used to forecast future results. Successful trend analysis depends on: •

Controlled Cost Baseline: The project manager must assess the actual spending and schedule performance against the planned spending during the same schedule period. Without a time-phased cost plan, the project manager cannot compare the burn rate to any comparable baseline;

•

Data and timing: If cost and schedule data are based on vague estimates, the trend analysis will be equally vague. If performance reports are scheduled quarterly, they may not be frequent enough to measure trends unless the project is very long-term (several years); and

•

Identified trend: The trend is the important element in trend analysis; it may indicate a pattern toward satisfactory or unsatisfactory performance. The focus is on the long term. Often, project managers focus too much on the current data and immediate needs.

Project Performance Reviews Project performance reviews are typically formal meetings held to assess the current status of the project in terms of scope, schedule, and budget. The completion of work should be reported with an assessment of the health of both the schedule and budget. Performance reviews are usually used in conjunction with other performance reporting techniques. For example, the need for corrective and preventive action may be identified in the performance review through the review of the quantitative results from the EVMS. Discrete issues should be identified as part of an issue management process and new risks should also be identified.

184

Project Management Software Project management software tools of various types are helpful in creating estimates, assembling budgets, and controlling cost performance. They range from spreadsheets and project scheduling tools to project management tool suites. Project managers enter cost or labor rate data in the project management software, or into a spreadsheet, to manipulate variables in order to see the results of different options. Other, more advanced statistical analysis tools are also used in some cases. Variance Management The cost management plan as discussed previously should contain specific thresholds and descriptions of appropriate corrective actions to be used in response to budget variances. For example, a relatively minor variance, such as less than 5%, should be reported and noted. The project manager should be aware of the reasons for the variance and should form a strategy for how best to deal with it. As variances grow to a larger percentage of budget (perhaps 10%), formal reporting using the variance management system should be required. This will call for an analysis and a written corrective action plan. If the control account variance continues to expand and does not respond to corrective action, it should be escalated to higher levels of attention in the organization. A formal system such as this minimizes surprises to the customer or to senior management. Also, it ensures that more senior management has the opportunity to assess the problem as early as possible.

Conducting a Performance Measurement Analysis The first step in performance measurement analysis is to ensure the completion of a project management plan and the establishment of a cost baseline. This baseline becomes known as the planned value (PV) of the project (and is the same as the previously mentioned Scurve). It is represented as a spending curve for each period of the project. Periodically during execution of the project, usually monthly, but perhaps more frequently, the following steps are performed. 1. Collect performance reports from each control account manager. These should state which planned tasks for the reporting period have been completed. 2. Compute the value of these planned tasks. The total value of completed tasks is known as earned value (EV). These amounts are summed and compared to the planned value (PV).

185

3. Compute a schedule variance (SV) by subtracting PV from EV. 4. Collect actual cost performance from the finance team. They will calculate the actual cost by summing all paid invoices and labor sheets during the reporting period. This sum is called actual cost (AC). 5. Compute the cost variance (CV) by subtracting AC from EV. The implementation of performance measurement analysis can generate some confusion, but given a well-defined process and a commitment to the goal of simplicity, it is possible to achieve a practical and quantitative method for measuring project performance.

Earned Value Management System (EVMS) An EVMS is the most commonly used performance measurement technique for managing projects. An EVMS compares the schedule and cost information at a point in time and avoids using the project manager's subjective interpretation of data. Earned Value Analysis The EVMS is based on the technique referred to as earned value analysis, which integrates scope, cost (or resource), and schedule measurements to assess project performance. Earned value provides a determination of whether or not work is being completed as planned. Earned value analysis is not new. The government has used it for decades in the formal Cost/Schedule Control System (C/SCS). In its current form, the government method describes thirty-five criteria to guide effective performance measurement, and requires formal certification. Earned value analysis is now broadly accepted as an efficient, quantitative method for assessing project status. Current project management software tools include features that incorporate earned value management techniques into project planning. Benefits of Using an EVMS Using an EVMS allows the project manager to integrate both schedule and cost information to gain a more comprehensive understanding of project performance. This gives the project manager a more complete view of project performance; schedule-only or cost-only comparisons do not provide the same data. This missing data could lead to misinterpretations of project performance. An EVMS compares the scope, schedule, and cost information at a point in time. In a sense, it provides a snapshot of the Triple Constraint triangle, showing the current status of the project. This minimizes the errors and misrepresentations possible with a schedule-only or cost-only comparison. Integrating schedule and cost status lets project managers forecast project status from trend information. An EVMS requires the project management team to correctly establish baselines and to learn earned value management terms.

186

For an EVMS to be effective, it is important for the project manager to ensure that the project baseline is valid, otherwise the data resulting from the calculations cannot be compared to a standard. An EVMS also allows the project manager to forecast future project performance by identifying trends and calculating results if the trend continues. Earned Value Management System (EVMS) Terms An EVMS uses a concept of "dollarizing" the schedule and performance data. A solid understanding of earned value concepts and terms is a prerequisite for the effective use of the associated methods. Three fundamental EVMS terms include: •

Planned Value (PV): Agreed value of work to be accomplished in a given period;

•

Earned Value (EV): Agreed value of work that was actually accomplished; and

•

Actual Cost (AC): Real cost of the work performed.

Collecting and Analyzing Planned Value (PV) Planned Value (PV), previously called budgeted cost of work scheduled (BCWS) in the government system, is the value of work that was scheduled to be completed as of a certain date. The PV is really a curve, or time-phased cost budget. At the end of the project, the final PV equals the budget at completion (BAC). PV is established by time-phasing the project's budgeted costs. When the project plan is approved, the PV becomes a fixed standard of reference. When it comes time each status reporting period to update the earned value analysis, the PV value is obtained by consulting the project baseline information for the associated time period.

187

Collecting and Analyzing Actual Cost (AC) Actual Cost (AC) is another parameter that must be measured during each status reporting period. This is typically information collected by the organization's cost accounting group, using the company cost accounting system. The cost accounting group collects all costs against the project work packages and control accounts, including labor accounting sheets, materials invoices, and other direct costs such as travel and contract labor. AC identifies what it really cost the project to operate during the reporting period, independently of what work was actually accomplished. The AC is reported as both the new costs for the current period and the cumulative cost for the project since inception. The reporting of cost is independent of the project team and represents the expenditure of real money, unlike the earned value discussed further in the course. The only control the project manager has over AC is to ensure that work is performed efficiently, as planned, using the appropriate resources. Inaccurate accounting of labor is a common cause for cost variances. AC is also referred to in older earned value management systems as the actual cost of work performed (ACWP).

188

Collecting and Analyzing Earned Value (EV) EV, the central concept in this technique, is slightly difficult to grasp at first. In very basic terms, every activity or item of work is associated with a dollar value. When you complete a particular activity, you "earn," or receive credit for, that declared value. A frequent point of confusion is that the actual cost of the job may be different from the earned value. Earned value is the agreed value of the task, not what you actually spend on it. If a contractor submits an invoice for an unforeseen additional amount, the actual cost of the job will be the amount of the invoice, but the earned value remains the original negotiated amount. The difference between the earned value and actual cost will be an indication of cost variance.

189

Methods for Computing Earned Value EV, the method for assigning value earned, is calculated based on one of several predetermined methods. In the simplest concept, the value earned is exactly the planned value of the task. However, determining when or how the value is applied may use different methods. Keep in mind that the calculation of earned value for a task is different than an individual reporting status against the task. Status reporting and earned value analysis serve different purposes. Earned value analysis allows the project manager to measure and report the overall project health, evaluating project schedule, cost, and work performed. It provides measures to detect variances, and therefore determine the overall ability to meet project objectives. The information presented below outlines the various methods for computing earned value along with descriptions of how earned value is assigned and their recommended uses. In practice, a project manager may elect to use only a few of these earned value techniques. They are discussed in more detail on the pages that follow. 0-100 % How earned value is assigned for this method No credit for the start of a task, but 100% upon completion Recommended use of this method When tasks are scheduled to complete within one accounting period 50-50 % How earned value is assigned for this method 50% value when the task starts, and 50% upon completion Recommended use of this method When tasks are scheduled to complete within two accounting periods Percent Complete How earned value is assigned for this method Value estimated by the person responsible for the task's completion Recommended use of this method Not generally recommended, although it may be used for longer work packages in which distinct milestones are not recognized

190

Weighted Milestones (WM) How earned value is assigned for this method Value given upon milestone completion, where interim milestones mark the completion of a longer task or work package Recommended use of this method For longer work packages for which discrete methods do not seem appropriate Level of Effort (LOE) How earned value is assigned for this method Value earned is proportionate to the total budget of the work package and based on elapsed duration Recommended use of this method Minimize the use of LOE to less than 10% of the total project budget Apportioned Effort (AE) How earned value is assigned for this method Value is planned and measured in relation to another (non-LOE) task Recommended use of this method Not recommended for frequent use but may help in instances where it is difficult to determine the exact value of the work

Percentage Methods for Computing Earned Value 0-100% The 0/100% method is the simplest and usually the best method for tasks of relatively short duration compared to the standard reporting period length. For example, if the project status data is collected once per month, this method should be used on tasks of less than 30 days duration. As an example of computing earned value using the 0/100% method, assume that there is a work package to paint a room in your company's headquarters. You approved the painter's estimate totaling $1,000 in labor and materials to perform the job, with a completion date of Friday. When the job is complete, you will credit the EV column with $1,000, the agreed value of the job. This tracks the completion of the SCOPE leg of the triangle. If the painter submits an invoice for an unforeseen additional $50 in materials, the actual cost of the job will be $1,050, but the earned value remains the original negotiated amount of $1000.

191

Suppose that on Friday the job has not yet been completed, so when the status report is filed, the value earned remains at $0. The difference between the earned value and planned value is an indication of schedule variance. This variance will continue until the work is completed. So, if the job is delayed until Wednesday of the next week, the schedule variance will be negative $1,000 until the completion is recorded, at which time the schedule variance returns to $0. Alternatively, if the painter finished the job early, a positive schedule variance would be posted. The 0/100% method is the-all-or-nothing approach, in which no credit or value is earned until the task in question is completed. In the above example, the painter earned no value until the room was completely painted (and presumably cleaned up and inspected). This method eliminates the common project management problem of subjective reporting such as "we're almost done" or "97% complete", etc. Instead, the task owner must ensure complete execution, which generally also assures higher quality results. 50-50% The 50/50% method is a minor adjustment to the 0/100% for tasks of longer duration compared to the reporting period. If project data is collected monthly, but a task is planned to take six weeks, the task owner would be showing a negative variance for the first status report, even though the work may be on track. In fairness, the 50/50% method allows the task owner 50% credit for the work, as long as the work has been started. This reduces the negative variance to a smaller amount, and assuming the job finishes on time, the variance will disappear by the end of the next reporting period. Other variations on 50/50% may be defined, such as 25/75%, 40/60%, depending on the rules in the organization. These should be established as standards in the project's cost management plan. Percent Complete The Percent Complete method is one of the recognized methods, but should not be used as a general practice. The discrete 0/100%, 50/50% or milestone methods are much more effective in controlling the reporting of task completion. The percent complete method is subject to abuse, as task owners may have no objective definition of what "60% complete" actually means. Often this is reported incorrectly as the percent of the time that has elapsed rather than the percent of the work that has been completed. While not generally recommended, this method can be useful for longer work packages in which distinct milestones are not recognized. If percent complete is allowed as a method, the work package template should provide an objective basis for awarding percent complete.

192

For example, if the work package involves testing to ensure 30 test cases pass successfully, one could earn 10% each time 3 more test cases pass. The cost management plan or the specific work package planning template must provide explicit definitions of each milestone.

Milestone and Effort Methods for Computing Earned Value Weighted Milestone The Weighted Milestone method is used for longer work packages for which discrete methods do not seem appropriate. Assuming that the process in the work package has clearly understood interim milestones, appropriate credit should be assigned to the accomplishment of each milestone. Level of Effort (LOE) The Level of Effort (LOE) method should be used very sparingly, usually only for the supervisory tasks on the project. The labor costs of the supervisors, such as the project manager and any clerical support staff, must be accounted for in the PV and EV baselines. The problem, however, is identifying exactly what work has been done, or what deliverables have been produced. After all, supervisors have highly unpredictable days, integrating all the other team members' activities, attending meetings, filing reports, and communicating with the stakeholders. Therefore, one assumes that the supervisors are always on schedule and allows them to earn value proportionate to the total budget of the supervisor's work package. For example, if there are 30 days of supervisory labor planned, the supervisors "earn" 1 day each day of the project. A general rule of thumb is to minimize the use of LOE to less than 10% of the total project budget. Otherwise, large sums of LOE value will mask or disguise smaller variances in other work packages.

193

Apportioned Effort Method The Apportioned Effort Method falls into a category similar to LOE, in that it should not be used often but may help in instances where it is difficult to determine the exact value of the work. For example, if a quality inspector is needed to monitor the activities of the test group, the quality work package would earn value at a predetermined rate proportional to the test work package. As the testing progresses, the quality work earns a corresponding percentage of work complete.

Analyzing Cost and Schedule Variances Earned Value Variances and Indices Once the status has been determined for the project, i.e., the PV, EV, and AC values have been determined for the current period for each work package, what does the data mean and how is it presented in a useful way? Several earned value calculations allow the project manager to evaluate both schedule performance and cost performance. A variance is a difference between actual project results and planned or expected results. A positive variance means that a project is ahead of schedule or under budget, while a negative variance indicates that a project is behind schedule or over budget. An index is a measure used to assess the magnitude of any project variances that do occur. For indices, a value greater than 1.00 is better than planned efficiency, while a value less than 1.00 indicates that efficiency is less than planned. EVMS Schedule Formulas •

Schedule variance (SV) = EV - PV

•

Schedule performance index (SPI) = EV/PV

•

Preferred state: SV is positive, and SPI is greater than 1.00 o

This means that the earned value is greater than the planned value. More work has been earned than planned, so the project is on or ahead of schedule.

194

EVMS Cost Formulas •

Cost variance (CV) = EV - AC

•

Cost performance index (CPI) = EV/AC

•

Preferred state: CV is positive, and CPI is greater than 1.00 o

This means that the earned value is more than the actual cost. More value has been earned than the actual cost expended, so the project is on or under budget.

Example of EV Components The example below illustrates these values at a time of status measurement.

EV Component Example In this example, the project is to build five prefab sections of a house for a total project budget of $500 (BAC). Recall that at the end of the project, the final PV equals the budget at completion (BAC). The task now is to compute the PV at this point in time. It was expected that $300 worth of tasks were to be completed (PV). In reality, only $200 worth has been completed (EV); but the accounting system collected expenses of $400 (AC) on the project. EVMS Example The following EVMS example uses the earned value formulas to calculate the variances and indices. •

PV = 300

•

EV = 200

•

AC = 400

•

SV = EV-PV = 200 - 300 = (100)

•

SPI = EV/PV = 200/300 = 0.67

•

CV = EV-AC = 200 - 400 = (200)

•

CPI = EV/AC = 200/400 = 0.50

195

The calculations in this example indicate that the project is behind schedule and over budget, with poor schedule and cost efficiency ratios. •

The SPI of 0.67 indicates that the project has accomplished only 67% of the work it was scheduled to accomplish by the status date.

•

The CPI of 0.50 indicates that for every $1.00 spent on the project, only $.50 worth of work has been completed.

EVMS Diagram The results of the EVM analysis are usually graphed to provide a powerful status report for the project. Such a diagram can be tracked at the total project level, and also for each control account. Project management software tools can help present this information. The EVMS data in the diagram below depicts the values over time for the three key parameters, PV, EV, and AC. The status reporting period during which these parameters were calculated is shown via the Update Now vertical line. At that point in time, the schedule and cost variances are depicted on the graph as the difference between EV and PV (schedule variance) and between EV and AC (cost variance). Another powerful feature of the diagram is its ability to show the trends in performance from one reporting period to the next. An experienced eye can read these charts quickly and draw conclusions about the project's performance, past, current, and future.

The EVMS diagram also illustrates how EV calculations provide more insight into the overall project health than straight comparisons between the original baselines and actual costs. If the actual costs are less than the original cost baseline, it may appear that the project is under-spending. However, by comparing EV to AC, a project manager realizes that, in reality, the project is paying too much for the work actually performed.

196

By comparing EV to PV, it is apparent that less work was accomplished than planned at the point of determining the project's status; therefore, the project is behind schedule. The key to understanding EV is that the cost or schedule is always compared to the value of the work performed-EV or the earned value. Forecasting Costs When the project manager knows the current project cost, he can also predict where the project is going using EV. This requires calculating at-completion and to-completion costs. There are several terms to define in learning and applying these calculations. Estimating the At-Completion Project Cost (Terms) Budget at Completion (BAC) •

Total cumulative PV at completion of a schedule activity, work package, control account, or other project component o

When applied to the entire project, BAC represents the total budget of the project, not including management reserve

o

At project completion, BAC will equal PV

Estimate at Completion (EAC) - also called Latest Revised Estimate (LRE) •

Estimate, or forecast, of the most likely total value based on project performance and risk quantification o

EAC can be greater than or less than BAC

Estimating the To-Completion Project Cost (Terms) Estimate to Complete (ETC) •

Estimate for completing the remaining work for a schedule activity, work package, control account, or other project component o

ETC is the difference between EAC and actual costs to date

Various techniques to calculate EAC and ETC are discussed on the following pages.

197

Estimating the At-Completion Costs Examples of Estimating At-Completion Costs At-completion values of interest to the project manager and stakeholders are calculated using the methods below. These calculations use the same data as the EVMS example of the prefab construction project: •

Total budget, or budget at completion (BAC) = 500

•

Planned value (PV) for this stage of project = 300

•

Earned value (EV) of project completed at review = 200

•

Actual cost (AC) = 400

•

Schedule variance (SV) = EV-PV = 200 - 300 = (100)

•

Schedule performance index (SPI) = EV/PV = 200/300 = 0.67

•

Cost variance (CV) = EV-AC = 200 - 400 = (200)

•

Cost performance index (CPI) = EV/AC = 200/400 = 0.50

There are many forecasting techniques to calculate EAC. Each of these approaches can be the correct approach for any given project and will provide the project management team with a signal if the EAC forecasts are not within acceptable tolerances. Calculating EAC using earned value data •

Using remaining budget: The cumulative actual costs to date plus the budget required to complete the remaining work, which is the budget at completion minus the earned value o

•

EAC = AC + (BAC - EV) = 400 + (500 - 200) = 700

Using CPI: The cumulative actual costs to date plus the budget required to complete the remaining work, which is the BAC minus the EV, modified by a performance factor (often the CPI). o

EAC = AC + [(BAC - EV)/(CPI)] = 400 + [(500 - 200) / .50] = 1,000

Calculating EAC using ETC (ETC is discussed further on the following page) •

A bottom-up Estimate to Complete (ETC) for the remaining work is provided by the performing organization. Often used when past performance shows that the

198

original estimating assumptions were fundamentally flawed or are no longer relevant due to a change in conditions. o

EAC = AC + ETC

ETC based on new estimate The ETC is a manual revised estimate for the remaining work in the control account, as determined by the performing organization. This more accurate and comprehensive completion estimate is an independent, non-calculated estimate to complete all of the work remaining, and considers the performance or production of the resource(s) to date. The ETC for the project is calculated by summing the manually revised individual control account estimates. The decision to manually create a new ETC should be balanced with the time it will take to perform it. If not calculated manually, the ETC can be calculated based on earned value data. Importance of Early Analysis Hundreds of studies across many industries have revealed that a pattern of variance from the baseline is usually set early, and the variances only get worse as the project continues. If a project manager's ability to predict the first 20% of the project is poor, his ability to predict the remainder of the project is usually worse. Early analysis results provide forecasting input. Based on history, after 15% to 20% of a project has been completed, the CPI will not change by more than 10%, and will probably get worse. For example, a CPI of .80 at the 20% point will probably not recover to reach a CPI of over .88. It is the project manager's responsibility to keep the project on schedule and within the project budget, keeping the at-completion costs as close to the original estimate as possible. It is also the project manager's job to get the project back on track when a variance has been discovered. Historical data indicate that early project analysis has the most potential for impacting the project, if corrective actions are necessary. The ‘To Complete Performance Index’ (TCPI) The TCPI is a calculation that indicates the cost performance (CPI) needed for the remainder of the project to complete either on budget (BAC) or at an estimated at completion (EAC) value. The denominator of the TCPI formula is adjusted depending upon which parameter is used, BAC or EAC: •

CPI needed to complete on budget: (BAC - EV)/(BAC - AC)

•

CPI needed to complete at the EAC value: (BAC - EV)/(EAC - AC)

199

Other Performance Measurements Many types of performance measures are available, such as: •

Status of quality measurements;

•

Status of risk management plan;

•

Status of technical performance measurements; and

•

Status against other planned baselines o

Lines of code

o

Labor hours.

Many different items can be tracked and used as performance measurements. Run charts, statistical process control charts, and other measurements from the quality plan are all performance measurements. Tracking identified risks and mitigating the risks are areas that affect performance as well as cost and schedule. Technical Performance Measurements (TPMs) are used by some industries to track how well the product is achieving critical performance parameters. Depending on the product, the metric being tracked could be weight, power consumption, fuel consumption, power output, throughput, production price, utilization percentage, capacity, or operational use data Variance Analysis Variance analysis involves comparing actual progress results to planned or expected results. The differences between actual project results and planned or expected results (baseline values and current or projected results), becomes the variance. Variance analysis can be used to quickly detect deviations from desired baselines. The comparison can be within the current period or cumulative over several periods. Variance analysis allows the project manager to identify differences between the work results and the project plan. Identifying these variances from the desired baselines is only the first step in status reporting. Simply knowing the variances will be of little value in ensuring a project's success. Once a variance is identified, the project manager should determine what caused the variances (root cause) and plan a corrective action. Action must be initiated if the variances are negative or potentially harmful to the project's intended outcome. In many cases, the corrective actions will require some changes to the project. These must be documented and managed; in many cases, the changes will need to come under configuration control.

200

Variance Analysis Reports Once a variance is detected, whether it is in cost, schedule, or scope and quality, it should be corrected. A return to baseline is the desired result of a recovery plan. A completed variance analysis report is a good starting place for the recovery plan. When completing variance analysis reports, ask these questions: •

What is the variance?

•

What caused the variance?

•

What is or could be the impact on the project?

•

What is the planned corrective action? o

Specific plan, with milestones

o

Responsible person

o

Milestone completion dates

A solid plan of recovery must be established, as recovery at a later date is nearly impossible. The project manager must ensure that a person is assigned to the task of leading the corrective action, and must make the recovery plan part of the weekly status review. Problem Resolution Strategies Problem resolution strategies can be simple to complex, depending upon the problem. Project variables of cost, schedule, and scope and quality can be negotiated with the customer. There is usually one element about which stakeholders may be flexible in accepting changes. This can be exploited to the benefit of the project. The key to altering the variables is to keep the customer involved in the problem-resolution process. Remember that customer satisfaction is usually one of the quality metrics.

201

Examples of problem resolution strategies include: •

No action required; accept non-critical variance.

•

Schedule variances

•

o

Alter schedule dependencies to get back on schedule.

o

With cooperation of customer, extend the project to cover slip in schedule.

o

Use the management reserve and assign additional resources.

Cost variances o

With cooperation of customer, alter scope and quality or schedule.

Revising the Project Baseline Once the project status has been analyzed and clear trends have been established over several reporting periods, it may become advisable to revise the baseline. Such a decision is not reached easily or very often. The point of the baseline is to illuminate areas of performance variance. Changing the baseline to correct variances would be counterproductive. If, however, attempts to correct the performance problems do not have a significant effect, and if the variances continue to worsen, the project manager should seek concurrence of the sponsor and key stakeholders to revisit the project management plan. This decision should be supported by a clear understanding of the variances and the dynamics of the project that are limiting the effectiveness of the corrective actions. Usually the decision to rework the project's baseline is accompanied by discussions about renegotiating scope, budget, and schedule expectations.

202

REFERENCES PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008 PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008 R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 “MASTERING PROJECT MANAGEMENT BASICS” Boston University, 2005 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010 M.Crouhy, R. Mark, D. Galai, "RISK MANAGEMENT", McGRAW-HILL, 2001 M. Effron, M.Goldsmith, "HUMAN RESOURCES IN THE 21st CENTURY", John Wiley & Sons 2003 J.Fitz-enz, "THE ROI OF HUMAN CAPITAL: MEASURING THE ECONOMIC VALUE OF EMPLOYEE PERFORMANCE", AMACOM 2000 NDIA, "EARNED VALUE MANAGEMENT SYSTEMS INTENT GUIDE", NDIA, 2005

203

Chapter X Project Quality Management To ensure the quality of the project management process and the quality of the facility/system/product/service resulting from the project process through the application of a "Quality" approach which focuses on "Fitness for Purpose" and "Customer Satisfaction". It should be noticed that there are two distinct areas in the management of Quality First, the quality of the project management process itself. If the process is not robust and sound, i.e. the project is not "well-managed", the product produced is unlikely to be satisfactory i.e. does not meet "Conformance to Requirements. Second, the "Quality Grade" of the product” Quality Grade reflects the "class" of product produced, i.e. "Fitness for Purpose" as specified or documented in the project's Scope Description, for example, a "gold-plated" element may be superior, but if it is not required for the purpose intended, the result is not a "Quality Solution". Quality is achieved in the Definition Phase through iterations in system selection to optimize the design configuration, close stakeholder liaison and a stakeholder sign-off of a Quality Plan. Quality Grade is part of the stated performance requirements and may be expressed in terms of the "-ilities":







Availability; Operability; Usability; Maintainability; Constructability; and Reliability..

Quality in the Implementation Phase is achieved by, o Close conformance to the documentation contained in the supporting Project Charter; o Continued close contact with Stakeholders; o Careful management of Scope Changes, and o Efforts to minimize re-work at all times.

204

There are several important things to know about quality in project management, first and foremost: what is a successful project? a project that satisfies the client and other stakeholders in its most important dimension, quality. After the project is completed time, cost, and scope are of historic interest and from all four project objectives quality is the most closely related to customer satisfaction and therefore is the most enduring. In project work, quality has two dimensions: Quality grade The category or ranking of the project's deliverables i.e. the most common meaning of the word "quality" Quality conformance The ability of the deliverables to meet the standards set by the quality grade Quality conformance applies at two levels, o The quality of the work that goes into the project's deliverables process quality, and o The quality of the deliverables that result: Product quality. By varying the quality grade of a deliverable you can affect the time and cost of the project provided the change is acceptable to the customer. Once the quality grade has been established, meaning agreed with the customer that means that the "requirements" have been set presumably within certain specified limits. Thereafter, the project must deliver according to those requirements. Failure to do so is "non-conformance" requiring rework of the deliverable at added time and expense to the project. It is not difficult to see that if the quality of the workmanship is not very good the resulting deliverables are likely to be poor, but the former can only be tested by examining the latter by which time it is too late! You cannot "test in" quality. Quality must be designed into the product. Inspection and testing should only be necessary to confirm that the product conforms to requirements. Quality is not in the eye of the beholder, it is in the skills of the individual.

205

Quality Assurance and Quality Control The difference between quality assurance and quality control is that the former aims to guarantee that quality work and quality deliverables will be built in before work is done. Quality control aims to determine that quality work and quality deliverables did occur after work was done. Quality control is conducted by inspection and testing of materials, workmanship and product. Quality control is all about conformance to requirements. Quality control involves a series of processes, 1. Planning for quality control i.e., identifying where control is to be exercised and to what extent or frequency 2. Identifying the relevant reference standards e.g. the technical (technological) specifications applicable 3. Influencing performance by collecting specific information Usually highly technical, standardized data 4. Analyzing and comparing results to standards 5. Reporting results to all parties concerned As a basis for management decision On appropriate corrective action On-going retro-fixing to maintain end results Appropriate action as a result of quality control may include, o Acceptance, perhaps because the condition is marginal or of little consequence in the specific location of the project, but still, the customer doesn't get exactly what he wants; o Rejection requiring repeat production or rework to the particular product; o Process adjustment i.e. process improvement to avoid the same condition recurring; and o Re-testing, if there is doubt about the test results. Often occurs where only small samples can be tested, but representing large volumes of product or because the samples are subject to human error.

206

There are times when the failed product is no longer accessible, a condition found in large construction works. In such cases it may be necessary to add supplementary work to secure the integrity of the works as a whole. Quality Assurance Examples QA in construction can become very sophisticated depending on the size of the project, its complexity and the various technologies used. It usually requires, o Leadership; o Determination; and o Training. QA Construction Example Here is a very simple example, consider the formwork for a retaining wall. We have seen such work done on an ad-hock basis, any old pieces of wood are used in any odd arrangement. Even if standard forms are used they are placed at the whim of the handler to suit the ground conditions. Quality absent !!! If the reinforcing steel is congested and it usually is, formwork ties are placed wherever they can be easily placed, with a bit of luck the concrete is poured and the form stands up, but not always if some of the ties are missed! Quality reigns !!! With a quality attitude the steel reinforcement will be designed with proper consideration for placement and form work and ties placed at regular spacing, but most importantly, the excavation will be properly opened up so that a foundation can be laid for proper construction to follow. You can usually tell quality construction by looking at work-in-progress. You can see when quality is being built in!

207

QA Software Example No matter the complexity of the program, people just love to get on with the programming "We'll worry about the other modules later and the interfaces to make them all work can easily fix it later" What is exciting is to get something that works and watch it work even if it is not quite what was wanted and doesn't work under all required conditions. Quality absent !!! We have seen program code dashed off as a preliminary run on a scratch pad and transferred to the computer all without structure, programming notes or explanations of the purpose of the routine perhaps even without proof reading and rigorous testing at the end of each day. Quality reigns !!! Software architects and programmers are all first trained to be methodical in the use of the same standard methodology and a common programming language and to document every step of the way. The client especially is given to believe there must first be a clear understanding of what is required, and an investment in a plan for the client's approval. A plan for the whole program is devised, not just the software, but all supporting peripherals such as user guides, training manuals, and promotion materials. The various modules are isolated and passed to those best able to write them. At every stage, the client is consulted and all the necessary tools and equipment are made available to a skilled production team. Finally, the detailed work will likely proceed by iterations, and/ or progressive releases, reliable and well documented, using standard models and standard templates wherever possible so that changes and updates can easily be made by any of the programmers in the team should the original person not be available. Quality has been built in!

208

Five Steps to Free Quality

Let's start with some "Quality Myths" • • • • • • • •

Quality is subjective and intangible It is not possible to eliminate all defects Lack of motivation or caring by the workforce causes most quality problems The aim of quality management is to reduce errors to acceptable levels Quality is best ensured by those who inspect the work Improving quality adds cost and reduces productivity Quality cannot be measured in dollars Quality is proportional to the resources spent on inspections ALL FALSE !!!!

In "Quality is Free: The Art of Making Quality Certain" Philip Crosby (McGraw-Hill, 1979) said Quality is free but no one is ever going to know it unless there is some agreed system of measurement. Quality is not only free but an honest-to-goodness everything profit maker. Every penny you do not spend on doing things wrong is a half-penny right in the bottom line. If you concentrate on making quality certain you can probably increase profit by 5% to 10%. That's a lot of money for free! Is that true of projects? The same approach can be applied to the production phases of a project provided you do your homework in the planning phases. Here's a practical five-step approach..... Step 1 Flawless execution is the goal, o Get top management committed to quality in project management; o Get project management focusing on the cost of quality; o Make "Zero Defects" the watchword through top-down education and training; and o Get management, not just supportive.

209

Step 2 Understand the project's production/construction system Identify and understand the production systems, relationships and variables for, Performing traditional work; Developing new work approaches; Promoting and selling it to the workforce; Make sure existing and new approaches are considered; Make use of repetitive patterns as much as possible especially at the lowest (task) level for maximum productivity; and • Set an example by using standard PM forms! • • • • •

Step 3 Define requirements Define the requirements for the project's deliverable and each of its component deliverables. Keep a top-down "contractual accountability" in defining requirements. Identify and incorporate repetitive patterns to simplify the work effort and build quality into the work systems. Make sure deliverable requirements are agreed with the "customer" and signed off accordingly! Step 4 "Do it right the first time" by planning. Plan the work so that deliverables satisfy the customer's requirements and can be produced right the first time. Make sure the repetitive patterns are applied to reduce the time and effort in preparing schedules. Make sure these schedules recognize the sequence restraints inherent in the work I.e. reflect effective coordination throughout. Think quality in, to build it in!

210

Step 5 Prevent non-conformance. Bring problems to the surface so they can be examined without delay. Identify root causes of problems. Take action to prevent reoccurrence by adjusting,




Faulty requirements; Work plans, sequence, delivery of resources, etc; and Methods and systems

Before all, project management should attack problems. Not people.

Recommendations When the project is complete one should ask, • • •

Did it meet requirements? Was the customer satisfied? Capture the lessons learned

The bottom line is think less about productivity, • •

Concentrate on quality; and Avoid being trapped by myths

211

Project Managers Competency Model

The Project Manager Competency Model was developed from the observable behaviors of successful, professional project managers in a variety of application areas. It provides a consistent, coherent structure for assessing the capabilities of current and prospective project managers. The Competency Model can be used to:


Guide a training needs assessment to help optimize the use of scarce training dollars by identifying gaps between job requirements and incumbent skill levels;




Perform individual competency assessments to evaluate current project managers or to screen prospective project managers; and




Conduct an organization-wide competency assessment to ensure that the most skilled project managers are assigned to the most critical projects.

The Project Management Competency Model identifies nearly one hundred observable behaviors grouped into thirteen discrete competencies: 1- Leadership Leadership means motivating and inspiring people to keep the project moving toward successful completion even in the face of the physical demands of aggressive project schedules and the emotional demands of discouraging developments. Successful project managers should:










Have people volunteering for their projects; Establish and communicate their vision for the project; Speak of "our project" rather than "this project"; Exhibit a "can do" response to problems; Demonstrate a positive attitude; Stay calm under pressure; Command the respect of the entire team; Award success to the team; and Accept responsibility for failures.

212

2- Customer Relations Customer relations involve managing the interactions between the customer and the rest of the project team. When the customer is external to the performing organization, it also involves managing the interactions between the customer and the performing organization. The result of good customer relations is that both parties are enthusiastic about both the relationship. Successful project managers should:








Work to understand the customer's point of view; Advocate appropriately for the customer to others; Advocate appropriately for others to the customer; Are accessible, available, and responsive to the customer; Seek customer feedback about project performance; Create mutual interest in repeat business; and Show respect for the customer at all times.

3- Project Planning Project planning means devising and maintaining a workable scheme to accomplish the need a project was undertaken to address. Successful project managers should:








Develop written plans for all significant undertakings; Document and distribute the project plan; Update and revise the project plan as needed; Insist on clear, complete statements of both product and project scope; Know what the project will really cost, how long it will really take; Use available planning tools effectively; and Get the team actively involved in the planning effort.

4- Performance Measurement Performance measurement involves collecting and analyzing project information to determine where the project stands and to predict future status and progress. Successful project managers should:








Actively monitor project status; Insist on constructive analyses of variance; Use the plan to manage the project; Hold regular status review meetings; Encourage an attitude of "no surprises"; Measure (and report) performance against the plan; and Submit status reports on time.

213

5- Communicating Communicating is the exchange of information. The sender must make the information clear and unambiguous. The receiver must make sure the information is complete and understood. Communicating has many dimensions: written and oral; listening and speaking; internal and external; formal and informal; vertical and horizontal. Successful project managers should:








Send clear messages; Choose the form and timing of the message for their audience; Create communications that look professional; Use language carefully; Confirm the accuracy of information sent and received; Explain things well; and Listen carefully to others.

6- Organization Effectiveness Organizational effectiveness is the ability to "get things done." It requires an understanding of the formal and informal structures of all the organizations involved. Successful project managers should: • • • • •

Know where to go to for help; Win approval of requests for support; Show respect for individuals regardless of position; Maintain a network of contacts from whom to get assistance; and Know which resources are scarcest and manage them most carefully.

7- Team Building A team is a group of individuals who depend on each other for success ("no one succeeds unless we all do"). Team building means encouraging and enabling people to work together as a team to accomplish the project. Successful project managers should:








Define the team to include all the stakeholders; Share management responsibilities with the team; Talk about process as well as results; Work hard to achieve consensus on all major decisions; Insist on the best the team can do; Call attention to team achievements; Develop good team players; and

214




Build professional groups that perceive themselves as teams.

8- Staff Development Staff development is the process of encouraging personal and professional growth among the members of the project team. It includes training your replacement as well as encouraging growth in an individual's chosen functional area. Successful project managers should:








Insist on the best that each individual can do; Demonstrate knowledge of team members' personal and professional goals; Value the individual's growth and achievements; Give credit promptly and sincerely; Provide constructive criticism promptly and in private; Provide timely and useful performance reviews; and Delegate appropriately for the person and the situation.

9- Perspective Having perspective is the ability to elevate ones view; to take a broader organizational view rather than a narrower project or personal view; to discern how the project relates to a hierarchy of larger undertakings; to sense and assess potential inter-actions with outside conditions and events; to connect seemingly unrelated events or conditions to the project. Successful project should managers: Demonstrate awareness of the organization's vision and mission; Demonstrate awareness of competitors' strengths and weaknesses; Encourage the team to consider "big picture" issues; Avoid getting immersed in unnecessary detail; Actively seek to acquire new knowledge; and Read widely.









10- Negotiating Negotiating means working with others in order to reach an agreement. A successful negotiation is one where all parties are satisfied with the agreement. Successful project managers should: • • • • • •

Advocate for interests rather than positions; Seek agreements that satisfy the interests of both parties; Work to keep personalities out of the negotiations; Are open to innovative and creative solutions; Use objective criteria to evaluate proposed agreements; Negotiate agreements that can be kept; and

215

•

Negotiate agreements that preserve the working relationship.

11- Risk Management Risk management means identifying, analyzing, and responding to risks over the course of the project. It includes both minimizing the consequences of adverse events and maximizing the results of positive events. Successful project managers should: Consider both the impact and likelihood of risks; Use contingency and management reserves appropriately; Distinguish between risks (always in the future) and problems (in the present); Take prudent risks and exploit unexpected opportunities; and View past problems as current risks and plan for them.

• • • • •

12- Problem Solving Problem solving is a combination of problem identification (what is the problem), solution assessment (what can be done), and problem response (implementing a solution). Project problems may be technical, managerial, or interpersonal. Problem solving may lead to decision making when a problem has many possible solutions. Successful project managers should: • • • • • • •

Use a structured approach for all significant problems; Look for root causes, not just symptoms; Seek (and listen to) both facts and opinions; Encourage innovative and creative solutions; Involve the team in problem solving; Ask perceptive questions; and Follow up to ensure that the problem remains solved.

13- Decision Making Decision-making means making the best choice from among many alternatives. Decisions can be received (from the customer, from the team, from other managers) as well as made. Decision making has a time element to it. The "best" alternative may not be the "right" decision if it is made too early or too late. Successful project managers should: • • • • • •

Use a structured approach for all significant decisions; Seek (and listen to) both facts and opinions; Make decisions when needed; Document important decisions; Delegate or escalate decisions when appropriate; and Follow up to ensure decisions are implemented.

216

Why Project Management? The goal is successful outcomes. This requires certain types of initiative, a focused effort through planning and execution to reach a successful goal. That focused effort is project management. Examples o Planning, financing, designing, building, opening or leasing institutional, commercial, industrial or infrastructure facilities; o Writing, producing, deploying books, plays, films; o Software development, distribution, deployment; and o Research and development, new products, roll-out. The Objectives of PM Direction 1. Ensure ultimate project success as judged by: a. Ability of product(s) to deliver benefits; b. Satisfied customers; and c. Within acceptable limits of scope, quality, time, and cost. 2. Provide overall direction to the project. Ensure that all required inputs to the project process are assembled 3. Manage project risks 4. Manage people involved 5. Manage and commit the resources required 6. Manage an effective project change process 7. Orchestrate decision-making 8. Manage reporting and communications, including publicity 9. Manage transfer of care, custody, and control of product upon completion

217

Not all Efforts are suited….. The work effort must be a project by definition Special features exhibited by projects: A- Rarity of product which means that the definition of the work's deliverables are unique or the conditions of their creation are unique or both. B- Constraints on process: Time is limited, resources required are limited, and money is limited. C- Dynamic responses are required: They must be visible as an agent of change, linked to the natural project life span evolution, and flexible to changes during the project life. D- Managerial complexity involved, • • • • •

Objectives and their constraints; Competing objectives among functions; Internal and external partners with different cultures; Complex technological issues; and Multiple stakeholders.

E- Multidisciplinary effort: Contributing efforts required integration, more than one discipline requires coordination across organizational boundaries, multiple skills required coordination, logical processes have to be followed, and daily issues must be resolved in good time to avoid delays. Additionally, there is a need for clear sponsorship, a broader-base understanding of project's technology, and appropriate management and technical skills. The bottom line: Effective application of project management expertise is essential if quality is to be achieved.

218

REFERENCES J.T. Brown, "THE HANDBOOK OF PROGRAM MANAGEMENT", McGraw-Hill Companies 2008 T.J. Esque, " NO SURPRISES PROJECT MANAGEMENT", ACT Publishing 1999 PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008 PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008 R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986

219

Chapter XI Risk Management Risk Management Plan The risk management plan typically includes the following ten components: 1. Methodology 2. Roles and responsibilities 3. Budgeting 4. Timing 5. Risk categories 6. Definitions of risk probability and impact 7. Probability and impact matrix 8. Revised stakeholders' tolerances for risk 9. Reporting formats 10. Tracking information 1. Methodology Methodology describes: •

The tools, methods, and sources of information that will be used to perform risk management, including how risks will be identified, analyzed, and categorized;

•

How risk response plans will be prepared, implemented, and monitored; and

•

How risk triggers will be monitored.

2. Roles and Responsibilities The roles and responsibilities section defines who does what during all risk management activities. In particular, it specifies who will direct and manage risk management activities, this person may be the project manager or a designated risk manager for the project.

220

3. Budgeting The budget establishes the anticipated cost of the risk management activities and the associated risk response plans, including contingency reserves. 4. Timing The timing describes how often risk management activities will be performed, and when they will take place within the project schedule. 5. Risk Categories Risk management deals with eventualities that might affect the project but are not documented in the project management plan. This means thinking not only of problems that have occurred with this kind of work, organization, or project approach, but also imagining problems that have never occurred before, but may occur during the project. The basic purpose of the Risk Identification process (presented in a subsequent section of the course) is to ensure that as many of these eventualities as possible are considered. To do this, it is helpful to have a list of risk categories that the project team will address, so that the process is as comprehensive as possible. The risk categories generated during the Risk Management Planning process will be an input to the Risk Identification process. There is no single, standard list, but there are good starting points from which the team can build. Agreeing on the categories and making the list complete and practical is one of the first steps in identifying the risks themselves. Considering each risk category should help the team generate ideas on risk events specific to those categories. Most risks fall into one of several broad categories; however, any project may run unique risks. Risk categories are tools that: •

Enable the project team to more efficiently analyze and respond to risks with common characteristics; and

•

Ensure that no potential sources of risk will be overlooked during the subsequent Risk Identification process.

Risk categories can be structured to provide different levels of groups for different risk management purposes or to provide greater scope or more focus as needed during risk analysis and response planning.

221

Typical Risk Categories Typical Risk Categories

Description

Technology or technical approach chosen to achieve the project objectives Schedule, project completion objectives, other project Time time-related issues Ability of contractors or other vendors to achieve Contractor capabilities project objectives Work in a multi-project environment, or interfaces with Interfaces existing operational activities Occupational safety, industrial safety, and potential for Safety contamination Environmental laws, licenses, and permits Environmental Involvement of any regulatory agency such as EPA or Regulatory involvement DHEC, or by local, state, and national governments Significance or visibility to local, state, or national Political visibility governments Availability and cost of using key technologies and Intellectual property techniques for critical project activities Involvement by someone other than a primary owner Involvement of key stakeholders for decision-making and management Issues with design criteria, functional requirements, Product and project complexity complex design features, or the condition of existing documentation Adequate resources, specialty resources, rapid labor Labor skills availability and force build-up, exposure to environmental extremes productivity Technology

Number of locations/site access/site ownership Funding/cost sharing Magnitude and type of contamination Quality requirements Public involvement

Site ownership and access issues Project duration and involvement/funding by other parties Presence of hazardous or mixed waste Requirement for precision work or other QA requirements Citizen interest or involvement

222

The Project Management Institute (PMI) guide Approach The PMI approach breaks risks into technical, project management, organizational, and external risks. •

Technical risks are introduced by the difficulty of the work itself, new or changed technology, unrealistic performance goals, or changes to standards;

•

Project management risks arise from poor use of resources, poor quality of the project plan, or poor project management discipline;

•

Organizational risks are associated with cost, time, and scope objectives. They materialize when project objectives are incompatible; projects are not prioritized effectively within the organization; funding is not reliably provided; or there is competition for project resources from other projects; and

•

External risks come from a changing regulatory environment, labor issues, changing priorities of the organization's owner, political or cultural factors in a country foreign to the organization, resource and product price fluctuations due to changing economic circumstances, and weather. They also come from issues that arise from dealing with the public.

6. Definitions of Risk Probability and Impact The methods for scoring and interpreting the Quantitative and Qualitative Risk Analysis processes must be set in advance to avoid injecting personal biases or inappropriate influence into the attention paid to particular risks. Developing a common standard for defining different levels of a risk's probability and its impact ensures that risks will be analyzed and responded to objectively. Probability and impact are independent variables. Risk probability is the likelihood that a risk will occur, on a scale between 0% and 100%, where 0% means it is impossible, and 100% means it is certain. Risk impact is the effect on project objectives if the risk event occurs. Risk probability and risk impact are investigated separately; however, a common pitfall is for these terms to be confused, for example, assigning a high probability to a risk because the potential impact is severe. For example, imagine the risk of being struck by lightning the impact is very high, but the probability is considered very low. During risk analysis, these two dimensions of risk are applied to specific risks. This helps determine which risk events should be managed most aggressively, and the level of effort and investment that is justified.

223

7. Probability and Impact Matrix Each risk's probability rating (P) is multiplied by its impact rating (I) to generate a "risk score" (RS). Since the number of probability rating values and impact rating values is limited (normally, five of each), all possible combinations can easily be established and entered into a table or matrix. (Tables and matrixes are presented in a subsequent unit, Qualitative Risk Analysis.) Organizations often find it useful to stratify the resulting RS values into three levels, one representing "low" risks, one representing "moderate" risks, and one representing "high" risks. To signify this, the associated matrix entries can be colored to identify which level they belong to. For example, the low risks may be colored green, the medium risks yellow, and the high risks red. Using this technique simplifies applying different policies (and hence effort and resources) according to the level of the risk's RS. For example, risks rated as "red" may require review at every weekly status meeting, while "green" risks may be reviewed only monthly, or on a less frequent, rotating basis. 8. Revised Stakeholder Tolerances for Risk Risk thresholds define the criteria that a risk must satisfy in order to be acted on. Example: One threshold may require that if a risk delays the project's schedule objective by more than 30% and the project team would require another 20% of project budget to mitigate the schedule impact to below that level, a reevaluation of the project's cost-benefit ratio is triggered automatically. Selecting which level of risk factors is "high" risk is a matter of stakeholder tolerance. In some cases, stakeholders may temporarily adjust their attitudes toward risk for a specific project, particularly if one or more project objectives represent significant strategic value to the organization. Sometimes an organization faces significant external threats, such as the pressure of competitive innovation or significant restructuring in the industry. Stakeholders may also be willing to revise their tolerance for risk when a windfall opportunity presents itself. By temporarily suspending normal risk thresholds, the organization will have the ability to respond. Such variances from the normal thresholds should be clearly decided and communicated. 9. Reporting Formats Reporting formats present: •

How the risk response plan will be organized;

•

How the risk management activities will be documented, analyzed, and communicated to project stakeholders; and

•

The contents and format of the risk register (described later).

224

10. Tracking Information The tenth and final component of the risk management plan is tracking information. Tracking information defines how risk management activities will be documented and audited for the following uses: •

Evaluation of the current project's performance; and

•

Historical information for the benefit of later projects.

G. Probability and Impact Matrix •

Has a matrix been constructed reflecting all possible combinations of risk impact and probability levels?

•

Have the entries in the probability and impact matrix been stratified into a small number of overall risk levels?

H. Revised Stakeholder Tolerances • •

Have the normal risk tolerances of all stakeholders been reviewed and determined? Have any of the stakeholders’ risk tolerances been temporarily relaxed or tightened for this particular project?

I. Reporting Formats •

• • •

Has a standard entry form for the various sections of the risk register been developed, including the probabilistic project analysis and the revised project objectives, as well as the risk response plans? Have report layouts been defined for the periodic reporting of risks to the stakeholders? Has a form been designed for stakeholders to report the results of implementing their risk response plans? Has a form been designed for identifying new risks?

J. Tracking • Has a repository been set up to collect risk management work products? • Are the minutes of risk review meetings being collected and stored in the • repository? • Are the start and stop dates of risk management activities being reported? • Are all the significant data concerning risk management (reports, notifications, • memos) that are reported to stakeholders being recorded in the repository? • How are the audits of the risk management activities going to be carried out?

225

Risk Management throughout a Project's Life Cycle Risk processes should be performed throughout the project life cycle, and can be performed at any time during the project life cycle. Determining when during the project life cycle to analyze potential risks should be one of the first actions in the process of planning risk management planning. When a project consists of several phases, each phase may have its own unique risk characteristics; a specific risk assessment may therefore be performed at the beginning and at key points of each phase to identify risks and to characterize their severity. Typically, the first risk analysis is performed early in the project, or during the concept exploration or project definition phases. It is during these phases that risk identification and management will have the most significant benefit in successful project completion. The project manager should consider conducting a risk analysis for the following reasons: •

A major risk that has been previously identified has been realized, and new information is available;

•

The potential of a high-risk item has been changed; and

•

The potential for new risks has increased.

The Iterative Nature of the Project Risk Management Processes

The Project Risk Management processes are iterative. The very acts of managing the project and managing existing risks lead to the discovery of new risks. The progress of the project will unearth new unknowns and assumptions. A project manager may learn very late in a project about problems that could not have been anticipated; e.g., regulatory changes, changes in personnel, or changes in relationships with suppliers or contractors. Over time, the analysis of risk should show the probability and impact of risks decreasing in response to effective management. However, residual risks may remain even after such actions are taken. The probability of a risk may be significantly decreased, but it will never be eliminated. Project managers should think of risk management as an integrated discipline that is practiced continually through the life of a project. This means that an action, or failure to take an action, in one area will usually affect other areas. Risk management often requires tradeoffs among project objectives. Performance in one area will often be enhanced or safeguarded only by sacrificing performance in another.

226

Managing Risk by Project Phase Different phases involve different types and sizes of risk. Two main principles cause this variation in project risk. 1. The kind of work performed in each phase is different, and each kind of work introduces its own risks. Example: In the design phase, the faulty application of a design technique or tool can result in significant difficulties. This problem cannot occur during testing or implementation because the tool or technique is not in use in those phases. 2. The earlier in the project life cycle the risk is encountered, the greater the impact on the rest of the project. Because most problems spread through the remaining project management activities and deliverables, more of the value of the project is affected by a problem in an early phase than by a problem in a later phase. Example: An omission in a specification that occurs in the design phase and remains undetected until testing or even implementation will usually require reworking the design and every downstream deliverable that is affected. Fundamental Concepts of Risk Management Despite differences across industries, the following seven fundamental components of risk management are widely recognized. They can be considered imperatives - actions or attitudes that are required for effective risk management. Determine Proportionate Expenditure. The first fundamental principle of risk management is proportionate expenditure. The time and money spent in analyzing risk and determining strategies for risk management and mitigation should be considered from the perspective of cost-to-benefit analysis. It should not cost more to manage or mitigate the risk than to realize the risk. In other words, if there is a risk of suffering a $1,000 loss on your project, an effective project manager would look for a preventive solution that costs, for example, no more than $100 in time or additional resources. If the risk cannot be prevented, a secondary strategy would be to find a way to limit the value of the loss to much less than $1,000. The goal is "spend a little to save a lot."

227

Determine Proportionate Expenditure to the Realized Risk. Realized Risk Realized risk is defined as the impact to the project should the risk actually occur. This can be understood in terms of financial loss, delay in schedule, or inability to achieve stated requirements. Ultimately, each of these can be reduced to the time and cost that will be required to repair or recover from the risk event. To illustrate, one might wish to estimate the value of realized risk from a public disaster such as a hurricane. We do not simply declare a "loss" of millions of dollars. Instead, we define the costs involved to return to normal (rebuilding roads, houses, and public infrastructure). Likewise, when a project suffers a loss, some course of corrective action is taken to recover. The cost of that action (in terms of time, resources, and budget) is the true realized risk. In some project domains, the idea of realized risk is replaced by the value of the risk multiplied by the probability that it will occur. Statistically, a risk with an impact of $50,000 but with only a 10% likelihood of occurring is worth, or has an expected monetary value, of $5,000. Using the above illustration, you should not spend more than $5,000 to eliminate such a risk. In a given project you will have dozens of risks, and only a portion of them will actually occur. You could not reasonably spend up to the full value of each risk in order to defend your project. Additional discussion of the statistical basis of risk will be seen in the material on Monte Carlo analysis presented later in the course. Be Pragmatic. The second fundamental principle of risk management is to use a pragmatic approach. Some risks simply cannot be controlled. For example, if a key resource pool belongs to a union that is sympathetic to a strike that may take place at an unrelated facility, management may choose to simply ignore the risk because there are no alternative strategies and the strike is beyond its control. Similarly, the possibility of an earthquake is very real in some parts of the world, and the consequences potentially severe. However, it may not be practical to plan mitigating this risk into the project itself if the likelihood that an earthquake will occur during the project is extremely low. It may be more cost effective to concentrate management attention on the mitigation of some moderate risks that can be controlled, rather than on some high risks with results largely determined by outside influences.

228

It may not be possible to manage or mitigate every risk; therefore, some risks must simply be accepted. Also, a risk with major consequences but an extremely low potential of occurring may not need to be considered a risk with any real potential for the project. Communicate Effectively. In order to maximize the probability that information about risks will reach the project team, every effort should be made to encourage and validate ideas from every possible source, no matter what the contributor's background or function. The project management team should also encourage the free flow of information among all participants in the project. This will ensure that as many available sources of information about risks as possible will be found and tapped, and that potentially sensitive information will reach the necessary parties. Because individuals have specific communications preferences, and because the project team cannot predetermine who will possess important risk information, the team should encourage the use of a wide variety of communication vehicles. This will increase the probability that information about a risk will be communicated effectively to the necessary parties on the project team. Apply Processes Continuously. The project team members and stakeholders must be constantly aware of the emergence of new risks. They must also continue to carefully monitor information sources that may provide warnings about impending risks. The project management team must remain continuously engaged in managing risks through all phases of the project's life cycle. Integrate Risk Management with Project Management. The jobs of the project manager and risk manager include making risk management activities an integral part of the other project management activities. This includes considering risk whenever a project status meeting is held, a new resource is introduced to the project, or an unexpected event occurs. In order to make Project Risk Management a more intrinsic part of project management activities, the project management team should ensure that all aspects of the project's infrastructure (such as its communication vehicles, repository, and work management processes) include a risk management component. Additionally, the project management team should encourage risk awareness within the project team's culture. For example, the team members should be tolerant of negative reactions to new circumstances, and should explore them openly for any possible validity. They should also routinely challenge optimistic assertions and forecasts, discuss how adverse events might affect the project, and talk about how to prepare for such events in advance.

229

Create a Shared Vision. To increase each team member's effectiveness and enthusiasm for identifying and managing new risks successfully, the team should share a common understanding of the final product or service of the project. They should also, to the extent possible, be involved in defining the product and its functions, not merely depending on the sponsors for direction. These two practices will make the team more alert to new threats to the project, and more tenacious about facing and averting them. Build Teamwork. The final fundamental concept of risk management involves teamwork. It is the project manager's responsibility to ensure that Project Risk Management is carried out, but the best results are achieved when all the stakeholders who might have information about project risks and impacts, or how best to mitigate them, are involved. Reasons for Building Teamwork The project manager will achieve the best results in risk management by engaging members of the project team in risk management activities. This is primarily because: •

Project team members have the greatest familiarity with the kinds of technical risks that are likely to occur;

•

Project stakeholders are in the best position to identify and assess external factors that may cause risks for the project; and

•

Creative and analytical thinking is enhanced when the team is working well together.

Benefits of the Risk Management Planning Process The Risk Management Planning process defines how risk management will be carried out, both as guidance for the team and as a commitment to the project sponsor. The benefits of the Risk Management Planning process are the following: •

It ensures that threats do not cause the project to miss its objectives; and

•

Opportunities are effectively converted into advantages for the project, all with a minimum investment of time and money.

For these benefits to be realized, the project management team must thoroughly and diligently design, then carry out Risk Management Planning and other processes in the Project Risk Management Knowledge Area.

230

Tailoring the Risk Management Planning Process The Project Risk Management Knowledge Area processes, like all other Project Management processes, must be tailored to match the level of effort in managing risk to the project's overall value to the organization. Example: A business-critical project would require more effort and more sophisticated Project Risk Management processes than a project to perform a routine upgrade to an infrastructure service. This tailoring can take the form of: •

A larger budget for risk management activities;

•

More time allowed to perform the risk management activities;

•

Higher levels of involvement by senior stakeholders; and

•

Larger contingency reserves of cost and time to absorb risk impacts that cannot be efficiently eliminated.

The stakeholders' tolerance for risk is another important factor affecting the Risk Management Planning process. Their risk tolerance will affect how much they are willing to invest in Project Risk Management activities and contingency plans, and how much they set aside for contingency reserves of time and cost. Organization Risk Tolerance The second enterprise environmental factor involved in risk tolerance is the organization's risk tolerance. With most opportunity comes risk. Organizations are in business today because they were willing to take risks. The key is to find a balance between the opportunities they want to pursue and the risks they are willing to take. Several risk experts have suggested that organizations and individuals strive to strike a balance between risks and opportunities in all aspects of projects and their personal lives. The idea of striving to balance risks and opportunities suggests that tolerance for risk is variable. The organization's risk tolerance can be affected by: •

The current economic environment;

•

The willingness of senior management to take risks; and

•

Whether the project is high-value and complex or low-value and relatively simple.

231

It is important for the project manager and project team to know the risk tolerance of a company early in the risk-planning phase. A template from previous project efforts can be used; this helps define and explain the organization's methodology regarding risk tolerance.

Organizational risk management policies The organizational risk management policies dictate: • • •

How risk management is to be performed; Who is to participate; and What deliverables are required.

Formally established, written rules assign accountability for risk management and ensure that new initiatives are analyzed for risk. The rules should also define: • • •

A standard risk process; Risk management tools; and The frequency and level of reporting.

Organizations may have policies or legal regulations for specific types of risks; for example, the handling and disposal of hazardous materials. Templates An organization may have a template for Risk Management Planning, especially in organizations with standards for quality systems, such as the ISO 9000 series. Applying the template ensures consistency, allowing individuals from different projects to easily comprehend the risk plans on any project undertaken by the organization. The risk management plan template will normally include or refer to: • • •

Specialized tools such as a standard base set of risk categories; Risk screening checklists; and A standard probability and impact matrix or separate probability and impact scales.

232

Definitions of roles & responsibilities The definitions of functional and matrix roles and responsibilities explain: • • •

Who must participate; Who is responsible for reviewing and approving risk management deliverables; and Who must be involved in risk mitigation strategies, including monitoring risk triggers and responding to risk events.

Depending on the organizational structure, certain types of risks may fall under the responsibility of specific parties in an organization. The primary technique for the Risk Management Planning process is a combination of planning meetings and analysis. These are conducted the same way as other planning meetings, using these tools and techniques: •

An agenda;

•

Objectives to create specific deliverables;

•

Data-gathering to ensure that all meaningful input is obtained; and

•

Objectivity in evaluating and making decisions

Planning Meeting Participants The Risk Management Planning meeting involves key members of the project team, including: •

The project manager;

•

Project team leaders;

•

Key internal stakeholders;

•

Risk officers, consultants, auditors, or others responsible for directing, conducting, or overseeing risk activities within the organization; and

•

External stakeholders as required and allowed.

Purpose of the Planning Meeting One significant purpose of implementing and following well-defined project management processes is to minimize the chance of oversights and errors. The project management team should review the processes for the current project to understand how these processes already minimize project risks. If a particular project management process does not minimize risks effectively, the team should determine whether applying the process more rigorously would help.

233

In particular, the planning meeting should establish a common understanding of the extent of control and the types of controls that will be in place for project monitoring and control. This helps team members understand the generic risk controls for low and medium risks, which are typically sufficiently covered by the prudent use of standard project management controls. Planning Meeting Results Planning meetings also define: •

Who will lead, support, and identify team members for each type of risk action;

•

What approaches, tools, and data sources will be used for risk management;

•

What scoring and interpretation methods will be used to categorize and analyze risks;

•

Which team members will be assigned to each identified risk;

•

What the criteria will be for the threshold of each level of risk impact;

•

How much additional cost for risk mitigation will be acceptable to the project stakeholders;

•

How often each risk management process will be performed;

•

How reports will be generated and what standard content will be included, analyzed, and communicated; and

•

How all the risk activities will be recorded and/or tracked.

The first planning meeting should define: •

How the planning meetings will be conducted throughout the project;

•

How organizational process assets will be tailored to meet the needs of the project;

•

How the remaining activities in the Risk Management Planning process will be conducted; and

•

Agendas and deliverables for the remaining Risk Management Planning meetings.

234

Planning Meeting Activities The planning meeting involves reviewing: •

Key project documents such as: o

Project charter;;

o

Project scope statement;

o

Project schedule and project budget; and

o

Previous project management administrative work products.

•

The planning assumptions

•

Historical information, such as documentation of lessons learned from similar projects and risk management plans of previous projects

•

Known risks, identified by questions such as: o

What concerns have sponsors or key stakeholders expressed?

o

What risks have occurred on recent, similar projects?

o

What areas of risk require the team's attention?

Reviewing these materials will facilitate early identification of risks and risk-related information. Additionally, the materials may serve as examples for the current project to emulate. Risk Breakdown Structure (RBS) Risk Breakdown Structures A risk breakdown structure (RBS) is a hierarchical, multi-tiered organization of the risk categories. When risks are being analyzed, grouping them this way makes it possible to gather and review together risks with a common characteristic, such as their cause, or the phase or activity in which they occur. This approach to reviewing risks that appear together in the risk breakdown structure increases the efficiency of investigating their causes, and may also increase leverage when risk response plans are developed. For example, risks with similar or a shared cause in a particular process step may be mitigated by the same process change.

235

Definitions of Risk Probability and Impact The methods for scoring and interpreting the Quantitative and Qualitative Risk Analysis processes must be set in advance to avoid injecting personal biases or inappropriate influence into the attention paid to particular risks. Developing a common standard for defining different levels of a risk's probability and its impact ensures that risks will be analyzed and responded to objectively. Probability and impact are independent variables. Risk probability is the likelihood that a risk will occur, on a scale between 0% and 100%, where 0% means it is impossible, and 100% means it is certain. Risk impact is the effect on project objectives if the risk event occurs. Risk probability and risk impact are investigated separately; however, a common pitfall is for these terms to be confused, for example, assigning a high probability to a risk because the potential impact is severe. For example, imagine the risk of being struck by lightning the impact is very high, but the probability is considered very low. During risk analysis, these two dimensions of risk are applied to specific risks. This helps determine which risk events should be managed most aggressively, and the level of effort and investment that is justified. Probability and Impact Matrix Each risk's probability rating (P) is multiplied by its impact rating (I) to generate a "risk score" (RS). Since the number of probability rating values and impact rating values is limited (normally, five of each), all possible combinations can easily be established and entered into a table or matrix. (Tables and matrixes are presented in a subsequent unit, Qualitative Risk Analysis.) Organizations often find it useful to stratify the resulting RS values into three levels, one representing "low" risks, one representing "moderate" risks, and one representing "high" risks. To signify this, the associated matrix entries can be colored to identify which level they belong to. For example, the low risks may be colored green, the medium risks yellow, and the high risks red. Using this technique simplifies applying different policies (and hence effort and resources) according to the level of the risk's RS. For example, risks rated as "red" may require review at every weekly status meeting, while "green" risks may be reviewed only monthly, or on a less frequent, rotating basis.

236

Reporting Formats Reporting formats present: •

How the risk response plan will be organized;

•

How the risk management activities will be documented, analyzed, and communicated to project stakeholders; and

•

The contents and format of the risk register (described later).

10. Tracking Information The tenth and final component of the risk management plan is tracking information. Tracking information defines how risk management activities will be documented and audited for the following uses: •

Evaluation of the current project's performance; and

•

Historical information for the benefit of later projects.

Checklist for the Risk Management Plan A checklist can be used to complete the risk management plan. The checklist below includes the ten components described on the previous pages, but can be expanded for the specifics of a particular project. The risk management plan checklist should be completed as the risk management plan is developed, and should be referred to at each planning meeting or review of the risk management plan. Next page is an example of a risk management plan checklist.

237

RISK MANAGEMENT PLAN CHECKLIST A. Methodology • Does the plan describe how it was developed, and how it will be maintained? •

Does the plan describe how Risk Identification will be carried out?

•

Does the plan describe how Qualitative Risk Analysis will be carried out?

•

Does the plan describe how Quantitative Risk Analysis will be carried out?

•

Does the plan describe how Risk Response Planning will be carried out?

•

Does the plan describe how Risk Monitoring and Control will be carried out?

B. Roles and Responsibilities • Who will direct all risk management activities? • Who has been designated to participate in the risk management group’s work sessions for risk assessment and Risk Response Planning? • What are the duties of the participants in the risk management group’s work sessions, including preparation, outside research, and documentation? • What governing body will oversee the execution of risk management activities? • Who represents internal stakeholders in risk management activities? • Who represents external stakeholders in risk management activities? C. Budgeting •

Have all risk management activities been budgeted?

•

Have contingency reserves for cost been set aside to accommodate residual and secondary risks?

D. Timing • •

Has frequency been determined for all regularly occurring risk management activities, such as risk review sessions? Have all risk management activities been incorporated into the project schedule?

238

E. Risk Categories • If a set of standard risk categories is available in the organization, was it adopted for use on the current project? • Has the set of risk categories been tailored to suit the characteristics of the current project? • If a risk breakdown structure (RBS) will be used, has it been developed yet? F. Definitions of Risk Probability and Impact •

Has a scale of terms been defined for different levels of risk probability?

•

Has a scale of terms been defined for different levels of risk impact?

G. Probability and Impact Matrix • Has a matrix been constructed reflecting all possible combinations of risk impact and probability levels? Have the entries in the probability and impact matrix been stratified into a small number of overall risk levels? H. Revised Stakeholder Tolerances • Have the normal risk tolerances of all stakeholders been reviewed and determined? • Have any of the stakeholders’ risk tolerances been temporarily relaxed or tightened for this particular project? •

I. Reporting Formats •

• • •

Has a standard entry form for the various sections of the risk register been developed, including the probabilistic project analysis and the revised Project objectives, as well as the risk response plans? Have report layouts been defined for the periodic reporting of risks to the stakeholders? Has a form been designed for stakeholders to report the results of implementing their risk response plans? Has a form been designed for identifying new risks?

239

J. Tracking •

Has a repository been set up to collect risk management work products?

•

Are the minutes of risk review meetings being collected and stored in the repository? Are the start and stop dates of risk management activities being reported? Are all the significant data concerning risk management (reports, notifications, memos) that are reported to stakeholders being recorded in the repository?

• • •

How are the audits of the risk management activities going to be carried out?

Being Proactive in Risk Identification Using a proactive approach to identify risks is far better than waiting for the problems to arise on their own. Being proactive has the following benefits: •

Anticipating risks allows the participants to become more comfortable discussing and analyzing circumstances and events that would normally cause anxiety. By handling the topics in a methodical way, participants are reassured that the risks will be successfully managed.

•

Analyzing the potential for risk helps ensure that all areas of potential risk will be fully explored and that identified risks will receive balanced treatment, regardless of personal biases and influences.

One aspect of the methodical approach involves separating the identification of positive risks from the identification of negative risks. It is usually best to provide separate agenda time or even to set up separate risk assessment sessions for these two kinds of risks. The reason for this is that thinking about negative risks tends to dominate the participant's attention since anxiety is such a powerful emotion. If the two types of risk are considered in the same period, the positive risks will tend to get overlooked or only reviewed in a cursory manner. Some risks will be seen to have both positive and negative impacts, depending on the actions taken. For example, a risk that a task will take longer than expected may also present an opportunity to finish sooner than expected.

240

Checklist Analysis Advantages and Disadvantages Advantages of Checklist Analysis The advantages of using checklist analysis to identify risks are: •

Checklists are helpful when they reflect lessons learned from previous projects; and

•

Checklists are simple and efficient.

Disadvantages of Checklist Analysis The disadvantages of using checklist analysis to identify risks are: •

Checklists can be limiting if the team automatically assumes that the checklists are comprehensive and complete, which is rarely the case; and

•

A large project is likely to require a lengthy checklist and no checklist can be wholly adequate without being tailored to the current project.

A Sample Checklist An organization involved in project management should consider developing a risk checklist specific to its needs; however, the sample below may be sufficient for most projects. The checklist below shows risks by category, such as technology and time. When time is short, this type of checklist lets the team focus on specific areas for their risk potential rather than running through the entire list. Once an area of concern is flagged, it is necessary to identify specific risk statements that describe the specific concern more completely, for example, "Development software vendor fails to provide adequate technical support," or "Major snowstorm prevents team from reaching offices for two workdays A. Technology New technology? Unknown or poorly documented technology? New application of existing technology? Advanced technology being modernized in existing application? B. Time Project schedule uncertainties or constraints that may impact project completion or milestone dates? Procurement items with long lead times that may affect completing the critical path or milestones?

241

C. Contractor Capabilities Potential that qualified vendors or contractors may not be available? D. Interfaces Significant transportation or infrastructure impacts? Multiple project interfaces? Significant interfaces with an operational facility? E. Safety Risks to worker safety during construction? Significant contamination potential? Accidents due to new design or other non-reviewed safety questions? Involvement of hazardous material? Sample Risk Register Worksheet In order for risks to be effectively managed, information about them must be managed and controlled. Changes and additions to the list, as well as removals from the list, must be made according to a formal process. The information in this worksheet should be stored in an automated system (also called a risk register), so that it can be integrated with other project management processes. Many departmental and enterprise-level project management systems contain a risk management subsystem for this purpose. For simple projects, a simple database, such as a Microsoft® Excel spreadsheet, may be perfectly adequate. An example of a risk register worksheet for risk identification is displayed below. The worksheet can be used to catalogue risk information, including severity, triggers, and risk category. At this point, the only information that is known for sure appears in the first three columns, although other information, such as severity, potential response, triggers, and root cause, may be known or hypothesized. Later Project Risk Management activities will involve assessing qualitative factors, such as probability and impact, and quantitative factors, such as costs; selecting appropriate responses to manage the risk; and documenting the final impact of the risk and the effectiveness of the associated risk responses.

242

Project: RAZ AZ ZAWR Risk Register Worksheet Risk Identification ID Risk

Type

Severity Potential Response

1.1 Transport External workers threat strike

.05

Triggers

Assemble Failure of components negotiations in another state

Root Category Cause N/A

Labor skills availability and productivity

Qualitative Risk Analysis To manage risks efficiently, it is necessary to understand each risk in terms of its relative significance to the project and its relationship to other risks. Given the list of identified risks and some conventions for measuring the size of the risk, two primary questions are answered in the Qualitative Risk Analysis process: how likely is this risk, and, if it occurs, how significant is its impact on the project? The result of the Qualitative Risk Analysis process is a prioritized list of all risks that have been identified. Purpose of Qualitative Risk Analysis The output from the Risk Identification process provides a comprehensive list of risks. This list may easily include dozens to hundreds of risks, depending on the size of the project. Such a long list can overwhelm the project manager and team and can also alarm the project sponsor and senior management, unless appropriate steps are taken to simplify and organize the list as much as possible. The goal is to begin establishing order out of chaos so that prudent and economical actions can be taken to protect the project from the risks. This is accomplished by first performing an analysis of each risk that has been identified. Using a divide-and-conquer approach, each risk is investigated so that it is understood more fully. Then the project manager prioritizes and allocates resources to all the risks to address the overall risk most effectively. The Qualitative Risk Analysis process is a way to determine the importance of addressing specific risks, and allows the team to guide risk responses based on the following factors: •

Time criticality of the risk;

•

Quality and quantity of information about the risk; and

243

•

The probability of occurrence and impact of the risk

The impact of the risk may affect one or more of the project objectives, including the schedule, cost, and scope and quality objectives. Because stakeholders' tolerance for risk varies, it is important to have determined the current stakeholders' tolerance for risk during the Risk Management Planning process. The tolerance levels will indicate which risk impacts can be accepted without further intervention, and what level of investment the stakeholders would consider justified to avoid or minimize the impact of a risk. Frequency of Performing Qualitative Risk Analysis As with the Risk Identification process, Qualitative Risk Analysis should be repeated throughout the project life cycle, especially at major milestones between project phases. This is done to identify significant risks and formulate strategies for managing and/or mitigating the risks. A project risk analysis can be performed at any time during the project life cycle. Subsequent reviews, revisions, and updates should be performed at least once during each project phase, preferably at the beginning of the phase, and at any time deemed appropriate by the project manager. For instance, a project manager should consider conducting a risk analysis for the following reasons: •

A major identified risk has been realized;

•

The potential of a high-risk item has been eliminated;

•

The potential for new risks is identified; and

•

New information has surfaced that may indicate that a risk's probability or impact has increased or decreased.

If possible, all participants in the initial risk analysis should participate in subsequent reviews. When these reviews are performed, all available information on project scope, project performance, and any other relevant data should be provided to the team. Determining the Probability of Occurrence (P) Using a Probability Scale In the formula Risk Score (RS) = Probability (P) * Impact (I), "P" is the probability of occurrence. Assigning a probability to a risk helps management determine whether the risk is likely enough to be worth addressing, and how much to invest in addressing it. Setting up a probability scale involves selecting a set of terms for probability so that all participants can rank risks in a consistent way. This type of scale is known as a Likert scale, and is frequently used in surveys. Examples of terms for probability are "very unlikely" and "very likely."

244

The terms for probability must be assigned meaningful values that indicate their relative positions. Probability is usually expressed as a percentage. In practice, 0% and 100% are to be avoided because they signify certainty that the risk will not or will occur, respectively. Examples of terms and values that can be used in a five-point scale appear below. Terms of Probability

Values

Very unlikely

10%

Somewhat unlikely

30%

50-50 possibility

50%

Somewhat likely

75%

Very likely

90%

A probability of "very unlikely" means that the event is nearly impossible, while a probability of "very likely" means it is almost certain to happen. A "50-50 possibility" means it is just as likely to happen as not. An example of a 50% probability is the toss of a coin: the coin is equally likely to land with the "head" up as with the "tail" up. We say the probability of heads is 50%, as is the probability of tails. A five-point (5, 25, 50, 75, 95) scale usually provides enough spread to differentiate between risks. In cases that are submitted to qualitative analysis, the usual quality of available data and the lack of a real measurement usually do not justify greater accuracy. Cautions on Determining the Probability of Occurrence (P) It is important to note that the values in the probability scale do not equate to an actual likelihood; they are simply relative values that permit later numerical analysis. This numerical analysis enables the project management team and stakeholders to compare dissimilar risks by ranking them. The probability of each risk's occurrence should be set at a single value that represents the best judgment of the team at this time from the available data. The team should not consider the impact while evaluating the probability. For example, the probability of a train collision has nothing to do with the freight or passengers carried by the train, or the damage the wreck will do. It is solely a function of the condition of the locomotives, tracks, switches, signaling and communications equipment, the weather, the schedule of trains, and the competence and fitness of traffic controllers and engineers.

245

Determining the Impact of Risk (I) Using an Impact Scale In the formula Risk Score (RS) = Probability (P) * Impact (I), "I" is the impact of risk. The impact of the risk measures the consequence to the project if this risk happens. A scale similar to that of risk probabilities must be set up for the risk impacts. The risk impact can be evaluated on a relative scale of values such as "none" to "highly undesirable." These values can also be assigned as numbers. Examples of terms and values that can be used in a five-point scale appear below. Terms of Impact

Values

Very low

1

Somewhat low

3

Moderate

5

Somewhat high

7

Very high

9

The scale does not need to use the equally spaced values used by a linear scale. Using a set of values with unequal intervals can emphasize the undesirability of somewhat high or even moderate negative impacts, or the desirability of a somewhat high positive impact, even though the risk has a relatively low probability of occurring. For example, the highest value might be set at 99, and the value below that at 95. This would inflate the risk score for risks assessed as having "failure" and "significant degradation" impact to the point of justifying significant investments in avoiding or mitigating these risks and getting approval from the stakeholders. Using a linear scale would not prioritize these risks as highly for investment in risk response. Quantitative Risk Analysis For most projects, the risks that have been prioritized by the Qualitative Risk Analysis process are put through the Quantitative Risk Analysis process. The main outputs of this process are a prioritized list of quantified risks, estimates of potential achievement of schedule and cost objectives, and, as the project progresses, a view of trends in the results of thee quantitative risk analysis. Quantitative Risk Analysis includes: •

Understanding the risk's potential effect on each project objective;

•

Providing an analysis of potential risk strategies in the face of uncertain outcomes of related decisions;

246

•

Identifying the risks;

•

Identifying the risks requiring the most attention according to their effect on the overall project risk;

•

Determining the risk exposure and contingency costs;

•

Modeling the probability of achieving the stated targets as a reality check for cost, schedule, and scope targets; and

•

Setting realistic targets for project objectives that match stakeholder tolerance for risk.

Quantitative Risk Analysis is more objective than Qualitative Risk Analysis, and provides a more detailed picture of the effect of the risk on project objectives. It is more difficult, requires sophisticated tools, and takes more time, making it substantially more expensive than Qualitative Risk Analysis. Therefore, it is common practice to put all project risks through the Qualitative Risk Analysis process first, and only then to put the risks rated high through the Quantitative Risk Analysis process to more precisely determine their possible effects on project objectives. Purpose of Quantitative Risk Analysis The Quantitative Risk Analysis process is intended to analyze the likelihood and impact of identified risks using numerical techniques. The Quantitative Risk Analysis process helps ensure that: •

No expenditure on managing the risk exceeds the expected cost of the impact of the realized risk;

•

Factors that influence the risk's probability and impact are understood well enough to leverage them, either to minimize the effect of a negative risk or to maximize the effect of a positive risk;

•

The probability of success for each project objective is thoroughly evaluated; and

•

Contingency reserves for project schedule and budget are calculated at prudent levels.

Application of Quantitative Risk Analysis An estimator who forecasts that a work activity will take 10 days and cost $50,000 is probably basing the forecasts on average figures. The actual duration could easily be lower or more likely, it could end up being higher. When each activity in a collection of activities in a project network schedule can take more or less time and cost more or less than

247

forecasted, no one activity determines the outcome. The totality of the durations and costs and their effects on each other determine whether the entire project takes either less time or more time than forecasted. Running a set of simulations is the only practical way to evaluate what the total project performance is likely to be, and within what range. When the project manager states how much time the task is expected to take as he assigns it to a team member, he often leaves the impression that it is acceptable to consume all the time before reporting the task's completion, whether the time is actually needed or not. This creates a tendency for tasks either to take the estimated time or to overshoot, but rarely to undershoot. To compensate for this bias toward overshooting, project managers often resort to adding a schedule contingency to each activity. As task durations expand and team members continue to overshoot them, an overall trend toward underperformance can be expected. To eliminate this phenomenon, the project manager can set the expectation that team members should do their best to beat the scheduled duration for the task. They should set the scheduled duration to the mean value for that task, calculated using the three-point estimating technique. In many situations, incentives for performance can help overcome the overshooting phenomenon. Then, the project manager should set up a schedule contingency at the end of the project schedule network, or distributed throughout the project at the end of each phase, so that the likelihood of meeting the overall project completion date will be as high as the stakeholders require. Sensitivity Analysis Scenario In sensitivity analysis, calculations of schedule, cost, and other factors in project performance are repeated while changing the impact of one risk according to its probability distribution. In this scenario, an event coordinator who has scheduled an important convention receives news of an impending snowstorm, and needs to determine what action to take. Risk 1: A snowstorm will cause some percentage of the attendees to cancel. Suppose there is a 10% likelihood that a snowstorm will cause 50% of the convention's attendees to cancel, a 20% likelihood that it will cause 30% of them to cancel, and a 70% chance that fewer than 10% will cancel. Suppose also that several speakers are flying into town for the meeting. Risk 2: Flights will be diverted from the local airport. The airlines will make decisions to divert flights based on the depth of snow on the airfield at arrival time. The coordinator assesses the probability of flight diversions to be 30%. Finally, suppose he considers hiring a limousine to drive the diverted speakers into town from an alternative airport to which the speakers' planes would be diverted. Risk 3: Limousines will not be available for attendees landing at a distant airport. The coordinator estimates that the availability of limousines will decline rapidly from the time

248

of the announcement of the snowstorm, so that delaying a request for a limousine by one hour reduces the probability of success to 90%, by 2 hours to 75%, and by 4 hours to 40%. He must decide among these choices: A. Reschedule the meeting at a cost that will exceed the original budget by almost 100%. B. Keep the meeting on schedule, but be forced to forego a percentage of the fees that are normally paid by walk-in registrants, who will choose not to attend due to the storm. C. Hire limousines that may not be needed, thus doubling the cost of the speakers. Using the probability distribution of each risk enables the coordinator to forecast the profitability of the convention based on each strategy. Sensitivity analysis involves changing each factor separately to see what it does to the overall project's objectives. It will show the coordinator which risks should be of greatest concern, and which ones he can mitigate to minimize the impact to the project objectives. Expected Monetary Value (EMV) Analysis The next of the quantitative risk analysis and modeling techniques is expected monetary value (EMV) analysis. EMV is a technique for assigning a specific dollar value to a set of alternative, uncertain outcomes. The EMV of a specific uncertain outcome is the value of the outcome multiplied by its probability. The EMV of all outcomes is the sum of the individual EMVs. For example, suppose that if a project risk were realized, it would cost the project $12,000. Suppose the risk has a 50% probability of occurring. Its EMV is (.50 * -12,000), or $6,000. The use of a negative number indicates that it is an outflow, or cost, and is undesirable. Suppose the project manager has to choose between two alternatives, and the first one leads to the risk described above, while the other one leads to a second risk. Suppose the second risk has an impact of -$15,000, but has only a 33% chance of occurring. The second risk's EMV is (.33 * -15,000), which is only -$5,000. So (barring other possible considerations), the project manager should choose the alternative leading to the second risk, not the first. Modeling and Simulation: Monte Carlo Simulation Simulation uses probability distributions to create a set of values for the variables under consideration. These values are run through a series of experimental trials to determine a range of outcomes and the likelihood of their occurring. For a project, the simulation uses a model that translates the uncertainties, or possible risks, associated with certain project variables into their potential impact on project objectives.

249

Project simulations are normally performed using the Monte Carlo simulation method. Monte Carlo simulation is based on statistical probabilities. It is extremely economical in analyzing complex situations, in which algorithmic calculations are too difficult or laborintensive to carry out. The Monte Carlo method involves randomly generating values for each input variable, using the probability distribution for the variable as the range within which the values must fall. The values of the variables are combined in a complex calculation to generate an outcome. This process is repeated many times, using, if possible, all possible combinations of values, and the outcomes are plotted into a probability distribution. Once a Monte Carlo simulation establishes the probability distribution for a set of outcomes, the project team can use this information to decide on a course of action. The result of examining the outcomes may involve either altering the project objective so that its likelihood of success is sufficiently high or reserving a contingency (usually a schedule or cost contingency) to reach the desired level of confidence in the project's ability to achieve the objective. For example, to determine the correct contingency reserve to establish for a project budget item, a Monte Carlo simulation would generate random values for the contingency reserve and apply them to a calculation of the total cost, factoring in the probabilities of other risk events occurring during the project. After running a number of these simulations, the project team can identify the cost contingency input value that produces an outcome that falls within an acceptable range of total cost and schedule, resulting in the lowest impact on the project objectives, or in achieving the stated target objective with the desired confidence level. Typically, the analysis centers on the project schedule network (or at least on its critical path). Each task on the critical path involves a schedule risk. To understand that risk, the project management team has to answer the following questions: •

What is the most likely duration of this task?

•

What is the risk, or probability, that it will be longer (or shorter)?

•

How confident is the stakeholder that the task was estimated and budgeted accurately?

Basic Steps in Monte Carlo Simulation As in qualitative analysis, the project manager and key stakeholders on the project will participate in creating the data used in the analysis. It is likely that they will need a trained specialist to assist with the Monte Carlo modeling in order to get meaningful results. They may also use the Monte Carlo simulation capability that is built into some project management software tools; other software can be augmented with an add-in Monte Carlo simulation module available from third parties.

250

The project management team takes these basic steps for Monte Carlo simulation: •

Interview experts on the project to gather likely answers to the questions on the previous page. Stakeholders who control portions of the work breakdown structure and associated budgets are included because they have a key interest in this analysis, and they have valuable experience in their respective areas of expertise.

•

Enter the values gathered from the interviews into modeling tools. Results of varying complexity are produced, depending on the sophistication of the tool.

•

Create the project network of activities in a standard scheduling tool analyze the project's total duration.

•

Estimate the minimum, maximum, and most likely durations for each activity.

•

Using the simulation tool, produce an analysis of the network, describing the critical path, the most likely project duration, and the distribution of project durations with their associated probabilities.

•

If the results indicate that there is too little certainty of achieving the original project schedule objective, either change the project objective or modify the project schedule. This adjustment would alter the planned activities by adding resources or changing dependencies until the resulting analysis indicates a likelihood of success.

Proactive Nature of Risk Response Planning for Negative Risks Responding to Negative Risks in Everyday Life For the negative risks naturally encountered in life - such as accidents or illnesses, it is normally most effective to minimize the probability of the undesired event happening, and then to minimize the impact. The probability of a car accident can be minimized by developing rules of the road, requiring drivers to pass a test demonstrating that they understand and can use them properly, providing rear-view mirrors, installing stop lights at intersections, and providing traffic police to deter drivers from ignoring the rules. The impact of a car accident can be minimized by wearing passenger restraints in cars, buying insurance to minimize the financial damage, and organizing community medical services to respond swiftly to minimize the health damage. Responding to Negative Risks in Projects What is true for everyday life is also true for project management. Risk responses should be designed to be cost-effective, and the most cost-effective controls are typically preventive controls.

251

But the risk response planning process also includes the development of contingency, or fallback approaches, to be implemented if and when the risk materializes. In most cases, the ability to implement these contingency plans also requires advance preparation. Therefore, we can say that all risk responses are to some degree proactive. Proactive Nature of Risk Response Planning for Positive Risks Responding to Positive Risks in Everyday Life For positive risks in life, people commonly prepare by enhancing their awareness of opportunities or their capacity to respond to them. Someone interested in community service might join a volunteer group in order to find opportunities to serve in the community. Joining the group does not directly result in service; it merely presents the opportunities and qualifies the individual to participate in them. As another example, many people pursue higher education or professional certifications before they learn of a job opportunity in which they can use their new skills. Both strategies constitute risk response planning for positive risks. Responding to Positive Risks in Projects Similarly, in projects, unexpected opportunities for the project management team to reduce cost or shorten the project schedule sometimes arise. For example, acquiring and incorporating a newly released commercial product to replace a component that the project team originally planned to develop may greatly reduce the development time and cost. Risk Responses The primary outputs of the Risk Response Planning process are updates to the risk register. These updates consist of risk responses. A complete risk response outlines: •

The identified risk;

•

The chosen response strategy;

•

Specific actions to implement the risk response strategy;

•

Symptoms and warning signs that indicate that the risk is about to materialize or has already materialized;

•

Contingency reserves of cost and time;

•

Risk ownership and responsibilities; and

•

Information about residual and secondary risks arising from risk responses.

252

Risk responses vary according to company policies and standards and the types of risks that have been identified. The risk response should be within the project team's and risk owner's capabilities, and should integrate smoothly with the existing infrastructure of the project team and the performing organization. Threat and Opportunity Response Strategies Since threats endanger the project's commitment to deliver its performance objectives, they generally receive most of, if not all the attention devoted to risk management. For opportunities, risk response strategies include exploiting the opportunity, enhancing the opportunity, and sharing it with partners. The possible strategies for threats are: •

Avoid the risk;

•

Transfer possible impact to another party;

•

Mitigate the risk (try to reduce the probability of the risk's occurring or its possible impact); and

•

Accept the risk as not worth addressing.

The possible strategies for opportunities are: •

Exploit the opportunity;

•

Enhance the opportunity;

•

Share the opportunity with partners; and

•

Abandon the opportunity as not worth pursuing.

Strategies for Negative Risks or Threats Strategies for negative risks or threats include: 1. Avoid the risk; 2. Transfer the risk; and 3. Mitigate the risk.

253

Mitigating the Risk by Identifying the Cause, the Driver, and the Power of the Driver What causes the risk? If this can be understood, and the causal relationship can be altered or exploited, it may be possible to reduce the likelihood that the risk will occur. For example, in research studies regarding head-on collisions between cars, it was determined that there was always a significant risk of a head injury. During testing conducted on crash test dummies, it was determined that head injuries were most often caused by striking the car's windshield. By implementing a shoulder restraint system that crosses the passenger's chest, it was possible to prevent the head from reaching the windshield and dramatically reduce this type of injury. The use of seat belts is a preventive risk response that attacks the causal factor in head injuries sustained during head-on car collisions. What drives the magnitude of the impact? If the factors that influence the magnitude can be affected, then it may be possible to diminish the impact of the risk. As an example, buildings in the city of Venice are sinking, and the effect of storm tides has been determined to be a significant factor in the rate of sinking. By installing tidal barriers that move, Venice has been able to reduce the size of the storm tides, while still permitting tidal basin flows to maintain the healthy flow of silt into the ocean and salt water into the lagoon. This strategy reduces the risk that severe storms will cause significant damage to the city. How controllable is the driver? In the Venice example, controlling tidal surges was not possible until the British and Dutch developed tidal barriers for controlling storm surges on the Thames and Eastern Scheldt estuaries in the late 1970s. As a result of these technical achievements, it became possible to control tidal surges as a driver of flooding damage in estuaries around the world. On the other hand, earthquake damage is caused by wavelike motions resulting from the opening of cracks in the earth, and by sudden vertical displacements in the surface of the earth. Only wavelike motions can be reliably controlled through the use of flexible construction techniques and large rollers in building foundations, as in the Transamerica Corporation building in San Francisco. Vertical displacement in the surface, which is the other driver of earthquake damage, remains largely uncontrollable.

254

Project Management Risk Mitigation Strategies The chart below shows suggested strategies for directly mitigating risk for a project.

Project Management Risk Mitigation Strategies Include the duration of risk response plans in the schedule baseline, and negotiate additional schedule relief. Use team reviews at the work package level to validate activity duration estimates. Clarify the definitions of requirements, deliverables, tasks, and milestones. Clarify and confirm assumptions and constraints. Use a change control board to implement formal processes for controlling changes to the schedule baseline. Schedule critical resources and technology within acceptable windows. Write definitions for periodic vendor performance reviews into the purchase contract. Ensure that vendors use project management tools. Include vendor representatives as part of the project team. Evaluate the use of more expert resources on challenging tasks. Include the cost of risk response plans in the budget baseline. Validate the budget having the team review bottom-up estimates. Provide productivity-enhancing tools that have short learning curves so that training on the tools does not consume the immediate benefits to the project. Monitor and manage costs using the earned value management system (EVMS). Conduct periodic performance reviews

255

Organizational Risk Mitigation Strategies The chart below shows suggested strategies to use within the organization to mitigate risk for a project.

Organizational Risk Mitigation Strategies Obtain firm commitments for specialized resources, with guarantees, if needed. Cultivate secondary sources for specialized resources, and implement methods for rapidly substituting a secondary resource if the primary critical resource becomes unavailable. Obtain written commitments for funding and other resources. Ensure that the project has a committed and active sponsor. Obtain the highest possible priority for the project by making sure that the costbenefit value proposition of the project conforms as closely as possible to the organization’s priorities. To ensure the commitment of powerful stakeholders, recommend that the scope of the project include elements that offer them direct benefits. Stay apprised of the progress of other projects on which the current project depends, and respond promptly if progress is unsatisfactory. External Risk Mitigation Strategies The chart below shows suggested strategies for mitigating risk that comes from outside the organization.

External Risk Mitigation Strategies Minimize development activities in hostile environments (political, business, weather). Avoid single sources when outsourcing critical capabilities. Include protections against shortages or price fluctuations in procurement contracts. Include provisions for quality monitoring and defect correction in procurement contracts. Confirm market data and analyses to support decisions.

256

Technical Risk Mitigation Strategies The chart below shows suggested strategies for mitigating risks arising from technical issues.

Technical Risk Mitigation Strategies Clarify technical requirements. Control changes to specifications, deliverables, and acceptance criteria. In the design, include tolerances and margins for technical products. Identify the project’s technical limitations early in the design process. Allocate work based on skill, or train and certify personnel in new or unfamiliar technologies. Ensure adequate supervision during early stages of each type of work. Involve suppliers in the design process. Conduct reliability studies early. Enforce discipline regarding the application of technical standards, procedures, and methods; conduct process training. Simplify the technical solution where practical. Conduct concept reviews and internal design reviews. Implement a phased approach to developing the technical solution with reviews by experts during each phase. Use an established project lifecycle. Build prototypes. Apply performance modeling, simulation, and analysis of designs. Implement a change control process for technical specifications and deliverables. Tie payment milestones to satisfactory technical reviews.

257

Risk Mitigation Strategy Guidelines The following chart shows examples of activities that contribute to risk and strategies that can mitigate those risks.

Activity Contributing to Risk

Mitigation Strategies

Use of new technology or new application of existing technology

Prototype testing

Unique new technology

Analytical modeling and simulation

Unusually complex design

Use of architecture to reduce coupling of subsystems and their functional testing

Novel design

Formal design review

Significant potential of exposing personnel to hazards

Safety review

Project schedule uncertainties or constraints that may impact milestones

Subcontracting work to others, financial incentives to vendors/subcontractors, additional resources, overtime, multiple shifts All involve absorbing a cost impact; appropriate in projects for which schedule has higher priority than cost

Production shutdown required for project implementation

Synchronizing implementation schedule with lowdemand period; contingency schedule in the event of implementation failure

Use of new technology or new application of existing technology

Prototype testing

For high or medium risks with low probability to low consequences, for which the team feels that no special mitigation is required (e.g., not cost-effective), acceptance may be the strategy of choice.

258

Strategies for Positive Risks or Opportunities EXPLOIT To exploit an opportunity, you take measures to ensure that the opportunity will occur and will be incorporated into the project. Examples of exploiting are: • •

Using more skilled resources on an activity for which the opportunity is expected to materialize; and Partnering with another organization known to provide the opportunity. For example, one company buys another in order to acquire existing marketing and distribution channels for a new line of products.

SHARE You can share an opportunity by choosing a partner who can exploit the opportunity for the partnership’s joint benefit. For example, creating a joint venture with a firm that has the capability to complete a difficult project activity and allowing them a share in the product ownership benefits both the organization that originates the project and the firm that has the expertise. ENHANCE Enhancing an opportunity is the reverse of mitigating a negative risk. To enhance an opportunity, you try to increase the probability that it will materialize, or you magnify its beneficial effects when it does. For example, relocating a firm to a university town can increase its ability to recruit candidates with technical or management ability, and can reduce hiring costs by avoiding extensive searches and expensive relocations.

259

Risk Register: Example of Risk Response Section The worksheet below is an example of the risk response section of the risk register.

260

Minimum Requirements for Managing Project Risk Scope Definition Having well-defined technical objectives based on functional and/or physical requirements: explicit definitions of all tasks necessary and sufficient to accomplish the technical objectives: a work breakdown structure. Experience shows that getting the requirements wrong is a major contributor to project failure. Roles and Responsibilities Having well-defined roles and responsibilities identified by the project manager. When each activity is assigned to a team member who is accountable for it, there is no risk that it will be "lost." Schedule Having a master schedule with company-controlled milestones, criteria and dictionary for milestone completion, documented assumptions, and schedule contingency plan. Explicit milestones clearly understood by all participants in the project limit the risk that the project will fail to meet stakeholder expectations and lose support, miss obligations to provide work products for dependent projects, or lose resources to other commitments. Cost Estimates Having cost estimates clearly connected to the work package definition, with documented bases and assumptions, and justified cost contingencies, derived using a methodical process and associated with specific WBS elements. Clearly associating costs with work packages greatly reduces the risk that unplanned costs will be incurred without producing useful deliverables. Performance Analysis Reporting Having periodic project status reviews, specific parameters for performance analysis, and specifications for data requirement and report frequency. Continual detailed analysis of project performance will give the project manager and sponsor the earliest indicators of whether the project will meet its objectives. Project Funding Having a funding commitment plan. Having secured funding will reduce the possibility that the project will become insolvent.

261

Accounting Having a cost collection system consistent with a time-phased cost budget and cost accounting standard. This is the basic procedure for ensuring that cost reporting is accurate, and to detect and deter fraud. Work Authorization Having a formal work authorization process. By authorizing the start of every assignment, the project manager both conserves the project budget and ensures that the risk of rework due to poor process discipline is minimized. Change Management Having defined thresholds and authority for baseline changes. Simply defining a process and authority for changes to baselines, especially the scope baseline, can greatly reduce the risk that the project will slip out of control if baselines no longer integrate properly and the project runs out of time and money.

Risk Triggers The risk trigger must be periodically monitored to ensure that the risk event is detected promptly. In the ideal case, an automated system monitors the risk trigger constantly and sends a notification to the risk owner when the trigger crosses a risk threshold. In other cases, project management must review the trigger indicator regularly. For example, if the Number of Issues Opened vs. Number of Issues Closed each week increases, the project manager should note the trend at each weekly status meeting. When the number increases for four weeks in a row, she should take action to determine the causes and address the team's failure to close the existing issues at an equal or better rate. She may determine that the product design is seriously flawed, and this is now manifested in design-related issues that are difficult to resolve.

262

Risk Monitoring and Control Risk monitoring involves: •

Tracking changes in risks as the project progresses;

•

Identifying new risks as they develop, and deciding whether or not they were successfully identified and managed before they materialized;

•

Tracking the effectiveness of risk response plans; and

•

Analyzing whether or not risks materialized.

Risk control involves: •

Choosing among alternative risk response strategies;

•

Implementing contingency plans as appropriate;

•

Taking corrective actions;

•

Redistributing resources previously allocated to risk management activities for a particular risk when the associated risk no longer exists; and

•

Requesting changes to budget, schedule, or scope, up to the point of requiring that the project plan be revisited.

BEST PRACTICES Weekly Team Status Meeting As part of the weekly team status meetings, the project manager should require reports on progress in managing risks. Depending on severity, some risks may need to be reviewed as frequently as every day. Monitoring trends in the appropriate risk triggers, for example, Cost Performance Index (CPI) dropping below .90, serves as an indicator or trigger to signal when a risk response plan must be activated. Communicating Risk Assessments to Stakeholders Periodic working sessions for risk identification and assessment can keep the stakeholders apprised of risk-related issues. This can help avoid unpleasant surprises: the project manager will not have to communicate surprising bad news when an identified risk is realized, and the stakeholders' expectations concerning the risk and its impact will have been set properly so that they understand the necessity of the risk response.

263

Records of Risk Metrics A key component of the Risk Monitoring and Control process is recording risk metrics to compare to the associated contingency plans for each risk. The data gathered from risk monitoring helps team members make effective decisions about risks before they occur. Prompt Implementation of Risk Response Plans The main indication that the Risk Monitoring and Control process is being successfully applied is the prompt implementation of risk response plans when risks materialize: although some project tasks may require more time or budget than planned, there are adequate contingency reserves to make up the shortfalls, and the total project schedule and budget are not expected to be exceeded. Learning from the Updated Risk Register The primary output of the Risk Monitoring and Control process is an updated risk register that shows that response plans are current, have been implemented whenever necessary, and have produced the intended results. If there are indications that any project risk is changing or not responding to the response plan, the project manager must ensure that the risk response plan is adjusted to meet the need.

264

Technical Performance Measurement Technical performance measurement is a technique for risk monitoring and control. Measuring technical performance involves reviewing a specific technical parameter against the specifications at the end of each phase. This may include reviewing delivered functionality against specified performance goals according to the project schedule. Any deviations from a planned schedule may signal that a risk has materialized. The diagram below shows how one aspect of a project's technical performance rises from a mid-range level in the Concept and Preliminary Design phases to a higher level in the Detailed Design and Construction Phases.

Sample Technical Performance Chart In this example, the initial analysis shows that the technical parameter fails to meet specifications during the Concept phase that ends in mid-January. The risk is that design activities will not deliver satisfactory performance. The black line represents the plan to improve performance from unfavorable to favorable during the Preliminary and Detailed Design phases, with the intention of proving success by the time of the Detailed Design milestone in April. Further development work during Integration is planned to continue to improve the performance, raising it high enough in the favorable range to provide a sufficient margin.

265

REFERENCES J.T. Brown, "THE HANDBOOK OF PROGRAM MANAGEMENT", McGraw-Hill Companies 2008 T.J. Esque, " NO SURPRISES PROJECT MANAGEMENT", ACT Publishing 1999 PMI, "THE STANDARD FOR PROGRAM MANAGEMENT", PMI, 2008 PMI, "A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE", 4th Edition, PMI 2008 R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010 M.Crouhy, R. Mark, D. Galai, "RISK MANAGEMENT", McGRAW-HILL, 2001 M. Effron, M.Goldsmith, "HUMAN RESOURCES IN THE 21st CENTURY", John Wiley & Sons 2003 J.Fitz-enz, "THE ROI OF HUMAN CAPITAL: MEASURING THE ECONOMIC VALUE OF EMPLOYEE PERFORMANCE", AMACOM 2000

266

Chapter XII Communications Management Planning Communications Planning involves identifying the communications needs of project stakeholders and determining how best to meet these needs. The planning process should produce a communications management plan that identifies who needs what information, when they will need it, how it will be given to them, and by whom. The Communications Planning process results in a communications management plan that supports the project throughout its life. The following pages will cover: •

Communications Planning Process;

•

Definition of Communications Planning;

•

Importance of the Communications Planning Process;

•

With Whom Does the Project Manager Communicate?

•

Communications Planning Process Considerations.

Importance of the Communications Planning Process An effective communications management plan is critical to the success of any project and provides the following benefits: •

Forms the foundation for coordinating project execution;

•

Enables successful stakeholder management;

•

Supports the establishment of a common team purpose and direction;

•

Addresses the needs of complex and geographically dispersed projects; and

•

Defines the distributed team and keeps all stakeholders focused on project tasks.

With Whom Does the Project Manager Communicate? All stakeholders need some level of ongoing contact with the project. Project managers will find themselves in the center of a communications web that requires them to communicate with people in various roles. •

Executives or sponsors provide direction on company policy or project parameters. They expect status reports from the project manager;

267

•

Functional managers provide resources to the project and want to know how their people are doing and when they will be available to do other work. They expect information on the project direction;

•

Customers provide direction and need to know if the project is on track. They expect to receive progress reports; and

•

Project team members need directives from the project manager. They in turn provide status reports.

Project staff need to know their duties, responsibilities, authorities, and how they are performing.

The information requirements for the various stakeholders will differ in terms of level of detail, communication methods and formats, and frequency of communications. These variations must be worked into the communications management plan. Communications Planning Considerations Within a complex, distributed project environment, a project manager must analyze information flow throughout the organization and map this into a viable project communications management plan. To increase the chance of project success through managed information flow, the project manager has many options to consider. Some of the key considerations are: •

Should the approach be centralized or distributed?

•

How will the communications plan help to manage stakeholders?

•

How can technology be used to support the plan?

•

Should the Approach be Centralized or Distributed?

268

Centralized A project with a strong centralized information distribution node at its core will have all information flowing through a central control point. This approach may serve a high-risk environment requiring tight management and control. On the other hand, it may introduce a single point of failure into the project communications network. When the project manager is not available, or leaves the project at a critical juncture, progress may suffer. Distributed A distributed approach to communications management may allow the simultaneous flow of information between different project team members. It may also allow for redundant, flexible communication patterns in the event of critical resource availability issues. This approach might create a structural barrier to tight, central coordination. How Will the Communications Management Plan Help to Manage Stakeholders? Communications Planning uses tools and techniques to identify all project stakeholders and their communications requirements, and to manage their issues to ensure project success. The project manager must consider the impact of change on project stakeholders and build a plan that addresses the potential for positive and negative stakeholder reaction. In doing so, the project manager should keep in mind three primary Project Communications Management objectives: 1. Enhance the impact of positive stakeholders on the success of the project. 2. Control or diminish the impact of negative stakeholders on the success of the project. 3. Convert negative stakeholders into positive stakeholders. The communications management plan should provide a healthy framework from which to coordinate the individual efforts and interests of stakeholders. It should establish a mutually beneficial agreement of interests and negate any unproductive or "negative" politics that may serve individual interests.

269

How Can Technology Be Used to Support the Plan? Delivering the right information to the right people, at the right time, and in a useful format means using technology effectively. The project manager needs to consider how technology can enhance information flow whenever it is needed. Enterprise Environmental Factors on communications planning Enterprise environmental factors include external and internal influences that can impact the success of a project. These factors include: •

Cultural and structural issues that may support or hinder a project;

•

Industry standards;

•

Infrastructure;

•

Human resources;

•

Marketplace conditions;

•

Stakeholder risk tolerances; and

•

Project management systems and software.

It is important to note that stakeholder risk tolerances constitute a significant, if not a majority share of the enterprise environmental factors. Faced with stakeholder issues, the project manager should consider how to leverage stakeholder support to combat negative stakeholder reactions. Organizational Process Assets and the communications planning Organizational process assets represent the toolbox from which the project manager can select the tools to implement the project. Organizational process assets may include: •

Work processes and procedures;

•

Knowledge bases;

•

Subject matter experts;

•

Lessons learned; and

•

Historical information.

270

Ultimately, the communications management plan represents the particular combination of organizational process assets that the project manager brings to bear on relevant enterprise environmental factors. In other words, the intersection of the communications management plan, organizational process assets, and enterprise environmental factors represents the project manager's organizational savvy, or the ability to "get things done" in the organization or within the project team. The first input, enterprise environmental factors, and the second input, organizational process assets, work together for Communications Planning. Project Scope Statement The third input to the Communications Planning process is the project scope statement. The project scope statement is a key input to project Communications Planning. The project scope statement results from the Scope Definition process and enables a shared knowledge of project scope among stakeholders. The project scope statement contains the following elements necessary for planning effective project communications: •

Project objectives;

•

Description of intended outcome;

•

Project requirements, including deliverables and stakeholder needs analysis;

•

Milestones;

•

Cost estimates;

•

Risks;

•

Constraints; and

•

Assumptions.

Constraints are factors that might limit the options or impact of project communications. Constraints may be related to available technology, expertise, time, budgets, or time zone differences.

271

Assumptions are factors that, for planning purposes, are considered to be true, real, or certain. They include: •

Immediacy of the need for information. How frequently is information needed to ensure success and control?

•

Expected project staffing. How will communications needs change as the project team expands to include more people, people with varying skills, and people at different levels in an organization?

•

Length of the project. How will communication's need change over the life of the project?

Project Management Plan The fourth and final input to the Communications Planning process is the project management plan. The project management plan defines, integrates, and coordinates subsidiary plans. It details how the project will be executed, monitored, controlled, and closed. Like the project scope statement, the project management plan contains constraints and assumptions that will impact Communications Planning. Communications Planning Process available tools Two categories of tools and techniques support the Communications Planning process: •

Communications requirements analysis; and

•

Communications technology.

These tools and techniques are explained on the pages that follow. Communications Requirements Analysis Analyzing communications requirements gives the project manager a clear idea of the type, format, and value of the information stakeholders need. The project manager must pay particular attention to communications that contribute to project success. Information typically needed to determine project communications requirements includes: •

Organization charts;

•

Project organization and stakeholder responsibility relationships;

•

Disciplines, departments, and specialties involved in the project;

•

Logistics information, including how many people will be involved with the project at various locations;

•

Internal information needs (e.g., communicating within the organization);

272

•

External information needs (e.g., communicating across organizations); and

•

Stakeholder information.

A Framework for Requirements Gathering There are a number of methods for requirements gathering, but for communications requirements, most organizations follow this general framework: 1. Use the scope documentation and collective team knowledge about the organization to identify affected roles and responsibilities within the organization. Typically, these roles may include the project manager, sponsor, customer, performing organization, and project team members. 2. Identify individuals who are currently performing the affected roles either formally or informally. 3. Interview these individuals as to their own expectations regarding the project outcome and communications requirements. 4. Solicit references to other, unidentified stakeholders from the interviewees. 5. Interview stakeholders. 6. Incorporate results into the scope documentation. 7. Repeat steps 1-6 as necessary to link a changing scope document to the communications management plan. Communications requirements should not be blindly accepted. Instead, they should be assessed in terms of potential impact on the project and incorporated into the communications management plan accordingly. Internal or External Stakeholders For analyzing communications requirements, it may be helpful to distinguish internal stakeholders from external stakeholders. Depending on the project and organization, there are several ways to make this distinction. •

Internal stakeholders could be those stakeholders who are funding, planning, managing, and contributing effort to the project, while external stakeholders could be those who are affected in other ways.

•

Internal stakeholders could be employees, while external stakeholders could be outside contractors, vendors, and others external to the performing organization.

•

Internal stakeholders could be the core project team, while external stakeholders could be all other interested or affected parties.

273

Communications Technology The second of the two types of tools and technologies that support Communications Planning involves communications technology. The project manager may consider a wide range of communications technologies to enable and enhance information flow between stakeholders. The project manager must be careful to match the technology solution to stakeholder needs. The communication method must be easy to access and use, and must deliver positive results. Other factors that may influence the choice of technologies include: •

The urgency of the need for information - How soon and how often is the information needed?

•

The availability of technology - What systems and technologies are available to the stakeholders?

•

The expected project staffing - Will the project participants be able to use the communications systems immediately, or will training be required?

•

The length of the project - Will the available technology be upgraded or changed before the project is over? Is it worth implementing a new technology for a short project?

•

The project environment - Does the team meet and operate face to face or in a virtual environment?

•

Organizational technical literacy - What are the skills levels of the performing organizations and external partners?

•

Compatibility of systems for transfer of files - Are there differences in technology, restrictions on the flow of encryption technology, availability of technology across national borders, or bandwidth availability?

•

Organizational acceptance - Are there issues to consider? For example, what about a centralized "non-silo" project information repository open to appropriate stakeholders?

Communications Planning Process expected outputs The Communications Management Plan There is one output of the Communications Planning process: the communications management plan. After defining the project scope, identifying the key stakeholders, and analyzing their communications needs, the project manager may begin to compile the communications management plan. The communications management plan documents the format, content, and conventions for project communications. It should answer the questions of who, how, when, and what frequency; and it should be compatible with the capabilities and culture of the organization.

274

The communications management plan provides: •

Stakeholder communications requirements;

•

Information to be communicated, including format, content, and level of detail;

•

Person responsible for communicating the information;

•

Person or groups who will receive the information;

•

Methods or technologies used to convey the information, such as memoranda, email, and/or press releases;

•

Frequency of the communication, such as weekly;

•

Escalation process - identifying timeframes and the management chain (names) for escalation of issues that cannot be resolved at a lower staff level;

•

Method for updating and refining the communications management plan as the project progresses and develops; and

•

Glossary of common terminology.

To help organize the communications management plan, a project manager can use a communications planning matrix, which is explained on the next page.

275

The Communications Planning Matrix The communications planning matrix organizes each stakeholder group and specifies what, when, and how project elements should be communicated. A column for stakeholder role helps to identify why each individual is listed as a stakeholder. A response column can identify each stakeholder's expected response. The communications planning matrix can become part of the overall project plan, and all or relevant parts should be shared with the project stakeholders. Once completed, it can serve as the basis for the formal communications management plan or, in certain cases, it might be the plan itself. Shown below is a partially completed matrix. It is a simple matrix for organizing the project communications. Stakeholders

Role

What?

When? How?

Response

Internal John, Peter, Charles, Developer Project Scope Statement Kickoff Meeting Acceptance External Keith, Liz, Mary

Contractor SOW

Week 3 Meeting Bid

In the example above, the stakeholder column could be further divided into roles, responsibilities, names, and other indicators, such as internal and external. Once completed, the matrix can serve as the basis for the written plan, or it may be the plan itself.

276

Another Communications Planning Matrix This sample shows how a communications planning matrix can be configured into a different view that facilitates managing specific project communications. Medium (How)

Overview / Description

Content (What)

Frequency (When)

Audience (Who)

• Project developments Team Meetings

Chaired by PM to update team and facilitate progress

• Status updates

Weekly

Developers

• Issues • Decisions • Issue • Status • Owner

Issues/Issue Log

Maintained by PM to • Potential impact track and resolve issues • Date logged • Closure deadline • Date closed

Risks/Risk Log Status Report Change Requests/Change Request Project Plan Project Control Folder

277

Project team As needed Project sponsor

Communications Roles/Responsibilities of Stakeholders This simple role/responsibility chart is another way to clarify communications responsibilities. The project manager should use a tool like this early in the project to define which stakeholders are involved in creating the communications deliverables.

Project Stakeholders

Communications Deliverables User Guide

Louis

Training Materials

Status Reports

R

Charles

R R

John

C

C

Peter

X

X

R

Legend Communications Responsibility R - Responsible C - Contributor X - Receiver

278

Building Commitment When developing the communications management plan, key factors to consider are the actual commitment, as well as the desired commitment, of the individual stakeholders. Both actual and desired commitment are a function of the stakeholders' interest in project success as well as their ability to affect the project outcome positively or negatively. The gap between actual and desired commitment becomes the basis for creating the communications management plan. The communications management plan describes the set of communications activities that must take place to shift the stakeholder commitment from the actual to the desired state, for example: A group of end users considers the project a threat to their current level of job flexibility, and they are passively resisting the implementation of a new tool. •

The communications management plan should incorporate a plan to inform the end users that their concerns have been understood and incorporated into the project scope; and

•

In this way, the project manager can alleviate some of the end users' anxiety, and perhaps transform them into positive project stakeholders.

Stakeholder End Users

Actual Commitment

Communications Plan

Desired Commitment

Resistant

Pre-installation seminar and user training

Supportive

279

Changing the Communications Plan The communications management plan must be continuously assessed and reassessed for suitability throughout the project life cycle. •

Risk triggers, unforeseen events, and scope changes are some of the factors that might cause a project team to re-evaluate communications activities;

•

Other triggers for changes to the communications management plan during a later phase might include addition of a new stakeholder, discovery of additional requirements, changes to other planning outputs (scope, HR, cost, etc.), or organizational resistance to planned information flows;

•

In the case of a troubled project, the project manager might opt to delegate specific communications duties to allow more time to bring the project back into accordance with the baseline;

•

The project manager must be vigilant to ensure compliance to the communications management plan. One option might be to audit documentation to see that it is complete and stored in a central repository;

•

As the team moves through the stages of team development and enters the highperforming stage, the project manager might choose to relinquish the role of central communications node, and distribute some of the responsibilities for implementing the communications management plan; and

•

Decentralizing project communications would require the project manager to give up some project control, but would allow quicker team response via multiple information channels.

Ethics and Integrity in the Communications Management Plan Project managers must use ethics and integrity as they balance the communications requirements of their stakeholders with the need to move the project forward. •

Potential conflicts might arise when stakeholders ask for information that may not be required to perform their function; and

•

Other conflicts might arise when the need for project information by an external partner is contrary to the interests of the performing organization. For example, there might be a request for information that could compromise the market interests of the performing organization.

280

The Communications Management Plan and Complexity of the Project Depending on the complexity of the project and potential stakeholder issues, the project manager might include the following additional components in the communications management plan: •

A process for escalation of issues that cannot be resolved at a lower staff level;

•

A method for updating and refining the communications management plan as the project progresses; and

•

Guidelines for project meetings, presentations, and reports. These guidelines might include required attendance lists, appointed meeting management roles, and an approved minutes of meeting format.

The Communications Management Plan and International Projects Particularly on international projects, and those using new personnel or an unfamiliar approach, terminology definitions and standards will help to prevent possible miscommunication. Examples of this might include: •

Setting standards for date input - July 4, 2000 can be represented as 7/4/2000, 4/7/2000, or 2000/4/7;

•

Setting standards for time notation -Time can be written as 8:00 p.m. or 20:00 to avoid scheduling issues. Time zones should always be specified. In international projects it may be helpful to communicate using Greenwich Mean Time, as it is observed around the world; and

•

Specifying a language for all public correspondence -If that is not feasible, plan into the system a way to translate correspondence into the underrepresented language groups.

281

Communications Plan Checking for Completeness The checklist below may help you assess the completeness of a communications management plan. If the answers to several of the questions below are consistently understood throughout the organization, it may not be necessary to address them in the communications management plan.

Description 1.

Is the level of detail in the communications management plan appropriate to the risk profile of this project?

2.

Have you identified every stakeholder who may be affected by the successful or unsuccessful completion of this project?

3.

Have you assessed stakeholder requirements with respect to scope and project communications?

4.

Have you assessed stakeholder levels of interest and impact on your project well enough to categorize the stakeholder as negative or positive?

5.

Do you have suitable communications policies in place to help neutralize the influence of negative stakeholders? Do you have suitable communications policies to safeguard the continued support of the positive stakeholders?

6.

Have you received acceptance or approval (as appropriate) of your proposed communications procedures?

7.

Have you incorporated outputs from the Risk Management Knowledge Area into your communications management plan to adjust communications level commensurate to the level of realized risk?

8.

Is all confidential information protected from unauthorized interception? Is your plan for information flow in compliance with national law and corporate regulations?

9.

Is your communications policy suitably flexible to work within the various organizational and national cultures on your project team?

10.

Has a suitable central location been established for storing all project documents that are relevant to the team as a whole or that will need to be incorporated into the project archives?

282

Information Distribution Information Distribution includes collecting, sharing, and delivering project information to stakeholders in a timely manner across the project life cycle. It is the process of executing the communications management plan adapting the plan to meet changing requirements, and responding to unanticipated information needs. Information Distribution is the Executing process that implements the communications management plan. Effective Information Distribution ensures stakeholders' receipt of information in a timely manner. Information Distribution includes: •

Implementing the communications management plan;

•

Responding to unexpected information needs;

•

Using communications skills;

•

Using information distribution media;

•

Implementing and operating information storage and retrieval systems;

•

Documenting lessons learned; and

•

Triggering changes to the project communications and project management plans.

As project activity occurs and communications needs arise during the project, Information Distribution ensures that appropriate stakeholders receive the information they need. Effective Information Distribution The project management team uses Information Distribution tools and techniques to communicate project information. In order for the tools and techniques to be effective, the project communications should have the following characteristics. TIMELINESS Timeliness has a major impact on the value of information. Information received too late may be worthless, or worse, it may threaten the project success. A project manager must ensure that information flows in a timely fashion. This is especially critical when changes to project requirements or scope affect a project in development, or when tasks are being performed in parallel on fast-track projects.

283

CLARITY A project manager is responsible for transmitting information clearly and in a form that is easily deciphered and analyzed. Clarity also means delivering only the information that is needed, and nothing more. All too often, project managers overwhelm stakeholders with unnecessary information. The risk in doing so is that critical, need-to-know information may be buried or ignored. UNDERSTANDING A project manager also needs to ensure that stakeholders receive and understand the information transmitted to them. There are a number of obstacles ("noise") that may interfere with the flow of information, including information overload, language issues, acronyms, and jargon. APPROPRIATENESS The method of delivering information to stakeholders must be appropriate to the information being communicated. Project managers use a variety of communication vehicles to transmit project information including meetings, presentations, e-mail, telephone calls, casual conversations, memoranda, databases, etc. To be effective communicators, project managers need solid communications skills and the ability to select a means of communicating that is appropriate to the message and the stakeholder. Barriers to Effective Information Distribution Barriers can interfere with sending or receiving messages through methods such as: •

Face-to-face communications;

•

Telephone communications;

•

E-mail; and

•

Written documents.

For effective Information Distribution, the project manager must devise methods to overcome these communication barriers. Such barriers include: •

Information overload;

•

Language issues;

•

Acronyms; and

•

Jargon.

284

Cultural Factors and Communications Decisions In addition to what to say and how to say it, project managers must be aware of cultural factors that may impact communications decisions. These factors may influence the use of one form of communication over another, or multiple versions of the same message may be distributed to various personnel. Formal or Informal Formal communications usually involve planning and documentation, while informal communications can be spontaneous and casual. Some organizations demand formality, while others are very informal and allow a free flow of information. Written or Spoken This decision may be based on the need for confidentiality. A sensitive political issue might best be addressed in a closed-door discussion with very little formal documentation. A project scope change, on the other hand, would best be addressed with extensive written documentation of the change. Vertical or Horizontal Vertical communication flows up and down the organization, while horizontal communication is with peers. The particular information need often determines the direction of the response. Participatory or Hierarchical Some decisions may be reached through a participatory exchange of ideas between two or more stakeholders. Others may require a communications path through levels of authority. Public or Private Issues of confidentially and security, as well as the subject of the communication, may influence this decision. Project successes and praise should be shared in public, as recognition for good work is a motivator for many project team members. Any criticism that needs to be shared with a project team member should be done in a private meeting. Negative feedback to an individual should never be given in a public forum.

285

Language Issues Communications to stakeholders speaking other languages may require written documentation in simple, unembellished language for clarity and later reference. Some icons may be interpreted differently in various cultures, or not even recognized, like the mailbox icons often found in American technical manuals. Information Distribution Process inputs Communication Management Plan The communications management plan should define most of the communications needs for each stakeholder group, as well as how those needs will be met by information distribution. The plan should address standard project communications as well as unique requirements identified in the stakeholder analysis. Examples of these types of communications include: •

Project status reports;

•

Forecasts;

•

Contract administration correspondence;

•

Work performance information;

•

Task coordination;

•

Risk trigger status;

•

Requirements (new versions); and

•

Performance appraisals.

A comprehensive communications management plan might also include details on handling ad hoc information requests, although these are often handled on an as-needed basis. The plan may also cover security topics, such as who has the right to access and share project information. Finally, the communications management plan must ensure that information is delivered clearly, on time, in an appropriate form, and by an appropriate method. Tools and Techniques for the Information Distribution Process Information Distribution uses a wide range of communications tools and techniques. Some are technology-based solutions, some are communication methods, and others are basic communications skills.

286

Communications Skills The project management team needs strong communications and other interpersonal skills to effectively distribute information to stakeholders. Research indicates that these so-called "soft skills" are the foundational building blocks that enable successful projects. The project manager should make sure that collectively the team possesses the skills to succeed in the following aspects of Information Distribution: •

Gathering, using, and referencing information;

•

Selecting the best medium for the audience and the message;

•

Using the selected communications media effectively by combining media to strengthen the impact of the message, when appropriate; for example: o

Using body language and tone of voice to help make a point non-verbally

o

Using graphics, charts, and illustrations to simplify complex information

•

Overcoming the challenges of the sender-receiver model by planning for physical and cultural barriers and implementing effective feedback loops;

•

Saying it positively, convincingly, and directly using writing and presentation skills, meeting management techniques, and interpersonal skills such as conflict resolution;

•

Mastering the art of persuasion by knowing the audience and building a case with facts, dates, events, and other objective, substantive information; and

•

Understanding "emotional intelligence," which relates to how the project manager recognizes and deals with the emotional states of stakeholders by factoring that into communications.

287

Meeting Management A critical skill that falls under the general communications skills category is meeting management. Productive meetings require planning, active participation, and follow-up. True meeting management includes soliciting sincere participation and moderating input among participants. Tips for Planning a Meeting •

Plan meetings only when necessary;

•

Ensure that all essential parties are able to attend;

•

Inform each party of his or her expected roles;

•

Communicate the purpose of the meeting and the meeting agenda in advance; and

•

Communicate the need to prepare, if necessary.

Tips for Facilitating a Meeting •

Begin meetings with a brief report of actions resulting from the last meeting or with a statement of purpose for the current meeting;

•

Focus on the agenda items;

•

Avoid distractions. Document important but unrelated points rose at the meeting on a white board or flipchart visible to all the participants (often called a "parking lot"). If appropriate, return to these items after completing the agenda items;

•

Ask for feedback from specific participants at appropriate times. The types of feedback solicited should be based on the participant's expertise, role, and position;

•

Ensure that the right person provides input when needed; and

•

After discussing each topic or at the end of the meeting, summarize and document decisions and action items.

Information Gathering and Retrieval Systems Systems for collecting information from team members should be easy to use and efficient for reporting project information. Information gathering and retrieval systems give the project team access to appropriate documentation in a timely manner. Examples of these systems are:

288

•

E-mail systems;

•

Electronic databases;

•

Project management software;

•

Filing systems that allow access to technical documentation, drawings, and other project information; and

•

Web-based content management systems.

Information gathering and retrieval systems should be efficient for both information providers and receivers. They should also provide security where it is needed. Information Distribution Methods Many tools and methods used in information gathering and retrieval may also be used for sharing and distributing information. Information distribution methods include: •

Project meetings;

•

Hard-copy document distribution;

•

Shared access to networked electronic databases;

•

Electronic media including fax, e-mail, voice mail, videoconferencing, project intranet, and web publishing; and

•

Electronic project management tools such as software, portals, and collaborative work management tools.

Selecting Information Distribution Methods Depending on the needs of the project, the stakeholders, the information, and the environment, Information Distribution may be formal or informal, written or spoken, manual or automated. For developing the communications management plan and responding to ad hoc requests, the project team members need to know which tools and techniques are best for communicating the various elements of project information. In a world where there is a phone in every pocket and a computer in every home and office, the options for communicating are expanding every day. Selecting the appropriate method for delivering information should take into account the pros and the cons of three basic forms of communication: •

Face-to-face communications;

289

•

Hard-copy communications; and

•

Electronic communications.

Pros and Cons of the Three Basic Forms of Communication Each of the three basic forms of communication has pros and cons. Face-to-Face Pros Personal; Conveys feelings as well as information; and Provides immediate feedback. Useful for: Confirming understanding; Gaining trust; and Conveying bad news or sensitive information. Cons Difficult to coordinate; Costly; and Physical and time zone issues.

Hardcopy Pros Provides a standard reporting format; Becomes an information record; and Is portable and readable without technology. Cons Information can be lost or not read; and Sometimes time-consuming to produce.

Electronic Pros Quick, immediate; Useful for: Shared information needs; Distributing large amounts of data; Widespread audience; Maintaining a record. Cons Inappropriate for confidential and sensitive information Requires tool compatibility May require training

290

E-mail Communications Tips E-mail and other electronic forms of messaging are rapidly growing in popularity. But like any communication tool, they can easily be misused and misinterpreted. Following are some tips on using e-mail effectively. E-mail Tips Content

Frequency

Do:

Don't:

•

Use e-mail for quick, straightforward, and brief communications

•

Send long e-mails. Try to limit the message to one screen

•

Use e-mail for sending documents, forwarding comments, and copying from electronically stored documents

•

Send sensitive information via e-mail

•

Use e-mail to deliver bad news

•

Stress the email system by sending very large attachments (such as documents rich with graphics) to multiple recipients

•

Leave the recipient guessing why you sent him this communication

•

Use discretion about what is communicated via email. Be careful to communicate only what is appropriate for public consumption

•

State clearly and early what you need from the recipient. Include any background after the request

Do:

Don't:

•

Recipients

Context

Monitor and control the volume and frequency of messages sent via e-mail

Do:

•

Send too many e-mails

•

Rely too heavily on e-mail or use it as a substitute for face-to-face communications

Don't

•

Limit recipients to those who need to know

•

Send e-mails to too many people

•

Use copy and blind copy options only as necessary

•

Assume that a read receipt means the message was read and understood

•

Ask for feedback when necessary to ensure understanding

•

Send "For Your Information" notes that require no action, unless they've been requested as part of the communications management plan

•

Maintain accurate and up-to-date distribution lists

•

Ensure that all recipients on a distribution list receive the information being sent

Do:

Don't:

•

Realize that e-mail lacks visual and verbal cues and can thus be misinterpreted. In general, e-mail tends to read more literally and seem more emotionally charge than is intended

291

•

Emphasize words for irony and sarcasm. Emphasis may be misinterpreted as anger or shouting

•

Use small pictorial elements to indicate mood. Do not show in recipients' systems, and they may appear unprofessional

Lessons Learned Process Documenting lessons learned from the current project for the future benefit and enrichment of the organization's process assets is a requirement of a good communications management plan. A lessons learned session has the following characteristics: •

Focuses on identifying project successes and project failures;

•

Includes key internal and external stakeholders;

•

Includes recommendations for improving future project performance;

•

Focuses on technical, managerial, and process aspects of a project;

•

Occurs at any time in the life of a project;

•

Increases project management effectiveness and efficiency;

•

Helps build strong project teams;

•

Promotes the development of business skills;

•

Provides: o

Updates to the lessons learned knowledge base

o

Updates to the risk management plan

o

Overall product and service improvements.

Information Distribution Process expected outputs The outputs of the Information Distribution process include: •

Organizational process assets (updates); and

•

Requested changes.

In the project environment, updating organizational process assets means adding material to the organizational knowledge base for use in future projects. Requested changes in the Information Distribution process may, in turn, trigger changes in the communications management plan and in other planning outputs. These changes are handled by the Integrated Change Control process.

292

Organizational Process Assets Updates Examples of organizational process assets (updates) include: •

Lessons learned documentation - This documentation includes the causes of issues, reasoning behind the corrective actions chosen, and other types of lessons learned about Information Distribution. Lessons learned are documented to make them part of the historical database for both the project and the performing organization;

•

Project records - Project records can include correspondence, memos, and documents describing the project. This information should, if possible and appropriate, be maintained in an organized fashion. Project team members should also maintain records in a project notebook;

•

Project reports - Formal and informal project reports detail project status and include lessons learned, issue logs, project closure reports, and outputs from other Knowledge Areas;

•

Project presentations - These include presentations made by the project team members to project stakeholders. They generally provide a record of the information that was relevant to the needs of the audience;

•

Feedback from stakeholders -Information received from stakeholders concerning project operations can be distributed and used to modify or improve future performance of the project; and

•

Stakeholder notifications -These contain information provided to stakeholders about resolved issues, approved changes, and general project status.

Performance Reporting Performance Reporting is a Monitoring and Controlling process. It involves data collection, analysis, measurement, and reporting of work performance on a regular basis. With Performance Reporting, the project manager can inform stakeholders about project progress, status, and forecasts. With Performance Reporting, the project manager can indicate to stakeholders: •

How resources are being used to achieve project objectives;

•

What the project team has accomplished;

•

Where the project currently stands; and

•

Where project results will be in the future.

293

Components of Performance Reporting Performance Reporting has three key components: •

Status reporting - This describes the current state of the resources being consumed by the project, for example, status related to schedule and budget metrics;

•

Progress reporting - This describes results such as the percentage of completion that a deliverable has reached, or what is completed versus what is in process and what is not yet started; and

•

Forecasting - This predicts future project status and when planned events are expected to occur.

Performance Reporting generally provides and integrates actual-to-date and forecasted information about the following: •

Scope;

•

Schedule;

•

Cost; and

•

Quality.

Although cost and schedule produce the questions most commonly encountered by project managers, there are other aspects of the project that may interest stakeholders, for example, risk management or procurement. To ensure the availability of current performance information, the project manager may schedule performance reports on a regular and frequent basis. Performance reporting can also be done on an exception basis to fulfill specific information requests or to evaluate performance in response to an event. Performance Reporting Objectives Performance Reporting helps the project manager achieve project control objectives, such as: •

Knowing where the project is in relation to established baselines (cost, schedule, scope, quality, etc.); and

•

Predicting how the completed project will relate to the project objectives.

Specific criteria should be met to ensure the effectiveness of Performance Reporting. Performance Reporting should be: •

Timely - identifying problems in time for corrective action

•

Accurate - measured against established baseline data

294

•

Complete - providing all the data for decision-making

•

Useful - warning of problems or trends in time to take corrective action

•

Easy to understand - ensuring that the receiver comprehends the sender's message

•

Balanced - benefits of reporting each type of information outweighing the costs of collecting, analyzing, and presenting it

Timely, Accurate, and Complete Information There is no question that project success depends on Performance Reporting that is timely, accurate, and complete. The sooner a variance is detected, the easier it is to correct or to compensate for its potential outcomes. Decisions based on late, inaccurate, or incomplete information are extremely risky and can even harm the project further. •

Weekly status meetings can force information to be timely. As the project progresses, status reporting may occur at different intervals as criticality and timeliness require;

•

Accuracy comes from correctly establishing baseline and performance measurement techniques. The project manager must establish reporting standards for data collection, analysis, and validation; and

•

Completeness combines the right information with the level of detail required for variance investigation and analysis, and ensures that no work performance problems go unnoticed.

Useful Information Data and information are not the same. Data is easy to generate with today's project management tools, but may not provide insight about the real status of the project. •

Data must be converted into useful information;

•

In order for performance reporting to convey useful information, the project manager must identify the needs in the planning stage; and

•

The list can be modified later, but an initial identification of reportable data elements begins to deal with the volume of available data.

295

Easy to Understand Information Project managers should know their audience and deliver project status to them in an appropriate format. The communications management plan should identify who receives what information, as well as the format of the information delivered. •

The information presented must be useful and needed by that audience, based on each member's function or role;

•

Formatting the information in a concise and useful way is part of the reporting process. Different stakeholders will need different types of information and different levels of detail, as documented in the communications management plan;

•

Presentations should illustrate status with an up-to-date snapshot of project information tailored to the audience's needs; and

•

Common status reporting tools include benefit/cost tables, Gantt charts, and earned value indices.

Balancing Costs and Benefits As with many aspects of project management, the benefits of reporting each type of information should be greater than the costs of collecting, analyzing, and presenting it. For example, the cost of implementing an integrated reporting system must be balanced against the value of the efficiency gains it may offer in handling the information it addresses. Performance Reporting Process Inputs The diagram on the previous page defined these inputs to the Performance Reporting process: •

Work performance information;

•

Performance measurements;

•

Forecasted completion;

•

Quality control measurements;

•

Performance measurement baseline information from the project management plan;

•

Approved change requests; and

•

Deliverables.

Minimum requirements for Performance Reporting demand only that workers report work performance information.

296

For more useful and complete reporting, the project manager should look at metrics or project elements that could have an impact on the project. Quality metrics, risk monitoring and controlling elements, and technical performance measures are items that a project manager should consider for meaningful, actionable performance reports. Work Performance Information The minimum requirement for performance reporting is work performance information. Work performance information is compared to project baseline information from the project management plan and other control documents (such as the quality management plan) that specify metrics and standards for the associated project activity. By comparing status to the project management plan and other standards, the project manager can determine progress and project future outcomes.

297

Additional Inputs to Performance Reporting The table below identifies additional Performance Reporting inputs beyond the minimum requirement of work performance information.

Input Performance measurements

Description Performance measurements may include the following: Quality measurements

These may be run charts, statistical process control charts, and other Quality Planning outputs.

Risk monitoring and controlling elements

These include identified risks and risk mitigation elements that may affect performance, cost, or schedule.

Technical performance measurements

Technical Performance Measurements (TPMs) are used by some industries to track how well the product is achieving critical performance parameters. Depending on the product, the metric being tracked could be weight, power consumption, fuel consumption, power output, throughput, production price, utilization percentage, capacity, or operational use date. Typical examples are:

Other planned baselines

•

Lines of Code (LOC)

•

Labor hours

•

Line of Balance (LOB)

Forecasted completion

This includes EAC (Estimate at Completion) values and ETC (Estimate to Complete) values calculated or reported by the performing organization.

Quality control measurements

These are the results of QC activities related to quality standards and processes of the performing organization.

Project management plan (Performance measurement baseline)

Approved change requests Deliverables

The performance measurement baseline is a part of the project management plan, and is an approved set of measurements and parameters used as a basis for comparing project execution measurements. Typical baseline measurements include scope, cost, and schedule parameters, and sometimes technical and quality measures. These are change requests that have been processed and approved through the Integrated Change Control process. Deliverables provide a verifiable measurement of project performance. Project performance is easily measured by checking the production of key deliverables against a predetermined project schedule.

298

Inputs Affecting Performance Measurements Approved change requests, deliverables, and quality control measurements are all factors that can affect performance measurements. •

Change requests - When a baseline is changed through an accepted change request process, the Performance Reporting mechanisms will also need to be adjusted and aligned with the communications management plan;

•

Deliverables - Deliverables are a verifiable measurement of project performance. Project performance can easily be measured by checking the production of key deliverables against a predetermined project schedule; and

•

Quality control measurements - These are the results of quality inspections to ensure compliance with the quality standards documented in the quality management plan. Tracking completed deliverables may be an irrelevant progress check if the deliverables are not consistently delivered to accepted quality standards.

Performance Reporting Process Tools Performance Reporting tools help the project manager gather, analyze, organize, and present the reporting information required by stakeholders. The Performance Reporting tools are displayed in the table below.

Tool

Description

Information presentation tools

These include software applications with reporting capabilities, spreadsheet analysis, and graphic output, as well as other automated and manual presentation tools.

Performance information gathering and compilation

These include manual filing systems, electronic databases, project management software, and other storage and retrieval systems for project documentation.

Status review meetings

These are meetings that are scheduled to exchange information about project developments.

Time reporting systems

These systems record the time expended on the project.

Cost reporting systems

These are systems that record and track costs incurred on the project.

299

Status Review Meetings Status review meetings, also known as status or progress meetings or status reviews, are meant to determine and assess project status, and to evaluate progress against the baseline plan. Status reporting also provides a wealth of historical data, which is useful when closing a project and planning future projects. Status reviews are typically used in conjunction with other Performance Reporting techniques to assess progress and issues regarding: •

Scope;

•

Schedule;

•

Cost;

•

Quality;

•

Risk (if required); and

•

Procurement (if required).

Frequency of Status Review Meetings Various factors may affect the frequency of status reviews. Due to the progress of the project, for example, a weekly meeting, which was appropriate in the beginning of the project, may be inadequate later. Or, data that is unavailable until a monthly accounting cycle ends or an important test or review has been conducted may force the review to occur less frequently. The critical nature of the parameter being measured will also influence or dictate how often a parameter is sampled or measured. For example, the crew of an aircraft in flight may not check the instruments often; however, the same crew frequently checks instruments during takeoff and landing. Projects will also go through phases in which data will need to be checked at intervals different from those originally planned, and the required data will also be different at various times in the project. Required Data for Status Reviews Status reviews should always give the project manager a clear understanding of current project status. Required data for status reviews includes: •

Scheduled and unscheduled work accomplished during the reporting period;

•

Start and finish dates;

•

Days expended/days remaining; and

300

•

In-process work o

Effort expended and remaining;

o

Estimated effort to complete.

As a minimum, status information should clearly communicate work accomplishments and the status of work in progress. Variances should be identified, if possible, including the cause of the variance and the impact on the project. Any corrective actions to eliminate or reduce the variance from the project management plan to acceptable limits should also be noted. Remember that data collection is not the result, but the beginning of numerical information conveyed in the report. For data to be converted into meaningful information, it must be analyzed and presented in terms that are clearly linked to project success criteria, and it must set appropriate expectations. Analysis Techniques Two techniques commonly used to obtain work performance information from reported data include: •

Variance analysis; and

•

Trend analysis.

Variance Analysis Variance analysis allows the project manager to identify differences between the work results and the project management plan. It compares the differences between actual project results to planned or expected results (baseline values and current or projected results) and considers each performance measure of cost, schedule, scope, resource, quality, and risk against stakeholder expectations and tolerance levels. The analysis can cover the current period or a cumulative period, or can be used for status extrapolation comparisons. Variance analysis can quickly detect deviations from desired baselines. Trend Analysis Trend analysis is a forecasting technique that looks at performance to date and identifies a pattern of results that indicates a trend. The trend is used to forecast future results and to determine whether performance is improving or deteriorating. Performance Reporting Process outputs Performance Reporting organizes and summarizes information gathered; presents the results of any analysis performed; and provides information at the level of detail required by stakeholders. Performance Reporting should be done according to the schedule and format outlined in the project communications management plan.

301

Performance Reporting outputs include: •

Performance reports;

•

Forecasts;

•

Requested changes;

•

Recommended corrective actions; and

•

Organizational process assets (updates) .

Performance Reports Performance reports should give all stakeholders a clear understanding of any differences between planned performance and actual performance (accomplishments) in executing the project management plan. Performance reporting extends status reporting by distinguishing how current project status differs from the project management plan. In general, performance reports should be short documents (one to two pages for a monthly report) that provide the relevant facts of project performance. Although formats can vary significantly to address different stakeholder needs, most performance reports contain these common elements: •

Reporting period;

•

Work accomplished in reporting period;

•

Schedule/cost status and performance;

•

Problems experienced, or approaching;

•

Corrective actions, or plans;

•

Summary of accomplishments planned for the next reporting period; and

•

Detailed quantitative reports attached.

Performance information should not only be accurate; it should also be presented in a uniform manner. For example, if in one reporting period a project manager reports the quality metric as the number of parts per thousand that were defective, then, in the next reporting period, reports the metric as the percentage of defective parts produced, the stakeholder group does not have a uniform measure for comparison. Best Practices for Performance Reports For stakeholders, much of the information in performance reports is a review, or confirmation, of events that occurred since the last review; not all information is new. A rule of thumb is that technical data should be no more than one month old, and cost data, three months old.

302

Other practices for optimal performance reports include: •

Ensuring that the report is simple, understandable, and accurate;

•

Conveying information at an appropriate level of detail;

•

Ensuring that the stakeholder understands how to read the report and how to use the information; and

•

Confirming that the report is necessary.

Common Performance Reporting Formats Some common performance report formats include: •

Bar charts;

•

S-curves;

•

Histograms;

•

Tables; and

•

Milestone charts.

303

Bar Charts One type of bar chart that conveys status information by depicting actual vs. planned activities is the Gantt chart.

A Gantt chart is a good management tool because it shows the original schedule (baseline), completed or partially completed tasks, critical path, and duration estimates for the inprocess tasks. On larger projects, summary information should be used for the top-level schedule, and intermediate, detailed schedules can further identify deviations. For forecasting, it is important to update the schedule with actual start and finish dates. The scheduling tool can then present the project up to the time-now line with actual data, and then adjust the schedule assuming original duration estimates for the remaining tasks. In this case, a slip to the completion date is indicated if the remaining tasks are performed as planned. It is also important to note that the Gantt chart, as well as other status reporting tools, does not indicate what will happen on the project. It merely indicates what could happen without the project manager's active intervention. The project baseline with status information is the starting point for recovery plans.

304

Bar Charts and Recovery Planning If the project status shows a slippage, project managers must ask: •

What caused it?

•

Has the cause been corrected or is it still influencing the schedule?

There are ways to recover lost time. One is called schedule compression. The chart below shows that the project will be completed as originally scheduled, but the durations of the remaining tasks are compressed from the original estimates. Although this shows that the project will be completed on time, it does not necessarily mean that the project will conclude accordingly.

The chart is reliable only if there is a reasonable recovery plan behind it, with action plans above what was originally planned. To enable stakeholders to understand the plan behind the new schedule, project managers must be able to answer the following questions: •

What changed to allow for the compression in duration?

•

Will more resources be applied?

•

Will new methods be employed?

•

Will new assets be purchased?

•

Will outside consultants be used?

305

S-Curve Many project baselines are presented as an S-curve plot. The name comes from the shape of the curve, which is derived from the initially slow expenditure of assets followed by a period of rapid expenditure, and by the trailing off of expenditures as the project comes to completion. This is a form of trend analysis because the S-curve is a predicted pattern for most projects. However, it is important to note that the slope of the S-curve can differ significantly between projects.

An S-Curve can also be used as a baseline against which to compare actual results, as shown in the following cost reporting example.

S

306

Histograms The histogram is another format for displaying performance. A histogram is a type of bar chart that depicts relative frequency of a collection of variables. It is usually drawn with frequency on the y-axis and variables on the x-axis. The Pareto chart is a particular variant of the histogram in which the variables are ranked according to relative frequency. In many cases, the Pareto chart demonstrates an informal rule that 80% of the defects in any product are a result of only 20% of the causes.

307

Tables Presenting performance information in table form is an easy-to-use approach, especially for reporting a wide range of information. One key drawback of this method is that the information and its ramifications may not be intuitively obvious to the reader.

WBS Identifier

Planned Start

Actual Start

Planned Finish

Actual Finish

Create communications management plan

3.1.2

1/14/2005

1/14/2005

1/21/2005

1/25/2005

Submit to primary stakeholders for confirmation

3.1.2

1/21/2005

1/25/2005

1/25/2005

1/29/2005

Revise with input from stakeholders

3.1.2

1/25/2005

1/29/2005

1/25/2005

1/30/2005

4.1

1/26/2005

2/1/2005

NA

NA

Task

Begin plan execution

Milestone Charts A milestone chart is a variant of a table that maps completion of key deliverables against a set of scheduled deadlines. One common example of a milestone chart is a childhood development chart, which maps certain key physical or developmental abilities against an age range. For example, by the age of eight months, infants should be able to sit up straight, crawl, and partially feed themselves with their fingers. Milestone

WBS Identifier

Planned Finish

Actual Finish

Slippage

Receive confirmation from stakeholders

3.1.2

1/25/2005

1/30/2005

5 Days

Receive green light from Finance

4.1

1/26/2005

2/1/2005

5 Days

Submit permit application

4.1.2

2/1/2005

2/2/2005

1 Day

Receive permit approval

4.1.3

2/102005

2/10/2005

0 Days

308

Other Performance Reporting Outputs In addition to performance reports, four other outputs for Performance Reporting have been identified: •

Forecasts;

•

Requested changes;

•

Recommended corrective actions; and

•

Organizational process assets (updates).

These outputs are explained on the pages that follow. Forecasts The project manager also uses Performance Reporting to forecast future project performance. The project manager should make stakeholders aware of any upcoming issues that can be predicted. The project manager also uses forecasted performance measures to make adjustments to the process, and to re-align future performance with the project management plan. Project managers should be ready at any time to answer two stakeholder questions: •

How much will the project cost?

•

When will the project be done?

309

Requested Changes Project performance analysis often generates requests for change. Variances from planned cost and schedule are often the triggers for implementing project changes. These changes are handled by a change control system (CCS), which is a formally documented process that includes paperwork, tracking systems, processes, and approval levels necessary for authorizing changes. Recommended Corrective Actions Recommended corrective actions include interventions designed to re-align future performance with stakeholder expectations. Organizational Process Assets updates Updates to organizational process assets resulting from Performance Reporting may include lessons learned documentation and updates to historical knowledge bases. Tip: Stoplight Technique for Reports Stoplight reporting is a special technique that can focus stakeholders on the most important project issues and help them identify trends. •

A green light indicates activity progressing according to the project management plan;

•

A yellow light signifies that issues have been identified and should be corrected with the corrective actions in place; and

•

A red light means an activity is failing and requires immediate intervention.

Stoplight reporting is a convenient way to lighten the reading workload of senior managers. It reveals project status while making progress clearly visible. For example, clear progress is shown when an issue that was previously yellow is now green. Conversely, if an intervention is not successful, the item may show up red in a subsequent report. In any event, a yellow indicator alerts stakeholders to a potential problem and focuses their attention on the issue in the subsequent report. Stoplight reporting is most effective when presented in statistical terms. For example: Green = within 5% of plan Yellow = within 15% of plan Red = over 15% of plan Project managers may attach supporting details to stoplight reporting, and can adapt the technique to their own use. Some project managers add color-coded reports that serve as a basis for weekly internal status meetings.

310

REFERENCES R. Mulcahy, "PMP EXAM PREPARATION", RMC Publications Inc. 2009 PMI, "PRACTICE STANDARD FOR EARNED VALUE MANAGEMENT", PMI 2005 S.J. Amos, "SKILLS & KNOWLEDGE OF COST ENGINEERING", AACEI, 2004 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010 M.Crouhy, R. Mark, D. Galai, "RISK MANAGEMENT", McGRAW-HILL, 2001 M. Effron, M.Goldsmith, "HUMAN RESOURCES IN THE 21st CENTURY", John Wiley & Sons 2003 “MASTERING PROJECT MANAGEMENT BASICS” Boston University, 2005 J.Fitz-enz, "THE ROI OF HUMAN CAPITAL: MEASURING THE ECONOMIC VALUE OF EMPLOYEE PERFORMANCE", AMACOM 2000 NDIA, "EARNED VALUE MANAGEMENT SYSTEMS INTENT GUIDE", NDIA, 2005

311

Chapter XIII Human Resources Management Project Human Resource Management includes the processes that organize and manage the project team. The project team consists of all project team members, including the project management team, the project manager, and for most projects, the project sponsor. The project sponsor is the person or group that provides the financial resources for the project. The project team comprises the individuals who have been assigned roles and responsibilities for completing the project. The type and number of project team members can often change as the project progresses; stakeholders on a typical team include: •

Sponsor;

•

Project manager;

•

Project management team;

•

Project team members;

•

Support staff; and

•

Contractors or other procured staff.

The project management team is a subset of the project team and is responsible for project management activities such as such as planning, executing, monitoring and controlling work, and closing the project. This group can be called the core, executive, or leadership team. The project sponsor works with the project management team, typically assisting with matters such as project funding, clarifying scope, and influencing others to the benefit of the project. In some instances, project management responsibilities may be shared among the entire team. In all cases, it is important for team members to take an active role in planning and decision-making. Early involvement of team members adds expertise during the planning process and strengthens the commitment to the project.

312

Human Resource Theories Merely identifying groups of people who will perform work on a project does not create the team synergy that is required to make the project a success. Over the years, much effort has been undertaken to understand how to manage people at work so that employers can achieve the best results possible. This effort has resulted in many theories about how to optimize investment in human capital. Industrial-organizational psychologists and management theorists have attempted to understand and measure human behavior in order to improve both employee satisfaction and employers' ability to select and promote the best people. Psychological studies have been conducted to analyze the issues that affect how people work and how well they work. These studies typically focus on: • • •

Motivation; Influence and power; and Effectiveness.

Motivation Many psychologists, supervisors, and managers struggle to understand what motivates people. Theorists feel there are two types of motivation: • •

Intrinsic motivation – Related to personal enjoyment (the carrot approach); and Extrinsic motivation – Stemming from the desire to avoid punishment (the stick approach).

It is interesting to consider why some people need no external motivation to produce highquality work, while others require significant motivation to perform at all. Motivational theories developed by well-known behavioral theorists are Maslow's Hierarchy of Needs Theory; Herzberg’s Motivation-Hygiene Theory; McClelland’s Acquired-Needs Theory; McGregor’s X and Y Theories; and Ouchi’s Theory Z.

313

Maslow's Hierarchy of Needs Theory According to Abraham Maslow, human behavior is motivated by a sequence of needs as shown in the following diagram.

• • • • •

Physiological needs are biological needs, such as the need for air, food, and water; When physiological needs are met, the need for safety will emerge. Safety and security rank above all other non-physiological needs; After physiological and safety needs are met, the need for social interaction emerges. This involves relationships based on emotion, such as friendship; Esteem needs include the need for the respect of and recognition by others, and the need for self-respect.; and Self-actualization is the instinctual need of a human to make the most of his or her unique abilities.

Few people ever reach self-actualization, and most do not move above safety or social motivators. Successful project managers recognize the importance of identifying the individual motivational needs of all team members.

314

Herzberg’s Motivation-Hygiene Theory To better understand employee attitudes and motivation, Frederick Herzberg performed studies to determine which factors in an employee's work environment caused satisfaction or dissatisfaction. He published his findings in the 1959 book The Motivation to Work. Herzberg’s studies included interviews in which employees were asked what pleased and displeased them about their work. He found that the factors that contributed to job satisfaction (and presumably motivation) were different from those that created job dissatisfaction. The result of this study produced the motivation-hygiene theory. He called the job satisfiers “motivators” and used the term “hygiene” to describe maintenance factors that are necessary to avoid dissatisfaction. Herzberg concluded that motivating factors for job satisfaction include: • Achievement; • Recognition; • Responsibility; and • Advancement. Factors that contribute to job dissatisfaction include: • Company policy; • Quality and amount of supervision; • Relationship with manager; • Work conditions; and • Salary. Herzberg reasoned that because the factors causing satisfaction are different from those causing dissatisfaction, the two feelings cannot simply be treated as opposites of one another. The opposite of satisfaction is not dissatisfaction, but rather, no satisfaction. Similarly, the opposite of dissatisfaction is no dissatisfaction. Herzberg’s theory explained why attempts to use positive factors such as reducing time spent at work, increasing wages, offering fringe benefits, and providing training in human relations and sensitivity do not instill motivation.

315

He argued that people want to self-actualize and therefore need stimuli for their own growth and advancement needs. Management must not only provide hygiene factors to avoid employee dissatisfaction, but must provide factors intrinsic to the work itself to ensure that employees are satisfied with their jobs. He also believed that job enrichment is a continuous management process.

McClelland’s Acquired-Needs Theory David McClelland is best known for his acquired-needs theory, which is based on the concept that a person's needs are acquired over time and are shaped by experience. McClelland believed that most personal needs as well as individual motivation and job effectiveness are directly linked to one of three needs: achievement, affiliation, or power. His theory emphasizes the following needs: •

•

•

People with a high need for achievement are motivated to excel and tend to avoid both low and high-risk situations. Achievers need regular feedback to monitor the progress of their achievements. They prefer either to work alone or with other high achievers; Those with a high need for affiliation require harmonious relationships and need to feel accepted by others. They tend to conform to the norms of their work group and prefer work that provides significant personal interaction; and People may need power in one of two forms: personal power, the desire to direct others, or institutional power (also known as social power) the desire to organize the efforts of others to further the goals of the organization. The need for personal power is often perceived as undesirable. Managers with a high need for institutional power tend to be more effective than those with a high need for personal power.

McClelland's theory is sometimes referred to as the three needs theory or as the learned needs theory.

316

Project managers should recognize that people with different needs are motivated differently: •

High achievers should be given challenging projects with reachable goals. They should be provided frequent feedback. While money is not an important motivator,

•

it is an effective form of feedback; Employees with a high need for affiliation perform best in a cooperative

•

environment; and Management should give power seekers the opportunity to manage others.

McGregor’s X and Y Theories Douglas McGregor examined the behavior of individuals at work and formulated two models, which he called Theory X and Theory Y. McGregor discussed these theories in his book, The Human Side of Enterprise, published in 1960. He found that although many managers expressed the “right” ideas, they actually followed a very different set of assumptions about worker motivation. •

•

Theory X Assumptions: Most people dislike work and will avoid it if they can. People want direction, dislike responsibility, and desire security above everything. This theory is also referred to as the classical systems theory; and Theory Y Assumptions: Expenditure of physical and mental effort in work is as natural as play or rest. People will direct themselves if they are committed to the aims of the organization, and the average person learns, under proper conditions, not only to accept but to seek responsibility.

McGregor theorized that most managers tend toward Theory X, although he views Theory Y as the preferable model and management method, as it produces better results and allows people to grow and develop.

317

Ouchi’s Theory Z In 1981, William Ouchi published his best-selling book, Theory Z: How Americans Can Meet the Japanese Challenge. Theory Z combined American and Japanese motivational approaches that emphasized trust, quality, collective decision-making, and cultural values. Ouchi’s Theory Z is more holistic than McGregor’s theories in that it not only emphasizes the way in which management views its workers but also includes the workers’ perception of management. One of the main characteristics of the Theory Z approach is trust. Theory Z assumes that employees can be trusted to perform their jobs well as long as management considers their personal satisfaction and welfare. Theory Z also promotes: • Long-term employment; • Collective decision-making; • Individual responsibility; • Slow evaluation and promotion; • Implicit, informal control with explicit, formalized measures; • Moderately specialized career paths; • Job rotation; and • Broadening of skills providing generalization rather than specialization.

Thamhain and Wilemon’s Influence on Projects Thamhain and Wilemon researched the various approaches that project managers have used to influence workers, and examined how these approaches affected project success. Nine bases of influence are available for project managers: • Authority — The legitimate hierarchical right to issue orders • Assignments — The project manager’s perceived ability to influence a worker’s future work assignments • Budget — The project manager’s perceived ability to authorize others’ use of discretionary funds • Promotion — The project manager’s ability to improve a worker’s position • Money — The ability to increase salaries and benefits

318

•

Penalty — The project manager’s perceived ability to dispense or cause punishment

•

Work Challenge — The ability to assign work that capitalizes on a worker’s enjoyment of doing a particular task or job, tapping into an intrinsic motivational

•

factor Expertise — The project manager’s perceived special knowledge that others deem

•

important Friendship — The ability to establish friendly personal relationships between the

•

project manager and others

Thamhain and Wilemon observed that projects were more likely to fail when project managers relied too heavily on using authority, money, or penalty to influence people. Instead, they recommend using challenging work and expertise to influence people. This approach validates the studies of motivation by Maslow and Herzberg. Covey’s Approach to Improving Personal Effectiveness Dr. Steven Covey is a leadership and time management expert teacher, and organizational strategy consultant. His work is an extension of the research completed by Maslow, Herzberg, and other industrial-organizational psychologists. Covey's behavioral theories embrace integrity and humanity, and contrast strongly with the process-based ideologies that characterized management thinking in earlier times. His book, The 7 Habits of Highly Effective People, became a blueprint for personal and organizational development when it was published in 1990. •

•

•

Be proactive – This is the ability to control your own environment, rather than have it control you. This habit promotes self-determination, choice, and the power to control responses to external stimuli and circumstances; Begin with the end in mind – This habit focuses on personal leadership. It focuses on relevant activities, allowing people to avoid distractions and increase their productivity; Put first things first – This habit focuses on personal management, since it relates to organizing and implementing activities that support the second habit;

319

•

•

Think win-win – This habit focuses on interpersonal leadership. It is based on the assumption that success follows a cooperative approach more naturally than the confrontation of win-or-lose; Seek first to understand and then to be understood – This habit focuses on communication, and involves the practice of empathic listening, which is listening with the intention of understanding;

•

•

Synergize – This habit focuses on creative cooperation, which is based on the principle that the whole is greater than the sum of its parts. It promotes the importance of recognizing the value of others’ contributions; and Sharpen the saw – This habit focuses on self-renewal, and it enables and encourages the other six habits to happen and grow.

In his more recent book, “The 8th Habit”, Stephen Covey introduced an eighth habit, which focuses on personal fulfillment and helping others to achieve fulfillment. Leadership, Collaboration, and Personal Skills The graphic below illustrates the need for project managers to have a variety of interpersonal and general management skills to manage the project team. In addition, strong communications skills are critical to the project manager’s ability to effectively negotiate, share information, and manage conflict.

320

Leadership Responsibilities Working as a team involves a delicate balance of personality, expertise, and cooperation. For a team to function, everyone must keep the best interests of the project, the company, and the team in mind. It is the responsibility of the project manager to develop and manage an effective project team. This can best be accomplished by: • •

Believing in the value of teamwork; Choosing and reassessing the most productive model for team leadership;

• •

Communicating expectations about how the team will operate; Nurturing all team members by delegating, coaching, and providing formal training

•

appropriate to their needs Rewarding and discouraging behavior in accordance with the chosen model for team leadership and the expectations communicated; and Setting aside time in team meetings and in one-on-one sessions with team members to focus on the team’s performance and development.

Human Resources Planning Human Resource Planning ensures that assigned roles, responsibilities, and reporting relationships are clearly defined and documented so that all project participants understand their roles and responsibilities in relation to other participants. The individuals and groups involved can be part of the organization performing the project, or they can be external to it. Ineffective Human Resource Planning can lead to underutilized staff, perhaps leading to layoffs. Conversely, it may also lead to overstretched team members who then become difficult to retain. Effective Human Resource Planning helps organizations meet production and service deadlines at the expected quality level, while ensuring effective utilization of all staff members. It can also: • • •

Clearly define effective workforce requirements; Establish flexible work arrangements; and Improve output by developing a better understanding of the relationships among productivity, organization, and technology.

321

Human Resource Planning Interactions with Other Processes Human Resource Planning occurs throughout different stages of project planning and often interacts with many processes at one time. Typically, the Human Resource Planning process interacts with the following processes: • Create a WBS; • •

Plan Purchases and Acquisitions; Activity Definition;

• •

Activity Resource Estimating; Activity Duration Estimating; and

•

Schedule Development.

Examples of Human Resource Planning Process Interactions Examples of the Human Resource Planning process interactions include: • Create WBS: The WBS dictionary developed by this process defines each resource requirement for the WBS work packages. After initial team members create a WBS, the team may need to acquire additional members; • Plan Purchases and Acquisition: The outcome of a make-or-buy analysis may reveal that purchasing an item is more cost-effective than renting it. Such considerations can affect the long-range strategy of the project team’s organization by identifying a new skill or competency level absent from the organization’s existing resource pool; • Activity Definition: The activity attributes developed during this process provide the primary data used to estimate the resources required for each schedule activity; • Activity Duration Estimating: When activity durations are estimated before all team members have been assigned, the actual competency levels of new team members can cause activity durations to change. For example, during early planning of a technical project, the project manager may decide that many senior and junior software engineers are needed. However, as resource needs are refined, the pool may be reduced to include only engineers with expertise in a particular programming language;

322

•

Activity Resource Estimating: Activity resource estimating is dependent on the output of Human Resource Planning that provides information on which resources are potentially available; and

•

Schedule Development: Schedule Development can require that resource estimates be reviewed and revised. If Human Resource Planning is done at an early stage, the project schedule will remain preliminary until the assignments of the resources have been confirmed.

Together, these interrelated planning processes gather information of different degrees of completeness and certainty from many sources. As new information is revealed, additional dependencies, requirements, risks and opportunities, assumptions, and constraints will be identified and resolved. Project management is multidimensional and causes repeated loops and feedback that can continue indefinitely. Procedures set by the performing organization determine when the planning efforts are complete.

Human Resource Planning Process inputs Enterprise Environmental Factors It is important to understand the culture and structure before planning which human resources will be required for a project. The definition of project roles and responsibilities is developed by analyzing the types of skills and skill levels required for the project, the anticipated team member interactions, and the existing reporting relationships. Relevant enterprise environmental factors involving organizational culture and structure include: Organizational Factors • Organizations, departments, and groups involved in the project; and • How these organizations, departments, and groups interact, both formally and informally.

323

Technical Factors • Disciplines and specialties that will be needed to complete the project work; • •

Different disciplines, equipment, or methodologies required for the project; and Unique challenges associated with the transitions from one life cycle phase of the project to the next.

Interpersonal Factors • Formal and informal reporting relationships among project team candidates; • Existing job descriptions; • •

Supervisor-subordinate relationships; Prior relationships between team members and clients or vendors;

•

Cultural or language differences among prospective team members that may affect working relationships; and Levels of trust and respect that exist between prospective team members.

•

Logistical Factors • Distance that separates the people and groups that will be working on the project; • Time zones that affect the collaboration of geographically dispersed team members; • Feasibility of virtual teams; and • Tool and telecommunications support requirements. Political Factors • Organizational goals and tensions that may drive stakeholders; • Existing alliances that may affect the ability to successfully manage the project; • Groups and people that have informal power in areas important to the project. Project Constraints Constraints in the enterprise’s environment limit the project team options when defining roles and responsibilities. Examples of constraints that can limit flexibility in the Human Resource Planning process include: Organizational structure/policies of the performing organization — An organization whose basic structure is a weak matrix means a relatively weaker role for the project manager.

324

Collective bargaining agreements — Contractual agreements with unions or other employee groups may require certain roles or reporting relationships. Economic conditions — Hiring freezes, reduced training funds, or a lack of travel budget are examples of economic conditions that can restrict staffing options. In general, the financial situation of the performing organization will affect the project ability to purchase or otherwise acquire labor. Preferences of the project management team — If members of the project management team have had success with certain structures in the past, they are likely to advocate similar structures in the future. Expected staff assignments — The way the project is organized is often influenced by the skills and capabilities of specific individuals. Organizational Process Assets Organizations with mature project management methodologies often have a repository of lessons learned from completed projects, allowing the project manager to draw on past Human Resource Planning experiences to plan the current project. Organizational process assets can help reduce the amount of time needed for Human Resource Planning at the beginning of the project and reduce the likelihood of missing important responsibilities. These assets include: Templates • Role and responsibility definitions or reporting relationships for a similar project; • Project organization charts; • Position descriptions; • Performance appraisals; and • A standard conflict management approach. Checklists • Common roles and responsibilities; • Typical competencies for particular skill levels; • Applicable training programs; • Team ground rules; • Safety considerations;

325

• •

Compliance issues; and Reward ideas.

Human Resource Planning Process tools The tools and techniques used for Human Resource Planning are often readily available within the performing organization. These items may include the established human resources practices, policies, and procedures of the organization, as well as pre-existing templates from similar projects that can be used as is or modified. The Human Resource Planning tools and techniques fall into three categories: • Organization Charts and Position Descriptions; • Networking; and • Organizational Theory.

Acquire Project Team Process Adding the right players to the team will increase the probability that project goals will be met, potentially bringing competitive advantage to the organization. The ability to attract, hire, and retain the right resources is challenging but critical to the success of the project manager and the organization. Lack of Project Manager Control The project manager may or may not have control over the selection of project team members. The size of the organization, the relative priority of the project within the organization’s portfolio, and other organizational or political factors my leave the project manager with little authority for resource selection. The Economy and Competition The health of the economy impacts all industries. When the economy is good, organizations compete for resources and may have difficulty recruiting and retaining good employees.

326

Employee Demographics Pools of available talent in the labor market fluctuate by industry. Shifting population demographics may cause a flood of available resources in some industries and labor shortages in others. When there is a surplus of talent in the market, organizations should take proactive steps to attract strong resources and thereby fuel their organization's growth. Recruiting Practices Today’s organizations have a wealth of options to recruit potential employees, such as web-based job search engines, advertisements in various media, job fairs, employee referral programs, and incentive programs. Recruiting the right resources to satisfy both long-term and short-term needs involves significant time and cost investments. Effective screening and assessment methods become critical processes for the organization. Companies without an internal recruiting infrastructure may outsource employee recruitment to an external firm. Acquisition from Outside Sources When the performing organization lacks the in-house staff needed to complete the project, the project management team may hire consultants or subcontract some of the work to another organization. Techniques for planning such acquisitions and selecting consultants and contractors are related to the processes of the Project Procurement Management Knowledge Area, such as Request Seller Responses and Select Sellers. Virtual Teams The use of virtual teams creates new possibilities when acquiring project team members. Virtual teams can be defined as groups of people with a shared goal who fulfill their roles with little or no time spent meeting face to face. They interact primarily through electronic means such as e-mail and conference calls, although they may occasionally meet in person. Examples of virtual teams include people working at different geographic sites and a project team whose members telecommute. Team membership may be relatively stable or change on a regular basis. Members may be drawn from the same organization or from several different organizations (e.g., if a project involves consultants or other external resources). Many organizations establish virtual teams because of differences in time and space for team members.

327

Specifically, teams may be distributed because of the new realities facing organizations such as: • •

Organization-wide projects or initiatives; Alliances with different organizations, some of which may be in other countries;

• •

Mergers and acquisitions; Emerging markets in different geographic locations;

• •

The desire of many people to telecommute; The continuing need for business travel, information, and communications

•

technologies available to support this travel; A need to reduce costs; and

A need to reduce time-to-market or cycle time in general (the increasing velocity in business). Virtual teams are supported by both hardware and software. General hardware requirements include telephones, PCs, modems (or equivalent), and communications links such as the telephone system and local area networks. Software requirements include groupware products such as electronic mail, meeting facilitation software, and group time management systems. •

Virtual Team Benefits and Challenges The virtual team format provides many benefits: • Teams can be formed of people recruited for their competencies and expertise, regardless of whether they live in widespread geographic areas; • Employees can work from home offices and during different hours and • Projects that may have been neglected due to travel expenses can move forward, as related expenses can be reduced and sometimes eliminated. The virtual team format also presents many challenges, not all of which are directly related to technology. Many challenges of managing a virtual team are related to: • Time and location; • Culture and diversity; and • Communications.

328

Time and Location When teams work in times zones that are two or more hours apart, this can translate to significantly different work hours. Project management teams can work to overcome this challenge by creating ground rules to accommodate all work schedules and specifying core hours of operation within a normal workday. Culture and Diversity Technology may create diversity among team members, especially if part of the team is together in one location and other members are dispersed. Some team members may feel isolated. An additional consideration is that virtual team members may come from multicultural backgrounds. In this situation, the team should be made aware of customs, phrases, and gestures that differ from country to country. Guidelines for Acquiring Virtual Team Members When acquiring virtual team members, project managers are not constrained to a particular geography. However, the skills required to work on a virtual project team differ from those required of a worker on a more traditional team. The skills listed below may assist project managers in the recruitment, assessment, and selection of effective virtual team members. • •

•

• • •

Use technical tools proficiently, such as email, collaborative software systems, the Internet, desktop videoconferencing systems, and teleconferencing; Form team relationships quickly and effectively by asking questions, showing interest in others, adapting to the working styles of other team members, and being aware of one’s interpersonal style; Communicate effectively in a virtual environment, with strong written and oral communication skills and a sensitivity to the cultural differences among team members; Plan and organize individual work to correspond with team schedules; Participate effectively in group problem-solving, cooperating with others; and Prioritize work and establish personal and professional goals.

329

Guidelines for Ensuring Effective Virtual Team Communications Miscommunication is more likely to occur when team members do not meet in person and there is no nonverbal communication. Nonverbal communication includes facial expressions, tones of voice, gestures, eye contact, spatial arrangements, patterns of touch, expressive movement, cultural differences, and other "nonverbal" acts. Research suggests that nonverbal communication is more important in understanding human behavior than words alone; the nonverbal "channels" seem to be more powerful than what people say. Miscommunication leads to distrust. The issue of trust is at the center of successful virtual team management. Old-style command and control management, based on constant scrutiny, is simply impossible in a virtual environment. Communications planning becomes much more important in a virtual team environment. Potential communication issues can be reduced or eliminated by using the following approaches when establishing a virtual team. Include Face-to-Face Time if Possible Include periodic face-to-face meetings throughout the life of the project. These meetings will help establish relationships among the team members and create an effective working environment where the team members work interdependently. Provide a Big Picture of the Overall Flow of the Project Always send team members copies of the updated project schedule, or provide an electronic view of the project schedule online using the Internet. Team members need to know where they fit in the big picture and the expected direction of the project. Establish Information Distribution Guidelines Include a policy of acknowledging a request for information within 24 or 48 hours. A complete response to a request may require more time, but at least the person requesting the information will know that the request is being addressed. Establish a communications management plan for transferring information among project team members, helping to ensure that project information is distributed on time and to the right people.

330

Expand Text-Only Communication Use the Internet to store charts, pictures, or diagrams so that everyone has access to them, or use the fax machine to disseminate this information.

Developing a Team A group of people is not necessarily a team. It is through the effective merging of group skills and talents that new possibilities are created, including collective intelligence, increased creativity, broader experiences, and cultural richness. A team is a group of people with a high degree of interdependence geared toward achieving a common goal or completing a task. A team outperforms a group and can sometimes outperform what is expected of the individual participants.” A team provides three major benefits for the organization: • Maximizes the organization's human resources — Each member of the team is coached, helped, and led by all the other members of the team. All members, not just the individual, feel a success or failure; • Produces superior outputs against all odds — The synergistic effect of a team can normally outperform a group of individuals; and • Demonstrates continuous improvement — When they pull together as a team, members will not be afraid to take risks to show what they can do. Personal motives will be pushed to the side to allow the team motive to succeed. When nurtured and developed, teams can be very powerful. The combined strength and collective wisdom of a team can help the team achieve success in meeting and exceeding project goals. Teams offer advantages in other key areas such as: • Distributing the workload; • Reinforcing individual capabilities; • Creating participation and involvement; • Making better decisions; • Making a commitment to the work; and • Generating and respecting diversity of ideas.

331

Project Team Tasks and Characteristics Team members cooperate in all aspects of their tasks and goals, and they typically share in tasks such as planning, organizing, setting performance goals, scheduling, assessing the team’s performance, identifying and solving problems, and tracking progress. Teams learn and demonstrate behaviors that are not exhibited by mere groups. Members of a team typically move through four levels of participation as the team develops: 1. Contributing data and knowledge. 2. Sharing in the decision-making process and reaching consensus. 3. Making a decision as a team. 4. Making an imposed decision work as a team. Characteristics of effective teams include: • Communication — open, honest, and effective exchange of information between members; • Trust — openness in critiquing and trusting others; • Belonging — cohesiveness by being committed to an understood goal and team identity; • Valuing diversity — creating synergy by respecting all individuals; • Creativity and risk-taking — allowing success and failure to be attributed to the team rather than to the individual; • Flexibility — openness to assimilating change; and • Participatory leadership — allowing everyone to lead to some degree. The potential benefits of teams make them valuable tools. However, teams will not typically form by themselves. The project manager must be the catalyst for bringing the team together.

332

Five-Step Model for Team Development Dr. Bruce Tuckman published his four-stage model of team development in 1965 and modified it to include an additional stage in the 1970s. According to Tuckman, all teams progress through five stages of development: 1. Forming; 2. Storming; 3. Norming; 4. Performing; and 5. Adjourning. Teams move in and out of these stages, and certain events may precipitate this movement. Each stage is characterized by unique attributes. Project managers, who are responsible for team-building, should develop the skills necessary to take their team members through all stages of team development.

Forming The forming stage begins when the group assembles and is identified as a team unit. This stage normally occurs during the initiation of a team, or when new members join the team. This is a stage of transition from a group of individuals to a team. This stage is necessary, but little work is produced. Typically, everyone is polite and there is a feeling of anticipation and excitement. Roles are unclear, so there is usually a greater dependency on some form of leadership or control. Management Skills Needed During the Forming Stage In this stage of team development, the project manager needs to provide directive leadership. Efforts should be focused on defining goals, roles, and standards for the team. The project manager organizes and directs the team members in meeting the project goals. Management skills needed in the forming stage include: • Organizing; • Teaching; • Setting standards and accountability; and • Determining goals for the team.

333

Storming During the storming stage, morale may begin to decrease as conflict, confusion, and frustration arise. This is a normal progression, as team members have different opinions about how the team should operate. How much and how long a team storms depends on many variables such as team maturity, experience, leadership, and purpose. As roles become more defined, individuals begin to defend their own tasks and accountabilities. Conflicts may arise between those who prefer to dive right into tasks and those who want to spend more time planning. Team members will look for structural clarity and rules to resolve these conflicts. Storming is typically the most difficult stage for teams to traverse. It can make or break the team. It is also the stage where members learn the critical skills and processes needed to resolve issues. Resolving issues in the storming stage of team development enables the group to begin the next stage, norming. Management Skills Needed During the Storming Stage During the storming stage, the project manager must help the team resolve conflicts, using both leadership and management skills to provide a high level of support and direction to the team. The project manager must resolve conflicts by being assertive, openly communicating, and using active listening. In addition, the project manager must be able to make decisions regarding the direction of the team and justify the decisions, providing opportunities for feedback. During the storming stage, leadership and management skills are needed to: • Help the team resolve conflicts; • Provide a high level of support and direction; • Explain decisions; • Provide opportunities for clarification; • Define roles and responsibilities; and

334

•

Clarify performance expectations.

Norming Norming is achieved when team members move from their personal agendas and begin to focus on the group purpose. During this stage, the team develops a common working method. Cooperation and collaboration replace the conflict and mistrust of the previous stage of team development. Morale increases, and any subgroups that may have formed disband. Leadership may be shared more within the team, and there is less dependency on outside leadership. Talents and skills are explored and used to make the team more effective and unique. Management Skills Needed During the Norming Stage Norming marks a change in the team dynamics from dependence on the project manager for direction toward greater self-direction. The project manager moves into a coaching role, forming a more collaborative relationship with the team members and providing constructive feedback. Management skills in the norming stage include: • Communicating effectively with team members; • Providing constructive feedback; and • Coaching team members and affirming roles of each within the team.

Performing Performing occurs when the emphasis is on reaching team goals, rather than on team process. Disagreements may occur, but they are resolved within the team, and necessary changes to processes and structure are made by the team. Relationships are settled, and the team members are likely to have built loyalty to one another. Skills and talents have been applied effectively to produce optimum performance. The team is challenged to do things better, faster, and more effectively. The team begins to push itself and explore more creative ways of working.

335

During the performing stage, the team is more strategically aware and shares the same vision for success. Although the team requires delegated tasks from the leader, team members do not require instruction or assistance. Team members can now focus on achieving goals, and they have a high degree of autonomy. Management Skills Needed During the Performing Stage Management skills required during this stage include: • •

Building a consensus among team members; Problem-solving ;

• •

Rewarding team members when appropriate; and Decision-making.

Adjourning The adjourning stage occurs when the team is ready to complete the project, or as some team members are released from the project. They need to recognize what they have done, and consciously move on. Adjourning or closing a team is more of an adjunct to the original four-stage model rather than an extension. This stage views the team from a perspective beyond the purpose of the first four stages. The adjourning stage is relevant to all team members, but not to the main task of managing and developing a team, which is clearly central to the original four stages. Management Skills Needed During the Adjourning Stage From an organizational perspective, recognition of and sensitivity to people's vulnerabilities in Tuckman's fifth stage is beneficial, particularly if team members share a close bond. In addition, it is important for project managers to acknowledge individual performance as well as team success.

336

Stages, Attributes, and Roles It is important for the core project team to understand the team development stages and to recognize the team behaviors that signal each stage. By using this knowledge, they can understand how to help the project team move to the next stage. Depending on where the team is in their development, the project manager will have to change management roles to facilitate the team-building process.

Team-Building Activities Team-building activities are designed to help teams bond and build a team vision. Teambuilding activities can help team members: • Build relationships among co-workers working in the same office or at remote sites; • Increase communication, learn new strengths, and gain insights about each other and project needs; • Build trust; • Feel valued and rewarded; • Understand the importance of planning and communicating ideas; and • Understand their roles in relationship to the rest of the group. Team-building activities can range from a five-minute agenda item in a status meeting to an off-site, professionally facilitated session designed to improve interpersonal relationships. Team-building activities help teams learn about themselves, each other, and how to work together efficiently. Understanding behavioral and social profiles of individuals can help project managers improve working relationships with team members. Management styles can be adjusted ® according to individual team member needs. The Myers-Briggs Type Indicator (MBTI ) and the Wilson Social Styles Profile are examples of personality and social profiles through which the project manager can better understand the motivations and preferences of individuals on their teams.

337

®

Myers Briggs Type Indicator (MBTI ) ® The MBTI is an instrument used to measure a person’s preferences, using four basic scales with opposite poles. It is based on the theories of C. G. Jung and was developed by the mother-daughter team of Katherine Briggs and Isabel Briggs-Myers. They expanded on and organized the work of Jung to create a system for measuring psychological type preferences. The four dimensions of ®

psychological type in the MBTI scale include: • Extraversion/introversion (E/I): The first dimension determines whether someone is generally extraverted, drawing energy from the outside world and activity, or introverted, drawing energy from the inner world of thoughts and •

•

•

emotions; Sensate/intuitive (S/N): The second dimension relates to how people process information. Sensating (or sensing) people are typically concerned with facts and familiar terms, and often describe themselves as practical. Intuitive people give greater emphasis to insight and to the future, and often describe themselves as imaginative, ingenious, and attentive to hunches or intuition; Thinking/feeling (T/F): The third dimension represents how people prefer to make decisions. Thinking judgment is based on objective and logical considerations, while feeling judgment is based on subjective and personal values; and Judging/perceiving (J/P): The fourth dimension represents how people prefer to organize their lives. Judging people make decisions in a structured way, and they tend to like closure and task completion. They like to establish deadlines that they take seriously, expecting others to do the same. Perceiving people organize their lives in a flexible way. They regard deadlines as a signal to start rather than finish a project. They do not feel work must be done before play or rest begins.

The various combinations of these 4 dimensions result in 16 personality types. Knowing the personality profiles of team members can help project managers adjust their management style to improve working relationships with each project team member. Individual team members can also benefit from an understanding of personality types as they pertain to team dynamics. For example, when a team meets to resolve a team problem, each team member contributes a different perspective to the discussion. One person may want to clarify the problem being discussed; another may suggest structured ideas for

338

resolution; a third may try to analyze the situation and produce an explanation of how the problem came about. The personality types of the team members contribute to the effectiveness of the team process. Wilson Learning Social Styles Profile Based on the Social Styles Model developed by Dr. David Merrill, an industrial psychologist, Wilson Learning Corporation developed the Social Style Profile, a tool that provides a profile of an individual’s interpersonal business style, based on how other people perceive the individual in the workplace. The Wilson Learning Social Style Profile categorizes people as having one of four behavioral profiles, or zones, based on their assertiveness and responsiveness. The four behavioral zones include: • Drivers – Proactive and task oriented. The Driver style works best when the environment is not constrained; • Expressives – Proactive and people-oriented. The Expressive style works best in an open environment in which interactions with others are important; • Analyticals – Reactive and task-oriented. The Analytical style works best when the elements of a situation are organized and directions for implementing are provided by others; and • Amiables – Reactive and people-oriented. The Amiable style works best when the environment is free of time constraints and pressure. The following figure shows the four social styles and how they relate to assertiveness and responsiveness.

339

Each of the styles is expected to work best in a particular set of circumstances. Understanding social styles will help project managers understand why two individuals don't respond in the same way to the same set of circumstances. Gaining support and commitment from different people takes different tactics.

Ground Rules Ground rules are statements of values and guidelines that teams establish to help individual members decide how to act. Ground rules establish clear expectations regarding acceptable behavior by project team members. They should honor free speech and the dignity, respect, and worth of everyone on the project team. To be effective, ground rules must be clear, consistent, agreed-to, and followed. The following examples of team ground rules demonstrate a behavioral model that addresses how individuals communicate, participate, cooperate, and support each other. Attitude and culture • Treat each other with respect; • Recognize and celebrate individual and team accomplishments; and • Help where necessary to help solve problems and keep work on schedule. Team meetings • Hold regularly scheduled team meetings; • Start meetings on time and expect everyone to be prompt; • Establish expectations that all will attend unless they are out of town, on vacation, or sick; • Cancel meetings only when there are not enough team members to maintain a quorum or there is insufficient subject matter to discuss; and • Create and distribute an action item list with assigned responsibilities. Communication • Speak one at a time, allowing no side discussions; • Do not personalize discussion of issues, avoiding personal attacks; • Respect the group's time and the meeting timetables; be brief and focus on facts, not opinions; • Accept responsibility and accountability with the authority given; and • Listen, be nonjudgmental, and keep an open mind on issues until it is time to make a decision.

340

Co-Location Co-location is a strategy that involves placing project team members in the same location to enhance their ability to perform as a team. Co-location can be temporary at strategically important times during the project, or it can span the entire project. Co-location strategy can include the use of a meeting room, sometimes called a war room, which has electronic communication devices, areas to post schedules, and other conveniences that optimize communication and create a sense of community.

Recognition and Rewards Part of the team development process involves recognizing and rewarding desirable behavior to encourage team development. Examples of rewards and recognition include offering bonuses, trips, or other incentives to recognize accomplishments made by the project team. Rewards that only a limited number of project team members can achieve, such as team member of the month awards, can hurt team cohesiveness. Rewarding positive behavior that everyone can achieve tends to increase support among team members. Decisions about how teams should be rewarded and recognized are established during the Human Resource Planning process, and award decisions are made through performance appraisals during the Manage Project Team process.

341

Managing a Project Team The Manage Project Team process involves tracking team performance, providing feedback, resolving issues, and coordinating changes to enhance project performance. Results of the process include an updated staffing management plan, input to performance appraisals, and documentation of lessons learned. The Manage Project Team process can become complicated when there is more than one performance review path for team members. In functional and matrix organizations, team members are accountable to both a functional manager and the project manager. Sometimes another management layer is added when a team leader manages the team. Often the project manager is responsible for managing these dual reporting relationships. In a balanced matrix, the project manager and the functional or area manager jointly evaluate team performance. Inputs to the Manage Project Team process •

• •

• •

Organizational process assets: Include information about the organization’s policies, procedures, and systems for rewarding team members during the course of the project. The team should look for innovative ideas to reward people, such as desirable job assignments, flexible hours, gift certificates, additional vacation days, and corporate or project-related apparel. Typical rewards include bonuses, letters of commendation, and recognition dinners; Project staff assignments: Provide a list of the project team members to be evaluated during this monitoring and controlling process; Roles and responsibilities: Provide a list of team roles, associated levels of authority and competency, and the work that each project team member is expected to perform in order to complete the project’s activities. This information is used to monitor and evaluate performance; Project organization charts: Provide a picture of the reporting relationships among project team members; Staffing management plan: Lists the time periods that team members are expected to work on the project, along with training plans, certification requirements, and compliance issues;

342

•

Team performance assessment: Allows project managers to formally and informally observe team performance. Continuous assessment of team performance enables the project manager to resolve issues as they occur, modify communication, address conflict, and assess team development needs to improve team interaction;

•

Work performance information: Includes observations of team member performance as it occurs. Direct observation of areas such as a team member’s meeting participation, ability to follow up on action items, and communication skill are considered and can assist in assessing training needs to improve individual

•

contributions; and Performance reports: Provide documentation about team member performance as it relates to the project management plan. Examples of key performance areas include schedule control, cost control, quality control, scope verification, and procurement audits. Performance report information helps project managers determine future human resource needs, recognition and rewards, and updates to the staffing management plan.

Manage Project Team Process Tools The tools and techniques used during the Manage Project Team process include: • Observation and conversation; • Project performance appraisals; • Conflict management; and • Issue logs. Observation and Conversation Observation and conversation are valuable techniques for monitoring the attitudes and performance of project team members. The project management team monitors indicators such as progress toward deliverables, accomplishments that are a source of pride for team members, and interpersonal issues. Observation and conversation allow project managers to provide encouragement when morale is low and reinforce the objectives and vision of the project as needed. Project managers who have good observation skills can intervene early to prevent conflict from escalating.

343

Management by Walking Around (also known as MBWA, or Management by Wandering Around) is a management style that is as valid today as it was in 1982, when Tom Peters and Bob Waterman popularized Hewlett-Packard's mantra in their bestselling book, In Search of Excellence: Lessons from America's Best-Run Companies. This term refers to managers who spend a great deal of time away from their offices, observing and communicating with their team members to stay in touch with what is really going on with the project. Project Performance Appraisals Evaluation and feedback are key methods for encouraging team members to achieve a high level of performance. Feedback about the performance of project team members is important, regardless of the size of the project. However, the size, length, and complexity of the project as well as organizational policies and labor contracts will influence whether the feedback is formal or informal. The amount and quality of communications are also major influences in determining the type of feedback mechanism. Typically, project team members receive feedback from the people who supervise their project work. Evaluation information can also be gathered by using 360-degree feedback principles. 360degree feedback gives each employee the opportunity to receive performance feedback from all the people who surround him or her at work: supervisor, peers, reporting staff members, co-workers and customers. Most 360-degree feedback tools also involve self-assessments. 360-degree feedback allows individuals to understand how their effectiveness as an employee, co-worker, or staff member is viewed by others. Objectives for conducting performance appraisals during the course of a project can include: • Clarification of roles and responsibilities; • Opportunity to provide positive feedback in a structured context; • Discovery of unknown or unresolved issues; • Development of training plans; and • Establishment of future development goals.

344

Conflict Management Conflict can be defined as a pattern of opposition between people (or groups of people) that positively or negatively affects something important. Conflict is often caused by scarce resources, scheduling priorities, and differing personal work styles. Project managers can attempt to proactively reduce the likelihood of conflict by introducing team ground rules and solid project management practices such as communications management planning and role definition. It is common to experience some level of conflict among the project team, stakeholders, and contractors during the life cycle of the project. In fact, conflict is not necessarily negative when properly managed. Differences of opinion are healthy and can lead to increased creativity and better decisionmaking. The challenge for project managers is to maintain the right balance and intensity of conflict. Successful conflict management results in greater productivity and positive working relationships. Harold Kerzner’s book, Project Management: A Systems Approach to Planning, Scheduling, and Controlling, describes five approaches to conflict resolution. These approaches include Confronting, Compromising, Smoothing, Forcing, and Avoiding. Confronting – Problem-solving, integrating, collaborating, or win-win style. It involves meeting face to face and collaborating to reach an agreement that satisfies the concerns of all parties. This style relies on open and direct communication, with a focus on problemsolving. It typically provides the best resolution, although it may not be appropriate in all circumstances, especially for time-critical decisions. Compromising – "Give and take" style. It involves bargaining to reach a mutually acceptable solution. It is helpful for maintaining relationships among the involved parties. Smoothing – Accommodating or obliging style. This approach emphasizes the areas of agreement and attempts to minimize the areas of disagreement. Unfortunately, conflicts are not always resolved by the smoothing mode. This approach is beneficial for maintaining harmony when time is limited and the stakes are low. It will provide a temporary solution, placing the situation in perspective to control the magnitude of the conflict and establish an obligation for future negotiations.

345

Forcing – Competing, controlling, or dominating style. Forcing occurs when one party forces its position on another, ignoring the needs and concerns of the other party. This approach results in a win-lose resolution, where one party wins at the expense of the other. Forcing should be reserved for situations when the stakes are high or the relationship between the parties is not important, as conflict may later increase and relationships may break down. Avoiding – Withdrawal style. This approach is viewed as postponing an issue for later or withdrawing from the situation altogether. It is regarded as a temporary solution because the problem and conflict continue to recur. It may be effective when there is not enough time to resolve the issue, or when stakes are low. Project team members are initially responsible for resolving their own conflicts. If conflict escalates, the project manager should help facilitate a satisfactory resolution. In early conflict stages, a direct collaborative approach is used. If a disruptive conflict continues, formal procedures such as possible disciplinary actions may be necessary. Issue Log Issues will arise in the course of managing the project team. An issue log is used to document obstacles that can interfere with the team’s ability to achieve project goals. Issues can stem from differences of opinion, situations to be investigated, and emerging or unanticipated responsibilities that need to be assigned to a team member. An issue log is a central repository of human resource issues that have been raised throughout the course of a project. Typically, the issue log is a table or database, listing each issue, when it was opened, who the “owner” is, and a target date for resolution. The log helps the team monitor issues until closure. At project closure, the issue log becomes part of the project archive and is a critical input to the lessons learned documentation.

346

An issue log can take the form of a spreadsheet and may contain the following fields: • Issue description; • •

Person or people involved; Resolution strategy;

• •

Status (Open, In Progress, Corrected, Verified); Issue owner, responsible for the resolution;

• •

Date logged; Target date for resolution; and

•

Date closed.

REFERENCES M. Effron, M.Goldsmith, "HUMAN RESOURCES IN THE 21st CENTURY", John Wiley & Sons 2003 J.Fitz-enz, "THE ROI OF HUMAN CAPITAL: MEASURING THE ECONOMIC VALUE OF EMPLOYEE PERFORMANCE", AMACOM 2000 NDIA, "EARNED VALUE MANAGEMENT SYSTEMS INTENT GUIDE", NDIA, 2005 A.Damodaran, "STRATEGIC RISK TAKING", WHARTON School Publishing 2007 “MASTERING PROJECT MANAGEMENT BASICS” Boston University, 2005 W.E. Deming, "OUT OF THE CRISIS", THE MIT PRESS, 1986 M. Imai, "THE KEY TO COMPETITIVE SUCCESS" McGRAW-HILL/Irwin 1986 A.H.Bell, "MANAGEMENT COMMUNICATION", WILEY, 2010 M.Crouhy, R. Mark, D. Galai, "RISK MANAGEMENT", McGRAW-HILL, 2001

347