Nutshell: Eyes on the prize: executing projects for success

A project’s implementation phase is when we put our well-laid plans into action. But there’s still plenty to think about along the way.

The Scottish poet Robert Burns might these days have won an award for understatement when he lamented (and we paraphrase) that even the best-laid plans often go awry. When it comes to projects and project management, scoping and planning are the bedrock, the foundations on which a solid project can be built. But when it comes to the building, we need to be equally vigilant about how a project is implemented and monitored.

Projects can be complex, multi-layered things, involving a range of factors that can be difficult to track, monitor and control, let alone deliver successfully. Even when a project is running smoothly, we still need to have processes in place to monitor and report on progress, making sure those key project elements – cost, time, quality and scope – are on track to meet project goals and objectives. More often than not, we’ll have to flex our plans as one variable or another changes. A curveball or a spanner in the works can easily make things veer off course.

This is also the stage where regular communication is essential and we’ll need to put into action that stakeholder mapping with a clear communication plan, regular reports and project meetings. 

So, there are plenty of plates to keep spinning as a project moves through its implementation or delivery phase. As project managers, it’s important for us to feel in control over this crucial stage. And, for that, we’ll need a robust system for making sure that things are on track.

Revisiting the iron triangle

When we’re thinking about implementation and monitoring, it helps to think about where things can potentially go wrong, and what that might mean if we find ourselves in that situation. The iron triangle of key project variables – time, cost and quality (or performance) – helps to keep us focused on the things that really matter.

Time

What stage are the various tasks at? Are they yet to be started, are they in progress, or are they completed? How much time has been spent on each of the tasks so far and how long is still needed to complete them?

We can use this information to assess whether tasks are on track to be completed within the timescales, or whether we need to rearrange resources to ensure that they meet their target completion dates.

Cost

How much has been spent so far? Measure this and add it to the planned cost of tasks still to be completed to calculate the estimated total of all costs that will be incurred.

We can compare this to the total budgeted cost that was agreed upon during the planning stage to see whether we’re still on target or whether we need to make changes.

Quality of outputs

When it comes to quality, we should look to create and encourage a culture of commitment to quality in our team, and lead by example. We need to show that top-quality work is essential to the success of the project. Quality control systems don’t need to be overly complicated, but they do need to effectively measure what we need them to measure.

Quality can be tricky to define and measure so it’s important to set expectations. We need to clearly describe what will be delivered and how. We can measure quality by comparing the work that is being done on the project to the methods, procedures and standards that we outlined in the planning phase, allowing us to measure the extent to which these guidelines are being followed.

Having measurable outputs means we can more easily assess them at various stages, which is why setting SMART goals and objectives and having a clear sense of deliverables is so important in the planning phase.

Using trade-off analysis

As we’ve seen, the three elements of the iron triangle are interrelated, and balancing them can be challenging.

The three sides are constantly influenced by the internal and external environment: costs can escalate, schedules can overrun, people can underperform. If one part of the triangle stops running to plan, one way to respond is to consider how we can trade off one or both of the other factors so that we can still deliver the best possible outcome.

For example, if it looks as though the project won’t meet its completion date, we could decide either to increase the budget or to decrease the quality (or performance) of what’s produced. That can mean making some hard decisions. Trade-off analysis is designed to help us make the best decisions possible to produce the best possible outcomes.

Any trade-off decisions we may make will be based on the available alternatives and the constraints of the project. They are further complicated by the fact that it is not always easy to trade-off one factor independently of the rest.

To help, project management expert Harold Kerzner offers a methodology that we can follow when making trade-off decisions:

Recognise and understand the project. Trade-offs are generally forced by errors or unexpected problems. When a forcing factor (or problem) occurs, we must understand what the issues are and how they’ll affect the project.  

Review the project objectives. Environmental factors, contexts and situations may have changed since objectives were originally set at the start of the project. Are our original objectives still achievable, realistic and relevant?

Analyse the project status and environment. We should assess the project status by comparing the actual time, cost and quality/performance with where we thought we’d be at this time. The project environment should also be considered here, including elements such as the financial risks, risks to potential future contracts and risks to an organisation’s competitive position.

The analysis should include discussions with all stakeholders to determine time, cost and quality priorities. Once these have been decided, the project manager should review the work that needs to be done from now on.

