The project manager must consider who they will need to communicate with. This will include which stakeholders should be communicated with. One way to do this is through stakeholder analysis, to assess their interest and power associated with a project. By considering the whole of the project life cycle and all the parties involved at each stage, the project manager will be able to successfully identify all of the parties to be communicated with.

The project manager will need to decide what needs to be communicated. This may cover things such as upcoming events related to the project, financial information, environmental considerations and potential issues, to name a few. Once the project manager has decided what should be communicated, they can link this to the above consideration of who should be communicated with.

The project manager should consider how they will communicate when required. This will depend on what is being communicated and to who. Examples of some forms of communication are formal written, informal written, formal verbal and informal verbal. Some of these methods may be deemed to be more effective than others.

The project manager will need to consider when communication should occur and, if more than once, how often. For example, it may be necessary to communicate plans to stakeholders during the concept phase to make sure there is early involvement. An example of another issue to consider is whether communication with a public body is required at a certain time before work begins. If so, this should be documented in the communication plan and project plan.

The project manager should consider the cost of the various communication options. Different options can vary greatly in cost. For example, having a conference call with employees of the organisation around the world would avoid the high travel and time costs of bringing all the individuals together in the same location. However, this may sometimes be necessary. These considerations should be related back to the project budget to see what was originally allowed for and therefore what would be acceptable.

An issue log is a record of the issues that have occurred on the project. Typically, it is maintained by the project manager and includes those things that are having a significant impact on the likely project outcome. For example, the ongoing poor performance of a contractor or the inability of the users to clarify their requirements could be issues. It’s important to record and highlight these sorts of issues because they are often beyond the ability of the project manager to resolve. For this reason, we escalate issues to the next level of management. Typically, this will be the sponsor, but in a contracting organisation, this could be senior management. The aim is the get the support of senior management in resolving the issue.

What do we need to include on our issue log?

• It’s important to identify each issue with a unique ID number. This prevents duplication and means that the issue can be tracked effectively as it matures. It may be that as more information emerges, we discover more about the issue and want to refine the description. By maintaining a unique ID, we can track the history of the issue through various issue logs.
• The description of the issue needs to be comprehensive. It should summarise the cause of the issue and the impact on the project. For example, ‘Lack of resources’ would be a poor description. A better description would be ‘A lack of testing resources has introduced a 6-week delay on the project’. This more detailed description is much more likely to stimulate action from senior managers.
• It’s beneficial to know who initiated the issue. The issue raiser can probably provide the best information of the cause of the issue and possible ways in which the issue could be resolved. By recording their name, we can also see trends in the issues as they emerge. Maybe one part of the project has more issues than another.
• It’s essential to evaluate the impact of the issue on the achievement of the project success criteria. As a minimum, this would include an impact on time, cost and scope. This assessment will guide the project manager and senior management in evaluating how critical the issue is to the delivery of the project. In some projects there may be many issues that need to be prioritised. Impact is one way of prioritising them.
• The status of the issue summarises the action take so far. It would map to the stages in the issue management process. This might include:
  • Raised: identified but no further action.
  • Assessed: the impact of the issue has been evaluated.
  • Escalated: the issue has been raised with senior management.
  • Closed: the issue has been impacted or resolved.

Tracking the issues in this way means we know where each issue is in the overall process.

Using structured project life cycles can prevent poorly conceived projects from being commissioned. This is achieved during the concept stage where the business case is developed. The use of gate reviews puts the project under scrutiny, and it may be the case that there is no sound reason to start the project. This would lead to an early termination of the project. For example, a motoring company decides it wants to build a new luxury car to compete with other brands. However, market research shows that the market is declining for this type of vehicle. Therefore, the project is terminated at the end of an early gate review.

A structured life cycle allows for resources to be planned more effectively, both in type and numbers. By paying attention to resource management early on, this will allow for a high-level view of the types and quantity of resource required throughout the project. This should form part of the project management plan which is developed during the definition state. For example, a project to build a housing estate will in all likelihood require architects, plumbers, carpenters, etc. The order and likely time that they are required can therefore be planned early on and the resource requirements better managed.

Using a structured life cycle gives a better indication of when key project reviews are to be carried out. It means that key stakeholders will have a rough idea of when and where they will be required to attend gate and stage reviews. For example, a 5-year project to build a new railway will require some very senior politicians and directors to attend reviews. Given that they are almost certain to have busy diaries, it would benefit the project greatly to ensure they have advance warning of when they are required.

A structured life cycle also ensures that the project remains viable through the use of stage reviews. These types of review are carried out during the development phase and ensure that the case for the project is continually reviewed against any changing circumstances. For example, a project to build a hotel will continue to assess whether what they are building is going to meet stakeholder expectations. Even when the building works are being carried out, it may be decided to change the scope slightly to ensure the final product delivers maximum value.

Finally, a structured life cycle is useful for ensuring that appropriate attention is given to the handover and closure stage of the project. This stage can sometimes be a little overlooked so it’s important that it’s carried out in a thorough manner. For example, a project to implement a new IT system cannot simply be put into place and not handed over correctly to the internal help desk team. It may be that the internal team require training on the product to ensure a smooth transition into service.