The one problem we have in the IT world is documentation. No one seems to like doing it. Unless you specifically pay for a design document and as-built, you are going to get a document that usually has a lot of cut & paste from official vendor documentation.
Some of the design decisions were not captured, the implementation may have been rushed or not scoped properly and this leads to a ‘just make it work’ scenario.
But at what cost? The poor support team? The customer that paid top dollar and didn’t get what they paid for?
I guarantee that when you get a tradesperson in to build you a kitchen or a house, you would be checking every corner, every wall to make sure it is what you paid for. Why does this not occur as much as it should in the IT world? Or maybe upper management believe it is happening, but at the coal face it is not.
For me, this isn’t right.
Until we have a system that will scan the network and automatically build an as built document (once I learn python, I will try!) we are stuck with people retaining information in their heads and not documenting designs.
This seems to occur more in the enterprise space as well, due to external vendors being used and scopes not including such vigorous documentation.
Some believe this slows down the process and the build as technology must move at the speed of business these days. This is all achievable if you just make a few extra steps at the start of the project.
Steps like a clear scope of works, measurable and provable outcomes from each technology and then allow time in the budget and project for these to occur.
So, my philosophy is as follows and really should be common sense and the basics of an operational network. Its based on a document I encountered a few years ago. I have made it high level, for easy reading.
1. Customer provides a clear and concise document outlining what they require.
2. Customer provides a document that highlights each technology, what they expect and the expected performance of this technology.
3. Project team prepares a POC or high level design document, POCs can be dangerous, by the time it works the customer expects it to work the next day and suddenly you have a POC GONE LIVE.
4. Project team stages design, tests design and documents.
5. Customer checks design and documentation.
6. Build begins, with testing documentation. Each section built, tested to specifications and then signed off.
7. Build completed, as built created from design. Highlights any design changes during the deployment. The real world may have introduced these depending on how close your testing environment was.
8. Diagrams and support documentation added to as built.
9. Project completed, and changes going forward to be added to as built and version updated.
This along with the following –
1. Transparency to customer and management
2. Handover session with support
Is a great start in building a new or upgrading an existing network.
It’s not the end of the project that matters or the completion that is the most critical part of ‘getting it done’ it’s the beginning.
This is where all those problems that will be coming can be removed.