Editorial note
Carefully framed- Some examples are deliberately abstracted to keep the judgement useful without exposing private systems, people, weaknesses or operational detail.
- Live procurement activity, budgets, suppliers, contracts and commercial decisions.
- Environment-specific designs, dependencies, lifecycle gaps or asset details.
- Internal acceptance records, support arrangements or retirement plans.
Procurement is usually where an infrastructure project becomes visible, not where it begins.
By the time quotations are being compared and products are being selected, some of the most important decisions should already have been made.
What service is required? What problem is being solved? What does success look like? What constraints will affect the design?
A request for better wireless, for example, might actually be about coverage, capacity, roaming, reliability, security or visibility. A request for new AV might be driven by intelligibility, easier operation, remote participation or greater flexibility.
The product comes later.
Infrastructure projects become stronger when the requirement is understood before the solution is chosen.
Understand constraints early
Infrastructure rarely exists in isolation.
Buildings impose constraints.
Existing cabling matters.
Power matters.
Cooling matters.
Licensing matters.
Support capability matters.
Network dependencies matter.
Identity integration matters.
Security requirements matter.
Existing contracts matter.
User behaviour matters.
Finding these constraints after equipment has been ordered is expensive.
Finding them during requirements gathering creates design decisions.
That is why infrastructure management needs to be involved early.
Design for operation, not just installation
Projects naturally focus on achieving go-live.
Can the system be installed?
Can it be configured?
Can it work on the planned date?
Those questions are necessary but incomplete.
The system may remain in operation for five, seven or ten years.
The design should therefore establish how the service will be monitored and administered, where documentation and configuration backups will live, who owns updates and support, how failed components will be handled and what skills the organisation needs to retain internally.
A system that is easy to install but difficult to operate is not a successful infrastructure design. It has simply delayed the problem.
Procurement should reflect lifecycle cost
Purchase price is also only one part of cost.
A cheaper platform may require more engineering time.
Licensing may increase later.
Replacement parts may be difficult to obtain.
The organisation may need specialist training.
Support may depend entirely on a supplier.
Power consumption may be higher.
The hardware may have a shorter useful life.
Lifecycle cost therefore matters more than initial cost.
The best-value solution is not always the lowest-priced quotation.
It is the solution that provides the required service at an acceptable cost and risk over its expected life.
Acceptance should be explicit
Installation does not automatically mean acceptance.
The organisation should know what successful delivery looks like.
That could include:
coverage targets
performance testing
configuration backups
monitoring integration
security review
documentation
asset information
administrator training
support details
user validation.
Without acceptance criteria, projects can finish while unresolved issues quietly transfer into operational support.
Those issues then become somebody else’s problem.
Clear acceptance creates a boundary between installation and service ownership.
Operation is part of the project
The infrastructure lifecycle continues after go-live.
Monitoring begins to reveal normal behaviour.
Incidents expose weaknesses.
User demand changes.
Software updates arrive.
Security requirements evolve.
Capacity increases.
Documentation needs revision.
These operational lessons should influence future design.
That creates a feedback loop.
Requirements inform design.
Design informs deployment.
Deployment informs operation.
Operation informs the next generation of requirements.
Organisations become better at infrastructure when that loop is allowed to work.
Retirement is also part of ownership
The lifecycle does not end when something becomes old.
Retirement needs the same discipline. Dependencies need to be understood, data handled appropriately, identities and DNS records removed where necessary, monitoring retired, licences cancelled and equipment disposed of securely. Useful documentation may need to remain even after the live service has disappeared.
Legacy infrastructure often survives because nobody fully understands the consequences of turning it off.
Good lifecycle management reduces that uncertainty.
Procurement is the middle, not the beginning
Infrastructure therefore has a much larger lifecycle than a purchase order suggests.
Requirement.
Design.
Risk.
Procurement.
Implementation.
Acceptance.
Operation.
Maintenance.
Improvement.
Replacement.
Retirement.
Each stage affects the others.
The organisations that manage infrastructure well understand this before the first quotation arrives.
By the time equipment is purchased, the most important question should already have been answered.
Not what are we buying?
But what service are we committing to operate?
Contents
About the publication
I turn complex infrastructure and cybersecurity responsibility into resilient services, controlled change and evidence leaders can trust.