Striving for Communications Effectiveness

I know I’ve said that Requirements Definition is the lifeblood of the project – and I still think that is true. But many aspects of project management are extremely critical to project success so if I can’t call communications the lifeblood of the project, then I’ll call it the backbone. Without effective communication – especially communication that originates or passes through the PM (since he/she is the critical communication focal-point) – then the project is likely to fail miserably.

Testing Communication Effectiveness

Whether the communication is written or verbal, formal or informal, the question must be asked as to whether or not it was effective. Did the information transfer that had to occur happen? Communications effectiveness can only be tested through feedback—the receiver is the ultimate determinant as to whether or not the message was received. The obvious test of communications effectiveness is to ask the receiver in the communications model to reiterate what has been said or what commitments have been made. Although they may be able to recite chapter and verse of what was originally stated, such regurgitation may not truly reflect understanding. Better instead to ask the receiver how they will act on the information or what the next steps in the process are, to ensure the communication has gone from interpretation to action.

Communication is Key

Communication is the cornerstone of effective project management, and yet most of it is done ad hoc, driven by individuals, personalities, and preferences, rather than by needs, protocols, processes, and procedures. Communication breakdowns are continuously cited as one of the key reasons that projects fail, which is why communication needs to be addressed as a critical activity and skill for project managers.

It is critical that managers improve or enhance their communications whenever possible. But “improving communications” is a vague concept. No two people are going to have the same notion as to what that means, unless com- munications goals are identified on the project. Communication is basically nothing more than an effort to make the world “smaller.” It is an attempt to create a common understanding and a common informational basis among various parties. It is the pursuit of commonality. It is an effort to bring individuals closer together.

How close is appropriate in the project environment? How deep must the common understanding be? The goal of communication in the project environment needs to be to establish a common understanding to the requisite level of depth. That level of depth will vary from project stakeholder to stakeholder. A security guard who affords access into the building may need only a single memo or e-mail from time to time, and needs virtually no understanding of the project plan or its intricacies. The customer needs to know what is being delivered and when, but may have no need to know how the work is being performed. Internal managers may need information on resource usage and performance, but may not concern themselves with project performance from day to day.

Summary

As a general practice, the goal of communication should be to clarify information to the level of depth required by the receiver by minimizing barriers that might inhibit understanding. In implementation, that implies a broad understanding of audience, interest, and environment.

The bottom line is the project manager must be the skilled communicator on the project and very adept and maintaining both formal (status reports, status calls, project schedules) and informal (phone calls, emails, adhoc meetings to discuss issues) with the delivery team, the entire delivery organization, and the customer.

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.

Training the Client and Support Staff for Go-Live

In the article title, “Project Phase 6 – Training” I covered the activities necessary to prepare for and apply training and knowledge transfer to the customer and other necessary staff. At this time, I’d like to present an alternative view-point from Jason Charvat’s book “Project Management Nation.”

Training and Knowledge Transfer

Frequently, users of the solution are either not trained properly or they are not trained at all, which results in rejection of the solution within the client organization. It is important that users of the system receive all the training and support they need to use the new system effectively. The implementation of an IT system is not an end in itself. It is important that staff members are able to use it and that the impact of its introduction on their productivity has been fully considered during the planning stage. Without these considerations, is it is unlikely that the anticipated business benefits will be realized.

Training of staff can take up considerable resources, often a significant proportion of the overall cost of the project. Training must address the needs of users and of those operating and maintaining the system. The project manager has a few options when it comes to training resources on the developed solution:

• Outsource the training to a reputable, accredited training vendor
• Provide the training in-house at the client
• Provide the training at the project manager’s organization

Project managers need to realize that proper training must be provided to the users of the solution, and the following types of training can be provided before the solution is implemented and delivered for use:

• Classroom-based lectures
• One-on-one sessions
• Self-paced, computer-based tutorials
• Providing the user with an operations manual

Sufficient time and resources should be spent in order to help the staff learn how to use the IT system. Consideration should be given to the possible effect the new system may have on productivity in the period following implementation. In particular, it is important to make a realistic assessment of the impact that introducing the new IT system will have on the productivity and effectiveness of staff.

