OpenSource Connections
Category: Uncategorized
Replacing an enterprise search product?
Use this three-step process to create actionable requirements for your team.
The inherent challenge in replacing existing enterprise products is that their functionality and attributes are already cemented into the consciousness and patterning of hundreds or thousands of users. Even when the legacy software is not well designed–and it never is, right?!–it is useful in a significant way that can not be understated.
So where do we start in order to exert meaningful change? Specifically, change that can be documented early in the process and change that inspires key stakeholders to continue with the project.
It’s standard practice to define and prioritize the issues. In that we like to leverage agile methodology to understand and then prioritize the task at hand, user groups are transformed into personas with critical needs and requirements. Yet as an enterprise search product, the software already performs numerous actions for many different user groups. User actions, therefore, are likely to fit within multiple personas. If deciphering the use cases were not challenge enough, combine that with having to appease numerous key stakeholders and it’s clear why it can be quite difficult to find the starting line.
To hold the metaphor above, if requirements are akin to starting the race, the process outlined below is similar to paying your entry free, showing up and lacing your sneakers. Proper preparation will insure that your prioritized business requirements will provide the best kick-off point and, if you’ve really done your work, they will act as guides throughout the build process.
Our three step process for project preparation success:
Discover
discovery – I can’t stress this enough. The failure of too many projects to count can most often be traced back to a lack of discovery. What is discovery? For us, it’s approaching a project as if we have zero domain knowledge, and then asking the questions–and digesting the answers–that allow us, by the end of the discovery period, to discuss the domain like an old pro. Sure, we know search best practices–that’s why they hired us!–but there are instances where a best practice may be exactly the opposite of what solves the business need. This is why a proper discovery period, one that lasts for a minimum of 2 weeks and as many as 4 weeks, is a preparation requirement.
Pro-tip: Insure that you have access to a product owner who is intimately familiar with the product and users. Ideally this owner has been identified prior to starting discovery. This relationship is mission critical. And don’t even think about a short discovery timetable if you won’t have access to this type of product owner.
Translate
translation – Take the problems that you’ve surfaced and bring them forward as support for your deep understanding of the product. Problems are often more than items that need fixing. They are gateways to creating a deep connection with the users so that you can solve their real problems. As outsiders, we are destined to fail if we are unable to pinpoint both the highlights and shortcomings of the legacy product. But that is not enough. We have been tasked with building a replacement, so we already have the challenge of bringing change (which is always initially resisted!). Translation is the process of speaking the same language as the owners and users. Effective translation creates common ground through clarity, it creates a space to work within that will be co-owned by both you and your client.
Pro-tip: It’s too easy to think you can rush through this step. The translation deliverable is the beginning of your development roadmap, so budget time for it.
Refine
refinement – Propose solutions that are manageable and that DO NOT partially solve each persona’s problem. Instead, refine your information to fully solve one major problem. Prioritize your other refined solutions, but present them in order of importance and propose one solution first. You must gain traction with your client; regardless of the agreed upon scope, people want to see tangible progress. Yes, this concept is ingrained in an agile approach to development, yet we have found that it is too easily missed within enterprise projects. The ability to refine tasks, earn stakeholder approval and then hold to the prioritized list is a game-changer when it comes to long-term client happiness. To be able to point to tangible successes during an extended engagement is critical. While at the outset it might not earn you buy-in with the entire organization, it will create a strong foothold with a critical segment.
Pro-tip: If you don’t work in segments, you are destined to fail. The legacy product simply has too much ingrained inertia. Segments must be thought of in two related ways: segments of the client’s entire team (personas) and segments of the entire solution. A distinct persona may have four or a dozen issues. Map the path to solving one key issue for the important persona and you’ll be well on your way to a positive long-term relationship.
Do Not Pass Go
The client may want you to “hit the ground running.” A couple of preliminary meetings have created rapport between you and the client and they believe you “understand the issues.” This is a trap. It’s a trap that is not set intentionally but will undermine a project. Do your diligence. Require it, in fact. Show your client that creating space in their budget for analytics is vital to project success. Better analytics is the foundation for actionable requirements. And actionable requirements guide successful search implementations. You owe it to your team and your client to take these steps.