The case for change: why the intangible benefits are important

Speculating on the potential value of a new way of working, a new service or set of tools can often be tricky. Estimating the potential benefits case for any new initiative, or even gaining support and approval to try something new, can often be an infuriating and troublesome endeavour. But is it possible to build the case for change by simply starting to change?

I’ve written more business cases than I care to count. Every single one of them has been in a different format, with a slight variation on the same sorts of headings and, whilst most of them ended up being approved, the road to getting them there was not always that straight forward. The one thing I learned along the way was that in reality, it didn’t matter that much what content I put in the business case, or how good an idea it was, what mattered most were three things:

  1. How much it cost (and whether the budget was available)
  2. The return on investment (and the speed of that return)
  3. Support from the decision makers

Logic would perhaps dictate that cost, then return, then support would be the logical order of importance in the eventual decision. If you’re a Finance Director, look away now!

My experience is that it is the support of decision makers that matters most. They will care about cost and return, sure, but if you can convince senior stakeholders in your organisation to care passionately about the idea, you’ll find that they will often fight your battles for you and drive the investment case without ever reading a single page.

I can say this from experience, as someone who has written cases for tens of millions of pounds that have gone through acres of red tape approvals (you should have seen the spreadsheets). I’ve also walked into a CEOs office and fifteen minutes later walked out with approval to run long on my headcount and re-purpose an entire (approved) project budget for something completely different. End to end that last one went from idea to execution in less than 24 hours – quite a stressful afternoon for my project manager!

In both extremes I practised one very delicate art. Influencing. I didn’t convince that CEO to change direction by having a pretty PowerPoint with charts and graphs and statistical data proving beyond all doubt that my suggestion was the right one. I did it by convincing them first that I was credible, and then second by seeding all of the emotional attachments to the idea for change. The intangible benefits.

The key to successful leadership today is influencing, not authority. – Ken Blanchard

Influencing people should, in my opinion, be the number one skill that all change management professionals list on the CV. I rarely see it. It is also the number one skill that you need to be an effective sponsor or accountable executive.

So how do you do it? One that comes in handy is something that I learned from my very first job in financial services, as a call centre agent collecting credit card debt. What’s In It For Me (WIIFM)? was a key principle driven home with every new starter at the bank.

It was simple really; it’s easy to work out why the bank wants the customer to repay their credit card debt but what’s in it for the customer? We would approach every conversation assuming that the customer couldn’t pay anything, or wouldn’t want to, and then engineer the conversation to help us understand what the customer was motivated by. Once we understood that, we could place the repayment of the credit card debt in a context that the customer could relate to and, usually, come to some form of arrangement.

Remove yourself from the idea for a moment, put yourself in the key decision makers shoes and ask yourself, why would I want this?. Also ask yourself why they wouldn’t want to support this idea. Find the conflicts of interest and objections and you’re starting to get somewhere.

The answers to these questions are where you start. If you don’t know what’s important to the decision maker, find out, and fast. Speak to people that know them better, read anything they’ve communicated to the organisation recently, find a strategy paper for their area – however you do it doesn’t matter, just get an understanding of what’s going on in their head. Discount any perceptions of what you think should be important to them as this won’t help you. Starting a conversation with hey, you should really be worried about this before addressing what someone is currently worried about is a good way to get yourself spun back out the door (trust me, I know).

Second thing; now that you know what’s important to them, challenge your idea against it. Does it, or can it, solve any of the existing concerns, or does it create something new to worry about? Can you help with any of the other problems as well, and create a shared set of goals? Kick your original idea hard – better you than someone else.

Thirdly, challenge your own credibility in this decision makers mind. Do they know you, or know of you? Why would they listen to you? If you don’t think you have the necessary gravitas with this individual, don’t worry, your options are either to build it by getting more involved and delivering solutions to their existing problems (takes time but has lots of spin off benefits – particularly if being used as a way to understand their current concerns better) or to use others to help you influence them. That may be getting someone else to pitch your idea for, or with, you or it might involve you pitching your idea to someone else who can then introduce you as a knowledgeable and reliable authority.