Identify alternative courses of action. When we’re identifying alternative courses of action, we need to consider all possible options for trade-offs:

• Time. Is a time delay acceptable? Do we have sufficient resources available for the new schedule? What costs will be involved? Are there any risks to other work if we take this course?

• Cost. Can anything be done to reduce the remaining costs? Is a cost increase acceptable?

• Quality. Can the agreed specifications still be met if there’s a reduction in quality? Are the specifications negotiable? Are there any liability issues for the product or employees?

Choose an alternative. After conducting our analysis, we can then select the option that will produce the best possible outcomes.

Revise the project plan. The project plan will be revised, outlining the new objectives for time, cost and quality, and the required resources and schedules.

It may be the case that either time, cost or performance is fixed and therefore non-negotiable. In this case, trade-offs will be made in one or both of the other two factors.

Where time is fixed, cost varies with quality. We may have to compromise quality which could mean not meeting objectives or the costs may have to increase to complete the project on time. It’s also possible to trade off costs and quality simultaneously to meet the schedule.

Where cost is fixed, quality varies with time. In this scenario, we’ll need to decide whether it’s more important for the objectives to be fully met, meaning the schedule will overrun, or if it’s more important to complete the project on time, compromising on quality. Maybe both time and quality have to compromise to meet the costs.

Power to the people

Many of the problems that might arise and impact on our key variables are related to the people involved in the project.

That means keeping on top of the skills we have available to us to deliver, adapting as needs change. We need to keep on top of how many people we need at any one time; what we need them to do; the skills they need to do the work – and all of this while keeping within our people budget.

We might lose key people during the project, so it’s wise to have in place contingency plans for reallocating tasks or hiring in new people, perhaps on a freelance or contract basis to keep up project momentum.

Giving people on the project team the opportunity to learn new skills is good for us and motivating for them: a real win-win.

The monitoring and control cycle

Ideally, of course, we’ll be able to head off potential problems before we have to make a tough trade-off decision. This means adopting a monitoring and control cycle that will help us to stay on top of what’s happening compared to our plan. We will then have the information we need to intervene and course correct early if we need to.

Just as there’s no fixed way to scope and plan for a project, there's no fixed way to monitor implementation. Much will depend on the size and type of project and the stakeholders involved. But whatever the project looks like, we will need a methodology or cycle for making sure that all of the key factors are on track.

Project management expert Mike Clayton calls this kind of cycle the “beating heart” of the delivery phase. If we keep moving around the loop, we’re much more likely to catch any problems before they spiral out of control. He identifies the following key factors that we need to keep an eye on:

Reporting

Regular reporting is crucial for lots of reasons. It gives us an audit trail and improves transparency and governance. It keeps colleagues and stakeholders up to date with how the project is going. Reporting also helps us to keep in touch with people whose advice and guidance we might need; for example, when making a tricky decision or to help us secure more resource.

Risk and issue management

We need to remain alert to issues that emerge or risks that are on the horizon. Keep risk registers under review and up to date. Make sure team members are also on the look-out for any problems and have good channels for them to communicate these to us.

Quality

There are two elements to this: quality assurance and quality control. Quality assurance means making sure deliverables match the expectations set for them. Quality control is about meeting the right standards. Both are crucial.

Team meetings 

Regular team meetings keep members briefed and provide a forum for sharing information and experience. They help to keep everyone engaged and focused and are also an opportunity to celebrate successes, to work together to solve problems and to identify issues that need to be addressed.

Craft meetings so that everything is covered but they take up no more time than is needed. Don’t be too rigid about format: the nature and style of meetings; they can flex and change depending on what’s happening at any particular stage.

Team morale

Keeping up team morale is essential at any time, and especially at crunch times or when the going gets tough. But we can’t just work on team morale when we’re under pressure or leave it to set pieces such as team meetings.

We have to take every opportunity to build rapport and engage with our colleagues, supporting and guiding them, and listening to, and acknowledging, their views, feedback and any concerns they may have.

Harvest and use lessons learnt

Learning lessons from the project should not just be left to the post-project evaluation. It’s something we should be actively doing throughout, so that we can learn and apply those lessons as soon as possible. It means we can implement any changes for the better at the first available opportunity.

