The first step of a report’s development process is the analysis phase. The analysis phase aims to create a detailed picture of the final deliverable and is usually conducted in the form of meetings that involve all Users of the final deliverable or, as commonly known, Stakeholders. Including all Stakeholders ensures that no vital information for the implementation is lost and that everyone is aligned with the expectations of the final deliverable.
At WITSIDE, we believe that the analysis phase is one of the most important stages of the implementation process, as needs, expectations, and deliverables are aligned. If we had to pick just a few of the most important lessons learned from our experience, then these would be summarized as follows:
1. Focus on the end Users’ benefit!
Many times, we assume we know the real value which the implementation will provide to the end User. This assumption sets the stage for a potential technically sound solution which does not provide the “right” solution to the problem. As a result, the implementation is not being fully utilized or its usage gradually decreases after delivery. So, before you start developing a solution, ask yourself: "Is the value that the implementation will bring to the end Users clear?", What will they actually achieve that is not present in their daily lives?", "What problem am I solving through the implementation?".
2. Don't Just document Requirements, Elicit Them!
What is the difference between documenting and eliciting and why is this such a big deal? The concept of just writing down what you hear contains an assumption, which is also a potential risk. This assumption is based on the fact that the specifications are clear both in terms of their content (available information) and the goal of their implementation (value they will add), which is most often not the case. Eliciting means to deeply understand a need that may not be clear even to the end User.
3. Understand the current situation (AS-IS State) in depth.
Having elicited and documented requirements now is the time to focus on why is it difficult for users to achieve the same goal today. What information is available for use? What is the process they follow? How does it start and Who is involved? Your goal is to identify any risks or obstacles that have not been adequately understood and could potentially jeopardize the project, potential integration points that have been disregarded or areas that affect the solution and have not been identified yet.
4. Validate the Requirements.
Having elicited but also documented requirements and developed a clear view of how they will be implemented, as well as clarified which goals will be accomplished as a result of their implementation and Who will be responsible for testing them, it is now vital to ensure that all Stakeholders are on the same page by signing off what is expected from the development team.
The goal of all the above is not to add more time or bureaucracy to the existing process, but to ultimately implement a solution that will make the user's daily life easier while leaving a positive mark on their experience.
Dimitris Kalogerakos, Senior Business Analyst