Phases of a Construction Project Life Cycle – Part 4

In Part 4 we will examine the final two construction project phases as described by F. Lawrence Bennett in his book “The Management of Construction – A Project Lifecycle Approach.” In this final installment, we review the project operations and project closeout and termination phases.

Project operations phase

In presenting the contractor’s activities on the construction site, we will suggest, perhaps too simply, that the responsibilities involve three basic areas: monitoring and control, resource management and documentation and communication. Five aspects of monitoring and controlling the work are important. Actual schedule progress must be compared against the project program to determine whether the project is on schedule; if it is not, actions must be undertaken to try to bring the program back into conformance. Likewise, the cost status must be checked to establish how actual performance compares with the budget. An equally important part of monitoring and control is quality management, to assure that the work complies with the technical requirements set forth in the contract documents. In addition, the contractor has an important role to play in managing the work safely and in a way that minimizes adverse environmental impacts.

In managing the project’s resources, the contractor will, first, be concerned with assigning and supervising personnel and assuring that the labor effort is sufficiently productive to meet schedule, cost and quality goals. In addition, materials and plant must be managed so that these same goals are met. Because construction projects require large amounts of paperwork, a special effort is required to manage this documentation effectively. Examples include the various special drawings and samples that must be submitted to the owner or design professional for approval prior to installation, the frequent need to respond to requests for changes in the project after the on-site work has begun and the all-important process for periodically assessing the value of work completed and requesting payment for this work. Various on-line and other electronic means are available to assist contractors with document management and project communications.

Project closeout and termination phase

Finally, as the project nears completion, a number of special activities must take place before the contractor’s responsibilities can be considered complete. There are the various testing and startup tasks, the final cleanup, various inspections and remedial work that may result from them and the process of closing the construction office and terminating the staff’s employment. In addition, a myriad of special paperwork is required, including approvals and certifications that allow the contractor to receive final payment, a set of as-built drawings that include all changes made to the original design, operating manuals, warranties and a final report. The contractor will also be responsible for transferring and archiving project records and will conduct some sort of project critique and evaluation; operator training may also be part of the contractor’s contractual responsibilities.

Criteria for Successful Project Management Offices

I was recently reviewing articles that I’ve written about successes and failures of Project Management Offices (PMOs) and some of the things that make that success or failure happen. I started making a list of these items and thought it might be helpful to share that info with the readers here on PM Tips again in this very condensed format. Remember, these are just my opinions that I’ve expressed in some of my articles along the way.

For PMO to be Effective:

• Director must be a key role in the organization
  • Must have backing and support of executive management
• Director must champion the efforts of the PMs
  • Don’t take credit for their actions
  • Provide ongoing support
  • Assist on critical/visible projects
  • Help breakdown resource acquisition barriers
• Director must run the PMO, not many projects
  • Project focus for the director should mainly be on the highly visible projects where exec decision-making is going to be needed on a regular basis or the business is extremely critical to the organization
  • Organization must value the PMO enough to ensure the director is not bogged down too much to be a successful leader

PMO Promotion

It is the responsibility of the PMO leadership to properly promote the PMO and help ensure its viability and visibility. Its viability is maintained by doing the following:

• Implementing proper and repeatable processes to consistently and successfully manage projects
• Implementing consistent templates for managing project and reporting status to customers and executive management
• Hiring competent, experienced Project Managers to lead projects for the organization
• Implementing proper compensation plans to retain good PM resources
• Implementing adequate training and on-boarding programs and processes to ensure that PMs are well-trained and up to speed on the PMO processes and practices

The PMO’s visibility is maintained by doing the following:

• Reporting project portfolio status on a regular basis and in a meaningful and useful format so that executive management realizes the PMO’s value
• Implementing solid PMO practices to ensure that the high-visibility customers are happy and referencable and the high-visibility projects are successful
• Inviting executive leadership to regularly attend weekly PMO meetings and sit in on project status meetings for the critical, high-visibility projects
• Managing project budgets thoroughly and reporting budget status up through executive leadership to show bottom-line PMO and Project Manager value

