The success of a project is defined by many factors. Few are more important than the accurate depiction of the ever elusive requirement. No matter what naming convention you use, where you house them, how you track them, they better be exactly what the client wants. Roughly 66% of all projects fail because the requirements are BAD. It may be technically unfeasible, too vague to be developed or tested, or simply not what the client wants to achieve.
As a Business Analyst, you are driving the workload for the entire project team. Everything you submit is going to be reviewed by one or more team members and they better be free of ambiguity. Surprisingly, 53% of all requirement validation occurs AFTER signoff, either in the development or test stage of a project. This is not good policy for getting your team on board for a successful project. Teams should be collaborating on requirements, making sure they understand the business goal and how they will be implemented technically. They should be made available through a collaborative workspace, where comments can be entered, stored and responded to by all members of a project team.
I started my career as a QA Analyst in the tech sector. My job was to sift through pages and pages of requirements and make sure they could be and were tested across all required platforms. I can tell you with certainty; it is much easier to review requirements than to create them. However, gone are the days where stakeholders are willing to pour through monstrous requirement specifications… There is just too much other “stuff” to do. There are many ways to get requirements entered and consumed. You just have to pick the best solution for your firm.
It’s not good practice to relay critical requirements through email, as employees simply get too many emails throughout the day to track and digest everything that comes in. E-Mail collaboration can also silo critical discussions, often excluding key resources rather than including them. Get your requirements out there in the open to be discussed! You can always use text to define your specs, but visual models can be an excellent aid with reviewer buy-in, engaging the reader/collaborator to become involved with the entire story, not just the words.
You may not always have the right resources on a project. You may not always have the scope, schedule or budge you really need to succeed. You may have to deal with impossible stakeholders who don’t fully understand their own business plan. One thing is for sure, if you want to achieve success, you better get your requirements clearly defined and be ready to explain them when needed!