Constant stakeholder engagement

We know that stakeholders are a vital component of project success, but it’s easy to lose sight of how important they are once project delivery is underway. But we need to remember to check in with stakeholders and keep them on board so that we keep them informed and can deal with any concerns they have.

Change control

If the project is going well, it’s a given that someone will take that opportunity to ask for add-ons or changes. We must balance the need to stick with the original plan (where that makes sense), not making changes for change’s sake, with a recognition that very few projects come to fruition without some (necessary) change along the way. Change within a project is not always a bad thing. But we need to plan for change actively and intentionally, rather than simply agreeing to ad hoc requests.

Clayton suggests that we should take a quiet moment every week to let our minds wander over the project, to review how things are going against our criteria and to think ahead. Has anything been missed? Sometimes, while taking a step back, we’ll have an idea that takes our thinking in a new direction.

Monitoring with RAG

RAG reporting is a simple technique that can help us with our project tracking, monitoring, and control. The 'RAG' in RAG reporting (also known as RAG status or a Delivery Confidence Assessment) is an acronym that stands for: Red, Amber, Green, based on the colours of a traffic light.

So, when we’re updating a project status report, we can use the colours to indicate in a clear and visual way how well different elements of a project are performing. Unsurprisingly:

Red generally means that we have some problems and the project team needs to resolve them in order to deliver the project successfully.

Amber usually indicates that we may have potential issues in the future. We’ll need to keep an eye on these issues or variables.

Green is usually used to highlight that the project is going well, is progressing as planned, and according to the agreed plan. 

RAG reporting can be applied in a number of ways: either to a whole project; key variables (such as budget); a work stream or strand of the project; a risk or potential exposure; an issue or a proposed change.

It’s also flexible because it allows us to identify exactly how we use those colour codes. So, we can set our own definitions and tolerances for what we mean when we say we’re code red for that part of the plan or green all the way elsewhere. For example, this could be something like:

• Green: The project is within tolerance.

• Amber: The project budget or timescale is +/- 5% and the scope is within tolerance.

• Red: The project budget and timescale is +/- 10% or project budget or project timescale is +/- 15% or scope is carrying unplanned changes.

With RAG we can develop and define a categorisation that’s suitable for our projects, using simpler or more complex metrics as relevant. The key thing is that everyone agrees what the colours mean and are clear about any implications.

Bear in mind, though, that RAG is a diagnostic only. It will not, on its own, solve any problems it highlights. If we decide we need to take action on the basis of an amber or red rating, we’ll need to consider carefully the right corrective action – and make it happen. 

Communication, communication, communication

We’ve already identified reporting and stakeholder engagement as two key factors when we’re monitoring implementation. When we identify who our key stakeholders are at the scoping and planning stage – hopefully getting them fully on board with the project plan – we will also have started to think about how we will communicate with them as the project progresses: the information they need, how regularly they need it, who needs it, how it will be communicated (email, video conference, face to face) and in what format. 

It’s now time to put into action a clear communication plan to report on progress as the project is developed and delivered.

Preparing a project communication plan

When creating a project communication plan, there are five key steps to follow:

1. Outline the objectives.
2. Define the audience/s.
3. Decide what information is needed.
4. Agree on methods and frequency.
5. Measure success and improve.
   

Outline the objectives

What do we want to achieve with the communication plan? Are we building support for the project, improving stakeholder engagement, gathering inputs from the project team, supporting remote team members – or all of the above? 

We should align our comms objectives with the goals and deliverables of the project. For example, do we need to pay particular attention to certain stakeholders at key points during implementation? Are certain stakeholders particularly concerned about particular variables, such as budget or final quality? Consider, too, the size and complexity of the project: a small project requires a lighter touch than a long-term, multi-department effort.

Define the audience/s

Who needs to receive information about the project? Typically, this will be project sponsors, key stakeholders, the project team, external suppliers and relevant internal departments. 

Decide what information is needed

Not everybody needs to know everything. Different team members need different information at different times. By tailoring the information we provide, we save time for the recipient. We need to think carefully about what information our audiences need to know – and how regularly we communicate with them.

