Tasmanian IT News   •   June 2, 2018

One of the biggest lessons I’ve learned over the years is that issues are not problems, they are opportunities.  Too many projects and organisations build unreasonable anxiety around issues, raising issues and managing issues.  Too much focus is directed on who is to blame, how it happened and how can we hide it.  This results in problems, but the issue was not the problem, the way the issue was approached was the problem.

The following 9 steps can assist with approaching issues in projects effectively.

1. Validate the details

If someone comes to me raising an issue with a sentence starting “I overheard…”  I stop them immediately.  Chinese whispers are a constant distraction in projects that can create issues from incorrect information.  If you are raising an issue, make sure you have baseline facts, not assumptions.

2. Validate that it is actually an issue

95% of “issues” raised to me on a daily basis are project inconveniences, not project issues.  If a individual task has slipped by a day, but it’s not on putting the critical path at risk, it’s an inconvenience, not an issue.  However, a history of regular minor delays from a specific area could become an issue.  In this scenario – log a risk and manage the risk.

3. Raise it early

During my early days in projects, I felt the need to solve issues before presenting them to my line manager, the business, Steering Committee or whoever was involved.  The intention was good, but the practice was poor.  It’s simply not fair or reasonable to hold back issues from key stakeholders for many reasons.  Step 2 above is a key example – what you think is an issue may not be for them.  Or with enough notice, management may be able to take action you didn’t realise was available to correct the path of the issue.  Either way, ultimately they are accountable, and it is your responsibility to raise it early, it’s their responsibility to thank you for giving them a chance to take early action.

4. Don’t focus on blame

One of the most toxic impacts of managing issues is the blame game.  There is no benefit during the management of an issue to have the default first step grilling a staff member.  Projects need to move fast, and seeking blame distracts from finding a solution, reduces staff moral resulting in a reluctance to raise issues and creates a culture that will stop a project from reaching success.  It is appropriate to review an issue, as long as it’s for learning purposes.

5. Identify the core “what if’s”

As the saying goes “there are a thousand ways to skin a cat”, and with issues the same applies.  There are infinite possible outcomes of managing an issue, which can become overwhelming.  So what are the most likely scenarios that could play out?  Focus on them.  Then consider a handful of the boundary cases, but don’t get caught up in a vicious cycle.  It is important to do this step before starting documentation – as with most things, it’s 90% planning, 10% execution.

6. Document it

So you’ve validated there is an issue, you’ve raised it early, you’ve focused on resolution and you’ve considered the impacts.  Now is the time to document it (formally).  There may be many emails, meeting minutes, whiteboard sessions involved in getting to this stage, but if it’s not formally documented, it’s not being managed.  Whether you document using an Issue Report, Exception Report, Issue Register or other medium (or all!), you need to be able to clearly articulate the issue in a format that is understandable, reportable and manageable.

7. Update other documents

It is important to understand that an issue may impact documents outside of the standard issue management templates mentioned above.  If an issue is financial, the budget needs to be updated.  If the issue is time, the schedule needs to be updated.  Both scenarios will likely result in a required update to the Project Management Plan and so on.  Project documents are not standalone silos, they are linked.  As such, if an issue arises, it is highly likely to impact on multiple areas and multiple documents of a project.  This needs to be a key consideration when managing issues.

8. Get on with it

This part is simple – just get on with fixing the issue.  The concept is simple, but the practice can be difficult if a pro-active, supportive culture does not exist.  Be the bigger person, lift the team and get on with it.

9. Learn from experience

This step is key, and one that is rarely handled well.  Learning for the staff involved, learning for the project and learning for the organisation is vitally important.  Focus on the situation, not the actors.  Be objective in seeking how the issue came to be, how it could have been avoided, how it was rectified and what risks need to be considered for future.  Then document.  Document how the issue came to be and use it as an opportunity to upskill the staff.  Document how it could have been avoided and add this detail to a lessons learned register or knowledge base.  Document what risks need to be considered, and add them to the risk register.

Finally, issues can be a huge cause of stress and anxiety, so I’m going to point you to another of our blogs on the “10 common thinking errors” which is a great resource by Reach Out USA which has been hugely influential in my approach to issue management.

Stressed? Anxious? OK Breathe… Challenge your thinking errors

Thanks for reading!

Sam