Keith HullKeith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith's former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG's Business Analysis Benchmark - the definitive source of data on the impact of business requirements on technology projects.
AddThis Social Bookmark Button

10 Ways to Use Requirements to Melt an Executive's Brain

So you've been tasked to get requirements on a strategic project, and you're thinking to yourself, "How can I make my business requirements documents as incomprehensible as possible?" Going this route may not be just a job security thing. Making yourself indispensable as the interpreter of requirements seems to be the traditional route of delivery and getting buy-in. Just keep running the requirements process until someone gets desperate and finally signs off on the spec in the vain hope of getting something useful for their effort before the end of Q4 2014.

So, some tips and traps for those of you looking to truly perplex and bafflegab your bosses:

  1. Just give a list of "the system shall ..." statements. Having a few hundred of these statements with no accompanying business process descriptions as a common point of reference to help navigate the swamp will keep the average executive bogged down for days. Their paranoia that something critical got missed might just match your paranoia when they show up at your desk to have requirement 143 explained to them.
  2. Experiment with similes when describing data objects. No one wants to hear about 'customers' repeatedly. Why not make the document more dynamic and talk about prospects, or accounts, or valued relationships, or partners, or something more interesting. You just shouldn't be overusing simple words repeatedly ... it's boring!
  3. The use of UML sequence diagrams and class diagrams will help prove to that doubtful executive that you truly understand systems development and have a deep understanding of industry standards. Just loading up their inbox with hefty documents packed with these pretty pictures will have them panting for more.
  4. Remove all evidence of traceability between one set of requirements and the next. The idea is to produce a set of business objectives and scoping documents in one format and using one set of techniques. Then get your business requirements using something completely different. Go for something truly unique in the system specs. The idea is to show your diverse understanding of ALL the different approaches available to the business analyst. Besides, they are signing off on each document separately anyway... there is no real need to look back at what came before.
  5. Be snappy with solutions. No matter what the request. Within three minutes of the executive's starting to the grand vision, cut him or her off and begin explaining how the solution is easily delivered by looking at the existing legacy applications. Your attention to promoting existing corporate assets will be well received.
  6. Tell your CFO that you want to use Xtreme programming on the Basil II financial compliance project. The idea of a programmers eagerly jumping into the breach to resolve important issues for the business should be warming to her heart.
  7. Tell your outside sales force they need to be dedicated to a requirements discovery session for three weeks. Your attention to thorough detail will be appreciated by the SVP sales.
  8. Adopt PowerPoint as your primary documentation engine. A few simple screen mock-ups to show the user interface will immediately grab everyone's attention as delightfully artistic. Besides, the workflow behind it should be entirely self-evident to any self-respecting programmer that's been with the company for a few dozen years.
  9. Make sure the first dozen pages contradict the second dozen pages. Every executive should be presented with options. How could they not like alternatives for the business?
  10. Drop out key sections of the document and pop these into secondary or tertiary documents. Then refer generally to the existence of these other documents, but don't put in the actual page, or a hyperlink. This is a great way to ensure they read the whole thing.

Hey guys - have fun and add your own. I wish you all great success.


Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith's former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG's Business Analysis Benchmark - the definitive source of data on the impact of business requirements on technology projects.

Comments (22)Add Comment
...
written by Steven A Jones, May 19, 2009
I'm still trying to figure out the purpose of this particular blog entry. Anyone else have a clue?

I get that its trying to be funny but with so many people either out of work or on the verge of being dropped, I think this entry was ill-timed. Believe me, I'm not one to take myself too seriously but this one feels like a serious waste of space.

Here's to hoping the next one will be back on track.
...
written by Vinu Shankar, May 19, 2009
This is a confusing attempt to make a funny post, I guess.

Vinu
...
written by Diana Ryan, May 19, 2009
Nice article! How about making requirements meetings with the customer more like gab sessions, with popcorn, candy and goofy jokes shared on the whiteboard? Continue like this week after week, with no regard to schedule or budget, and if you're really lucky a requirement will pop up! This happened to me when I was the newbie developer working on my first internal project with a developer who'd been at the company 12 years or so. He already knew the customer pretty well from past projects, and really just wanted to socialize. It's a miracle we ever finished. That one was melting MY brain!
...
written by Kristin Zaharias, May 19, 2009
Thanks Keith for a delighful blog entry. Ill-timed? No way. Any true analyst will be able to determine that this is NOT the way to make oneself indespendible and valuable to the company. It is a reminder to us all to not take ourselves so seriously that we jeopardize projects through confusion and opacity.
...
written by Morgan, May 19, 2009
It reads like a cosmo article. Some valid points are made.
...
written by Mark Parker, May 19, 2009
Kinda stupid and not real funny. EPIC FAIL?
...
written by Jim Freel, May 19, 2009
Business analysis and the value it brings to businesses, people, and careers could have done without this. Given the author's experience I would not have expected an off-handed article such as this, let alone BA Times to put it front-and-center. This site has a broader audience than just the BA community and I expected this site would have had more regard for the profession in the eyes of the public.
...
written by Christine miller, May 19, 2009
WOW! People need to take themselves a little less seriously. This blog is funny because even though they sound rediculous when so many of these things are actually done (though usually in a lesser capacity). I appreciate a little BA humour on a Tuesday afternoon.
...
written by David Wright, May 19, 2009
Satire is not always recognized by those who may be its subject.
...
written by Steve Hogan, May 19, 2009
Good article. I've found over the years that if you point out how big a task is you're made to feel "negative" and unsupportive". But if you do as outlined above and point out how big the task reaaly is without saying it - management tend to listen and you get more time to do things propoerly.
...
written by Rizwan Khurshid, May 20, 2009
waste of time for me ...
...
written by Rajeev, May 20, 2009
Very well timed and precise in humour.
...
written by Keith Ellis, May 20, 2009
Hey - let's fan the flames some more. My theme was 'people do some pretty crazy things in the name of good business analysis'. Oddly, I've seen all of these practices at various companies. I'm sure there was a reason for doing it at the time that made sense, but probably someone just getting caught up in the moment trying to get 'done' rather than asking themselves "what's going to create value in the eyes of my internal client?"

