The benefits of a radio management system

A radio management system can maximise cost-benefit over both the short and the long term.

Implementing a radio management system (RMS) typically follows a common process. First, stakeholders develop objectives, needs and constraints into a scope. Then, the specific needs and requirements are developed from that scope, deliverables are designed or sourced to meet requirements, and project-, change- and risk-management controls are applied.

While this is a sound approach, it relies on the scope and requirements to be fixed at some stage. An RMS typically represents a substantial and long-term commitment. As an organisation’s primary concern is the effective and efficient exchange of information, radiocommunications more and more need to evolve with technology, business and operations. Whether that is via IP networks, phone or mobile, or two-way radio depends simply on which method is best suited. Thus, many requirements an RMS needs to meet go beyond readily identifiable needs and objectives. That is sensible, as no organisation will want to risk investing in an RMS that cannot support its operational or business objectives in the future.

Figure 1. Cost-benefit in system implementation.

Substantial effort is afforded to projecting which future capabilities need to be considered now, even though it is often not clear when, or even if, they will actually be required. A common practice is to ‘work backwards’ from these projected needs to determine the relevant requirements today.

Yet this can be particularly difficult in view of major changes in technology; for example, new or developing radio technologies and standards, or the advance of IP-based communications and ‘smart’ mobile devices.

It can be costly, and even risky, to attempt to address these diverse needs, both current and future, within a single specification. Is it better to settle on one radio standard? Or will that create constraints? Should future needs be addressed now, and at what cost? What is the risk of not doing so? What are the returns, and when will they be realised? What can change in operations and business that may impact on radiocommunications and systems?

Needs and benefits

To resolve this dilemma requires accepting that change and uncertainty are not necessarily negative — they can be addressed in better ways than simply avoiding them. It also requires revisiting the basic purpose of an RMS. If this seems obvious, consider applying the following questions to the scope and design of an RMS:

• What is the measurable benefit from a required capability, and when is that benefit realised?
• What does it cost to implement that requirement now?
• What risks and costs may arise from not meeting the requirement now?
• Is there a risk that making that decision today creates constraints on future opportunities?
• What else may change between now and when benefits are supposed to be realised?

Of course, the answers to these questions depend on just how certain or uncertain the variables are. The approach therefore should be to revisit purpose and key objectives, and break these down into functional needs and requirements according to their predictability and the relevant time frame (see Figure 2).

Figure 2. Needs, cost-benefit and risk.

Certain needs are those where the solution can be clearly defined, and where a measurable benefit or return can be quantified, and can be delivered within a specified time frame.

Uncertain needs typically fall into three categories:

• Perceived needs are typically short to mid term and may be reasonably predicted from past experience or other knowledge, but the benefit is uncertain.
• Perceived opportunities indicate a future benefit, typically short to mid term, but this benefit cannot be quantified in the present, and when it will be realised is uncertain.
• Uncertain needs and opportunities are perceived needs and opportunities that cannot be reasonably defined in time, likelihood or benefit, but which may pose a risk if not addressed.

Some basic examples of certain and uncertain needs include a need to connect operators with more than one radio (current, with a clear cost-benefit), the need to be able to add more radios to a console at a future stage (perceived need, with a predictable cost-benefit), an opportunity to interconnect analog HF radios to digital trunked radios (perceived opportunity, with a predictable cost-benefit), and an opportunity to allow all terminals to interconnect with each other (uncertain as availability and cost-benefit cannot be predicted, but risky if not considered as it pertains to a widely implemented standard).

Figure 3 shows a typical evolution cycle. Here, the main approach to dealing with uncertain needs and opportunities is to define requirements today that should ensure, as best as possible, that future needs and opportunities can be met. The disadvantage in this approach is for one that it is very ‘specification heavy’, and secondly, it is costly and complicated as it needs to address a whole range of possible permutations.

Figure 3. The typical ‘evolution’ cycle.

For example, a lot of attention has been focused on ‘interoperability’ at a standards level. One can argue that this is more interconnectivity than interoperability — after all, what determines operability is specific to the organisation and its needs. One can also argue that standards should not try to be all-encompassing, and certainly not create unnecessary constraints on organisations using the technology. Instead, they can provide a foundation to move from a predominantly technological view to an operational one. The internet and mobile telephone are two excellent examples.

Indeed, an organisation’s primary concern is not how radiocommunications ‘work’, nor the features they provide. An organisation’s key concern is how effectively and efficiently ‘radio’ works within its specific context — and this cannot be standardised. It is a very basic premise that investments in radio capabilities only deliver a return when and where they are put to productive use. What is productive is not determined by the technology or solution used, but by the purpose and the context within which it is used.

So, if standards and ‘forward requirements specification’ are not the answer, what is?

Allowing for ‘evolution’

An RMS is a key interface between the radio network and the communication of information within, and often beyond, the organisation. As such, any RMS needs to consolidate the capabilities of the radio network for it to work effectively and efficiently. As described previously, issues arise when the focus is predominantly on technology and functionality. Instead, organisations may first focus on determining what they really need, and when — and indeed, what — they don’t need.

An RMS is a substantial investment of resources and time, and at some stage the design of the RMS needs to be agreed on. But what if that didn’t need to be the case for every capability? What if all the future needs and opportunities didn’t have to be addressed through detailed specifications in advance? What if capabilities could be added when the need arises, and real, measurable benefits can be had?

To achieve this requires flexibility in scope and requirements. It also requires confidence in the ability to meet future needs. In fact, radio networks have always evolved, typically built up over time using a range of assets of different types and technology. And that makes perfect sense. Just as the organisation’s needs for radiocommunications evolve, so does the radio network.

Organisations seek to maximise return on invested capital, return on assets and usable lifetime of assets and infrastructure, while managing expenditure and costs. Thus planning and investing in ‘radio’ involves making trade-offs between functionality, cost and time frames. Sometimes it may make technological, but not financial, sense to replace an asset. What makes these trade-offs possible is the knowledge that an organisation can source the capabilities it needs when it needs them.

Why not apply the same rationale to radio management systems?

Figure 4 shows how such an approach can work to deliver excellent fit and cost efficiencies. Allowing for additions from within the RMS, rather than prescriptive requirements specification, allows an RMS to evolve… just as the radio network described earlier. Such an ‘evolve-able’ system does not need to specify all possible permutations — instead it matches predictable needs and opportunities to a repository of capabilities. This is done once during the initial system concept.

Figure 4. Building an ‘evolve-able’ RMS.

Organisations can address needs and opportunities by adding the relevant capabilities, when and where it makes sense. Since these capabilities are held in the repository, organisations can add capabilities in increments that fit their schedule and budget. For example, adding a single HF radio, a group of DMR, TETRA or P25 radios, or all together. Other capabilities can also be added, such as VoIP phone lines, voice recording and location mapping.

Organisations can do this without having to repeat the specification and design process; it can all be done within the design of the RMS itself. What remains are the truly uncertain and unquantifiable needs and opportunities, which in any case are best managed using suitable risk and change management processes.