The PMO Director, as the leader of the PMO, must be a strong leader with pull inside the organization to ensure that these things happen. Otherwise, the PMO runs the danger of becoming obsolete or, at the very least, insignificant…and the mission critical projects will pass right by the PMO to special teams outside the PMO’s jurisdiction. Executive leadership must see value and ensuring that happens begins with the PMO leadership.

PMOs fail usually for one of the following three reasons:

• Lack of strong, focused leadership
• Lack of repeatable process
• Lack of executive leadership support

Five Signs Your PMO is not Meeting Your Organization’s Needs:

• Executive Management is not Included in the PMO Process
• Training Plans are Non-Existent
• Common Templates and Processes do not Exist
• Poor Upward Project Reporting
• Major Projects Circumvent the Process

All successful PMOs feature four basic components:

• The right processes
• The right tools
• The right people
• Executive level organization support

You can always hire different people. You can bring in consultants to help define better processes or identify better tracking tools. But without the executive-level support, none of it will happen or at least it won’t succeed.

Successful PMOs make an impact on organizational success by performing the following tasks:

• Aligning project delivery with strategic business goals and priorities
• Requiring that every project have an effective PM
• Implementing an appropriate PM methodology
• Consistent management and oversight of the project portfolio
• Obtaining and maintaining company leadership support

Defining Strategic Projects

In his book, “Project Management Nation,” Jason Charvat looks into Strategic Projects, what they are and how we translate corporate “strategy” into the projects for the organization.

What are Strategic Projects?

Where the project is a component of a broader business sense, it should be assessed as an integral part of the strategic program. All the normal financial assessment rules should be applied. The executive team should pay close attention to those parts of the proposed solution that clearly show the benefits of proceeding with the solution. Managers should ensure that detailed plans for achieving the benefits, and specific responsibility for delivering them, are in place.

IT planning must take account of the intended direction of the business, financial constraints and criteria, and human resource (HR) plans and policies. It must also be flexible enough to cope with any likely response from competitors over the whole project life cycle. Project managers should have a clearly communicated policy for the way to collect, use, and store information in support of the business objectives and the way the systems will enable them to harness the value of this information in the future.

Translating Strategy into Projects

Once the strategy has been determined and has been approved by the company executive team, the responsibility of the project success does not fall only at the feet of the project manager. The chief executive officer (CEO), chief information officer (CIO), directors, functional management, and staff all have specific tangible and intangible roles in the project. In this manner, mutual expectations can be met and benefits realized. For a successful transition from strategy to project, the business must have in place:

• Agreement on what needs changing, and why (this should be clearly supported by the project sponsor)
• A common “language” for analyzing and describing requirements, based on a shared understanding of the business processes across “client,” purchasing, and information systems (IS) departments (don’t assume this is the case)
• Agreed processes that involve the users in the selection and design of systems solutions (consider making a “client,” rather than an IS specialist, the program manager responsible for delivering the business benefits)
• The support of a skilled, experienced technology project manager

Each and every project should have some sort of a mission. The mission identifies the client’s requirements and clearly defines the purpose of the project. A project’s mission must be completed for success of the project. Objectives define the success criteria for the project. The objectives relate directly to the completion of the project’s mission. Completing all of the objectives should accomplish the project’s mission. Measurable objectives provide a method of quantifying the results and establishing quality standards to evaluate the success of the project.

Defining Risk Management – Part 4: Risk Quantification

There’s more detail available than what I’m going to go into here or include here from the book excerpt. Mostly, because this article would end up being far too long. I’ll go into Risk Quantification at a higher level here, and then present further detail in a subsequent article.

This information below on Risk Quantification comes again – for the most part – from the book “The Project Management Question and Answer Book.”

What is Risk Quantification?

Risk quantification is the process of evaluating the risks that have been identified and developing the data that will be needed for making decisions as to what should be done about them. Risk management is done from very early in the project until the very end. For this reason qualitative analysis should be used at some points in the project, and quantitative techniques should be used at other times.

