.png)
The most vital stage of any project is ensuring that all the requirement and needs have been very carefully gathered. 3B Media's David Shapiro presents a few tips to ensure that it is done right.
“Requirements? Sure we gather requirements” is something you will hear from a lot from project managers when setting out on a new project.
That is great. Gathering requirements is, without doubt, the most crucial phase of any project. It outlines the needs that the project needs to cover. It serves as the oracle for the entire project from the RFI/RFP process, through to the actual implementation and rollout of the software.
However, it is not enough to just ‘gather requirements.’ The real questions that you need to ask are:
How well are the requirements being gathered?
Are the real, low-level business needs of the organization carefully being collected and documented, while at the same time the high-level, end to end process is being taken into careful consideration?
Are the right team members gathering the requirements, asking the right questions and speaking to the right people in the organization?
Will the requirements play the vital role and contribute to the project further down the line, or will they remain as just another document that will be used for the tender process and then cast aside?
Too often have I heard of projects that have missed the set budget and defined schedule, regardless of how good the project team is. One of the main reasons for the lack of success was that too many crucial issues were found late in the project, resulting in the need to allocate resources and time to resolve the problems that were not part of the original project plan.
Disclaimer: Despite what you’ve just read, from my experience, it is almost inevitable that some level of requirements are left out or forgotten. However, it is possible to reduce these ‘left-out’ requirements to a bare minimum, and the purpose of this document is to describe what steps you should take to accomplish just that.
So how should you go about gathering all of your requirements?
Here is a list of 4 do’s and dont's when you are faced with the critical tasks of gathering requirements.
Rule # 1 - Ask yourself the right questions
You cannot start gathering requirements without asking yourself three crucial questions:
• What?
• Why?
• Who?
What?
When speaking to the users to document their business needs, you have to ensure that you have a 100% understanding of the requirement at hand. You have to be able to record the requirements in a way that fully portrays the need, and describes the need not only from an operational perspective but also from the business/workflow perspective, which brings us to the next question.
Why?
Know the ‘Why.’ I don’t mean why you are gathering requirements. I mean the ‘why’ behind each requirement. When a user requests or needs a specific piece of functionality or ability from the system, you must understand the business logic behind this, and why the user is requesting it in the first place. Not only will this allow you to better understand the need, but also the standing point of the user. Knowing the ‘why’ may also allow you to propose a solution that already exists, a workaround, or even something that could be fulfilled by a feature or requirement elsewhere, resulting in a reduction of the amount of required customization, minimizing costs and time along the way.
Who?
The ‘Who” is made up of two parts:
1. Who is most suitable to gather the requirements?
Which business analyst, or other members of the team, have the best ability to do a proper job gathering requirements. These people need to have a good understanding not only of the business, end-to-end processes and data flow, but also the high-level shortfalls of the current legacy system and processes. Furthermore, they have to have a clear understanding of why the decision has been made to replace the existing legacy system, to ensure that the same sore-point do not repeat themselves. Lastly, they must be people who are not afraid to ask questions and probe deep, no matter how 'stupid' it makes them seem.
2. Who are the most suitable staff and users to be interviewed to provide the necessary information?
Simply answered, the people who can give the maximum input. But wait. Who are the right people? In most cases, it is good to take 2-3 people from each department. 1-2 will be super-users; users who have been with the company the longest and most presumably have the best understanding of how things work. However, the time they have been with the company should not be the only guideline. There may be users that have been with the company only a few months but possess the technical out-of-the-box thinking that could be vital to the project. Identifying these traits is essential. When in doubt, speak with peers or more senior staff to get their input as well.
An additional person will be the team leader/department manager. It is vital to include this level of management in the conversation. Despite that fact that in many cases managers will not be extensive users of the legacy systems, their managerial approach into how processes work beyond the system is vital to the requirement gathering process.
Rule # 2 - Never Speculate
When you are documenting requirements, never, but never, take anything for granted. No matter how dull the issue at hand might be. If there is a process that you are sure, 100%, works in a certain way, always back that theory up with confirmation from the user. Where possible, everything you hear during the process should be backed up with a demo by the user.
Always look at the legacy systems the users are using, even if it is the shape of an Excel spreadsheet or Word document. You will be surprised how much additional information you will get from this beyond what the users are telling you. When looking at the legacy system, implement the three ‘W ’s discussed in the previous section of this article.
Taking something as a given without following it up could have very costly circumstances later in the project.
Rule # 3 - Dig Low. Look High
Simply put, don’t be afraid to drill into the bits and bytes of each requirement, but at the same time, keep a very close eye on the high-level, end-to-end workflows, and how each requirement fits in.
What this means is getting the whole picture on the micro level, but also ensuring that the requirements do not disrupt anything on the macro level.
When diving into each requirement, don’t be afraid to ask annoying, and what may seem like stupid questions. You will be shocked at times by the answers that you get.
What exactly do I mean? When interviewing the users, you may receive information that at face value seems complete. However, if you start to probe a little deeper, you may find treasures lying at the bottom of the ocean.
Let me give you a small example of something that I came across recently.
During the discussions, we were analyzing how to implement pre-defined secondary event templates on commercial breaks. I learned that when preparing the playlist, secondary events are placed on a 3-second station ID logo that is scheduled at the beginning and end of every commercial break. Seems pretty straightforward, no?
However, when probing deeper, I discovered that the station logo changes depending on the program and that not all logos have a duration of 3 seconds. I also found, by paying careful attention to the current lineup, that promotions proceed only some of the logos and not others.
This information is vital because it dictates what is required to ensure a full solution to the issue. If we want to be able to define a secondary template on commercial breaks in the new system, we need the flexibility to be able to correctly assign it to the right logo event, regardless of its duration and what came before it.
By continuing to ask questions, and probing more in-depth into each process, who are very likely to find crucial information that could easily be left out and may not be discovered until the UAT stage.
Don’t leave anything out of the requirements document. You must jot down even the most simple, stupid, visible, a goes-without-saying feature. Why? Because it is these simple, stupid, obvious and goes-without-saying features that are so much taken for granted, that in the final analysis, they will not have been discussed or included in the scope of the project. All of a sudden, you may find yourself with a partial solution for these features, or a solution that does not works as you would have expected.
Rule # 4 - Document the Requirements in a useful manner
Before you start writing your requirement, make sure you have a clear vision in your mind as to exactly how the document will be laid out.
As we mentioned at the beginning of this article, the requirements are something that will accompany the entire life-cycle of the project and act as a constant guideline ensuring that the installed solution covers all necessary business needs.
As such, the requirements document should be one that can also be used throughout the life cycle of the project, to be referred to in a simple yet clear manner when needed.
Each requirement should be prioritized with the help of the users. This is essential not only to better know which requirements are important than others, but also the prioritization will help assist you in evaluating the vendors’ replies. A vendor may have replied a lot of ‘Yes’s”, but if these are all for less important requirements, then this does not count for much.
Once the preferred vendor is chosen, and the system implemented, the requirements document will serve as a checklist to ensure that every requirement is indeed satisfactorily met.
This stage is crucial for not only discovering which requirement is not in fact met, but also discovering requirements that may not have been documented in the first place. As we mentioned earlier, despite the efforts you put into the requirement gathering process, it is almost inevitable there will be some requirements that slip through the gaps. Therefore, identifying them as soon as the system has been installed locally for training and UAT purposes is essential, allowing for the issue to be quickly resolved, resulting in as little damage as possible to the project's budget and the set timeline.