The larger the scale of change you’re proposing, the greater number of interested parties there will be. The more decision makers, the more times you will need to repeat this process. Whilst that may seem daunting, it’s important to realise that, in reality, this is really a domino effect. Go after the low hanging fruit first; those you know best and have a relationship with, or who will most likely be supportive of your idea. Line them up and then engage them to help you win round the others. Get their advice and support to help you introduce the concept of your idea.

Notice that, at this point, I haven’t mentioned numbers once. So what are the winning arguments if the numbers aren’t the answer? Well, that will depend on your business model but some possible answers are:

  • Better Customer experience
  • Greater brand awareness
  • More Process efficiency (time savings)
  • Higher colleague satisfaction
  • Regulatory or legislative compliance
  • Lower complaint volumes

Some of these can be quantified, either as revenue or cost realisation but most are largely intangible and difficult to pin a number to. They can however be used to bring to life in the minds of your key stakeholders just how important and exciting your grand idea could be.

Finally, there is one more thing you can always put on the table when trying to persuade an organisation to prioritise and fund a significant change. Start small, and prove the concept. Build a prototype, run a small pilot or simulate a customer experience. Make it real and walk people through it. Get real customer, or potential customer, feedback if you can.

And remember that, for the majority of people in business, it’s about winning both hearts and minds. Just don’t forget one in favour of the other.

If, then, else: a foundation for good decision making

One of the things I have often taken for granted has been the ability to read and understand programming code or website script, and more importantly, the effect that has had on my offline thought processes. So am I an outlier, or do people who can code to some level of proficiency think differently and make better or more considered decisions?

I’ve managed, and worked with, lots of different types of people in my career. Most of them were not developers and most of them would have run a country mile if I’d asked them to tell me what a page of HTML script did, or showed them a page of C++ or .net or Java code. That said, many if not all of them have been problem solvers, business analysts, project managers and business function managers who have had to define and explain what they want the technology around them to do differently or start doing. Downside? Most of them have no idea how to talk to developers in a way that clearly expresses what they want the software to do, and not do, under various circumstances.

Most of my career has been spent translating these two worlds. I’m not a developer, far from it, but my understanding of the basic concepts of programming, database development and website creation has allowed me to capture and interpret business requirements and articulate them to developers. I’ve sat alongside non-code-literate colleagues doing the same role and, in my early career, was often baffled by what I saw as an inability to do this translation or, in some cases, even attempt it. It all seemed so logical to me and I struggled to understand why people didn’t think the way I did.

The need to think through a wide range of possible impacts quickly has never been more important.

It wasn’t until much later, when I began to run teams of my own, that I started to understand that the way I thought about problems was different to most other people. Most people, when you talk to them, can articulate what they want the outcome of a change to be. What they don’t do, without help, is think about all of the various permutations and variables on that outcome that need to be catered for. For a developer, that’s a pain. For a business, that’s expensive.

In today’s world, where the decisions we make as senior business leaders are increasingly real-time and the consequences felt within days not years, the need to think through a wide range of possible impacts quickly has never been more important. It’s not enough to simply say, “this is what I want to happen” and expect everyone to know what to do if something else happens instead. Customers are not as predictable as we might want them to be, and neither are our colleagues, and that’s OK. In fact, it’s better than that, it’s amazing. If we only ever got what one person thought of and wanted, we’d stifle innovation and many of our best ideas as a society would never come to fruition.

The problem with Humans is that we tend think in a linear way. And this is where my basic education in programming, combined with the demands of risk management from my project days, has stood me in good stead. Most people think along these lines: “if this happens then I want this to happen.” Simply put, I tend to worry about what won’t happen, or what might happen.

If you can plan for the exceptions, and be clear about the different outcomes in different scenarios, then you stand a much better chance of having a successful outcome

When coaching my team I try to get them to introduce some complexity to their thinking. “If this happens then I want this to happen, else I want that to happen”. Now we’re getting somewhere. But it’s not quite far enough. Gradually as you embed this thinking you can start to introduce more complex logic. For example, “I want this to happen for as long as a certain set of conditions is true, then I want to stop, or for something else to happen”.

