Peer to Peer Magazine

P E E R T O P E E R : I L T A ' S Q U A R T E R L Y M A G A Z I N E | S U M M E R 2 0 1 9 47 upgrade and that you're great at executing those upgrades. If you have influence over any suppliers in this area you should also be insisting that they make migration and upgrade as simple as possible. That creates a win-win; for the suppliers keeping you on the current version reduces the support costs and also increases the likelihood that you'll stay with them. Being current means you get the best quality support and the incremental value of the latest features that have been added to the solution. The next easiest quadrant to understand is the high complexity or high effort and low value quadrant. In principle you shouldn't do any projects that fall into this area. Pretty much the only reason for doing projects that fall into this space is that either they're forced by regulation or they are essential to prevent an easy to predict bad outcome. Projects might feel like they fall into this category if the value is hard to quantify as well. You need to be careful if you don't know the value not to ascribe a low value. The other complexity here is the often these projects can address binary risks. If something never goes wrong, then you might not need the solution that you are implementing in this quadrant but when things do go wrong it could save the organization. This quadrant is useful for weeding out those projects that are an individual's or team's pet projects or seem like a good idea at first blush but ended up being very complex in the end. A good test for projects in this quadrant is the "so what?" test. In relation to the whole project and in relation to the goals that the project is trying to achieve. Asking, "so what?", about the proposed benefits can often lead to a proper discussion on the real core of what is being requested and hopefully, that will lead to the project been canceled or re-imagined and moved to another quadrant. The high complexity high-value quadrant is often a good approximation to the innovation quadrant. Innovation is on everyone's lips at the moment and you need to be doing stuff here. The general rules of innovation apply to projects in the space, namely: You have to be prepared to fail and leads to all change, all projects, facing bigger barriers for approval and more resistance during implementation. So let's consider the four quadrants one at a time. To make this more understandable I'm going to use the example of implementing a series of projects in a law firm. I'm also going to assume that the law firm has an internal IT department that has a reasonable record of success implementing change i.e. it has the access, capability and credibility to discuss priorities with stakeholders across the firm. The low complexity low value quadrant seems pretty simple to quantify but in fact includes many things that can, when done wrong, take a great deal of effort, don't deliver a great deal of value. If you like this is the "plumbing" quadrant. Things like an upgrade to Microsoft Office, Windows or your DMS fall into this quadrant. You could argue that these are complex. Or at least sometimes they are complex. I'd challenge that and say if they are complex then probably that's because you've made mistakes in the past. Maybe by over configuring these environments that work best when installed as near to standard as possible. One of the most important things you can learn from this analysis is that the basic infrastructure must be engineered in a way that makes it easy to upgrade. Microsoft themselves went through that epiphany when they decided to move to a much more frequently updating environment with Windows 10 and Office 365. Somehow you need to get your organization to the same place. And although these tools offer great value in themselves the projects that simply upgrade them don't offer great incremental value so these projects in my view sit resolutely in the low complexity low value quadrant. That doesn't mean you shouldn't do them. Projects in this quadrant tend to be essential even if they aren't very valuable. Of course, since they're not delivering a lot of incremental business value you should minimize the number of projects in this quadrant and also the effort expended. That loops back round to making sure that the basics of your infrastructure are easy to fail fast. You need to start small with realistic objectives and think about the minimum viable solution or the minimum viable product, keeping it simple. You need honest and open review and critique of what's going on and be prepared to change direction. You need to avoid those rabbit holes and don't go down them. Looking at your list of initiatives in this area the key things to think about are; are they too many are there too few and are any of them too big. Asking those questions will let you right size list here but you do need a list. You have to have a way of killing things and a fast-start way of launching things. The final quadrant is the low complexity high value quadrant. You might ask if these are the projects we should all be doing all the time. It seems pretty obvious, doesn't it? You do need to do plumbing projects, you do need to do innovation, and external factors can cause you to do projects that are complex but low value. In fact, in many organizations that I work with the shortest list is in the low complexity high-value quadrant. Many many organizations get sucked into doing long carefully planned and managed plumbing type projects that don't deliver huge value. With the current legal innovation landscape many organizations are devoting more effort to high complexity high-value projects to try and get a competitive advantage and, as a consequence, over-extending there. Worries about security, data protection, and data privacy have driven a lot of firms to spend more time than the ideal in the high complexity low value quadrant. So in fact, the most obvious quadrant to prioritize, the low complexity high-value one, is the one that often gets neglected. Projects that would benefit most, or all, of the firm are the things that are put off for the future, and the future never comes. I'd argue very strongly that neglecting this quadrant for whatever reason is something that can really damage the reputation of technolo within your organization. These are the projects that pass the WIIFM test for users and show them that change isn't just about more controls or a different way of doing the same thing. An interminable series of projects that deliver

• Cover