Addressing the Training Infrastructure

Providing the training for users at a suitable training location is imperative in ensuring that the users are satisfied with the quality of the solution being implemented. If the training facility is situated at the back of the office, it immediately gives users the impression of an inferior solution. Sufficient thought and user acknowledgement must be given to training, and it starts by making sure that the users have (1) adequate training material, (2) training in a proper facility, and (3) the correct training resources. Using these three factors can only result in successful training.

Once training has been synchronized with the implementation schedule and approved by all the stakeholders, it becomes necessary that the system is tested and fully functional by the time that user staff return to their environment.

Technical Support Training

Before implementing a project for a client, the project manager should be sure that the client IT operational support staff are adequately trained and knowledgeable on the technical support issues of the system being commissioned. After all, the IT support staff are responsible for maintaining the various technologies and platforms once the project is handed over.

Defining Risk Management – Part 9: Risk Control

This is the ninth and final installment in the Defining Risk Management series. In this final segment, we look at what risk control is and how we monitor and track the risks that are identified and new ones that are encountered on our projects. This information is again, for the most part, derived from the book “The Project Management Question and Answer Book.”

What is Risk Control?

The process of monitoring and controlling and keeping track of the identified and the unidentified risks is risk control. In this process we hope to identify risks that are no longer possible and risks that are coming due, as well as any new risks that may become evident. We will also monitor risk activity to make sure the risk plans have been carried out successfully. Problems that have been found out in the risk plan can help us adjust the plans for future risk activities.

Risk control and monitoring are part of the risk management process and must be started early in the project and continued until the end. As the project progresses, we will find that many of the risks will change, some will no longer be possible, others will happen and be disposed of, and new risks will be identified. In addition we will learn about the project and the risks associated with it and adjust our vision of individual risks.

The level of risk tolerance should be monitored as well. The attitude of the stakeholders will change during the course of the project. Communication with all stakeholders is important since it gives us a means of assessing changes in their risk tolerance.

Risk control may involve changing the way we look at risk. There are several reasons why this might take place. The risk tolerance of the stakeholders may change; the risk tolerance of the project team may change. As the project progresses toward its completion, certain risks that were thought to be very important to the success of the project may become risks that are no longer thought of as being so important.

In the beginning of the space shuttle project, the heat-resistant ceramic tiles were originally thought of as being one of the major risks in the program. If the tiles were lost or their integrity was compromised, the heat of reentry, some 3,000 degrees Fahrenheit, could reach the airframe’s aluminum structure and cause breakup of the ship. As time went by and NASA flew over one hundred missions with the space shuttle vehicles and the whole take-off and landing process became routine, the perceived severity of the risk diminished. During this time there were minor failures of the reentry tiles, but these failures proved to be minor repairs, and the shuttle vehicles suffered only minor damage. A program to develop a method of repairing risks in space was discontinued because it was deemed impractical. Part of the impracticality was probably because of the perceived reduction in the probability and impact of heat shield failures.

On February 1, 2003, just three days after the anniversary of the crash of the space shuttle Challenger, Columbia, the oldest space shuttle in the fleet, disintegrated on approach to landing. At this writing the investigations have hardly begun, but the heat shielding tiles are once again suspect because there is little that can go wrong on reentry except for a heat shield failure.

We see that during the project, the evaluation of the risk of heat shield failure began as a high risk. As time went on, the risk was revalued lower and lower. After the crash, the valuation of the risk has no doubt been raised higher than its former level.

In all projects, as we gain knowledge and experience about the project and its risks, we will change our attitude toward the risks in the project. This is natural and important. As we learn, we must change the level of effort we spend in certain areas or we will never have the resources, time, or money to complete any project.

A control system for risk is influenced by the organization the project is being managed under as well. In a project that is high in risk, we might have a person who is at a high level and is exclusively responsible for managing risks. On projects that are relatively routine by comparison, the risk manager may be the person responsible for the tasks that are most affected by the occurrence of a risk. These persons are responsible for communicating risk progress to the project manager and other affected stakeholders.

Risk audits can be used to document the effectiveness of the risk plans and the strategies that were used to mitigate, avoid, or transfer risks. A judgment can be made as to whether it was cost-effective to ignore the risks that were ignored.

