Enrich your projects with “rich requirements”

I’ve walked into many otherwise well-planned projects where the requirements have gone straight from the users’ lips to the WBS.  This is bad, bad, bad, and wrong, wrong, wrong.

The smart PjM won’t let this happen.  Smart IT management won’t let this happen.  Why?

It’s smart to manage stakeholders’ expectations and requirements from the earliest stage of the project.  We know that a key measure of project success is meeting (at a minimum) stakeholders’ expectations (and, while this isn’t the only CSF, we know that an on-time, on-scope, and on-budget project not meeting stakeholders’ expectations will definitely be categorized as a failure).  The smart move is to make sure those expectations are managed properly from the day the project charter is drafted.  And the way to do that is to work closely with users early during the conceptual phase (the Microsoft Solutions Framework calls this the “envisioning track”; Doug DeCarlo calls it the ”visionate” step) to insure the requirements are realistic and achievable.

This approach doesn’t mean you want to reign the requirements in-on the contrary!  The goal is to make sure the project team can deliver effective results.  And a great way to accomplish this is to have PjM’s and business-savvy team members work with the stakeholders and users in developing what I call “rich requirements”.

A “rich requirement” is a user’s requirement enriched by feedback, suggestions, clarification, and a sharpening of focus from the project management side.

Users’ requirements are frequently couched in terms of an existing, specific situation.  Smart IT people know the use of design patterns and leveraging existing code offers huge productivity and quality benefits.  So, a smart IT person working with a user’s requirement should be able to see not just the specific situation but the abstracted requirement, or, not what the user is asking for, but what the user wants.  The process to accomplish this is to question the user about the requirement itself and the framework of the requirement, and then to offer a vision of the deliverable.

Here’s an simple requirements example.  The sales executive needs a monthly sales analysis report ordered by sales territory, with orders and dollars.  The IT requirements specialist can offer these enriching ideas like these:

1. Design the report to run from a date range, thereby allowing daily, weekly, quarterly, and ad hoc reporting.
2. Design the report to run with territories based on state/province, country, metropolitan statistical area, and based on distance to distribution centers.
3. Design the report to run with various ordering options (e.g., descending dollar volume, by state/province).
4. Design the report to support reporting by regional sales managers.

Okay, none of this is rocket science.  Even so, you’d be disheartened at how often IT people fail to think farther ahead than the user.

It’s likely the user will concur with some ideas, reject others, and leave a few undecided.  That’s okay-what we’ve done is demonstrated IT’s value by showing an understanding of, and an appreciation for, the nuts and bolts of the user’s side of the business.  Business users are pleased when IT people know the details of the business, and if you had been awake during Accounting 101 instead of working on that goofy bubble sort routine, you’d know sales go in the credit column.

Ah, you say with a gleam in your eye, you’ve gone out of scope and you’re gold-plating.  No, I say-we’re not doing project planning; we haven’t defined project scope.  We’re developing requirements that eventually will become part of the preliminary scope.  What we’re really doing is building more value into the project for the user.  If IT offers 10 suggestion and the user agrees that any have value, the following has been accomplished:

1. IT has proved it is sensitive to the big-picture needs of the business.
2. IT will accelerate the value received from the solution by providing more features earlier.
3. IT, by providing a ”better” solution, has increased customer satisfaction by reducing the possibility of the user coming back with an enhancement request.
4. If unrealistic requirements (“sales report broken down by age and sex of the customer”) are removed, the development effort will be simplified.
5. The net effort to develop this report will be substantially less, and quality will be much higher, than if IT made multiple modifications to the report based upon a series of enhancement requests.

The IT requirements person must know enough about the business to make a reasonable case for any proffered suggestion.  With any requirement, it’s critical to test it by challenging its basis, and the best approach is to ask for a clarification or explanation.  Respectful questioning was once known as the “Socratic technique”; today, it’s known as the “5 why’s”.  The goal of questioning is not unlike the process of decomposing the WBS to get to what Karl Wiegers calls “inch-pebbles”: by asking questions, you’ll refine your understanding of the problem, you’ll uncover hidden issues, and you’ll be able to do a better job of estimating the effort required for delivery.

A key IT success factor is recognizing the need to be in the user’s office, not hunkered down behind a pair of 24″ monitors in the IT department. 

Guiding, assisting, and coaching the user during the requirements definition process can pay big dividends all around.  It helps IT and the project team deliver the right value earlier to a happier user.  And a happy user is IT’s best friend.