By Erwin L. Sison
As I have mentioned on my previous blog on How to conduct an effective Requirements Gathering, the input document in that activity is the Requirements List from your Sales Team. Now, the output document is still the Requirements List but this time it’s an even more detailed version.
The project team has just come back to office after a grueling week or so of onsite Requirements Gathering. The good news is you got what you want. The bad news is, it's not time to relax. Now that the dust are all settled its time for the next phase of the project.
Enter Business Analysis.
I have also mentioned from my blog How to conduct an effective Requirements Gathering that I will discuss what is Requirements Analysis and Business Analysis.
Requirements Analysis is an activity that involves both the client and the project team, it is an activity where the project team gathers and records information supplied by the client. While Business Analysis in activity within the project team only, this is where you go through with all the information you have gathered from the previous activity and come up with a solution to all the requirements. Bottlenecks within the business flow are addressed here. This is where you try to improve the business process of the client.
Personally, this is the most challenging part of the project. This is where the whole team rolls up their sleeves, put on their thinking caps and work. This is practically when the backbone of the ERP design that will be rolled-out in the coming months will be defined. This is the time when the project team will lay the foundation of the solution that will be implemented.
Here are some tips on how to go about this very important yet tedious task.
- Classify. It is always good to start by splitting the requirements into two general classifications, Standard and Customization. For the sake of everybody, I will briefly explain these two. Standard are requirements that you could deliver without touching a single line of code. While the Customization, as its name suggests are requirements that needs to be developed.
- Sub-Divide. After classifying them into two, look closely at the Customization List and further divide it into two again, this time, In-Scope and Out-of-Scope. Since most of the time, out-of-scope requirements are chargeable or up for negotiations. Alert your PMO on the Out-of-Scope list and let him take care of that with the client. I could discuss this extra activity on my future blog.
- Use previous Solutions. It is a known fact that there are companies out there with similar workflow thus similar requirements. To save some precious time, it is not a bad idea to implement something that has already been tried and tested with other projects. Use your experience to your advantage.
- Involve the Technical Team. While the functional team can handle all functional aspects, it is important to involve the technical team as well specially in a complicated solution that requires extensive coding. Always remember that two heads are better than one.
- Communicate with the Client. It is normal to find yourselves facing a blank wall after a more detailed study of the requirements. There are times when you realize that you failed to ask an important question during the Requirements Analysis phase or there is information that simply needs confirmation from the stakeholder. Do not hesitate to call the client to ask or confirm. After all that is what those contact details you gathered from them during the Project Kick-off Meeting is for.
- The Simpler the Better. During this phase, since the whole team has put on their thinking caps, it is common to over design something. Avoid this! You do not want to build a White Elephant, if you find yourselves designing a very complicated solution, think again. Look at it at a different angle. If you need to involve another colleague to look at it, please do so.
- Ask for Opinion. Number 6 kind of preempted this. It is perfectly all right to seek help from other teams in terms of opinion. You will be surprised that sometimes you are able to solve a problem in your head just by discussing it with another person or other team. If the other person has an even better solution then consider it as a bonus. It will not make you a lesser capable Project Manager by asking opinion from others.
- Document everything. Make sure you document everything by using your Project management tools. This activity might take you several weeks to finish depending on the scope, so documentation is very crucial. There are several output documents in this activity, which I will discuss in my future blog.
Again you could add some other strategies that you know would work for you. At the end of the day what is important is that the Project team has addressed all requirements and has a workable solution before you meet with the client again. Be wise, be systematic and most of all be patient.