Last week the “Password Guru” Bill Burr admitted that he had “got it completely wrong” in his 2003 Password Bible. Our CEO, Greg Collins, was quick to remind everyone that his views on the issue had been clear from the outset.
Is it smug to say ‘I told you so’? https://t.co/ot8uumhpfK
— Greg Collins (@JPReisCEO) August 9, 2017
Bill was the man who asked us to mix cases and symbols to produce secure passwords, or should that be P@55w0rD5? We were also asked to change them every 90 days to something we hadn’t used before. With imaginations stretched and inboxes full, the world’s corporate workers were consistent in bypassing the system’s intentions by making the smallest iterative changes; ManUnited1!, ManUnited2! etc. The result was years of irritation being endured to generate passwords that were barely more secure than what had gone before. This is an example of a business process that causes disruption even when the underlying technology is working just fine.
Avoiding Disruption on the Trading Floor
I do most of my technology transformation work on financial trading floors where disruption is not tolerated. It’s pretty much the ultimate time is money environment. Translate that old saying into business speak and we’re talking about opportunity cost; how much would it cost us in lost time to do this? In my experience, the adoption of new technologies can be held up for years by businesses that are avoiding disruption. However, those same companies can be blindsided by broken processes that provide limited benefit. Let’s have a look at both sides.
You may have read in some of Greg’s blogs about how financial IT managers are usually quick to grasp the benefits of new technology but are reluctant to invest if they fear a disruptive implementation or slow user acceptance. If the new technology will take longer than the accounting period to pay for itself then it often goes unselected.
Sometimes that’s a justified decision. Back in 2012, JP Reis Principal Consultant Marc Henson talked about the unacceptable call delays associated with first generation mobile voice recording solutions. In other cases, it’s less certain. Trading floors were some of the last places to adopt VoIP, SIP and Unified Communications. Good consultancy and project management could have seen these technologies implemented much earlier with minimal disruption. The benefits are undisputed.
What every bank and large organisation remains most susceptible to is not disruption from technology itself but from flawed processes and policies. This could include ill-conceived implementation plans or the more pervasive password example that we started with. As technology transformation experts, JP Reis regularly design processes and contribute to well-managed projects. Unfortunately, we also arrive sometimes to discover unplanned projects or processes with no chance of success. Even at the best firms, policies and processes can cause unintended disruption. Here are some of the key signs of a process that is doomed to failure.
Eight Signs that a Process Will Fail
- The process, or project plan, has not been properly defined;
- The process, or important parts of it, have no ownership;
- The process is not understood and people don’t know what to do;
- Performance of the process is not measured;
- The process is not being enforced;
- The process, like the password example, is badly thought out, laborious and has unintended consequences. This can be particularly acute when one division imposes a process on others;
- The process is wasteful. It may not fail directly but its benefits are limited by inefficiency and someone will eventually shut it down;
- The process is not linked to strategy or seems irrelevant to those who have to follow it.
Designing an Effective Process
As a consultant, my aim at all times is to achieve uninterrupted, high-performance service both for users and for anybody who may be affected by the change programme. I work back from required outcomes to design project plans, processes and policies that achieve the objectives. Key stake-holders on JP Reis projects sign a document that we call the Project Charter. This establishes what is going to happen when, who is responsible for each task and how success will be measured. We explain why any given action is important. People do not sign until they understand the implications. Where necessary, managers from different business units e.g. Legal, Compliance, Trading or HR, may be involved in this step. When we implement a new technology, we make sure it works (Functional Acceptance Testing) and that users know how to work with it (User Acceptance Testing). We provide administrators with a Run Book of how to manage the system or process day to day and in a series of defined scenarios.
This is one way to do it, over many years this thorough approach has proved to be an effective way of working. As a result, my radar is always on, looking for broken processes. I intervene where I can because I know that a flawed process, more than most of the people and technologies I’ve worked with, poses the biggest threat of disruption.