Left unchecked, issues (like risks) have the ability to kill your project off quickly. Not only that, but if you don’t have mechanisms in place to control their impact they can give you sleepless nights and even affect you personally.

The project management method PRINCE2 defines an issue as ‘a relevant event that has happened, was not planned, and requires management action. It can be any concern, query, request for change, suggestion or off-specification raised during a project. Project issues can be about anything to do with the project’.

Issues can relate to people, the things you’re building, money or the suppliers you’re using. Like managing risks, managing issues is a key requirement of a project manager.

To be able to manage them, you first need to know about them. That sounds obvious, I know, but I’ve known project managers who have been unapproachable, which has led the team either to try to work around them or, worse, not to tell them of any problem.

If you’ve read this book sequentially and have decided to practise everything you’ve read in chapters 1 through 41 (good for you, by the way), then approachability is not going to be an issue. If not, you’ll need to work on this quickly. Only once you know about an issue can you act on it, and act you must.

It is essential that you seek to clarify the problem and identify its root cause, which may not be as easy as it first seems. You’ll need to draw on the people closest to the problem to get clarity on its nature and seriousness.

Once you have done that, you need to write it down. Leaving it to fester in your head isn’t good for you or your project and will block you from taking the next important step, which is to compare it to all the other issues you currently have.

If this is your first issue, then the priority is pretty clear. If it’s your fifteenth or sixteenth, it’s not so straightforward, but the last thing you want to do is to waste time resolving this particular issue, if the people and time are better served elsewhere. ‘The key is not to prioritise what’s on your schedule,’ says Stephen Covey, ‘but to schedule your priorities’. Once you know what to work on first, then you can gather more information about what it will take to change something.

In projects where you’re using an agile method, change can happen quite late. One of the principles of the Agile Manifesto is, ‘Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage’. It’s likely, therefore, that you’ll have a different approach to managing change in these projects, but you still have to manage it.

For waterfall projects you need to estimate how much it will cost to introduce the change, what the impact will be on the end product and expected outcomes of the project (it should enhance them), and how long it will take.

You should also identify the trade-offs required to deliver it within the planned time and cost. Saying yes to every change request is project management’s equivalent of opening Pandora’s box — you could end up releasing all the world’s evils, along with any hope of successful delivery.

Once you have all the information, you need to make a decision. If it’s not your decision to make, then escalate it to the responsible person so they can make it. Either way, the decision needs to be made, and the answer should be ‘no’ as often as it’s ‘yes’.

In a 2012 review of large-scale IT projects, McKinsey identified change control as one of the core project management practices necessary to deliver projects on time, to budget and at value.

Projects don’t fail because of scope creep, they fail as a result of poor scope control. Project leaders are in control at all times.