9 Steps for Discovery Workflow
Since discovery workflow varies based on the complexity of your project, check to see whether your project is a David or a Goliath before getting started.
Once you’ve identified and sized-up your project, your discovery process strategy can come to life. The [breakpoints] detailed below will help you to identify the difference between tactics targeted for David or Goliath in the following steps.
-
Start. Discovery is a business development process. As you are qualifying your next project, discovery should start and finish before an estimate has even been delivered. Believe me, you’ll save your project stakeholders from the heartburn of scope creep, and you’ll save your team from stepping through feature iterations six ways to Sunday.
Why?: Understand client expectations. Mitigate misalignment to a poor RFP. Identify key motivations for undertaking a project (they’re not what you expect, usually).
-
Identify. Identifying key stakeholders and key users a prerequisite to saving time during your discovery. If you don’t have these people in the same room during your discovery workshop, you’re heading towards building an incomplete solution.
Why?: Goals and requirements come from stakeholders. Pain points and identification of features that cause friction or inefficient come from users. Identifying the latter will improve the ease of adoption, so look into it.
[Breakpoint] In smaller projects, you may be working directly with the person who will use the platform (think small business owner). Developing a pretotype for these kinds of stakeholder-users in simple projects will help to improve understanding and adoption.
-
Elicit. Gather requirements through elicitation with each of the stakeholders in a workshop setting. While other methods (questionnaires, surveys) can be useful, they won’t help you create a dialog about potential solutions. If you have an RFP, this is a great place to start, but as a solutions architect for a Drupal shop, you may want to ask some pointed questions about the requirements to see if contributed modules from the community will work well—or if you need to specify the gap for a custom module.
Why?: It’s important to build up a working knowledge of what problems you are trying to solve for the client. A list of requirements in an RFP will give you the what, but often times you are searching for the “why”. Motivators can often be unspoken due to internal corporate culture, so you must cut through and ask the hard questions.
-
Inspect. Requirements for the new platform can sometimes be hidden in the old user experience. Find an expert user from each of the user roles and have them walk you through their regular tasks. Recorded screen sharing sessions can help you to document key functionality and deliver valuable user experience history to the development team for reference during development.
Why?: Articulating requirements is often disconnected from experiencing them. A blog author may be able to tell you what they do day to day, but you will always glean more knowledge from experiencing it first-hand. Keeping these recorded user sessions available for your team will minimize back-and-forth while developing the user experience.
[Breakpoint] For smaller projects, inspection may help to streamline the elicitation process. Familiarity with the system will make your elicitation questions more pointed, and you can save yourself and the key stakeholders some time.
-
Analyze. As a solutions architect, depending on your level of technical skill, you may want to discuss which requirements are going to potentially be high effort. This conversation is best served by a technical architect, but if you’re familiar with the typical use cases of Drupal, you may recognize when a client’s requested feature doesn’t align with something that is easily achievable in the framework.
Why?: You want to call these out to the client so they have a perceived expectation of cost vs. value. Understanding these high complexity cost items will pave the way for prioritization in the next step.
[Breakpoint] For smaller clients, when you start to stray from a standard Drupal solution and you don’t feel like the client has the budget, try to dive deeper into why the client needs this feature. If you can identify an alternative solution that is easier to implement, you should detail the requirements and conversation that lead the client to this decision.
At this point, you are probably done with the discovery. Depending on how you are collecting this information, you will want to stakeholder and client sign-off for a discovery report. A sign-off will help you to solidify a baseline for future change requests, and helps the stakeholders understand how requirements evolved since the original planning phase. Once your estimation team has delivered their estimate, if you stay on as a product owner for the project there are a few more steps in the requirements engineering process.
Backlog Flow
Now that you’ve completed your discovery, there’s three more steps you’ll want to iterate on each sprint.
-
Prioritize. You may know this step more commonly as backlog grooming. It’s an important step to take up at the beginning of the project as you identify key priorities for the business in terms of product value, and also identify features which are blockers for future sprints.
Why?: Delivering the features that create the most business value for your client at the beginning of the project will pave the path for a successful project. Even as requirements and scope creep cause you to make trade-offs in later sprints, your delivery of this key product value will carry the project through to success.
-
Specify. In a discovery, you will never have the time to collect 100% of the requirements for the backlog. Your designated product owner should be working to detail these in full as you move sprint to sprint.
[Breakpoint] You may want to detail full requirements for smaller projects during the technical architecture phase after a discovery.
-
Manage. As you move from sprint to sprint, product owners will need to prioritize and manage trade offs as new features are uncovered. Understanding how to appropriately manage the requirements, and tracking not only how requirements change, but also why requirements are being changed is the responsibility of the product owner or business analyst on the team.
Why?: You want to manage the scope creep for the project and detail change as clearly as possible. Versioning requirements, and detailing the timeline and cost impacts is the best way to achieve this from small projects up to the enterprise size.
As you take up your next project, I encourage you to start incorporating some of these steps in to your discovery to improve your workflow. Whether you're a business analyst working within a large corporation, or a consultant working with clients, take a look at your discovery process try leveraging these techniques. It’s a bit overwhelming to change your whole process, so perhaps start with one step and improve your process over time.
----
Jordan Ryan (@jordan_ryan) is President and Solutions Architect-for-hire at Facet Interactive (@FacetLA). When Jordan isn't hustling through his most recent discovery engagement, you can find him enjoying the finer grinds of fresh ground coffee in Santa Monica or fiending for a foodie fix wherever Yelp may take him. Follow him on Instagram if you like to feast with your eyes.
