Project Management | Project Managers

(This blog first appeared in the Business Analyst Times, May 19 posting)

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.

Comments (2)

Subscribe to this comment's feed

...
written by Digigurl, May 27, 2009

How about "Never write in plain English; convoluted, pseudo-technical language that cannot be parsed by a grammarian will ensure your documentation is carefully reviewed and analyzed. If the executives can't understand anything, they will either (a) ask you, or (b) give up and assume that they're the ones who are too dumb to understand the important work you do in the organization."

• 
• +1
• 
• 

...
written by dannyboy, May 29, 2009

Acronyms...use acronyms whenever possible. Think of the savings.

• 
• +1
• 
•