The objective of quantification is to establish a way of arranging the risks in the order of importance. In most projects there will not be enough time or money to take action against every risk that is identified.

The severity of the risk is a practical measure for quantifying risks. Severity is a combination of the risk probability and the risk impact. In its simplest form the risks can be ranked as high and low severity or possibly high, medium, and low. At the other extreme, the probability of the risk can be a percentage or a decimal value between zero and one, and the impact can be estimated in dollars. When the impact in dollars and the probability in decimal are multiplied together, the result is the quantitative expected value of the risk.

Various statistical techniques such as PERT (program evaluation and review technique), statistical sampling, sensitivity analysis, decision tree analysis, financial ratios, Monte Carlo, and critical chain can all be used to evaluate and quantify risks.

Qualitative and Quantitative Analysis

Qualitative risk analysis is appropriate early in the project and is effective in categorizing which risks should or should not be planned for and what corrective action should be taken for them. Qualitative analysis techniques will not give us the precise values for the risk that we would like to have. They are very effective when we have little time to evaluate risks before they actually happen.

Quantitative values may be applied to risks when using qualitative analysis. Values such as very risky, not so risky; high and low; high, medium, and low; high, high medium, medium, medium low, and low are generally used. Qualitative evaluation might also evaluate the risks on a scale of one to ten. These values can be applied to both the probability and the impact of the risk. The impact and probability can then be combined to give similar descriptions to the severity of the risk.

If an evaluation of impact and probability used a scaled evaluation of one to ten, the numbers could be multiplied to get the severity. In this way a probability of 7 with an impact of 9 would give us a severity of 63. This number for severity should give us plenty of information for ranking the risks. Using the high, medium, and low version sometimes creates disagreements about risks that are on the borderline between one value and another. For example, does this risk have an impact of medium or high when it is close to the border between the two values? And what happens when the impact is very high or very low and the probability is the opposite?

While qualitative analysis is less precise than quantitative analysis, evaluating the results is far less expensive in terms of both time and money. The results are good enough to indicate the overall risk of the project and identify the high-priority risks in order to begin taking some corrective action. This kind of information may assist in pricing the project to a client.

Quantitative risk analysis attempts to attach specific numerical values to the risks. The severity can be assessed from these numerical values for impact and probability. Numerical techniques for decision analysis are used for this approach. These techniques include Monte Carlo analysis, PERT, computer simulations, decision tree analysis, critical chain scheduling, statistical estimating techniques, and expected value analysis. Generally we find the use of statistics and probability theory to be useful in quantitative analysis.

Care should always be used in quantitative analysis because using a good quantitative technique with bad data is worse than not using the technique at all. Many people are impressed with statistical models and simulations and never look at the data to see how good they are. It is quite possible to impress people into making the wrong decision based on excellent analysis of bad data. Care should also be exercised in the use of quantitative techniques because the cost of applying the technique and collecting the data can sometimes be more than the cost of the risks the technique helps to quantify.

The Skill Set of the Project Manager – Another View

In my article “The Characteristics of the Project Manager,” I began what ended up being a five-part series and still probably needs a final summary article – assuming I’m done and have no more characteristics to share…which I probably do.

I’m always open to new and different information as well as different opinions on information I’ve already provided so far in articles on the PM Tips site. That’s why I’m presenting this excerpt from Gary Heerkens’ book entitled “Project Management.” It covers what he considers to be the overall skill requirements of a project manager. It’s not exactly the same concept as the characteristics of a project manager, but it’s close.

Skill Requirements of the Project Manager

To fulfill the responsibilities of the role of project manager and handle the challenges you’ll face, you’ll need very diverse skills and a wealth of knowledge. So what knowledge and skills does it take to be an effective project manager?

There are many ways to slice up this pie. The way that makes the most sense to me is to break it down into four major knowledge and skill categories:

1. project management process skill
2. interpersonal and behavioral skills
3. technology management skills
4. desired personal traits

Let’s examine each in detail.

Project Management Process Skills

