“What is it you’re trying to tell me?” my manager prodded me. “The Business has given me their requirements, but there are open questions I need answers to before we can be sure of a quality implementation. I simply need backing to tell the Business that until I am satisfied with answers to certain questions by the end of January, I will consider their request out of scope for the March release.” The Business had worked earnestly to answer my questions without objection. This made my holding out on their request seem punitive. But the alternatives had other maladies.
One alternative is that the Business accepts risks caused by the unanswered questions. Although this has the appearance of being the Business’s problem. In truth the risk would be mine. Any issues caused by the unanswered questions likely will be blamed on my IT team’s implementation, and not on the Business’s unanswered questions.
Another alternative is that the IT team accepts limited scope as an incremental release. This has the risk of narrowing analysis to the point that it ignores how related scope may be interdependent. Indeed, certain functionality can be incremental as long as it clearly has no relationship with upcoming scope. In my experience clarity in this regard is rare, and worse, it may be deceiving. Because of this possible false positive and the repeated regression testing involved, incremental releases should be avoided.
A third alternative is that the IT team or Program Manager drive the Business for answers to the questions. It is always an IT responsibility to educate and prompt the Business for the needed requirement details. However, other than in extreme cases, pulling requirement details is beyond the responsibility of IT. For one thing it weakens Business ownership of the product. For another, it probably will result in requirements that have more of a functional, rather than business, perspective. In addition, it is impractical in most release cycles to expect IT to have time to hunt down the accountable Business contacts and force requirements decisions to occur outside of the customary Business workflow or time frame.
What alternative is going to come to my rescue? After weeks of letting my thoughts congeal, my predecessor in this role offered the names of several influencers in this delivery channel. These names seemed reasonable candidates for a possible solution delivery board. Now an alternative is forming. This was articulated by my peer in Engineering during a hallway conversation. “You need to tightly manage how the Business gets you requirements. It’s not enough just to sync well with the platform groups.” So, manage the Business and the Engineering platforms. These steps come to mind: 1) Socialize with and understand the needs of the Business. 2) Write and enforce a checklist to qualify some requirements as customary. 3) Establish the expectation that non-qualifying requirements will have unpredictable lead times. And 4) Lead Engineering teams to conduct early analysis for non-qualifying requirements.
Is this the rescuing alternative? It seems to solve most of the maladies above. All questions automatically “non-qualify” a requirement, and therefore are given all the time they need. One non-qualifying requirement does not block related requirements. It does cause a risk, but with the built-in mitigation of planned analysis. Instead of driving for answers from the Business, we lead Engineering, which in turn supports the Business to revise their requirements. There is still a requirements deadline and non-qualification for scope. But, this time the Business is aware, in control, and supported. I think we have a winner.