1. Design
Before asking anyone for a quote, you need to know what is going to be built. We prepare a high-level proposal —what is done, why, what alternatives there are and what each one involves— and, once the path is chosen, the low-level proposal with the technical detail: equipment, versions, addressing, integrations and downtime windows. It is the document the work is then carried out from, and against which the delivery is checked.
High-level proposal · Low-level proposal
2. Pilot and proof of concept
When the risk justifies it, we first build a mock-up: a pilot with the real equipment on a limited part of the installation. It is used to check that what the manufacturer promises holds true in your specific environment, which is where surprises usually appear. If the proof of concept fails, it has failed somewhere where nothing happens.
Pilot installation · Proof of concept
3. Implementation
The go-live, in the agreed window and with the rollback plan written before starting. It includes the basic configuration of the equipment and the advanced one —high availability, policies, integration with what is already there— and, when needed, customising the applications so they fit the new platform.
Basic configuration · Advanced configuration · Application customisation
4. Testing and acceptance
A test plan written before implementation, not improvised afterwards. Each item is carried out in front of whoever is responsible and signed off. Until it is signed, the project has not been delivered. This is what avoids the "I thought that was included too" conversation.
Test plan · Acceptance test
5. Documentation
We hand over the real map of what has been built: diagrams, addressing, properly managed credentials, operating and recovery procedures. Written so that someone who was not on the project can understand it, because two years from now that person will be the one reading it.
Installation mapping · Handover documentation
6. Post-launch support
For the first few weeks we stay on top of the system: we monitor, adjust whatever is needed and answer the questions of the team that is going to live with it. It is the part almost nobody includes and the one that prevents the most problems, because the faults of a new deployment do not show up on day one, they show up at the first month-end close.
Babysitting after go-live