Thanks Steve, ya - huge issue to get folks to listen to a tough message. Of course, I'm also doing the blog thing which means I need to get flamed a bunch too just to get interest up.

CCMiller: you bet - and great comment. I'm thinking a positive attitude is the big difference between those that succeed and those that wish they had success. It's really tough to have a positive attitude if you take yourself too seriously.

and Kristin - you're absolutely right. It looks like you've experienced the challenges of being an analyst and have seen what it takes to deliver value.

Diannageek - lol - cool example. It'd be like requirements facilitation by golfing - once a week we do a 4 hour session together.
...
written by Rizwan Khurshid, May 20, 2009
Keith no offence but i have read your other blogs on HP and found those really useful...

Thanks,

Riz
...
written by Michael Cornell, May 21, 2009
Well played Keith. Well written too.
A good BA needs a good sense of humor. We've all been in those strange requirements gathering meetings...

...
written by Doug Goldberg, May 22, 2009
Keith...Nice!
the absurdities of our analysis world demand that we take a step back, suck in a little unpolluted air, and laugh until our bellies hurt.....so we can do it all over again tomorrow.
...
written by Tze-Chiu Lei, May 27, 2009
Contrary to some comments here, I think the timing of this humorous article was perfect. It's during the tough times that I especially need a laugh, for sanity's sake! My fave's #9, and from my experience most readers don't get to the 2nd dozen pages anyway. :D
...
written by Scott Pollino, June 04, 2009
Right on! You always need to consider your audience.
A visual model for an executive will look much different than the one you pass to your infrastructure architect.
http://www.linkedin.com/in/scottpollino
...
written by Patrick Wong, June 08, 2009
I love this articles, its so "REAL", they are the fact and difficulty we are facing. The question is how we're going to react? Accept it and continue the old way sadly? or do something different to let yourself gain more value?

I truely believe a green BA could not use the above "Tricks" to gain respect, but a real productive experienced BA could. Take Point Number 10 as an example, before you could maunipulate a "Key Section", you should know what is "Key" and shuffle it to an adequate subsequent document, It sounds trival, but I believe not everyone could do it nicely, it is definitely not easy.

Then, when the executive come to you, could you link all relationshop and depict the whole things by your own speech? If you could you are the audience of this excellent article.
...
written by leslie munday, July 07, 2009
If you don't get the humour in the article I question why you are on this site at all. Anyone with analysis experience should see that this is actually a well written tongue-in-cheek list of things NOT to do if you are a serious analyst.

Here are some others:
11. If you have a really important requirement, make sure that you repeat it several times in the document, to ensure that the reader does not lose sight of its importance.
12. Put all the requirements information into a single document (including version history, project team members, phone numbers, addresses, change requests, glossary terms and issues) that way readers in need of this information only have to look for it in one place. This is more important the larger the project.
13. Don't waste time defining common words in a glossary. Readers can pull up their definition from an English dictionary.
14. (I believe the author already caught this one, but it is worth repeating) Keep you readers attention by varying the use of words to explain similar requirements. For example don't keep repeating 'The user enters' information, but introduce words like 'inputs', 'types' and 'keys-in'.
15. If you are not sure whether the information is needed in the requirements document, put it in, just to be sure.
16. Documenting procedures for changing the requirements document is a waste of time and just causes confusion amongst the authors. Let each author have their own copy of the document and merge them together when it comes time to release.

Leslie.
...
written by Pat Maher, July 08, 2009
I'm on the side of the people who loved the article. I read it laughing loudly (apologies to my coworkers) and ruefully. I didn't find it flippant at all because it is such a spot-on depiction of pitfalls.
...
written by Rainer Thiel, November 04, 2009
Very funny, and very true. Pity the few humourless among this community.

@dwright: You are spot on!

Oh, and fwiw, heres a further extension to the useful points about keeping the language lively:

Make extensive use of a Thesaurus, and also, never provide synonyms for anything. Maybe have a glossary, but it should never be anything more than a long list of words, preferably unordered. That way you can hide lots of repetitions. Descriptions, explanations are actually a waste of time. Remember you are dealing with a very smart community of stakeholders who are already in perfect agreement on the exact meaning of any terms or phrases you bring to the table. ;-)

Write comment
We love to see comments! However, please do not market or sell any products. Your comment will be removed immediately!
smaller | bigger

busy