When you assume…
Most of us have been told at some point in our lives that we should not assume things because it makes an ass out of u and me. Being a Business Analyst is one profession where making assumptions is actually a good thing. Assumptions help identify factors that you use to plan activities. Assumptions can be considered true, real, or certain without proof or demonstration. The more assumptions that you identify for a project the easier it is to adjust projects timelines, budgets, resources, and functionality if an unforeseen situation occurs. If properly addressed in the assumptions section of a Business Requirements Document or other project deliverables when an unforeseen situation occurs, you will have an approved document that you can use to help you adjust your project needs.
For example: If your project has been planned around one Project Manager, one Business Analyst, three Developers, and two QA testers, and your project is scheduled to release 10 new or updated product functions with a three-month development phase and one-month testing phase then your assumptions can look something like this.
Assumption 1: The project lifecycle will last five months; one month for BA and PM activities, three months for design and development, and one month for testing and verification.
Assumption 2: This project will use one Project Manager, one Business Analyst, three Developers, and two QA testers for the full five months of this project.
Assumption 3: All the documented and approved requirements will be delivered. The stakeholders will not add or modify the functionality of the approved requirements for this project.
Assumption 4: The five-month project timeline is based on a seven-hour workday with each resource dedicated to this project.
Assumption 5: If any of the resources from Assumption 2 are no longer valid for this project then the timelines, budgets, or functionality should be altered to reflect the change in resources.
After your assumptions have been documented and approved, if one developer was moved to another project, the timelines should change to reflect the loss of the resource, or the budget should change to reflect the overtime needed to meet the same timeline or the functionality may be reduced to get the project in on time and on budget. The assumptions are your documented proof that if anything changes so should other aspects of the project.