Deviations in the project performance may indicate the effect of risks on the project. The earned value reporting system is helpful in identifying trends in performance on the project. Generally, schedule slippage and cost overruns are the result of some problems that have occurred. Trends in certain areas may indicate that risks are more severe than was anticipated or that new risks have taken place. One important product of the earned value reporting system is the indication of the cost and completion date at the end of the project. The sooner these slips in schedule or budget overruns can be communicated to the stakeholders, the better it will be for the project. Schedule slides and budget overruns that are severe enough can result in project termination.

A workaround is an unplanned response to a risk that was previously unidentified. These are the unknown risks that were discussed at the beginning of this chapter. They are also the risks that were passively accepted since these were deemed to be risks that would be ignored. Workarounds are paid for from funds from the contingency reserve or the management reserve, depending on whether the risk was identified and accepted or whether it was unknown until it occurred. In any case, the funding for the workaround comes out of these accounts and is put into the operating budget of the project, and a new baseline is created.

Since contingency plans and workarounds are not part of the project baselines until they occur, they should be initiated and approved by the execution of an official change notification. Remember that changes to the baselines should require an official change notification as the vehicle for showing the change in funding, schedules, and scope resulting in a new and current baseline.

Defining Risk Management – Part 8: Risk Response Finale

In this Part 8 of a nine-part series on Risk Management, we conclude the discussion of Risk Response. Here we go into detail on where money usually allocated for the different strategies of avoidance, acceptance, transfer, and mitigation. The following information, for the most part, is from an excerpt of the book “The Project Management Question and Answer Book.”

Risk Strategies and Money Allocation

Perhaps it would be a good idea to review how the money is allocated for different risk strategies. Risk avoidance is frequently going to cost some money. The money that we spend to redesign the project so that the risk is eliminated is money that will have to be spent regardless of the probability of the risk. The additional work of doing the redesign and adding more expensive parts will be part of the operating budget. No money needs to be put into the risk reserves if the risk is completely eliminated. If the risk has already been allocated funding in the contingency budget, the increase in the operating budget can be taken from the contingency budget.

Risk acceptance will have money put into the contingency budget if the risk has been identified. If the risk is an unknown risk and has not been identified, the money for it will be roughly estimated and become part of the management reserve. If the risk does happen, the money is taken from the contingency budget or the management reserve and moved into the operating budget when the plan for dealing with the risk is put into place.

Risk mitigation will have money put into the contingency budget to handle the risk if it occurs. There will also have to be money put into the operating budget to take care of the cost of the mitigating activities that are being taken for this risk. The mitigation of the risk will reduce either the probability or the impact of the risk, and the contingency budget should therefore be reduced.

Risk transfer requires money to be put into the operating budget to pay for the additional cost of either subcontracting the risk or buying insurance for it. The money to do the work for the activity affected, not including the risk cost, was put into the operating budget when the task was created. The cost of the transfer, either the additional cost that the supplier will receive or the cost of the insurance premium, must be added to the operating budget. This money can be taken from the contingency budget.

The operating budget of the project, sometimes called the performance budget, is the amount of money needed to do the things that are planned for in the project. This includes all of the work to produce all of the deliverables that were planned for in the project. It is not the total project budget; it includes funding only for the things that are planned for. Subject to limitations in the project policy, this money can be spent freely by the persons responsible for the tasks of the project as long as the expenditures are following the project plan.

The contingency reserve is the money to do the things that may or may not have to be done but that have been identified. This is where the funding for risks that actually take place comes from. When a risk takes place, the project manager authorizes money to be taken from the contingency budget and placed into the operating budget. Generally the project manager must approve money transferred from contingency reserves to operating budgets. In larger projects a subproject manager may approve these funds. The transfer of funds must include any appropriate changes to scope or schedule.

The management reserve is money that is set aside for the risks that have not been identified, the so-called unknown risks. This transfer is made when a risk occurs that has not been identified and money must be spent to solve the effects of the risk. The use of these funds usually has to be approved by a manager one level above the project manager.

In the final excerpt on Defining Risk Management (Part 9), we’ll discuss Risk Control.