Climbing the curve

Change on a project is inevitable, its impact and frequency are not. You can take steps to minimize both the number of changes and the magnitude of those changes.

Those steps are inclusion, review, and response. You must include all project stakeholders in the design process. Follow your RACI explicitly.

Do not short-circuit the review process, both internally and externally. Involve your client and other off-project stakeholders. Double the time allocated for model review, it’s a wise investment.

Process all change order requests and requests for information quickly. Make sure change orders have both cost and schedule impacts assigned, even if they are wild guesses. It is better to have a sense of the size of the change than no measure at all.

Should any changes need immediate attention (actual work) before approval, regard that as a red flag. Your policies and procedures are not working. There should be time to evaluate a change before it’s necessary to effect the change. If there’s not enough time, your system is broken. Fix it at once, before change takes over your project.

A project, as is most of life, is surrounded by uncertainty – risks. These risks can be specific, as in a hurricane, or more generic as in labor productivity. You should develop a plan(s) to deal with the risk, should the risk occur.

Caution: You are far better off having a plan than trying to develop one under the stress attendant with something going wrong.

The risk register is where you start. You and your team need to peer into the future and imagine what could go wrong (or right) with your project. Then evaluate the identified risk. Next, assign responsibility of monitoring and preparing for the event, to a specific team member.

It is up to you to make sure your people are working the register. Uncertainty/risks need to be re-visited periodically. Once is never enough. As time passes, we will know more. Some risks will fade away and others will appear, and still others will change in impact. Stay on top of your project uncertainties.

Most schedule risk arises from the imprecision of estimate unit rates. This imprecision reflects the effect of location, skill levels, craft availability, complexity, or whatever has on the unit rate. It takes time to understand the actual impact of these factors and adjust the unit rate. Do not be concerned with productivity until you achieve about fifteen percent of the specific task (or group of tasks that use the same unit rate) completed. Before that, you are measuring mobilization, not productivity.

Due diligence refers to the care a reasonable person should take before entering into an agreement or a transaction with another party. In this case, hiring Steve as the project engineer is such an agreement.

While I strongly urge reliance upon ‘your gut’, or instinct, or the ‘quiet voice within’, augment your feeling with review and investigation. Here John was correct to ask for references even though time constraints limited his options.

Later, Ed will suggest that John go beyond those references to talk to others, those not on the reference list, when they talk to Palindrome. Having the wrong person on your team will cost you – morale, productivity, aggravation, frustration, and eventually anger.

You owe it to yourself and the project to get the best people available, that requires due diligence. Take nothing on face value. To torture the phrase: Trust, but verify.

Trust your instincts, your judgment, but get corroboration.

We all rely on the personal interview. It is not as reliable a gauge as we think. People can fool us. Go beyond your first impression and get data, get confirmation, or refutation, as the case may be.

While staffing is a crucial element in project execution, a team that doesn’t work together is not a team. You must make your team coalesce, come together, work together.

Team building is what you must do to make the disparate project elements work together. If most of your people knew each other and worked together on other projects before, that might not be a problem. They know what to expect, what to do, and what not to do.

People, being people, might not always get along as they should. If it’s the result of dis-familiarity, you can correct that. Get them together as much as possible in an informal – read fun, setting. Let them be themselves. Usually this will work. If it doesn’t, don’t hesitate to replace the ‘flat spot on the wheel’.

The old saying about the one rotten apple spoiling the barrel is appropriate to project cohesiveness. It’s your project, your family. Protect it, nurture it, and let it grow.

As a client PM, you won’t have much say in promotions of contractor staff. When appropriate, be free with public praise. Similarly, let your displeasure be known, immediately, but less publicly.

Another element of team building is to get your customers involved as much as possible and as early as possible. Here your customers are the operators, the crafts, and the home office. Operations and construction involvement is critically important.

More important is your boss, or bosses involvement. If you don’t keep your bosses happy, it will not matter. They might tolerate you for the duration of the project, if they have no other option, but you won’t advance your career. Do not embarrass them, do not surprise them, and do not disappoint them.

