I’m the first to admit that when I tackle a new project, I sometimes jump in and get started without a lot of planning. I think that’s a natural reaction for those of us who are “doers” and problem solvers by nature. You’ve got a problem? Let me find you a solution, right now!!
I’ve heard a lot of reasons for shortchanging the scoping (or inception) phase of a project. They include:
- It’s a really small enhancement or project
- We already understand what’s needed
- We’re using an agile approach so we’ll figure it out as we go along
- It takes too much time and we have a tight deadline
Looking back on our CRM conversion project, it would have been easy for us to point to several of those criteria and skip over scoping. The fact that we didn’t save our collective behinds on more than one occasion. Let’s review the seven deadly sins of skipping scope and I’ll share our near misses with you – including one that could have been fatal to our project. Spoiler alert: it involves our consultants quitting…
Deadly Sin #1
Missing Impacted Stakeholders
We define stakeholders as anyone or anything that either affects or is affected by a proposed solution. During scoping it’s important to identify people and systems that will need to interact with your solution. It’s easier than it might seem to overlook one. Any time you miss a stakeholder you miss requirements, and the later you find a missing requirement the more expensive it is.
Remember that stakeholders aren’t necessarily a part of your solution delivery team or even the organizational unit that is sponsoring your project. In fact, they may not even be part of your organization at all:
HINT
A context diagram can be a helpful visual tool for identifying impacted parties and systems. See our quick tip “Ensuring Quality in the Context Diagram” for helpful hints!
OUR NEAR MISS
Students can visit the B2T Training website and view their course history, along with the badges and certifications they’ve earned. I totally spaced that until Bob looked at the context diagram I’d sketched and pointed out my oversight. This interface handles the user authentication and data exchange in a very specific way. If I had missed that, we might have implemented a solution that was not capable of handling the interface requirements.
Deadly Sin #2
Missing Key Functionality
It’s also surprisingly easy to miss key features or functions needed in a solution. I find that people tend to make assumptions – “Well, of course, it needs to track student attendance!” In the early stages of a project, we should not be digging into detailed descriptions of functionality. We should, however, have a high-level understanding of everything the solution needs to do.
HINT
A user story map or a functional decomposition diagram can help ensure that we don’t overlook key functions.
OUR NEAR MISS
We have a number of clients who track their employees’ certification status. At the end of each year, we produce a report showing badges and certifications achieved by their employees during the year. It’s something we only do once a year so I hadn’t thought of it – but fortunately, our business manager Mary did!
Deadly Sin #3
Underestimating Time, Effort and/or Cost
This one typically ties directly in with sins #1 and #2. When we don’t understand all of the high-level requirements for a system, it’s nearly impossible to produce accurate estimates. We discover those missing requirements later in the project and often find ourselves trying to figure out how to adjust so we can still meet our deadline and stay under budget. It’s so much better to start the project with a deeper understanding of what it will really take to deliver what is really needed.
HINT
Check out our template for Estimating Analysis Time!
OUR NEAR MISS
Had we not identified the missing stakeholders and requirements mentioned in near misses #1 and #2, we likely would have missed on all three of these. The time estimate was particularly important to us, because we had an implementation date we wanted to meet.
Deadly Sin #4
Setting Yourself Up for Scope Creep
Ah, our old friend scope creep. We all know what it is: that gradual expansion of project scope that can happen as a project moves forward. Having a well-documented scope is one of the keys to preventing – or at least minimizing – scope creep. It was particularly important in our project because we wanted to outsource much of the migration work. We needed to make sure that our consulting partners clearly understood what was expected.
HINT
We cover scoping in detail as part of our Essential Skills for Business Analysis course.
OUR NEAR MISS
A few weeks into our project, the consultants we were working with brought us a request for additional funding. They felt that we were asking for things that were not part of our original agreement. Fortunately, our scope documentation clearly included those items so we were not obligated to pay extra.
Deadly Sin #5
Choosing an Incorrect (or Suboptimal) Solution
There is almost always more than one way to solve a problem. It’s so tempting to latch on to a solution that looks right without considering other alternatives. We owe it to our stakeholders to look for the best way to solve a problem, not just the first or most obvious one.
HINT
Review your proposed solution using our Solution Completeness Checklist!
OUR NEAR MISS
We needed to create quite a few custom data tables and functions to handle our certification program. There were many CRM solutions on the market that initially looked like good candidates, but many of them had to be eliminated from consideration because they couldn’t handle this key requirement.
Deadly Sin #6
Missing Expectations
When I ask students to define “scope”, most of them talk about boundaries. It’s true that one of the purposes of scope is to define what’s in and out of scope. But, very importantly, scope is also used to set expectations. Everyone on the team should have a shared understanding of why the project is being done and what success looks like. To quote one of my students, failing to get everyone on the same page results in “chaos and confusion”.
HINT
Take the time to review your scope with the team and proactively confirm their understanding. Don’t just send out a document via email and take silence as acceptance.
OUR NEAR MISS
A number of our team members are contract employees. It would have been easier to skip them and elicit information just from full-timers who are more readily available. Taking the time to include those additional perspectives in our scope ensured that we understood the needs and expectations of everyone on the team.
Deadly Sin #7
Failing to Identify Risks
I have a list that I call “Phrases to Fear” for business analysts. At the top of that list is “That’ll never happen”.
Except it can. And does.
It can be tough to get the team to identify and plan for risks. Like it or not, if you don’t identify and plan for a risk, then by default, you accept that risk. Ideally, you want to proactively plan your risk response strategies. For each risk that is likely to happen or that would have a significant impact if it did, you should proactively decide whether you will accept, avoid, transfer, or mitigate that risk.
HINT
Learn to identify and plan for risks in our Risk Analysis and Planning class.
OUR NEAR MISS
Never in a million years would I have expected this to happen… but three months in, our consultants quit.
I mentioned earlier that we had a deadline for our CRM conversion. When we started the project, we gave the consultants a deadline that was about four months away. At the three-month mark, I sat them down for a serious conversation about our progress. We were nowhere near done and were stuck in a loop of testing, rejecting, and recoding the certification functionality. I asked them to come back to me with a plan that showed how we could meet our deadline and what each of us – including B2T – needed to do to make that happen.
The next day they sent me an email and quit. Yep, via email.
ONE FINAL HINT
Scope is Not a “One-and-Done”!
Scope needs to be regularly reviewed. So many things about scope can change – and change can be good! Remember that as agile practitioners we “welcome” change as a way to better serve our stakeholders. We do want to manage that change, however, so that we don’t end up with uncontrolled scope creep. The first step in managing scope creep is to have a well-defined scope. The second is to frequently refer back to our original scope and consciously address changes that occur.
Scope doesn’t always need to be a huge, formal document. Ours is very informal and lives on a Miro board. So even when you’re in a hurry, take the time to do “just enough” to ensure that everyone on your project has a shared understanding of the mission. It’ll save you from near misses like ours!
All the best,
Kathy
... and the Rest of the Story
Are you wondering what happened when our consultants quit? Stay tuned to future newsletter issues; we’ll share the whole story!
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.
