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.

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.

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

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.