While you may have a formalized processes and sets of documentation requirements for your software projects (this can be helpful or hurtful), you might be starting with no process or set way of specifying requirements. Starting from scratch every time can be very counter-productive.
Given that this is a common challenge, I thought I’d share a bit on the way I approach project situations with little to no processes in place or templates to use.
- First, I get my head around the scope of the project and the need for documentation. Documentation should fill a need. The more I know about how my documentation will be used, the better I will be able to provide the right documentation.
- I evaluate what stage the project is in. Is there a budget in place and a development team ready to start? Is there a need to evaluate off-the-shelf solutions? Do we need to start with a scope document to support a go/no-go decision on project funding? I make sure whatever my first deliverable is helps drive the next project decision forward.
- I often hunt around in my archives of past work for something I’ve done to fill a similar need. After a few years, I’ve got a repository of everything from a 100-page requirements monster to a 1-page epic to a data feed specification to a user interface specification to a 10 page project scope document. I’ve also started building a repository of templates to use with my favorite sections, questions, and gotchas. (If you don’t have the advantage of an archive of past work, you might be interested in my Business Analyst Template Toolkit where I’ve annotated my most useful templates so you don’t have to start from scratch.)
- If I’m approached with a new situation, I do a few internet searches to see if there are any suggested practices out there. I also pull out my favorite books for ideas. I might reach out to a few colleagues or contacts for help. As a side note, asking for help with requirements challenges is a great way to stay in touch with your professional network.
- I create a preliminary plan of what deliverables will best serve the project. Sometimes this is a full-fledged requirements management plan. Other times it is simply a plan to get to the next decision.
- Finally, I discuss some options with the project leadership and document consumers. I seek out their input on what would help them take the next step.
I’m probably a bit unique in that I never fully trust a template, which is why it took me so long to annotate mine and finally make them available. A template is a good starting point, but you also need to apply your own independent thinking and seek input from your stakeholders about what works for them. Every project is a little bit different and needs some special TLC.
Don’t Start From Scratch
Check out the Business Analyst Template Toolkit – my repository of editable and annotated templates you can use so you don’t have to start from scratch on your next business analyst project.
Click the link below to learn more:
https://www.bridging-the-gap.com/business-analyst-template-toolkit/
