Discussion on:

Don't fall prey to these false project requirements

I think this is a good checklist to help you understand when a stated requirement needs further investigation. I recently posted on the subject of Why Requirements Are Hard on my blog at http://outofthetriangle.wordpress.com/2008/03/09/why-requirements-are-hard/

I have the view that gathering requirements in fundamentally difficult because of the way our mind works but I suggest a few ways that you can ensure requirements more accurately reflect what the customer wants.

We seem to be in the age where the most novice person can have at least a partial grip on technology phrases (and even concepts).

I've been in a lot of requirement gathering sessions where people that are making the requirements start to request a specific technology or implementation, not realising that this comes after the requirement gathering.

The worst was a particular client that had an employee that had once written a ?really cool Access database? and was in the meeting only because he knew what a relationship was. Any time someone was discussing a real requirement, he?d interrupt them with how the tables should be laid out.

... is when that person has already evangelized their vision of what the end result should be to the customers before they even sit down at the table with you. You might as well give up right then, because you will not be able to do anything rational at that point.

J.Ja

"request a specific technology or implementation, not realising that this comes after the requirement gathering."

If a client specifies that the application should run on a specific platform, shouldn't this be called a requirement?

Consider that the client wants to leverage and maximize investment on their chosen platform.

Just my two cents:)

and any constraints or limitations it will impose on the product other that simply 'having' to use it, are understood.

Then yes it is.
Why wouldn't a windows house require you to use windows tech.

If they say use access for an enterprise database, that's a different matter.

It's dumb ass contraints you don't need like use X because Gartner recomended it or some such.

I have a couple of issues with the original article; a) the 6 points listed, and the article itself, doesn't recognize that requirements gathering is a two way communication and iterative process; b) if you don?t know the difference between these 6 items and a ?requirement?, as a requirements gather, you should not even be in the room.
David?s post (link in his feedback) is much closer to the mark. When a client states a ?requirement? you have to ask why until you get the core requirement(s). Often, as David?s article covers, we fill the gap (i.e. I think I know what they mean), but we must also remember the provider is doing the same think ? they have existing knowledge, experience and prejudices that impact their requirements statements (to take an example ? client states they want a gasoline/petrol engine, why? Oh because they are more eco-friendly ? is that a correct assumption on their part? But if they stated, because the operator and unit will be operated in suburban locations for extended periods and gasoline/petrol is easy obtained in these locations if they run out, we don?t carry too much fuel for safety concerns ? and what we have here is actually a set of requirements/design considerations ? i.e. length of operation without refueling, availability of fuel and safety considerations associated with carting additional fuel and if you go on, cost of fuel/operation).
As a requirements gather, you must be good at asking the questions, feed backing and validating requirements (preferably in scenarios), and educator (i.e. broaden the audience?s mind to alternative considerations, impacts of fulfilling a requirement (e.g. think integration, example would be a finance requirement impacting negatively of shop floor flexibility or efficiency), linking the small detail requirement to the overall objects and goals.
Two big risks I think occur during requirements gathering; a) accepting a ?solution? as a requirement (e.g. ?I need batch management? v.s. ?I need to be able to manage perishable goods, which make up around 5% of my inventory, as we seem to through a lot away?); b) focus on requirements not solutions (there is a fine line here between educating and solutioning).
Solutioning is slightly different game, but I think the same considerations as stated above, plus some other skills and approaches are needed once you get into that area.

I find that the best way to truly discover the real requirements of a project is to start asking "why?" until you get to a basic principle. 95% of what users give you when collecting requirements is "how". Some "how" examples:

* We need a drop down list of the vendors we buy from

* We need to see the logo in the top-left corner of the screen

* The text should be green if the status is OK, and red if it is not

"Why", on the other hand, generates these analogues:

* We need to be able to select a vendor that we buy from at this point in the process

* The Marketing department feels that it would help our "branding" if the application prominently featured our logo, and management has chosen to make this a requirement

* We need a visual representation, other than the words themselves, to indicate status; many of our users have poor reading skills

After all, if the customer could come up with requirements on their own, why would they need us? Not to be snide, of course, but it is true. Most people don't really understand their requirements, they simply know what they currently do, what their boss says they are supposed to be doing, and what their pain points are. When you ask "why" and have them examine the underlying assumptions, you help to improve the process, not merely replicate what is probably a bad process to beghin with. After all, if it was so efficient, why bother turning it into an IT project?

J.Ja

Sadly, it is very common here at the gulf area with lots bribes that control even the clarity of the Tenders?

I don?t know what other countries are doing to prevent Tender departments from putting Vague requirements and only respond to certain companies they get bribed by.

Thanks Tom,
I've run into all of these on one project or another over the years. Learning to recognize the false requirements is a big step and learning how to deal with them tactfully can be challenging. It would also be helpful to include an example of a response to each of the example false requirement statements.

In response to: "to make employee's lives easier": we can ask for example time increments per transaction. "With an average of 100 transactions and 10 user's per day, how can we save 15 seconds per transaction?" This kind of question causes some people to realize they are asking for sprinkles on the cake frosting if it really is a "nice-to-have" and doesn't save enough time to pay back the IT resource investment. On the other hand, this can also point out some real value added enhancements that are worth spending the IT resources to implement.

Thanks for sharing your knowledge of project management. You have very valuable insights and I have learned a lot from your articles.

Rick Lorenzen

The examples were too extreme to really provide useful commentation on the points you were making. Of COURSE, "This needs to run on the moon" is not a requirement. Can you show us better examples that might illustrate something we may ACTUALLY mistake for a requirement?

Thanks

Your "on the moon" comment is how I feel about some user requirements for sure, but more like they are the ones from the moon. "You and your '3rd' dimension: It's cute. On the moon we have 5... thousand.. 5000 dimensions!"

Great list of false requirements - (read:users often unclear on the concept of scope, scale, and purpose).

Thanks!

First the checklist are ok. But i wish the examples cited are not the extreme ones.

???This product needs to be able to run on the moon.???

While this one is obvious, but I wish that the article give illustrations that are real-world examples. I haven't had encountered a client making that kind of request.

I had a funny experience. I was sitting at Nortel, Canada and we had to built a user interface for one of their switches. And we wanted to talk with their designers on what could the best approach.

At the same time, our hands were tied. The buget is low, team is small, etc.

Now when you ask them, one designer commented that they would first call photographers to take some photographs and then come with possible UIs. And at the same time, we were already asked to have the same UI concept (they had earlier ones) and do as quickly as possible.

Sometimes, you need to take it with a grain of salt. A lot of people say a lot of things. Some are down right arrogant, some are really stupid, and some are political. Listen to all the **** they have to tell, but finally it happens what is doable.

--Satya Narayan Dash

Requirements gathering includes not just the functional requirements, but the non-functional ones: Budgets, deadlines, technology, operating environment, security, etc. We shouldn't dismiss these as "false" but I do agree that we should not confuse them with the functional requirmements. I recommend separating requirements into three major categories - functional, constraints, and security/compliance. Requirements gathering and validation/signoff for each involves different stakeholders.

This may be a complete over-simplification or overly holistic approach, but I think if you ask the right questions, within the right context, "flavored" the right way for the audience, then you can get exactly what you need.

In the end, if the business unit has to provide all the answers you're looking-for, you'll never get what you need.

The trick is to lead the conversation with your questions, and allow the business unit to respond. Ask more questions if necessary for clarification.

This way, the business unit thinks they're in control since they're providing all the answers... but you (the Master Jedi) are actually leading the conversation with your questions.

Unfortunately client often don't know what they really want and are not aware of
what will work for the end user.