Do it Yourself Guide for Building Templates
When the requirements document templates that you have to use within an organization do not fit the situation, you should consider making a new template. There will be organizational procedures that you will need to follow but it is possible to request new templates for your project needs if you believe it provides a higher-quality deliverable. Senior analysts can recognize such opportunities when they arise and have the skill set to create new formatting for requirements deliverables. Less experienced analysts rarely think of building new templates but what you need to remember is that someone built that template from scratch so it’s not impossible or even a real obstacle. Rather, it could be the next building block to increasing your skills.
When standard procedures and processes, templates or job aides do not give you what you need to be successful, managers expect business analysts to utilize their expertise and create what they need for projects. Three common mistakes that business analysts can easily avoid are:
1) Refraining from using excuses such as “the pre-set templates are all I have to work with.”
2) Assuming you are not empowered to improve processes or expand the tools of your trade.
3) Listening to more experienced peers insist that their template fits every business situation.
You need to first agree that there is not a one-size-fits-all requirements template document. If you don’t believe this is the case then compare a requirements document designed for product development to a requirements document for a services organization responsible for product implementations. What’s different about these two documents? The differences between requirements documents within each organization are found in the intended audience, the document’s purpose and the overall tone or message.
You might have a difficult time finding a requirements document for product development today since many organizations are changing to AGILE methods. The requirements document for product development is an output of a waterfall methodology for software development in which the market and business or detailed requirements were written out mainly for the purposes of developing the software. Sometimes it’s called a business requirements document (BRD) and can be split with another requirements document called a software requirements document (SRD). Focusing on just the SRD, the audience is internal resources, mainly developers and testers. The intent is to provide the detailed system requirements (and sometimes non-functional requirements) for verification testing. These requirements tend to be more feature- or function-driven with details about processing. The message or the purpose of the document is to provide direction for development organization in terms of scope, assumptions, constraints and detailed functional or non-functional requirements.
With software implementations, the requirements document has a completely different purpose. First, the audience is your client. The client reviewers of this document can perform various roles within the client organization, including CEO, executive leadership, Director, Manager, subject matter expert (SME), and project team member. The intent of the requirements document is to provide the recommended implementation approach for how the product can be implemented to meet the needs of the organization. The message or purpose should be to easily and succinctly give executive management a clear picture of how the product matches up with the organizational goals. Therefore, it should include an executive summary. If there are unfulfilled requirements, they need to be clearly spelled out so executives understand the impact to the business and whether or not there are viable workarounds. If there are decisions to be made prior to proceeding, it should be there and if there is additional work requiring new contracting or additional expenses, it must be noted in an executive summary. As a manager of BAs, I insist that a requirements document should not exceed 25 pages in length and should include the detailed requirements in an attachment. All the detailed business requirements and specifics can be attached as references or included in appendixes at the end of the document.
If the above scenarios for product and service requirement documents do not describe your situation, the direction that you have been given by your management team, or resemble the document structure that you use within your organization, don’t be surprised. That is the whole point, as there are so many other variations for requirements documents. The question is: Which document is right for your situation? You can make a determination regarding what you think would improve your templates once you begin to comprehend the reason and purpose behind the document template you’re currently using.
If you are thinking about creating your own template, ask yourself these few basic questions. If you can answer “yes” to all three then you can successfully make a case to build another document template.
- Do I understand the audience, document purpose and message in the current templates?
- Have I formulated the message and done the analysis necessary to write a good requirements document?
- Do I have a unique need that is not fulfilled by the current template?
If you do NOT answer “yes” to the above questions then your business case will not succeed. It will highlight flaws in your own analysis skills and that is something most people prefer not to bring to the attention of their manager. Bringing a case for a new template to management and not being properly prepared could bring to light root causes for why you are struggling to write requirements documents that have nothing to do with the template itself. Common reasons that analysts struggle when using templates are:
- Not realizing what is supposed to be documented.
- Not having the analysis complete.
- Weakness in underlying business writing skills that cause difficulties using a template, including problems with how to express opinions, persuade a reader, influence a decision, etc.
- Lack of advanced Microsoft Word features knowledge such as inserting pictures or objects, inserting hyperlinks, modifying pictures, using and including styles, advanced page break or header/footer notation and section breaks.
If you did answer “yes” to the three questions above then you have to ask yourself if you want to improve the process within your organization. You can do so by following a few simple rules:
- Talk to your manager about your intentions and he/she can connect you with the right resource within your organization.
- Recognize that someone is already in charge of the processes. Check in with that individual and explain your situation.
- Partner with a few peers in order to get your idea realized and your template streamlined by building your business case and explaining your current need.
Do not forget how important including your peers can be to succeeding in new template development. They can give you feedback, improve your template, and support its usefulness and need within the department. If they are aware and were part of its creation, they will be less likely to resist using the document once it’s part of standard operation procedure.
Working towards improving templates and processes by building new tools for team use is a great way to show initiative and creativity. It shows a commitment to quality and an interest in improving processes within your organization. Your leadership skills can be demonstrated by taking the time to work through an idea and navigating organizational processes and politics to see your ideas turned into realized solutions.
Maryanne Miller, CBAP, Business Services Manager for MEDecision, Inc., has over 15 years of business and technical experience in the corporate world of health care IT services. As a professional consultant providing business and technology leadership, her areas of experience include business process improvement, business analysis, and health care IT.
It can be trying to read about what as a business analyst you should have as inputs to begin BA activities when you don’t have those materials but are still actively working. Business analysts who are responsible for product installation and software implementations at client sites do not always receive the necessary information they need as inputs to their processes. In addition, not every organization is supportive about providing input materials to begin business analyst activities. Still, projects kick-off and resources are assigned and business analysts and project teams get to work. What should a BA do when placed in this situation? 
Have you ever started a project without the formal contract? Have you been on a project without fully defined scope? As an analyst who has worked in various organizations and different industries, I can tell you that I have been in both those situations. Is that normal? No. In fact it goes against everything that the PMBOK and BABOK state are required input materials.