If you’ve been reading our newsletters for the past couple of years, you know that my husband Bob and I purchased the rights to B2T’s training materials from Netmind in the spring of 2023. We had more projects on our hands at that point than we knew what to do with. The website had to be rebuilt, the courseware had to be rebranded and brought up to date, we needed email and other infrastructure set up…the list went on and on.
A few weeks in, Bob came to me and said “We need to find an alternative to our current CRM package. I want to migrate to something else”. After I got past my knee-jerk reaction – which was something along the lines of “No way, not another project, not now!” – I put my BA hat on and asked the first question you should always ask when someone comes to you with a project idea:
Some of the most important analytical work is done as a pre-project or gating/portfolio management activity. Before an idea becomes a project, it’s important to:
- Identify the real business need
- Provide stakeholders the information needed to decide when or whether to address the need
- Review other portfolio projects and initiatives to help identify cross-project/initiative impacts
The BABOK® Guide v3.0 classifies this work as “Strategy Analysis”. In a perfect world, someone with strong analytical skills leads these pre-project activities.
Kate McGoey, a former B2T staffer, always likes to say “I can do anything, but I can’t do everything”. That’s the situation we were in – with the talents present in our team we could do almost anything, but we certainly couldn’t do everything. That meant that we needed to make sure that we understood the real need for the project because it was going to have to compete with all the other projects for scarce resources. We needed to develop a business case. Steps involved in business case development include:
- Understand the problem to solve
- Set goals and objectives
- Establish a high level scope
- Identify risks
- Consider alternatives and do cost-benefit analysis
- Summarize and document the results
1
Understand the Problem to Solve
Bob’s response to being asked “Why” was something along the lines of “Because our current platform is expensive and a pain to use.”
Hmm.
While those things were certainly true, they weren’t really what I would define as a problem. In our Establishing Business Value with OKRs and KPIs class, we define a problem by saying:
“Problems block someone’s ability to meet or achieve a goal. They require solutions.”
An issue is defined as:
“Annoyances, hindrances, points of contention or concern. They are typically much more minor than a problem. Resolution for issues may be readily identifiable or even unnecessary. Issues can often be managed without having a true solution.”
Things like “expensive” and “a pain to use” certainly sounded more like issues to me. I needed to do some more digging. Ultimately, we did identify some real problems – as an example, certain portions of the custom code that tracked student badges and certifications weren’t working properly. We definitely needed a solution for that!
Sometimes the real problem isn’t as obvious as ours was. Techniques like fishbone diagrams and the Five Whys can help you identify the real “root” cause of a problem. Our Five Whys Template provides a way for you to guide and capture conversations so you increase the likelihood that you’re focusing on a real problem and not just a symptom.
2
Set Goals and Objectives
The next important question to ask is, “What does success look like”? We developed goals (desired business outcomes) and objectives (SMART measures of success) to ensure that we all understood the big picture. There are many other ways to establish a vision of success – OKRs, KPIs, etc. – but you must ensure that the entire team has the same understanding of the mission.
3
Establish a High Level Scope
Our current CRM package had been in use for many years. Over that period of time it had been customized significantly. In addition to just tracking our customers it kept records of all the classes our students had attended, what badges and certifications they achieved, marketing campaigns, and even our instructors’ schedules. In order to accurately estimate the effort involved we needed to ensure we had a solid understanding of:
- Data that we would need to migrate
- Processes that would need to exist – or be created – in a new CRM
- Interfaces to people and systems that would be needed
We started by developing models of our as-is state and found a few unexpected surprises along the way. There were interfaces to external systems like Pardot and Mailchimp that were no longer being used. The instructor scheduling function had broken some time ago but our staff was just working around it. The conversations we had during this step allowed us to ask some really important questions: How much of the existing functionality did we *really* need? And what would we like it to do that it wasn’t currently doing? It’s so tempting with a project like this to assume that what you have is what you need…except it frequently isn’t.
4
Identify Risks
This is the part of the project that kept me up at night. We had over 20 years of critical business information stored in our CRM and we couldn’t afford to lose it. The consultants who had built our custom code were long gone and there was no documentation. Nobody on the B2T staff had the skills necessary to customize a new package so we were going to have to use an external resource. I’m pretty sure at times I got a stress rash just thinking about all the ways this could go wrong.
Even though thinking about risks is stressful it’s really important. Of the four common risk response strategies (accept, avoid, transfer, and mitigate), the default is “accept”. I call that the “Oh well!” strategy. In other words, if you don’t proactively put some other plan in place, you’ve basically said “Oh well! That could happen! Guess we’ll deal with it if it does!”
We ended up being really grateful we’d thought through some of our risks when a big one manifested itself later in the project. I’ll share more about this one later, but after three months the external consultants we’d hired quit with absolutely no warning.
5
Consider the Alternative and Do Cost-Benefit Analysis
There’s almost always more than one way to solve a problem. It’s important to consider alternatives before settling on an option. Bob already had one in mind when he came to me – switching to another CRM package. While that ended up being the option we chose, we could also have:
- Rebuilt the custom code in our current package
- Developed our own solution for things that were not natively done by the CRM
- Supplemented the CRM package with something better suited to handling the training-related aspects of our work (like a Learning Management System).
A critical component of the decision-making at this stage is cost-benefit analysis. Each of our potential solutions had very different costs associated with them. They also delivered different benefits and had different potential drawbacks. All of those had to be weighed as we finalized our solution choice.
6
Summarize and Document the Results
Honestly…we didn’t do any formal documentation of the business case on our project. At best there’s a spreadsheet we built to summarize the one-time and ongoing costs we identified for each option. That makes a good point, though. The amount of documentation you develop should always be driven by your audience. Our audience (Bob and I) didn’t need a formal document, and we didn’t need to “pitch” the idea to ourselves. There was no value associated with creating any formal documentation.
In most business situations, though, someone (or a group of someones) must approve the project recommendation. Our class Developing an Effective Business Case walks you through developing, documenting, and presenting a compelling business case that is tailored to the appropriate audience.
One of the tools we share in that class is our Business Case Template. This template can be a good starting point if your organization doesn’t already have a predefined format for business case submissions.
And…we’re off!
Ultimately we decided that this was a project we needed to prioritize. Check in with us next month as we roll up our sleeves and get started!
Until next month,
– Kathy
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.