Now, for some, this may seem obvious. Others will be baffled and see this as utter nonsense. For a few, probably those who code in one language or another, you’ll see what I’m doing. I’m embedding the basics of things like if statements and do-while loops, these bamboozling concepts that non coders assume is voodoo and terrifying, into the thought process of “normal” human beings. This helps them to translate business outcomes to developers more accurately but, beyond that, it encourages them to think about the exceptions and alternative paths their decisions might lead.

Now, if everyone in the organisation could articulate what they wanted in these terms, I predict that the success rates of projects would go up, purely because the outcomes and exceptions would be better thought through at an early stage. It takes the emotion out of the decision making process and replaces it with pure logic. If you can plan for the exceptions, and be clear about the different outcomes in different scenarios, then you stand a much better chance of having a successful outcome or at least predicting some of the other things that might happen and plan for those.

The best business analysts and project managers I’ve worked with think like this. Some of the strategists I’ve met along the way as well. They take problems and they break them down, consciously or otherwise, into these logic-driven statements and then articulate the various potential outcomes.

Recent movements in Agile methodologies have also helped, heralding the importance of prototyping which, in it’s own way, forces people to consider alternative outcomes they might not have otherwise. Frankly, anything that makes you stop and think, “what else might happen?” can only be a good thing.

For me, I’ll be forever grateful to that early education in foundation-level programming Whilst I never grew up to be a coder, the principles have stayed with me and, I like to think, made me a better business leader and decision maker as a result.

Artificial Intelligence? I’ll stick with the real thing for now

With the ever increasing focus on digital services, not just in the customer outcome, but also in the mechanisms by which we deliver solutions, people are quickly becoming the only true differentiation for companies. Can the quality of our people really influence the project outcome or the customer experience to the extent that technology by itself is no longer important?

This would seem like a backward question to ask for many of us. From years of having words like “automation” and “digitisation” thrown at us (the latter is not even a word) all predictions throughout the 90’s and early 00’s we’re of a future surrounded by robots, automated processes and a very quiet time for Human Resources departments. It hasn’t quite panned out that way yet though and, in my view, it is becoming increasingly less likely.

That’s not to say that companies won’t continue to reduce cost and workforce numbers over time. This sadly is a trend that larger organisations will certainly continue for some time to come. The idea that the future holds a handful of mega-companies that produce everything we need (Microsoft, Walmart, Apple, Google and Amazon for example) seems to me to be less likely though.

The reason for this? Startups. There has never been a more fluid startup market than now. Venture capital and crowdfunding mean that new enterprises are getting off the ground far more quickly and regularly than ever before. With this constant and continuous innovation comes a frantic pace of change that seriously challenges automation of delivery practises. You can only automate something that is repeated. With the exception of certain regression testing routines, and the manufacturing industry as a whole, it is hard to see where you can automate much of what goes on in today’s workplace.

Artificial intelligence on a level of sophistication that we have yet to see would be needed to seriously threaten the human mind. When it comes to the mental agility required to innovate at the pace demanded of today’s workplace, the focus from employers should certainly be on finding the best people, not the best technology. Don’t get me wrong, you need the best technology, or certainly very good technology in order to be competitive in most industries. But the best technology in the hands of average people is worthless, or possibly even counterproductive. Find the best 5 people and give them slightly above average solutions to work with and they will easily out-produce 100 average people with the best tools in the market.

When asked recently by my CEO what I was most proud of I answered very simply. My team. I’ve delivered some brilliant and innovative solutions in the last year alone but, for me, having the best people has made that possible. And so, in this digital age, I will continue to focus the majority of my time and energy on people.

A perfect storm: the dreaded website redesign

Well your website design is a little dated, your content is somewhat stale and the content management system you have in place is so cumbersome to use that it takes three days and an IT engineering team the size of NASA to change an image on the page. So how exactly do you go about running a large website redesign?

