Problem solve Get help with specific problems with your technologies, process and projects.

How to involve execs when writing business requirements

How do you engage high-level business executives in the process of writing business requirements?

Executives are key stakeholders and thus key resources for writing business requirements. But being a source for business requirements is a lot different than writing them. Note, though, that the BABOK guide v2 online (IMHO somewhat misguided) enterprise analysis knowledge area describes the executive's role as dictating objectives and high-level requirements of the product to be produced in the project being initiated. BABOK often is interpreted as meaning that the business analyst (BA), if involved, merely captures whatever the executive says.

Unfortunately, many executives assume their level alone suffices to define a project and its business requirements. Yet, simply having an executive title often fails to provide the business analysis discovery skills and awareness needed to get the business requirements right. Such shortcomings frequently cause projects to fail and are exacerbated by the executive's inability to recognize the shortcomings, let alone acknowledge them and respond accordingly.

That's all the more reason to involve executives appropriately when writing business requirements, but this usually is easier said than done. To me, the starting point must be the BA's attitude. To truly add value, the BA must do more than take dictation. Rather, the BA must discover business requirements through an integrated combination of active data elicitation and analysis. The focus must be on the business, not on the product the project is to produce.

T o achieve necessary executive rapport and understanding of the business situation, the BA must take the initiative to gain sufficient relevant business knowledge before eliciting and analyzing data. Such prior contextual knowledge will aid the understanding needed to discover the real business requirements, not to presume them.

An added benefit of taking such a business perspective is that it tends to guide more productive executive involvement. That is, it leads to questions concerning business problems and opportunities, along with likely key causes and potential business deliverables that will solve the problems when satisfied.

Instead of tying up executives in writing business requirements, the BA and more directly involved stakeholders should do the bulk of the writing and then present it to executives for review. Executive review can be individual or as part of a group, either just executives or a mix of stakeholders. Either way is usually a more effective and efficient use of the executive's time.

A little-known additional non-requirements way to involve executives in defining requirements is proactive testing master risk analysis. This mixed stakeholder group method applies special techniques to identify often numerous ordinarily overlooked large showstopper-sized risks in the high-level design. Most large risks reflect design errors and omissions, in turn mainly stemming from wrong and missed business requirements. Executives and other key stakeholders generally find such large risk discovery very rewarding. Once they've participated, they and their colleagues want to be sure to be included thereafter.

Next Steps

Common sense tips for writing requirements

Elicitation techniques for discovering software requirements

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What methods have you used to involve executives in writing business requirements?
Thank you for your article!
Recently after a review of a set Business Requirements for a new Product development, I made a comment about the referenced "Applicable Documents" to one of the Execs. The comment was: The publication dates of these documents are rather old, and some have the status "draft". It certainly got his attention!

Herman Driessen
I send the daily minutes in gathering requirements and in Agile i bring them in daily stand up meeting in call reviewing the status of what is done on the day and what should be done on the coming day.

Thanks for your comments. 
A few years ago, my wife was analyzing a bank’s procedures and found
that several business continuity backup copies of key forms were pre-printed with
dates like 195__.

Better that the exec is already so well invested in the process that you don't have to ask for involvement. Failing that - I know, I'm a dreamer - appeal to their bottom line. Make them aware of the cost variables. Cost of implementation and ongoing cost of use. And if that doesn't get them to pay close attention, point out that their name will be on the bottom line....
Fully agreeing with "ncberns" apart from that following:
1) Stakeholder management plan.
2) Thomas - Kilmann Instrument to know your stakeholders.
3) The Fisher & Ury Negotiation approach.

I've never been in a situation in which we had very close involvement with an executive. I guess it depends on what you consider to be an executive - we have had close involvement with lower level managers. Once a manager rises above that level, they typically become too busy to be directly involved. We now work with a BA who does an excellent job of representing the business needs. Occasionally he will need run something by an executive, but he has most of the responsibilities of decisions making. It works out well for us.
I don't know of any mid or large sized companies that are able to actually get high level execs to write requirements. It should be their place to explain their goals, and a product owner or BA can then interpret those goals into detailed business requirements.