How many times have you heard someone dismiss a potential risk? I have a list of “phrases to fear” as an analyst. On that list is this phrase: “That’ll never happen!”
But what if it does?
As I write this, it’s been almost exactly a year since our CRM conversion project nearly imploded. Why? Because a key risk manifested itself. The consulting firm we had hired to complete the project quit with no notice and left us stranded.
Fortunately, we had identified the risk and had a plan in place so we were able to recover. Having said that…while we did a lot of things right, there were also things we could have done better. Let me share the story and follow it up with some tips on risk management.
It started off so well…
If you’ve been following our series this year, you know that we needed to transition to a new CRM package. Our existing package had been heavily customized to track certification program achievements. Unfortunately, the customized code was no longer working properly and the consultants who originally built it were no longer available.
Frankly, the project itself was just one big, giant risk. Our project involved:
- A business-critical system
- Specialized requirements – off-the-shelf wouldn’t cut it
- Knowledge gaps – no access to the original customization team
To reduce the risk, we asked the new CRM vendor to recommend their top consulting partner for data conversion and customization efforts.
After doing some careful vetting, we signed an agreement with Company X in May of 2024 and got to work. We let Company X know that we had a deadline. Because summer is typically lighter for training classes, I cleared most of my calendar for the months of June, July, and August. Our account manager assured us that they would have everything ready for testing in 3 to 4 weeks.
But, problems started to surface...
I’m sure it will come as no surprise that I had developed detailed documentation about what we needed. I sat down with Company X’s developer and reviewed everything. The developer assured me that he understood and was ready to get going.
Fairly shortly thereafter, the developer did a demo for me. He thought he had the certification logic working…but he didn’t. I went back through the requirements with him and was once again assured that he understood what needed to happen.
Then, things got a little tense…
This turned into a repeating loop. I’d get an update and test it. Some things would get fixed, but others would get broken. With our deadline looming, I got frustrated and asked the Account Manager for a meeting.
The Account Manager and I sat down and reviewed our progress. I told him that with only 5 weeks to go, we could not continue to get updated code every 3 – 4 days only to have it fail predefined test cases. I needed two things: more thorough testing before turnover and a faster turnaround time. I asked him to respond to me with a clear plan for meeting our deadline. I made it clear that we were willing to adjust and adapt on our end as well, but needed to know how best to help them accelerate their process.
Finally, this happened...
The very next day, Bob and I received this email:
That’s right. They quit. Via email. With no notice. And the cherry on top? “Please be advised that we will not be available for further discussions related to this project.” Wow. Just wow.
What We Did Right
By now we’ve had the time to assess how we planned for and responded to this risk. Some things we did well:
We identified that there was a risk.
It sounds obvious, but recognizing a risk is the first step to preparing for. Too many projects get derailed because of risks that are never identified. We knew working with an unfamiliar firm was a risk, but without the skills to do the work ourselves, it was one we had to take.
We realized that risk isn’t static.
We broke the work up into bite-sized pieces and monitored progress along the way. That let us spot variances before early, before they jeopardized our deadline. As the project progressed and things began to go sideways, we reassessed the probability of this high-impact risk, moving it from low to medium to high.
We had – and used – a contingency plan.
Once this risk reached the high probability stage, we took action. We brought in a trusted colleague to review the code and give us an independent assessment. We dedicated another resource to testing and made it our top priority to accelerate our feedback loop. We didn’t just sit back and hope it would get better – because that almost never works!
Where We Goofed
There were also some things we could have done better:
Better confirmation of understanding.
You know that gut feeling you get when somebody says they understand something but you’re pretty sure they don’t? I had that with the developer. All the head nods and “I got its” didn’t convince me. I put my instructor hat on and tried again, using different visuals and techniques to convey the information.
As it turns out, none of that really worked. I should have asked the developer to restate the information back to me so I could confirm their understanding. I didn’t do that because I was concerned I’d offend them – my doubt might have been interpreted as condescending or untrusting, and I didn’t want that.
Next time, I’ll trust my gut and do a better job of confirming a mutual understanding, no matter how awkward it feels.
Better stakeholder analysis.
Mid-project, the consulting firm quietly replaced their offshore developer without letting us know. When I found out, I did a bad thing…I made an assumption about the reason for the switch and the qualifications of the new person. I assumed that the offshore developer was replaced to improve code quality and turnaround time.
I was wrong. Next time I’ll go back and assess the new (and very important) stakeholder.
A contingency plan that covers the worst case.
We were totally caught off guard when the consulting firm walked away. Thankfully, our trusted colleague stepped up for us. In less than a week they learned the scripting language for our new CRM and developed the certification logic. I dug in and did the data migration myself. Mary and I spent countless hours testing the logic and validating the data transfer. We met our deadline…but you can probably guess what my stress level was like!
Our contingency plan hadn’t considered this scenario because…well…we’d fallen into the “That’ll never happen!” trap ourselves. We thought we might miss our deadline…or that it might cost more than projected…but we never dreamed that our highly-recommended consulting firm would just quit.
Takeaways
It’s so easy to skip risk analysis – or to dismiss potential risks. Remember these tips:
- Identify the risk – and if it has a significant probability or potential impact, plan for it!
- Continually monitor your risks – they aren’t static
- Respond quickly – if a risk begins to manifest itself, be proactive in addressing it
We’re providing a tool to help you: our “Risk Response and Planning” Job Aid. This guide outlines different risk response strategies and offers practical tips on when and how to use each one. It also highlights key factors to consider for each approach.
I hope the next time you begin a project you’ll ensure that risks have been properly identified and planned for. Your team – and your stress levels! – will thank you!
Best,
–K.
Something Extra
I really do have a list of “phrases to fear”. I previously shared them in a blog – how many of these have you heard?
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
