2 Essential Discovery Strategies

Clients and partners often ask us: What’s your workflow for Discovery? How do you determine the best approach to a specific project?

We tailor our approach for each project, all while using overarching principles to based on complexity. The two-pronged approach is akin to sizing up your opponent as either a David or a Goliath.

Sizing Up David & Goliath

If your project is a David—your project is probably pretty small. You may have fought an army of David’s in the past, and your discovery approach will likely leverage your pre-existing knowledge for similar David-sized projects.

If your project is a Goliath—you know enough about this project to know that your plans will need to be carefully managed during discovery. Later on, when your team is working together to take down this giant, they may start at different ends—it’s important they each have the same goals in mind while being allowed to nimbly move out of the Giant’s grasp.

Essentially, if you’re looking to take down a giant, your plans will need to give your team the most agility and flexibility possible, and your discovery will need to be solutions-agnostic in order to achieve this.

Confused? Let’s take a look at solutions-agnostic discovery means in practice. The process we’re about to detail works for both internal business analysts and agency business analysts performing a discovery for a client project.

Goliath Project

When working on a Goliath enterprise-sized project, discovery means requirements engineering. Enterprise projects are often too large and too intricate to begin thinking about solutions.  Focus on mapping out the requirements so that the technical architect understands all of the moving pieces and priorities. Write stories. Perhaps even acceptance criteria if you feel that a requirement is best captured that way. By delivering the specified requirements without suggestion for implementation, your development team will be free to determine the best approach for toppling Goliath.

David Project

When working on small- or medium-sized client projects, discovery begins blending into solutions architecture. If the project is simple enough, you can save quite a bit of time thinking in terms of solutions instead of requirements. After all, you’ve probably fought many David’s before—you know how to think to tackle this project. If you see a clear path to victory, implementation specifications may save your team a lot of time. Of course, use this second method with caution—you should always start with requirements first and put time towards a site build recommendation if you have time during the discovery.

Why a different approach based on size?

Quite simply: it’s cheaper for the client, and less stressful for the team. In both cases you need to collect enough information to be valuable for an estimation process after the discovery.

In a Goliath Project, you run the risk of narrowing the estimation team’s field of vision for implementation if you come in with your own solution. Your team may find that once they get onto the battlefield, you have accidentally tied weights to their ankles—slowing them, and costing both your team and Goliath company more time and money.

In a David Project, your vision for a complete system can often prove valuable to the estimation team and execution team. Detailing your site build recommendations in a Drupal project can give the team a jump start on implementation, and can help to validate your findings in the Discovery.

As a business analyst or a solutions architect working with a Drupal shop, it’s important to understand the need for each of these approaches in your discovery workflow. At Facet, I think we excel at this and it’s one of the key factors that differentiates our services from other discovery solutions.

Once you’ve decided on an approach, then you can then get into the discovery flow. Next week we'll dive into discovery workflow and the full iterative requirements engineering process including practices held during agile development.

Check Out: 9 Steps for Discovery Workflow

----

Jordan RyanJordan 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.