Three Steps to Prepare for and Execute Requirements Discovery
Requirements discovery is a vital step in starting off your project. A lot of solution consulting firms have patterned their methodology around firming up requirements at the outset of the project rather than diving right into an Agile-minded development phase where caution and budget are basically thrown to the wind. So with that, this week’s post has three tips to help you get the most out of your discovery sessions.
Agenda Prep – Firm, but Loose
As with any meeting of significance, agendas are a must. A tip for creating an agenda is to examine the statement of work or contract and extract functional topics from that document that help form your agenda. Put some estimated times around the length of discussions you think you’ll have but be mindful that some conversations will run long and some will wrap up sooner than expected. One common mistake is that when topics come up in conversation that are deemed ‘out of scope’ that the conversation is immediately squashed. It’s good for the project team to understand everything, even the out of scope items. Often times it’s discovered that while the customer initially said that a particular item is out of scope, they realize that it’s important enough to put back into scope with a change request.
Subject Matter Experts – Decision Makers Present and Accounted For
Make sure the client understands the importance of having subject matter experts attend all relevant sessions. Empowered decision makers are the key experts to have as it helps cut right to the heart of the matter and get firm decisions on detailed requirements. Having a delegate attend who is not allowed to make decisions puts a real wrench in the discovery process as it usually necessitates an offline conversation that our team is not privy too and often times can result in a narrow-minded decision that could prove costly to the project.
Our job as consultants isn’t to be mere order-takers. The best business analysts I’ve worked with made it a habit to almost always ask “why” when a requirement was stated by the customer. Not in a confrontational or blind way, but it’s important for not only the consultant to understand but also for the customer to understand why they need it a certain way, and “it’s how we’ve always done it” should never be accepted as an answer. Often times there are revelations on the customer’s side that perhaps business needs to change along with the solution implementation. Remember, the customer is paying you for your knowledge and expertise – they can pay an order taker far less money to build something to their spec without question. The Business Analyst needs to justify design decisions to the project team and needs to understand, in detail, the “why” for each decision. I’ve yet to see a customer get upset over a consultant asking too many relevant questions that start with “why”.
Solid requirements are the foundation of any successful project. By employing these three tips, you’re sure to come out of the session with a wealth of great information that will help form your business requirements to support your solution design.