The past ten years has seen an explosion in Agile product development methods, which are now the norm for innovation and technology development. In this article, we discuss how these techniques can also work well for operational development – in this case, deploying a new radio network.
Traditional processes call for exhaustive requirements, a well-documented schedule and strict adherence to process. In contrast, the agile approach recognizes that in a rapidly-evolving technical space, not all requirements will be captured, very few problems can be forecast and schedules change rapidly due to setbacks and successes – either of which may be unforeseen.
Agile methodology acknowledges project unknowns and values the learning outcomes from the process, as much as the deliverable itself. It recognizes that learning by doing, learning by failing and most importantly learning before fully committing resources, leads to better results than the traditional dogmatic adherence to process and the Gantt chart.
Agencies and organizations looking to upgrade mission-critical systems are acutely aware of the pitfalls and risks that a system migration brings. The costs involved in a technology refresh are significant, and typically occur infrequently as once a decade, so the organizational learning from previous migrations will likely have dispersed. Adopting an agile approach can go a long way to mitigate this situation, by improving stakeholder engagement, learning first and refining the solution prior to fully committing resources.
A traditional system upgrade process would see the documentation of a comprehensive specification based on stakeholder input and then an invitation to the market for a turnkey solution. The agile approach divides process into smaller steps, learning as you go, thereby reducing risk and staying closely linked with stakeholder expectations, while also being flexible enough to change requirements and scope as the needs arise. I have seen this approach successful implemented as a technology evaluation period, followed by collaborative, high level design and pilot project.
The customer purchased trial equipment and then ran an in-house trial. They learned the new technology and evaluated a number of solutions without pre-sales pressure from the vendors, but were able to call upon their expertise as required. Once they identified their preferred technical solution, they invited the vendor to commit to a pilot.
A pilot project is an exceptionally useful deployment methodology. It allows the vendor to prove their technology, design, deployment and support services while the customer continues to learn the technology, engage with their user groups, to refine the requirements before committing to a full-scale migration. This can pay big dividends as customer and vendor learn and grow together, working not to wordy specifications, but experiencing the deliverable and operational outcome. If you are interested Tait offers more information about it’s services on the website.
In the earlier example, the successful pilot allowed the customer to confirm their requirements, validate the specification and proceed with their state-wide deployment, confident that the technology worked, the design was sound and that the users were well served.
What drove this success were the parameters of the pilot itself. The initial scope was limited to a minimal, viable deliverable in the same way a tech start up does. They identified a region of modest size, but with sufficient technical, topographical and operational complexity to simulate conditions in other parts of the state.
Next, they briefed key stakeholders, eliciting significant support both from leadership and the operational users for the practical and phased approach to the migration. This ensured a great outcome for the pilot and the radio team, irrespective of the technical results.
Why a pilot?
- Learn by doing – get the experience first-hand before you commit to a vendor or solution
- Expose risks – develop mitigation strategies
- Apply the lessons learnt – refine the design how to run a successful pilot
- Define your goals and objectives.
- Define the scope, time, stakeholders, topography and technology
- Define the success factors – what does success look like how will it be measured?
- Communicate to stakeholders, project team, operational staff, suppliers and contractors.
- Review against your success factors.
By Richard Fry, Services Sales Specialist. This article is taken from Connection Magazine, Edition 4. Connection is a collection of educational and thought-leading articles focusing on critical communications, wireless and radio technology.
Share your views, comments and suggestions in the Tait Connection Magazine LinkedIn group.