These next few blogs are inspired by The GIFTD PM who asked to have more Blogs that don’t just detail best practice but talk about how you got to an end solution or action. So, I wanted to spend a few blogs going through some issues I’ve had during my career and how I managed and dealt with it.

Scenario #1. Unidentified issues arise during testing that critically risk the success of testing/schedule/go live.

Answer: I’ve had this a few times. Best practice says that we should have an adequate test plan in place that will identify issues before they occur and avoid any massive “surprises” that you might see during testing. But, I’ve had it several times that for whatever reason (too much trust in resources, not enough time to do a test plan, difficulties with testing).

Ive found that if an issue comes up, it’s critical to jump on it as soon as you’re made aware and this is critical. During testing, make sure that your team are aware and are not afraid to tell you when an issue comes up. I make this a ground rule during testing so that everyone is aware of what I’m expecting from them. Once an issue has come up, you need to do the following:

• What’s the issue? (All of it)
• What’s the root cause?
• What can we do to resolve it?
• How long does it take to resolve?
• What is the risk to resolve? /Fix?

Once you have this information, you’re able to communicate to the team about the next steps, what the impact is and analyse accordingly. It’s important that if an issue comes up, that you communicate with the stakeholders and understand the consequences of the issue that’s occured. This includes:

• What’s the impact of fixing?
  • Schedule
  • Cost
  • Time to fix
  • Risk to fixing
• Does it need to be fixed?
• Is there anything else you need to be aware of?

Issues occur in every project but the worst thing you can do is either ignore it, or try to brush it under the carpet. When I’m working with clients, I will be upfront about issues that we’re facing and give them the information that is relevant to them.

As an IT Project Manager and someone who works predominantly in software, the main risk areas that I see from my experience are in: interfaces, insufficient test coverage, poor test case quality. If you are working and preparing for testing, then I’d recommend looking at these areas to make sure that you have everything covered and if it makes sense to you as a Project Manager (e.g. you understand what is being tested, why and it’s relevance).

Scenario #2: Another PM steals your resources

This has happened a lot to me! Especially when there are insufficient resources /resources which are in high demand. When this happened to me, I tried to not panic and instead took my time to understand:

• What was the impact of the removal of the expertise?
  • Can anyone replace them?
  • What’s the schedule impact of their removal?
  • What does this mean for the project?
    • E.g. if they’re the senior developer, supporting a junior with their work, their absence would critically impact not just their work but also the work of the junior.
    • E.g. the schedule impact if they’re not able to complete the assigned work
    • E.g. guidance if they’re the Senior Architect or developer.

• What can you do?
  • Escalate to the resource manager
  • Escalate to your sponsor/senior stakeholders

If you escalate, you need to make sure that you can provide facts and consequence of the removal and also what you are expecting from them. This could include:

• Reinstatement of the resource
• Understanding when the resource will be returned to the project
• Confirmation that they understand what this removal means for the project (delay, cost etc).

You may need time to understand this but it’s worth making sure that you have formally documented everything for your project and notified the Steering group if appropriate. In one project, I escalated internally and this was enough to get my resource returned but in other projects, I’ve shown the impact of the loss through a JIRA progress chart to show what happened every time they removed my resource (the progress line went straight or down rather than going up). This was useful during the lessons learned as I could factually show the impact and cost to the project and organisation of losing my resource.

What you shouldn’t do:

These things happen. I would recommend making enemies with your colleagues by demanding your resource back or throwing your PM weight around. Instead try to look at ways that you can work together, ways that you can both work together.

Was this helpful for you? Would you like to see more of this? Let me know!