Why is it that some businesses seem to have a Linux infrastructure that just works, with users able to do the tasks they want to be doing without distractions, whereas other businesses always seem to have just one more niggling issue to sort out before ‘everything will be fine’?
The difference is often that the former have taken the time to define their requirements, whereas the latter are sure they know what they are doing but haven’t thought it through, let alone written it down.
Define what you are trying to achieve
Businesses that don’t have defined, written Requirements Documents find that they spend too much time bending their Linux infrastructure to meet their (undefined) needs: systems are unreliable and are used inefficiently; storage space is not available where it is needed; too many people are involved in day-to-day IT drudge work; unexpected expenses occur too often.
By contrast, businesses that do have defined, written Requirements Documents make good use of their IT resources, and, on the whole, IT becomes a ‘solved problem’ for them, meeting the evolving needs of the business and freeing staff to do the work they want to be doing.
Why you need a Requirements Document
The Requirements Document serves a number of purposes:
- It clarifies thought. Just thinking through the points will lead to a more refined, more appropriate infrastructure.
- It gives consistency. By defining all the requirements at the outset, you can ensure that they do not conflict with one another. Far easier to resolve such conflicts before implementation.
- It becomes a checklist. Once your Linux infrastructure is up and running, reviewing the requirements will show whether you really do have everything in place.
- It allows your infrastructure to evolve. Over time, requirements change. Identifying the change within your Requirements Document makes it easier to determine what needs to change within the infrastructure.
- It brings consensus. Agreeing requirements means that everyone involved, both within the business and externally, is aiming for the same result.
What, not how
A key aspect of a successful Requirements Document is that it must focus on what must be achieved and completely ignore how it may be achieved. One common mistake is muddying the waters with implementation details. It’s all too easy to couch the requirements such that they lead towards a (possibly unconsciously chosen) specific solution.
We’ll help you
We will work with you to define your requirements. We’ll help you define the end result you trying to achieve. We’ll also help you define what ‘great’ looks like. We’ll walk you through the critical questions that you need to answer before you starting building the solution.
Want to know more? Get in touch.