Assumptions and constraints

Assumptions

Never assume, because you make an ass out of u and me.

An assumption is a fact that has been implied from the known information. This is either a result of a definitive answer not being known, or because the question hasn’t ever been asked.

For instance, it may be appropriate to assume that a system should log users out after half an hour of inactivity, even if this hasn’t been stated as an explicit requirement.

Usually, assumptions are far more tenuous; for example, what if you were told data needs to be reported but you have no further information? You might create a spreadsheet, which fulfils the requirement, but the client wanted a graphical representation.

There will always be assumptions – sometimes even very specific requirements can be open to interpretation.

The goal in project management is to identify these as early as possible, and then include them in the Risk Analysis. All assumptions are treated as low-level risks. This is important because once something is included on the risk assessment, it forces the project manager to think about how the risk will be mitigated, and ensures it will be monitored more closely.

Constraints

Constraints are restrictions on what you are able to do. You should always look for issues that fit into the following categories when completing a project initiation (by reading the project brief):

• Deadlines and time available – a deadline is when the project should be completed, and is a definite restriction in your ability to create a system. Time available is also a constraint: if you have four weeks to complete a project, the time available is likely to be around 140 hours. You may be able to increase this through the use of overtime or weekend-working, but it is still a restriction.
• Funds for the project (and contengency) – if you have been allocated a budget of £25000, then it’s no good designing a solution that will cost £50000. The budget restricts what you can achieve, and what you can spend. A contingency is a sum set aside in case it is required for unforeseen purposes later on: things like price increases from suppliers, unforeseen issues (maybe a member of staff is sick and you need to hire a contractor)
• Availability of staff when required – as mentioned in the Stakeholders page, it is likely that the company will be undertaking more than one project concurrently. This has implications for the availability of staffing, and this is a constraint common to all projects.
• Availability of equipment when required – as above, plus in the event that equipment needs to be hired or purchased, the availability of the equipment for hire or purchase is also a constraint.
• Technical expertise in the project team – it is fair to say that different people have different levels of skill and competence in their work. For instance, it is clearly possible to design a portable computation device with a screen and built-in input and output devices (smartphone). However, it would be unrealistic for most companies to undertake a project like this due to a lack of expertise.
• Limitations of technology – sometimes, we can have ideas and come up with designs that just aren’t possible due to the limitations of technology. A tiny camera sensor with insane resolution? We can imagine it, but technology doesn’t allow for it – the sensor cells become too small to reliably capture light. Battery life could be another common limitation