How does your end-user derive true value from the product/service you provide? The end-user doesn’t care too much if the product/server was delivered within budget or on-time. They are most concerned and get the best benefit as long as their requirements have been met in its entirety.
Therefore, it is of foremost importance to nail requirements early, regardless of the project methodology you plan to employ. Even though early requirements gathering is prevalent in every facet of any profession out there why is it that we more often than not miss those crucial requirements and the end result is NOT what the end-user wanted.
Inexperienced business analyst: We often do not have the right person for the job and end up compromising this very important step of the project. During my time working at a software development company our early business analysts were software developers. They were excellent software developers but lacked the knowledge to elicit requirements. They would more often than not jump straight into deigning the solution without fully vetting out the need.
Insufficient documentation: I am often guilty of this myself but there is really no excuse for insufficient or no documentation. There are always multiple key players on every project. A good business analyst cannot capture all the requirements and keep it to themselves and save it in their minds database. These requirements must be written, yes, I said it. They need to be documented so you delivery team, your client, your stakeholders, project managers all have the opportunity to review and agree to what is being delivered.
I am sorry, there typically is an excuse for no documentation and that takes me to my next point
Time/budget: I have heard this often, “there was not enough time to document”. At time this is good reason and not an excuse for missing the requirements documentation. Here the project manager needs to play a pivotal role in engaging with the customer to educate them on the importance of the requirements gathering process to budget accordingly. In most cases if you try to same time/money in the requirements phase it will likely end up costing you more in the long run because you will miss something important.
On the job observation: This is great tool to understand your client’s business, yet, it is underutilized. The successfully delivered projects are the ones where you the vendor can fully assimilate yourself in your client’s business process. When you, the business analyst understands why your client needs to spend 3 days to generate a single financial report you will have a much deeper appreciation and a vested interest in delivering a solution that will benefit that client. Therefore, not all requirements are collected in a face-to-face interview inside a conference room.
Talk to the right people: Identify your stakeholders early. Your project manager and the client need to identify the key people to interview and observe. I have been onsite as a business analyst totally unaware of the players and spent time with that “squeaky wheel” trying to discuss the project only to find I had wasted some precious project time gathering requirements that were not really vital to the project.
Requirements are never 100%: You can have all of the above points satisfied and yet find that you missed some requirements. I have learnt this over time and share this with business analysts that your requirements list is a living and ever changing document. A novice business analyst often falls prey to the idea that the requirements must be 100% correct before they can share with the team. They feel that any corrections to the requirements translates to them not doing their job. This is so far from the truth and I have fallen into this trap myself as a junior business analyst.
Therefore, in an effort to ensure your requirements are close to 100% correct they have to go through a few iterations with your client. Share the requirements early and meet with the client to get the needed buy-in and always use a collaborative approach to requirements elicitation.
AMIT TRASI |Project Manager
Amit is responsible for institutionalizing project management governance at KTL to streamline ERP implementations. With over 15 years of technology experience as a software developer, project manager, and program manager, Amit has managed end-to-end ERP implementations with Dynamics NAV and GP as well as POS implementation with e-Commerce front end. He holds extensive experience deploying POS and ERP applications at non-profits, theme parks, and museums across the United States. Amit joined KTL in October of 2013 and holds an MBA in Information Systems as well as holding a Project Management Professional certificate.
