Scope

Scope focuses solution discovery and development processes on meeting specific organization needs, with a clear definition of completion.

Stakeholders negotiate the scope of an organization’s needs that a solution’s version will fulfill.

Motivated Discovery

Click a title to see excerpts

Scope: Are We Done Yet? (Key Story)

Scope: Are We Done Yet? excerpts:

• This story shows the importance of scope when discovering business needs. The sales executive led with his need for the report to group accounts by industry because that was most important to him at the time. He assumed that you would know to include opportunities. When you gave him the opportunities report, you assumed that was all that he wanted. You both lacked scope to define exactly what he needed from the report.
• A better approach would start by asking the sales executive what he wanted from the report, even if he does not have time to spell it out completely. Putting scope around the report specifies what it should and should not show.
• Scope acts like a container of customer needs. When the container is full, it has all of the needs to complete the solution.
• Scope focuses your effort to get the most out of the time, energy and attention you devote to a solution. It specifies completion of a solution stage, so you know when you're done. When you discover customer needs, other requests can emerge that are out of scope. For example, the sales executive in the story asks you for a dashboard to go with the report. He doesn't want to wait for the dashboard to get the data from the report. That puts the dashboard out of scope and into the next version of this solution. After the sales executive accepts the report, you would ask what he expects from the dashboard and put those needs into the next version scope.

Coverage: How Much is Enough?

Coverage: How Much is Enough? excerpts:

• Software solutions often fail when they do not cover enough user needs. The Project Management's Institute Pulse of the Profession® (2017) found that 39% of surveyed organizations reported inaccurate requirements gathering as a primary cause for project failure. They did not accurately cover customer needs within the project scope.
• The Elements.cloud confessor found him/herself on the path to solution failure. The confession refers to user stories, which describe what a user does with a solution in a specific case, and why. The original user story author did not cover enough of the user needs. In this case, the confessor checked the user stories and presumably asked a lot of critical questions. S/he went back to discover the user needs and rewrote or created new user stories to ensure they covered the project’s scope.
• Ideally, you want to discover all of the user needs within the solution scope. Stakeholders rarely have enough time, energy and attention to reach that goal. They rarely think of everything they need from a new solution. If your solution replaces an existing solution, the stakeholders may not recall everything that your replacement solution should cover. Upcoming posts in this blog will show you how to get closer to ideal coverage.
• Discover as many customer needs as possible and decide which ones will cover your solution scope. The Business Analyst, Architect, and stakeholders should at least discover the downside of uncovered needs. Those needs may not be worth fulfilling in the current scope, making the risk acceptable. If you develop solutions for a regulated industry, you need to have 100% coverage of regulatory requirements.

The Force that Leaves a Solution Unfinished

The Force that Leaves a Solution Unfinished excerpts:

• You need to defy Solution Gravity while discovering customer needs, and continue to defy it until you have enough customer needs to cover the solution scope. The next post introduces defiance of Solution Gravity.
• You're leading the final discovery meeting with a user manager and an executive sponsor. They eagerly anticipate the release of your solution. You have a vague, uneasy feeling and want to find out where it's coming from. You review the business needs with the user manager and ask her how much the scope covers those needs. She ponders the question and replies, "I think we have it covered." You recommend going through the user workflow one more time. "Again?" the sponsor asks. "It looks good enough to me." The user manager agrees - they want the solution as soon as possible!
• Everyone in this story felt a strong force to deliver the solution, even though it did not cover the business needs within its scope. I call this force Solution Gravity. Like physical gravity, it applies to everyone. The executive sponsor wanted the solution as soon as possible, the user manager needed the solution's benefits and you were eager to please both of them. Solution Gravity pulls stakeholders and the development team towards building a solution. If the solution scope does not have all of the customer needs, the incomplete solution will disappoint the customer.

Defying Solution Gravity

Defying Solution Gravity excerpts:

• You should set goals for the customer discovery meeting, starting with determining scope. Scope specifies what customer needs the solution will fulfill, and only those needs. If you have questions about the documents you read to prepare for the meeting, set a goal to get answers to those questions, within the scope. The meeting should result in a document summarizing the customer needs in the scope, with supporting details.
• Once stakeholders recognize that you have captured their pain points, Solution Gravity becomes stronger. The stakeholders want relief from their pain as soon as possible. You must continue to defy Solution Gravity to capture all other customer needs in the scope. If the pain points hurt enough, the stakeholders may decide to limit the scope to only relieving the pain points. That risks ending up with an incomplete design, needing additional discovery and design rework. Ideally, the scope will include pain point relief and needs for improvements, making the solution more complete.

Gathering Intelligence for Discovery

Gathering Intelligence for Discovery excerpts:

• A new client is replacing their marketing system with the Salesforce Marketing Cloud. You will lead the implementation and need to learn about their marketing processes. The client gives you sample marked-up reports, showing the information they want from Marketing Cloud. The reports show their expectations of the solution, and provide insight into their terminology and metrics. You focus on the reports that fit within the scope of the project.

Surpass Customer Expectations with Opportunities

Surpass Customer Expectations with Opportunities excerpts

• While the detail page worked well enough for three years, we kept discovering needs to improve the registration experience. We enhanced the registration page as much as we could, within the constraints of page layouts and Visualforce components. We collected needs that fell outside of those constraints or the current scope for a “Nirvana” registration solution.
• Ambitious ideas often emerge in discovery, outside of the current scope. Collect those ideas for a time when you can realize the dream of an ideal solution.
• When discovering what a customer needs from a solution, ideas often emerge for a perfect solution. These ideas fall out of scope of the current discovery. The pressure to deliver a solution within the current scope makes it tempting to dismiss these ideas. There won’t be enough time to develop these ideas. The case below shows how keeping a list of “perfect solution” ideas paid off.