Keep Your Eyes on the Prize
…IF you can tell what the prize really is. Let’s consider a list of potential “prizes” and the meaning of each for developing requirements.
THE Prize (by definition): Meeting Organizational Goals and Objectives
This ought to be the gold standard for developing requirements. Is it the standard at your organization? Try carrying the organizational mission, goals and objectives with you to share at requirements meetings. Whenever a debate erupts about some requirement, pull the goals out. Ask the group if the existing goals offer direction to resolve the debate. If so, the organization is practicing “BA behavior”.
If the group cannot relate the debate to existing goals, ask for any missing goals that ARE relevant. If the group cannot name any such goals, yet persists in the debate, your organization is normal, and does not practice the gold standard (or the silver or bronze either). The most extreme case of this can be encountered in certain government or academic institutions, who practice the “mushroom*” standard.
Example of the extreme case (fictitious, of course, no one would ever, really!):
BA: “What is your understanding of the organization’s vision, mission and goals?”
Stakeholder: “I try to stay out of that.”
If subsequent sponsor review does not clarify the related goals (or gets negative attention), you can be sure that business analysis is not in play AT AL. As a BA you can start to release the need to practice BABOK and can seek the most useful mushroom standard. You will do better to identify the true “prizes” in play from the list below, while complying with the “ignore mission” culture.
Secondary Prizes for BA “Eyes’es”
1. Meeting Actual Business Needs
This is where the best BAs live most of the time (see “normal” at top of essay). It is dangerous (some stakeholders might notice that meeting actual business needs is a lot like striving for goals), but might slip by, IF you keep an eye on ALL the following secondary prizes. Any of these can destroy good requirements by trumping actual business needs.
2. Serve the “Solution Approach” Regardless of Merit
Don’t get me wrong; the solution approach may be brilliant and relevant to business goals. It’s just that in the absence of clear business goals, any approach has little to guide it as decisions are made. The decision IS the approach, and everything becomes about “looking good” (see “looking good” below).
Example:
BA: “What was the most important consideration before buying ABC software?”
Sponsor: “It’s the best – everyone’s using it – You just stick to making the requirements work.”
Translation: My friends like it. When it fails, it will be a BA requirement failure – you failed to get the requirement – if you were a better BA, you would have gotten it from me, and you would have gotten it right.
3. Serve the Solution Scope
“You said you wanted all data in one query – you didn’t say it had to run at lowest priority!”
Only do this to people who scream when they get things wrong by jamming them down your throat. The others are no fun, and will just want it fixed without learning anything. When compelled to serve scope, don’t squeeze any in by working harder. It just encourages scope creeps, and makes managers think deadlines are reasonable. ‘Nuff said.
4. Serve the Business Case
No goals, no business case. That was easy. How does one estimate benefits without clear goals in mind? Costs are easy, and often the business case goes like this:
“We want X solution, it costs Y, we can afford it”.
Why we want X is left for another day, say after the sponsor is promoted.
5. Pleasing the “Fox” or Foxes
This is always a strategy when clear goals are missing. Sales persons (who have little or no attachment to facts in their incentive plans) talk of “finding the fox” – the TRUE decision maker, regardless of who is taking sales calls.
If you can identify “the fox” in your organization you can find the “true” requirements (whatever the fox wants). Someone hired a BA (you, remember?). Is the hirer the fox or are there other “foxier” foxes that are looking to outfox your immediate leader?
This is not always easy to do. Foxes are foxy and do best when they have dens to hide in, and there is often more than one fox. Once you find the fox your strategy is easy. Do what THEY want, and let the fox stir the mud with difficult stakeholders that take too much time to please.
5. Look Good
Any goal based requirements confusion can be obfuscated and postponed to problems after deployment, when the BA is long gone. This requires use of little or no text (no one reads, and will not pretend that they believe text) but lots of diagrams (most organizations have permission to pretend to understand diagrams, but NOT to pretend to understand text – I don’t know why this is).
The most brilliant diagrams are full of extraneous graphics and detail. Little “Lego” like end user figures, pictures of dollar signs, company logos and colorful, attractive icons labeled “NEW STATE of ART SYSTEM”.
These diagrams are not brilliant for requirements (who does what and how), nor for subsequent development (see “Tufte” for more clues on this). They ARE brilliant for “looking good” and creating warm feelings among stakeholders, as long as you don’t have to deliver.
6. Relax
Above all, don’t make it your job to pursue requirements for business goals not shared by stakeholder consensus. There are several ways to do this.
- Become part of the problem by looking for issues instead of solutions.
- Share the risk by coding the requirements instead of analyzing them. That way everybody hurts, and they call you Scrum instead of treating you like scum.
- Become the lowest common denominator, so everyone is pulling you forward instead of vice-versa.
- Set your own personal goals and vendettas, like everyone else (see BA-elzebub’s Glossary on “Agenda” definition can be found here)
* Keep ‘em in the dark and feed ‘em…you know, mushroom food.
Don’t forget to leave your comments below.