Sal was excited to dive into the company's new D365 implementation project. The company asked them to take the lead and collect requirements, map them out, propose the solution, and work with the organization's partner to implement it.
Everything was off to a great start.
After an intense but informative requirements gathering phase, Sal had the plan crafted, the teams bought in, and everyone seemed excited at the thought of what this new system was going to do for productivity and operational efficiency.
As the build phase got started, teams were invited to see aspects that related to their work. People were enthusiastic and really diving in, and with this excitement came new ideas.
The more possibilities they saw, the more employees wanted, so people started adding daily requests.
At first, Sal thought this was great news: "Everyone is REALLY excited about this," so the list of desired features grew longer.
Then, it happened...
During their weekly sync, Sal was horrified to learn from the project manager that they were nearing the end of their hours. The system was nowhere near completion. The project manager explained that as teams suggested new features and changes, the build team had to revisit, undo and redo some aspects, and this ate up a lot of time.
Sal sunk in the chair at this news as they realized they'd need many more hours to get the minimum viable product stood up.
How could this happen?!
Sal's situation is a pretty common challenge, and I've heard horror stories about its impact on various projects. That said, I must acknowledge that this scenario should never get this far that quickly.
Every project should have people monitoring its status on a regular basis and the red flags around some of these things should be waved well in advance of Sal experiencing the shocking moment described above.
But, this is textbook scope creep.
The good news? It can be avoided with some simple actions. Let's dive into three tactical items that should help any organization avoid a case of scope creep.
A Minimal Viable Product (MVP) means the foundational elements of your system are in order; the minimum set of features you can live with initially. It is not the full system in complete form. Generally, especially for larger projects, the initial push is to get the MVP done then future phases (sometimes called "sprints") add special functionality over time.
Use "MVP" often with your team so they understand what it means and why it's important.
Explain to your users that success is measured by phase, the MVP being the very first one. It's important that users understand that there will be additional builds over time, and that the goal of the MVP is to provide a stable foundation for those enhancements.
People have a tendency to look at the MVP list and say, "Well, if we just do this and that too, it won't be an issue, right?" or "Just add this to the list, it's small and easy." Such items add up real fast, as Sal learned earlier.
Be realistic. Have you ever done a renovation in your home? I've heard various figures, but the one I hear most often is the "30% rule." However long you thing it will take and however much you think it will cost, add 30% to both.
Why? Because there are always unexpected hurdles that will lengthen timelines, and there might be nicer hardware or features you want that will bump up the budget a tad.
Let's face it, you want to "do it right" the first time, so sometimes there are logical bumps you add-on.
No matter how thorough your requirements gathering might be, it's only natural that people will begin to dream a bit when they see and test the solution (a new field here, an automation there, changes to the view, chart or dashboard, etc.) It all seems small, but it all adds work.
Factor in add-ons and prepare for "bumps"by providing some padding, including space for features the team will potentially add to the list. You don't need to know what these bells and whistles or necessities might be, but you are simply making space for it to happen.
Whether you use 30% or some other figure, creating space for additional configuration or development will allow you to broaden your scope a little bit without jeopardizing the integrity of the entire CRM project.
The key to this, however, is to have a first line around what can be added.
Perhaps it's a certain number of features, or, more logically, an additional X of configuration/development time. Anything beyond that is a no-go, and gets added to the backlog for future consideration.
If you want to become more active in life, set a fitness goal and track your progress toward it.
If you want to reach a point where you are walking 5 days a week for 30 minutes, get a calendar and keep track of the days you actually do it. Keep it somewhere you'll see it multiple times a day to act as a reminder and to help foster the habit into your daily routine.
Managing a project has some parallels to this methodology.
The MVP discussed above is your guide. It defines, clearly, what should be focused on. Anything raised in addition to the items on your MVP list needs to be captured in a backlog for future consideration. Validate each item being worked on to ensure it maps to the MVP's scope to avoid starting something that isn't truly necessary at this stage.
Consider tracking this in a tool such as Azure DevOps or a project management software. Keeping tabs on what is being worked on, when, by whom, and the estimate delivery times around it will help keep the project on course.
I've listed just a few tips, but there are certainly others. At C5 Insight, we believe embedding these practices into your project plan will help you manage the risk when it comes to scope creep.
Worried your CRM project may be starting to drift? Postponing your CRM project because you don't know where to start? Reach out to our team at C5 Insight today and request a quote!
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.