Project management process skills (sometimes called the “hard skills”) are knowledge and skills related to the mechanics of project management. You should be extremely knowledgeable about project management tools, techniques, and process technology and be able to apply them. For example, you should be know how to prepare a comprehensive customer requirements document, construct a network diagram, and construct a work breakdown structure. Without these skills, you’ll find it very difficult to coordinate and facilitate the creation of a high-quality project plan and to maintain control during project execution. Also, since these skills are a basic expectation, you can expect to encounter problems of respect from your team members if you’re deficient in this area. As mentioned earlier, this skill set is the main focus of this book.

Interpersonal and Behavioral Skills

Since managing projects is all about getting things done through other people, your skills in dealing with people are of immeasurable value. Closely tied to your interpersonal skills are your behavioral skills: your personal conduct, style, and approach. Together, these two skill sets are often called the “soft skills.” Here are some examples of soft skills:

• team and individual leadership
• oral and written communication
• conflict resolution
• negotiation
• influencing
• delegating
• coaching and mentoring

For individuals coming to project management from a highly technical background, soft skill development can be particularly challenging. Later in this chapter we’ll discuss methods for developing these skills.

Technology Management Skills

Most projects have one or more embedded technologies. An embedded technology refers to the process or technology areas at the core of the project. Examples might include software development, chemical processing, or commercial construction. Your ability to guide and coordinate the application of these technologies is crucial to your success as a project manager. If you’re like Brad, you’ll probably have sufficient knowledge and skills in the primary embedded technology of the project. However, it’s likely that there will be several technology areas associated with your project. Although they will differ in focus, the process steps and related skills involved in managing their successful application will be similar.

Among these technology management skills are the following:

• proficiency in project’s core (primary) technology
• proficiency in supporting technology areas
• industry knowledge
• ability to prepare comprehensive technical specifications
• design skills
• product knowledge
• process knowledge
• management of intellectual property
• patent knowledge

Desired Personal Traits

Many studies have been performed to correlate personality traits to success as a project manager. Although each study reveals slightly different results, the traits shown in Figure 3-1 appear in most. Possessing these traits will stand you in good stead in your role as project manager.

• Honesty and integrity
• Thinks like a generalist
• High tolerance for ambiguity
• High tolerance for uncertainty
• Persuasive
• Assertive
• Process-oriented
• Self-aware/reflective
• Open and accessible
• Politically astute
• Decisive

Of these personal traits, I consider the following four to be among the most critical.

1. Thinks like a generalist—Project managers must always be thinking in terms of the big picture. This can be a challenge for those who are accustomed to focusing more narrowly. Although this trait certainly requires knowledge in many different areas, what’s crucial is that you must pay attention and care about everything and everybody.

2. A high tolerance for ambiguity—This competency will be particularly challenging if you’re technically oriented. You’ll often receive mixed signals or contradictory data. You need to develop processes for finding truth and narrowing down inputs without getting frustrated. This will probably not be easy for you.

3. A high tolerance for uncertainty—As with ambiguity, this is particularly challenging if you’re entering project management from the technical arena. Most technically oriented people are accustomed to precision. As a project manager, the norm is to make many decisions without sufficient information. You must condition yourself to making decisions that are only acceptable, not perfect.

4. Honesty and integrity—Although obvious virtues, these traits are worthy of specific mention. Whenever studies are performed on the traits that people most admire or desire in leaders, honesty and integrity always rise to the top. One of the best behavioral traits for a project manager is to be known as doing what you say you’ll do. Closely related is the issue of integrity, having a reputation as someone who will follow principles, even in the face of adversity or temptation.

Together, the combination of hard skills, soft skills, functional competencies, and personal traits compose the raw material for your overall capability as a project manager. But how should you develop that capability?

Skills that are somewhat mechanical can be learned or developed through self-study, reading, or facilitated training and practice. Many of the hard skills fall into this category. However, as you migrate toward the soft skills, the preferred mode of development moves from programmed learning to coaching or mentoring. Here, soft skills are best developed through observation and feedback from others— preferably those in a position to do so.