Across the board, successful IT projects follow a certain recipe for success. Time and time again, however, you’ll see organizations skip this step, or that step, and the result can be less than satisfactory.
One such example is the Requirements Definition phase, which answers the most basic questions: “What needs to happen?” and “Why does this need to happen?”
Tweet: “Tips for a Better Requirements Definition Process”There are several reasons why this phase might be overlooked by a project team. Here are just two:
- Defining requirements is more conceptual than tangible. IT is heavily result-oriented by nature. The mantra is “give me something I can see, give me something I can touch.” Strategic visioning and future state is not even considered “real work” by some IT folks.
- IT often receives a project with rigid budgetary and scheduling constraints, where a Requirements Definition stage is not built in. Someone else applies their decision making power, allocates the capital, and decides that IT will only acts as a tool to design, code, test and implement the solution. In this scenario, someone’s idea with the attached budget and deadline is all the defined requirements a project will ever see.
But a proper Requirements Definition is a crucial step and if skipped can make life for a PM very difficult indeed. This phase will omit surprises during design, development, testing, and support.
I have personally seen how focused efforts during the Requirements Definition phase can reduce the number of support issues following go-live to the single digits.
Over the years, I’ve honed some techniques to give proper justice to this important activity during an IT project life cycle.
Apply the steps below to establish this phase as an important, indispensable step—especially in the eyes of upper management.
Requirements Definition Phase Activities
- Conducting interviews
- Gathering use cases
- Performing research and analysis
- Diagramming business processes
- Validating findings
Note: depending on the type of IT project, the order of these activities may vary.
Here is a typical sequence of events during the Requirements Definition phase of an IT project:
Interviews
During this stage, the project team will conduct interviews with upper management to understand and record the vision behind the project: What is the driving force? What is the urgency? Who is going to be the owner of the project and what business commitment can the team expect? What resources can the team use? This information needs to be recorded, shared and preserved.
On several engagements, I have seen this information get lost, especially during “changes of guard,” where resources are re-allocated, removed, or added.
This information is very important during a long implementation, when people need to be reminded and inspired by the real benefits of the hard work they are putting forth.
Use Cases
Gather information on the current processes. Ask questions like: Do you do these operations? Do you utilize these features during your normal business activities? What information do you need to receive to perform this step? And very importantly: what else we are forgetting to ask?
Tip: Use a table of contents from the proposed software as an agenda for the meeting with business representatives.
The purpose of this step is to gather a preliminary list of activities that are happening now, and what might need to be reproduced using a new software solution.
Research and Analysis
During this stage, the project team has to rely on internal Subject Matter Experts (SME), and often external consultants.
Generate a list of dependencies: Reports; Inbound and Outbound Interfaces; Customizations; Licensing Requirements; Hardware and Software Requirements; etc.
This step is usually the hardest, since it can be hard to find sources of information. People who implemented legacy solutions might have since moved to other divisions or left the company.
The truth is, any list that may come out of this stage of the requirements gathering will seem incomplete and temporary. Yes, that is the feeling. Yes, it is also the reality. But it’s necessary to ask these questions to lay the foundation for next steps. If you capture 80-85% of the project requirements during this stage, you’ll be in good shape.
Process Diagrams
During the process diagramming stage, you draw a lot.
Using information gathered during the previous steps, draw the business processes as they are now (current state), and draw new processes as they will be (future state). Suddenly, you will find holes.
You will see that some operations or procedures are completely absent. That’s good! This is the purpose of the exercise.
You might need to go back to managers, SMEs, and support personnel to ask additional questions. By the end of this stage, you will ideally have 90-95% of your requirements collected.
Validation
During the final stage of requirements gathering, organize meetings to review the findings.
The ideal form of presentation is a peer review, when departments present their findings and all parties cross-check and cross-validate the information.
Email is not an apt medium for this stage. It is very important to narrate the results in audio-visual presentations.
Cross-departmental presentations do wonders to people’s minds. They learn how “the other side” works, and at the same time uncover new dependencies, special cases, or configuration procedures that were skipped during the previous steps.
By the end of validation stage, you should approach 99% completeness of your requirements for the new project.
Finally, present the requirements to upper management, to confirm that they are still comfortable with moving forward.
Conclusion
The information that is gathered during Requirements Definition is transferable. It is tangible. It will help the project team develop a detailed RFQ, if that is the plan.
After a proper Requirements Definition phase, the next steps (in the Design phase) should be very clear.
The true payoff from a successful Requirements Definition stage is the ability to make an informed decision about the project. Even if management decides to change direction and go with a different solution, time spent on defining requirements was time well spent.
