Project Management

Don't fall prey to these false project requirements

If you could ask your clients about requirements and know they were responding with exactly everything they needed, gathering requirements would be a piece of cake. However, in the course of the requirements-gathering process, it just usually isn't that easy.

In project management, requirements describe how a product or service should act, appear, or perform. These details explain the features and functions of the products or deliverables the project needs to have.

If you could ask your clients about requirements and know they were responding with exactly everything they needed, gathering requirements would be a piece of cake. However, in the course of the requirements-gathering process, it just usually isn't that easy.

In fact, you'll often hear information from clients that, on the surface, appear to be requirements when they actually aren't requirements at all. We call these items false requirements.

False requirements come in many forms. Here are some of the more prevalent categories:

  • Vague requirements: How many times does a client offer a statement that contains a hint of one or more requirements but doesn't offer any kind of specifics? Vague requirements require good follow-up and probing questions to make sure you have the correct level of detail. For instance, your sponsor might tell you, "I want this application to make employees' lives easier." This is not specific enough to be a requirement. You need to ask some follow-up questions to learn exactly how the client wants the application to help employees.
  • Opinions: While opinion statements can be requirements, many times they're not. In many cases, the client will provide an opinion on the features and functions of a deliverable, and these are valid statements. However, if a client manager tells you that he thinks the company is spending too much money on the project, he's offering an opinion --- not a requirement.
  • Project-related statements: Requirements describe deliverables -- not the project. For example, if a client tells you that "we should prototype this solution first," he's giving you input for the project approach -- not a requirement. If a client states that she wants the project completed by a certain date, she's giving you a schedule constraint -- not a requirement.
  • Out-of-scope statements: When gathering requirements, you may find that you get off on a tangent (either related or unrelated to the discussion). For instance, when discussing a set of reports, the client might remark that a coworker has a new printer and that she would like a similar one. This is not a requirement; it's out of scope for the purposes of the reporting discussion.
  • Comments from the wrong person: It's important to know the role of a person providing requirements, so you can determine if the information he's providing is consistent with his authority. For example, a user might tell you, "I think we should allow our vendors access to this information." This isn't a requirement since the typical user doesn't have the power to make this type of decision.
  • Unrealistic or not testable: You might hear requirements that are really just marketing hype or extreme hyperbole. For instance, a client manager may tell you, "This product needs to be able to run on the moon." This isn't a real requirement since you can't test or validate it. Make sure to ask follow-up questions to determine the real requirements behind the statement.

Learning how to quickly recognize these false requirements and how to dig deeper for the details is vital for a project manager. It can help save time in reworking the project as well as prevent further confusion later in the project.

Want more information about managing successful projects? Automatically sign up for our free IT Project Management newsletter, delivered each Wednesday!

18 comments
schultzy05
schultzy05

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

addicted2speed
addicted2speed

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.

donstrayer
donstrayer

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.

ndsatya
ndsatya

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 shit they have to tell, but finally it happens what is doable. --Satya Narayan Dash

jcjr031064
jcjr031064

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.

kfrey
kfrey

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!

tags
tags

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

Rick.Lorenzen
Rick.Lorenzen

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

fabishi
fabishi

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.

david
david

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.

mattohare
mattohare

And a lot of the article was not saying to ignore the non-functional, but ask questions to get to where it relates to the function. Bottom line, everything on the spec needs to relate to something they want and need in the deliverable. And it has to go towards that deliverable's ability to perform its function.

Matthew S
Matthew S

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.

mattohare
mattohare

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.

Justin James
Justin James

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

jcjr031064
jcjr031064

"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:)

Justin James
Justin James

... 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

Tony Hopkinson
Tony Hopkinson

If nothing else it helps you extract a much better picture. Contradictory requirements is always a good one. Getting them to question their assumptions is good as well. The pleasantly surprised expression after you explain if they changed that to this, which would still do the job, they can now or in the future get those and them as well...

Tony Hopkinson
Tony Hopkinson

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.