For example: Stakeholders will want to know about project plans, status, budgets, change requests, and risk management. The project team wants to know about their assignments, status, work in progress, issues and risk tracking, and lessons learnt. Suppliers want to know about schedules and deadlines, the status, and any delays. If there are internal departments to communicate with, they’ll want to know the status, including any changes to deliverable deadlines.

If any amendments have to be made to the original objectives, deliverables, or scope, communicate these clearly to make sure that stakeholder needs are still being met, that they’re satisfied, and to manage their expectations.

The project manager will probably act as a point person for gathering project performance data, but team members will also be involved in providing relevant updates, depending on their roles and responsibilities. We need to be clear about what’s expected of them as part of team-building in the planning phase.

Agree on methods and frequency

How frequently we communicate with our stakeholder – and the methods of communication we use – will also vary depending on audience needs.

Regular, standardised (written) progress reports can be completed easily by the team, will be understood by recipients and allow for comparisons at different project stages. Results and figures should be clear and transparent. Reports should communicate any amendments to the original objectives, deliverables or scope.

The project team itself should meet on a regular basis, either in person or via video conference. Meetings should have clear agendas, structured around key metrics, so that we can check on progress, resolve any problems and allow project team members to raise issues.

Meetings are also an opportunity to praise team achievements and highlight progress and milestones, helping to keep the team motivated and enthused. Keep the momentum going between meetings by following up every time on any to-dos and outstanding tasks.

Measure success and improve

We must track and analyse our communication plan at regular intervals. Schedule time to see what’s working, what isn’t, and what adjustments are needed. Ask stakeholders and the team for their input and document any findings to improve future plans.

Houston, we have a problem

However good our communication, and whatever monitoring and control systems we have in place, most projects encounter some problems along the way. The trick is to be alert to them and to respond thoughtfully and decisively if and when they do arise.

Even the smallest signs that things are going less well should be taken seriously. For example, if a team member is increasingly irritable or seems unable to make decisions, it could be a sign that they are overwhelmed or losing enthusiasm for the project. When we pick up on those signals, it’s best to get to the heart of the problem quickly and look to resolve it.

Other problems might be less straightforward. That’s when it’s good to involve the team in some structured brainstorming to explore all of the things that could be causing the problem before we start to think about a solution.

Cause and effect (fishbone) analysis

Developed by Japanese quality management pioneer Kaoru Ishikawa in the 1960s, cause and effect analysis is a diagram-based technique for interrogating all possible causes of a problem, not just the ones that are most obvious. It’s often known as fishbone analysis because the diagram we end up with looks a bit like the skeleton of a fish. Here’s how it works:

Identify the problem

In a box on either the left- or right-hand side of a piece of paper, write down as precisely as possible the problem being faced. Draw a line horizontally across the paper from the box, which will look like the head and spine of a fish.

Work out the main factors involved

Brainstorm the factors that may be part of the problem. These may include systems and processes, equipment, materials, external forces or the people involved. For each factor, draw a line that extends out from the long horizontal line, adding some bones to our fish spine.

Identify possible causes

For each of the factors identified, consider possible causes of the problem that may be related to that factor. Show these as shorter lines coming off the bones of the diagram.

Analyse the diagram

Once as many causes as possible have been identified, we can use the diagram to consider which causes are most likely, and either investigate these in more detail or start working on solutions.

American engineer (and creator of Murphy’s Law) Edward A Murphy once claimed: “If everything seems to be going well, you obviously don’t know what’s going on.” It’s a useful reminder that project management is not just a matter of putting together a plan and then leaving the project to run itself. Instead, we need to be on alert, actively monitoring a range of different factors as the project is executed – from the budget and scope to quality and how our people are doing – all the while keeping open clear channels of communication.

We also have to acknowledge that things will shift and change and we’ll face problems and issues we’ll need to resolve.

That can be a tough brief. But the rewards are there for those of us who can keep our eyes on the prize.

Test your understanding

• Identify the three project variables we need to consider in trade-off analysis.

• Explain what the R, A and G stand for in RAG reporting.

• Outline why cause and effect analysis is also known as 'fishbone' analysis.

What does it mean for you?

• Reflect on the stakeholders involved in a project you might be working on or planning. Think about what different stakeholders will need to know as the project progresses, and create a communication plan for how and how frequently you’ll report on progress.