Differentiate between the general concepts of a risk, a requirement, a constraint, and an assumption.
A project vision will generally consists of an idea or multiple ideas that make up a project. As well a the idea(s), the vision will layout a scope, requirements, constraints, assumptions and risks.
The scope is a statement that details what is included in, and what is not included in a project. This will aid the project team in setting a clear defined goal which all parties are able to understand and adhere to. This also helps eliminate any stray tasks to be consumed as part of the project. For example, you may be virtualising a Microsoft Exchange workload running Exchange Server 2003, however upgrading the Exchange Server to Exchange 2010 at time of migration is out of scope.
The scope will also set out different phases of the project. For example, you wouldn’t (or at least I hope you wouldn’t) expect to have a target of virtualising 100% of workloads in one go. The scope is likely to specify groups of workloads, simple candidates or workloads of high priority.
A requirement is a need that the design must meet or a goal that the project must achieve. A requirement can be of business or technical focus. The requirements should be listed and referenced in the design documentation.
Examples of requirements include:
- Must be SOX compliant
- Must meet SLA of 99.9% uptime
A requirement will affect a design choice substantially.
A constraint is something that plays the part of a restriction or limitation. It could well limit a design choice. Much like a requirement, a constraint can be of business or technical focus.
Examples of constraints include:
- Existing vendor relationships will continue, therefore Cisco UCS will provide compute resource
- Workloads cannot experience downtime outside of any agreed maintenance windows
- All workloads must remain under full vendor support
The constraints should be listed and referenced in the design documentation.
An assumption is something that will be true to the project design, but is something that has not been fully tested nor verified.
Examples of assumptions include:
- There will be sufficient bandwidth between primary DC and DR DC for replication to take place
- There will be enough power and cooling in the primary DC to house the new kit
- Business stakeholders will provide certain application before a given date
The assumptions should be listed and referenced in the design documentation.
A risk is something that could hinder or prevent completion of the project, or perhaps could adversely effect the design. Risks are common place in every project and should be identified early to eliminate any aspect of surprise.
Examples of risks include:
- The software and technology being used is cutting edge, has it been done before and to this scale
- Existing hardware is unstable and unsupported
- The project has a set completion date
The risks should be listed and referenced in the design documentation.
Given a statement, determine whether it is a risk, requirement, a constraint, or an assumption
I think I’ve covered off this deliverable in the above,refer back to ensure ability to understand the differences.
Analyse impact of VMware best practises to identified risks, constraints, and assumptions
I’m not a huge fan of the term ‘best practise’. I would always suggest referencing vendor documentation and guidelines however always use these as just that, guidelines. They should never be used as set rules.
Using vendor guides can help a design avoid known ‘constrains’ which will help eliminate ‘risk’.