The estimate is the ‘linchpin’ of effective project controls. Your budget flows from it, as does the project schedule. The estimate holds the project together.

Get the best estimators; give them enough time to develop the best possible estimate. Provide sufficient resources (time) to review every estimate. You must understand all the qualifications, assumptions, and metrics used by the estimators.

The estimate must reflect the current scope. Change the estimate as you receive new information. As significant discrepancies are discovered, adjust the estimate. Do not wait for the next planned update.

You must control to the best information, otherwise you risk demoralizing your project and/or disappointing your bosses.

This is your project. If you don’t get it right here, the rest won’t matter.

Assume nothing. Review all data given you. If it doesn’t seem right, it probably isn’t. Trust your gut, your intuition. You won’t have that much intuition at this point, but you will have some. Use it. You will make some assumptions, especially early in the project, but don’t let those assumptions go untested for long.

Logistics is a prime example. Know the site and all its limitations. Anticipate the things that can go wrong and develop a plan for dealing with them. The plan might not work, but at least you have a plan. Inaction in the face of a crisis will make matters worse. There could be times when doing nothing is the right course of action, but that should follow from an analysis of the situation, not paralysis

Never go to management with a problem without a plan to solve it. If you need additional resources – that includes time – tell them what you need and why.

Go to management as soon as you know there’s a problem, when there is still time to do something about the problem.

You don’t want to go to management with a problem without a solution or not enough time to do anything about it. If you rob them of options because you delayed, you will lose whatever support you could have had.

A problem without a solution, or too late to address, will cost you. No one wants to feel powerless, especially management.

Develop a plan or schedule as soon as you understand your project. It need not be a complete understanding. There is not enough time to wait for a complete understanding of your project before you plan.

Get your team working to deadlines. Identify deliverables and assign responsibility for the completion of those deliverables. Hold assignees accountable, including you. If you fail to live up to your obligations, you cannot expect your team to live up to theirs. ‘Do as I say, not as I do’, will not work here.

Always track your performance against your plan. You should change your plan, when you can no longer realistically follow the original plan. Before you change, know why. This is not a trivial exercise. Changing the plan is an admission that something was wrong with your plan.

If the scope of work is misunderstood, or has changed, find out why. If the estimate is flawed, find out why. If the project team is not working efficiently, find out why. Once you understand the reason(s) why, fix it (them). If you can’t fix the problem, you won’t have a successful project.

Another essential step is ‘buy-in’. If the person assigned the task does not accept ownership of that task, that task will not be delivered when expected or to the degree expected. Incomplete performance is not acceptable. Make sure the assignee knows what you expect, along with when you expect it.

If they need more resources – staff or time – make every effort to get it for them.

You should spend as much time as necessary to clarify and understand the project Scope of Work (SOW). This is not a waste of time. It may be the best investment you make as a project manager.

You will not achieve the project goals/objectives, if your team doesn’t understand what is expected and when. Formal acceptance of responsibility is essential. Be sure to crosscheck the Responsibility Assignment Matrix (RACI) and project schedule against the statement/scope of work. Expand and clarify as needed.

The major players associated with the project, especially the owner/project sponsor, must accept the SOW. Every person assigned a deliverable must formally acknowledge responsibility. They must accept the scope of the assignment and the date of delivery. Formal means a signature somewhere.

The same holds true for the WBS. Think through the steps and stages your project will pass, and make sure the WBS reflects those steps. This is an iterative process. The WBS will gain complexity as the project gains greater scope understanding/development.

Make the WBS construction-centric. Design and procurement must fit/follow the construction structure/sequence. Operations or accounting has no voice in the development of the WBS.

The sole focus of design and procurement should be support of construction.

Time spent on the RACI and WBS is an investment. The payoff is effective coordination, ease of communication, and acceptance of responsibility – each necessary to achieve project success.