Requirements Extraction / Capture / Development / Specification…or, Building a Common Mental Picture

Parker Smith is a tenured MMY associate with 30 years as an IT consulting veteran. A graduate of West Point, Parker’s intelligence, dedication and work ethic has made him one of our most sought after analysts. His background includes project management, reporting systems development, application development, relational database design and implementation, business intelligence analysis, and software analysis and testing. Parker has been kind enough to share an eight part series entitled “What I Wish Someone Had Told Me”.

Part One: Requirements Extraction / Capture / Development / Specification

Or, Building a Common Mental Picture

I often joke that consultants and developers have something in common with people having relationship problems – you see them raising their gaze to the skies, and in a tone of extreme anguish exclaiming, “Just tell me what you want!”

It’s surprising how often folks: A – sincerely believe they know what they want, and B – sincerely believe that they have given you a clear, complete, and internally consistent description of just what that is. And, turn out to be mistaken on both points.

Well, even if things are not clear, we still need to get the work done, and to get the work done we need to understand what is being asked for, as well as what is wanted and needed. Optimally, you are ensuring that everyone involved has a common mental picture of the desired end state – where everyone is agreed on what is wanted, and why, and how to proceed – maybe for the whole effort, or maybe just on how to get started and how to figure out the rest of it.

I often make the offer to a client that I will undertake to provide anything within the scope of work “that you can unambiguously define”. This works as something of a test – the best folks to work with are the ones who laugh, and then get a very thoughtful look. They are the ones who pick up on the word ‘unambiguous’, and realize just how much I am hedging my promise. And, it prompts them to see that they, too, have a role to play in defining what needs to happen.

A good starting point for all of this is to come in knowing the formal terms of any agreements. Often there is a master agreement with the organization and a specific order for your tasks, or something similar. If so, get copies of them if you can, and make sure you understand them and incorporate them in your work. But, be prepared for formal documentation that only provides an outline of what needs to happen.

There may be a good bit of work involved in all this – look at it as a key part of your job, and dig into it. Concentrate on what is needed to make a good start, and to ensure that no one involved is waiting for work. Know, too, that you will need to revise and extend the requirements based on experience and events – make sure the ‘common mental picture’ is kept both common and current, and you will make success much more likely.

A final note – it is fine to play the ‘inexperienced’ card, if it applies – it shows you are willing to be honest about what you do and don’t know, and it lets the people you work with know the kinds of information that you expect them to provide. If you do this, though, you want to do it early, while at same time being sure to communicate what you DO know and what you ARE bringing to the party. You want to show that you are looking for a partner who will complement your contribution – not someone who will have to carry you along.

Coming Soon – Part Two: Understanding Organizations

Or, Smith’s Extrapolation from ‘The First Myth of Management’