The last few weeks, I have periodically bemoaned the fact that no matter how much effort you put into creating a meticulous business requirements document or functional specification, key members of your project team probably aren’t going to read it, or at least they won’t read it very carefully.
Those key members usually come from the business side, and they often are higher-level managers. Technical managers are still technical folks at heart and are wired to think on a particulate level. Not so with a lot of LOBs. These folks are busy, and the minutia of a functional spec doesn’t fit in with the way they are used to digesting information.
So, how do you push forward with refining the details of a project when it’s clear that key stakeholders may be glossing over issues that will result in costly, wasteful delays if they are not clarified now? It’s tricky when you are just a guest at the table, and as with any consulting engagement, the business culture of your client will determine how best to proceed.
Here are a few tricks I have come up with on how to nudge stakeholders toward reading (or at least, understanding) key points of the business requirements.
Triage your questions, and make sure you are picking your spots wisely.
Does it really matter at this point whether the functional specification calls for a dropdown combo box or radio buttons? Probably not, and Dev will probably pick the form factor it likes anyway. Be sure to rathole only on issues that will substantially impact the project later if they are not clearly resolved now.
Does that meta tagging structure really need to be flat, or do you need to design a child-parent relationship from the get-go? Do you really want to employ a two-step user registration process, or would you experience less attrition with an AJAX or similar one-screen implementation? These are the kinds of questions that can’t be left unanswered.
Find yourself a mid-level details champion.
C-level columnists love to tell you that a strategic initiative needs an executive champion to push it through the budgeting and political morass. As a consulting business analyst, this is most often not your problem — your job is to turn the strategic initiative into an actionable plan. Identify somebody on the project team who gravitates toward minutia — i.e., they read the spec — and use them as a conduit to push questions in channels where you might not have immediate access. Hopefully, this person will be at least in mid-level management, so it’s just one hop up the food chain to that executive who is not paying particularly close attention.
Call break-out meetings if necessary.
With the aid of your details champion, don’t be afraid to ask for quick side sessions with key team members to drill down on questions. You may be able to get your answer through a strategically forwarded or copied email, but sometimes 10 minutes face-to-face is the best solution. The one caveat here is that you have to let the whole team know that the meeting took place and the results of the session. Some tact is required here — you never want to send the message that “I had to get the stupid VP in a corner to make him digest this very basic concept,” but you also don’t want to send the message that you are sneaking around and playing political games.
Create a PowerPoint.
When in Rome… . If you find yourself faced with a fairly pernicious conceptual snag (i.e., blank stares) over a key issue, do a five-slide presentation to list the pros and cons of possible directions. Throw in a pie chart or other visual, if you can. As much as PowerPoint has fueled a penchant for oversimplifying complex issues — at least in this detail jockey’s opinion — it can be quite useful for isolating and illustrating a single topic. And it’s the preferred media for a lot of business executives. When you are defining a project, communication is always the key, and you have to do what it takes to make that happen.