Another enhancement will be a feature called aliasing. “It gives the radio user the ability to log on to a new role”, he explains. “Once you do that, you get a subset of TETRA features relevant to that role. It could give you different speech items, it could give you the ability to pre-empt other users when PTT-ing, it could allow or disallow private calls.” But he adds: “There’s of course lots and lots and lots of different, other features. Some still haven’t been decided if we will use, if we won’t use. We don’t jump on every feature!” But the continuing succession of changes has necessitated a closer relationship with APD, which had originally been simply another subcontractor. “We would do upgrades or buy new features through a contractor that was then talking to APD, who then were talking back to that contractor, which was talking to our management, and finally it ended up in my lap”, Janis says. “So the whole process needed to be shortened.... We needed more direct communication and more agile way of developing things. We have changed that for the last three years now. “We’ve been working directly with APD and I would say we work very agile, which is quite popular these days. We work with nightly builds, we work with beta. “When I started the project, we had two drops a year of software – so basically we wrote our requirements specification, we sent it into this third party, which it then translated it from Swedish to English and sent it to a PDF. And we waited six months – and then we got a piece of software that we tested, and we realized that this was not exactly what we ordered. That’s been changed. Now we work directly: we have day-to-day contact with APD and it works very, very well.” In this way, any new piece of software code can be tested at once on the experimental TETRA network to find whether or not it works. And if something needs further work, the engineers can simply send the log back to APD. “I personally am allergic to these ‘big bang’ releases, where you order something and then you hope that it will be what you ordered”, Janis says. “It’s a lot easier if you see every day the progress of the project.” And he adds: “We’ve had a lot of benefits from the fact that we actually have our own test system. We’ve been able to first of all learn a lot about TETRA. We don’t have to rely on marketing from Cassidian or MSB or anyone else. We can actually test it ourselves and see how it works; we can tweak every single aspect of that infrastructure. So if someone tries to sell you a feature, you can test it.” Updating managementRPS’s other special ingredient is its ‘governance’ strategy, in the care of governance manager Johan Ferngren. “I call it governance because it is about managing all services and maintenance and taking the management perspective of the system owner and the organization”, he says. “Instead of being reactive, I think we are proactive and demanding decisions, pushing future investments we need to do, taking a closer look from the demand side – and taking that very seriously – and actually transferring that into executive summaries for the head of the police to make decisions.” This approach, he believes, has made a real difference to the success of the project. “First of all, we have got very much closer to the top management. We have got airtime! “It’s a learning process to make them aware of what is expected of them, what the system is, what it does, how critical it is, the measures we need to take to keep it up and to be operational on a minute- and seconds-based baseline, so to speak. And I’ve also changed a few ways of the internal decision structure because of this. We’ve also managed to get an official label on this, that this is mission-critical for us. And being mission-critical, we get other kinds of priorities when it comes to decisions or getting resources. “But the most important thing of all is a balanced communication on a business level, so we match expectations to what we deliver.” Keeping a team togetherI think one of the successes in this has been that we’ve transformed the project group into becoming the maintenance and governance group, instead of doing it the normal way, where the project ends and all the resources and knowledge walk out to another project somewhere”, says Johan Ferngren. “When we put up the maintenance and governance structure around this, I insisted on keeping the team together. “We also took a glimpse at the future, the updates and upgrades and other kinds of challenges we were facing, so it was more natural to keep the team together – and that was a bit of a struggle, to get the organization to understand the reasons why.
|