Poor Requirements

Poorly defined project requirements are not as uncommon as you might think and they are one of the main causes of project failure. Requirements are ultimately delivered by a finished project. If they are poorly defined then the whole project will suffer because the team isn’t clear on what is expected of them.

Common problems include confusion in regards to what deliverables are expected, a lack of communication between the customer and the project team in defining the requirements, vague requirements, a lack of prioritization, incorporating unnecessary functionality and so on.

The key to resolving these issues is to ensure that the project manager consults with the customer or project originator to clearly define what their expectations are. Often, the needs your project addresses may not always be clear.

For example, let’s say that your project is meant to overhaul the financial system of your organization. The question is whether this overhaul addresses poor communication, a lack of organization or is meant to cut costs. This is why it is essential to understand the real desired results.

The problem is that many customers reveal needs that aren’t relevant. It is the business analyst’s job to dig deep and discover exactly what the customer’s expectations are. This can be difficult because determining what people are thinking is difficult at the best of times.  Sometimes people aren’t sure themselves what they want, at other times they prefer not to reveal their needs and sometimes they simply aren’t able to express themselves properly.

Some solutions to this issue include:

  • Lengthy discussions or workshops with the customer, even if it means they keep repeating their needs. The more they talk, the better you will be able to understand what their expectations are.
  • Clarify aspects you find unclear, even if you have to do it multiple times. It’s better to ensure you fully understand what the client expects rather than walking away confused and botching up the whole project.
  • Listen carefully to the client for any contradictions. If they contradict themselves, they might not be sure what they want and it’s up to you to point out the discrepancies so that you can resolve the issue, otherwise you might be blamed for poor results when the client simply wasn’t certain what they wanted.
  • Confirm the information you have from multiple sources. This could mean conferring with someone else from the client’s team, or it could mean having another person from your team present when the discussions are taking place. This helps to confirm whether or not your understanding of the requirements is accurate.
  • Use questioning techniques to dig down to the real cause or problems.
  • Observe the client or user performing a process or using a system.
  • Document the process. Understanding all the elements and people involved gives you a

broader picture of the situation and environment, you may identify that the real root
cause of the problem stems from poor quality information from a system used 5 steps
ago in the process by another person.

4 Characteristics of Good Requirements

1. Ensure the requirements are clear, concise and measurable. For example, a requirement to improve customer satisfaction is not sufficient. You need to have a way to measure the  success of the project. This can only be done with a measurable requirement.

In this case, it could mean anything from being able to answer a customer’s question 1- second faster to improving system performance by 10%. You need to clearly define the  requirement because if there are 10 people on the team, there will be 10 different  interpretations of what the goals are.

2. Ensure the requirement offer value to the project. In other words, if you were to remove  the requirement in question, would the project change? If the project would remain the same, then the requirement in question is likely irrelevant and will simply add to the confusion.

3. Make sure the requirement is stated in a way that everyone understands it. In other words, if five people read the statement, they should all understand the same thing. Diagrams, mock-ups and pictures are a good way to ensure a common understanding.

4. The requirements need to be directly linked to the scope of the project. For example, if the scope of the project is to “develop a new application that allows users to post to all their social media profiles from one window on their mobile device”, then creating a list of the top five smart phones on the market is not within the scope of the project.

Comments

Powered by Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *