Simon Long (@SimonLong_) wrote a post here detailing the problem with assuming certain things. I see where he is coming from and I agree with his point. However, I also think there needs to be further clarification as to how to deal with assumptions. Most of the times I see assumptions being put in to ensure that the client provides certain basic infrastructure services, such as AD, DNS, NTP etc. These should ideally be called Pre-Requisites, since they are critical for any VMware or non VMware Production environment to operate effectively. Don’t call them assumptions. Assumptions are used when you have little or no control over certain aspects of a project or with an application you are dealing with.
But when you are making these assumptions ensure that there is a requirement given by you as the lead architect to the customer on what you want. Like Simon said, ensure that you do the math right to get the number of DHCP leases required and put the exact number as an example. You can also find some more examples below with an explanation on why I would come to that assumption.
Examples of Assumptions:
- The write workload of the content batch loading process will be staggered across the day and therefore will not consume excessive bandwidth or impact other workloads.
- If manual reconfiguration of the IP Addresses is required, this will be done by XXX and will not be the responsibility of yyy or zzz. (You don’t have control over the end state environment due to ITIL policies etc)
- Different Layer 3 IP addressing for Web Tier VMs has been tested and validated by XXX. VLANs representing both networks will be assigned to the VMs. But only one nic will be connected. The script for re-configuration (re-connecting the nics) on the VMs will be the responsibility of XXX. Again ITIL policies and ongoing maintenance 🙂
- Since there are multiple instances of an application VM (VM serving an application function), loss of one particular VM is not considered loss of an application. Dealing with Performance and availability from a RTO point of view.
- There is sufficient bandwidth on FC links to sustain peak bandwidth requirements of VPLEX workload. For this project there is a requirement for 2 x 128 Mbps dedicated links including one for failover. (You should provide the details on how much bandwidth your project requires. Don’t Guesstimate, you need to run proper workload analysis to get the details.)
As per the examples above, there is certain level of uncertainty on mainly whose responsibility it is to ensure certain things happen. When its not in the scope of the project for you to do it and you don’t know who else is responsible for it, you assume that someone outside the project is responsible for it and ensure that the project manager knows it.
Examples of Pre-requisites (also can be used in Assumptions):
- Application level communication will be configured to minimise the cross site IP traffic.
- AD, DNS, NTP and other infrastructure services are already available. (Ensure that there are test cases to perform tests on these).
So categorise each of your assumptions as follows
- Things you have no control over. All of these are also risks and should be documented as such.
- Things you can exert some control over or know whom to speak to about. These can be a mixture of constraint (dependent on external entity) or risk (you have some control over it but not complete control)
- Process Driven Things (ITIL policies might have some really weird things which you need to assume will work). Call these out as constraints.
- Certain requirements that don’t quite make sense (for example, not having an application run active-active across 2 sites even though it can). This also becomes a risk as well as a constraint.
This is not the only way in which you should deal with Assumptions, Risks and Constraints. This is the way that worked for me. During my first defence I didn’t have a lot of risks knowing that most of my assumptions and constraints were posing a risk. Documenting them not only made sure I explicitly stated how each of them affected one another, it also enables you to paint a picture of your “perfect solution” if you didn’t have these constraints/assumptions/risks. Always think of the alternatives when dealing with assumptions, risks and constraints, how would your end design change if your assumption was incorrect or worse became a major risk if you didn’t call it out as one.
Just my quick 2 cents.