I faced this exact challenge recently. In hindsight, whilst we knew the fundamental elements of what we needed to do, the project really didn’t have the emphasis on the right problems, nor the resource focus in the right areas, at the right time.

From my experience, a large-scale website redesign project can be bracketed into three main themes:

  1. The technology – the replacement or upgrade of the existing content management system
  2. The design – the user experience and look and feel of your new shiny website
  3. The content – the words, images, video, documents and tools that users will interact with

Asking yourself at the outset how many of these three elements you want to significantly change in one go is hugely important to defining the success of the project. It is also essential in keeping the expectations of your senior stakeholders, and indeed, the anticipation of the wider organisation, in line with what will actually be delivered.

If possible, I would strongly suggest changing a maximum of two of these three elements at once. It significantly reduces the number of chicken and egg problems you need to solve and reduces the risk of the project dramatically.

For example, if I were switching to a completely new content management system (basically, building a new website), I would probably look to overhaul the design at the same time, but keep the content the same. This might still require a rationalisation of the existing content into a different site navigation, but at least it reduces the number of people across the organisation that need to be involved, which reduces complexity.

The trickiest two to change in parallel are the design and the content. When these two are thrown up in the air together, it becomes a difficult juggling act to keep everyone’s expectations aligned, and almost impossible to hold a project plan together once content and design start bouncing back and forth.

Beyond the primary three there are two other important elements that must not be forgotten.

First, how will the site be monitored and analysed? Whether it’s Google Analytics or another package, take the time to think through what you’ll be reporting against. This fits best into your technology stream.

Secondly, your SEO strategy. This should fit strongly into your content stream. Take the time to consider who your site and content is for and how you are going to monitor how successful you are in bringing that audience to your content.

Ultimately, any large-scale site re-build carries risk. As much as possible, reduce that risk by focusing the effort into those key elements that are going to give you the biggest possible benefit in the fastest possible time. Focus on the authoring experience and the user experience equally, and don’t forget that everything you implement needs to be monitored and tracked so that it can be continuously refined.

Project management is dead: long live change management

Call me a little old fashioned but over the last few years, spurred on by the demands of popular project methodologies like Agile, the practice of properly gathering, analysing and prioritising requirements seems to have become a thing of the past. Why is that, and is the new way of doing things really better?

I’ve worked on projects that have used waterfall, multi-waterfall and agile methodologies. Whilst much is made about difference between them, the reality for me has always been that it is the people, not the methodology, that have defined the success or failure of the project.

One of the biggest differences is often described as a reduction in documentation required by using agile-led ways of working. This is something of a misunderstanding; it’s not about less documentation but rather breaking the process up into smaller, more manageable chunks – and that includes the documentation.

The most significant problem I have observed as a result of this is that senior stakeholders in the project forego the process of properly understanding and analysing the full scope of a project and prioritising accordingly. In the race to make everything quicker and more efficient, we often forget that we still need to specify some boundaries. Our time, cost, quality triangle has gone out of the window and has been replaced by fortnightly sprints, standing up for ten minutes each morning and project plans that…well, there are no project plans anymore!

Except that, in large organisations at least, none of that is actually true. The need to control cost hasn’t gone anywhere. Nor has the demand to satisfy senior executives’ desire to predict the future with specific project implementation dates. And so, as project professionals, we find ourselves operating in a hybrid of hybrids. The agile multi-waterfall.

What all of this means is that we now try to run huge, complex projects without trying to constrain ourselves to specifying the deliverables in the early phases, but allowing them to evolve over the course of the project. We keep to a fixed deadline and “deliver” whatever we end up with when either the time or money runs out. Or worse, we keep going back for more.

And so, born from the desire to be more efficient, to evolve our designs and segment our projects into more manageable chunks that can demonstrate progress more quickly to our stakeholders, we have created the anti-thesis of project management. It is now possible for a project to have no end date, to have no fixed cost and to have no specified outcome.

In short, by not focusing on our requirements and prioritising what we want to deliver at the outset, we’ve killed the project management ethos and created something entirely new. We’ve created the change management industry.