Getting to the point of change 3 - The 'How to" post

So far lots of whining - but the frustration comes from the fact that as an enterprise you can lift your chances of success by an order of magnitude by just following some basic principals when you undertake any kind of technology driven business change. In this post I want to share some actions that I have seen work time and again. Alone none of them can guarantee success, combined none of them can guarantee success. But as a passionate backgammon player, I know that probability is all. The fact is nobody can guarantee you anything in the IT and change world, and anyone who claims to is a best economical with the truth. But what I know for sure is that the probability of success increases dramatically if you follow these four simple rules:-

1: Be honest.

If you plan to reduce headcount and/or restructure the way folk work then say so up front.  Explain your reasons why as early as possible and define what the ideal end state looks like. Will people be happy? No, but they know they are dealing with an honest person/company and not a snake.

2: Engage with stakeholders right from the get go.

Engaging with stakeholders unfortunately is often taken to mean talking to managers. Though managers have a critical role to play, its not managers that get the nitty gritty work done in an organization. Whomever is doing the nitty gritty work should be very high on your stakeholder priority list. I could fill a book with stories of IT projects that deliberately avoided engaging with the folk doing the actual work they were going to impact, only to later only sincerely regret doing so. Trust me, when a manager tells you the process his or her charges follow to get work done, the 'charges' version of affairs is almost always very different.

3: Do both of these things way before you chose technology options

One of, if not the most common reason for IT projects to fail is to get involved in procuring (buying) technology way too early. Until you have clearly mapped the 'As Is' situation, mapped the desired 'To Be' situation. Broadcast the need to change, and started to engage and listen to stakeholders etc you should stay well away from technology. A project I was involved with many years ago had raised a budget of several million dollars to tackle a particular problem and buy technology to address the problem. When my colleague and I pointed out on day one of our engagement that the problem was far more simply resolved and could be fixed without any technology...... we were sent home and our contracts cancelled. Fair enough.  But way too many big IT projects involving new or replacement technology can be resolved without any technology investments at all.

4: Embrace failure

Its a cliche but any successful person (Richard Branson for an ultra cliché example) will tell you that to get to where they are involved a lot of failure.  IT projects are started, change is decided upon - often though a sinking feeling emerges that questions whether this is a good idea or not. By planning and inserting multiple go-no-go milestones in your project plan. By honestly assessing where you are at any point, and whether this project still makes sense you will increase your chances of success ten fold. Embrace failure, walking away early on is far better than undertaking a death march to oblivion. Sadly most projects once started are determined to get to the end, regardless of whether they deliver any value or not.

Clearly there are many more factors to ensure success from building a business case to managing time and resources effectively. But the above four I highlight here as these are fundamental and need to be addressed from the start of any initiative.

Getting to the point of change 2

At the end of the day people are people, and its not really in the remit of a technologist or consultant to try and change the human state. Even so a basic understanding of how we all tick should be at the core of any business change activity.  Like it or not successful leaders and advisors do understand how folk tick, its why they are successful. But that does not mean that they are neccessarily empathetic or caring - it means that they know how to get things done and how to get people to change ingrained habits and processes. Enterprise technology projects are seldom led by strong leaders, rather they are led by folk with a good understanding of the technology, the company or both.
As such major change projects that would have otherwise had input from HR professionals or outside specialist consultancies elsewhere in the firm, are classified as IT projects and don't get that input.

If business change is involved, and it almost always is in Enterprise Software and Services situations, then you need to start planning the change process long before you get involved in selecting technology. You need a no holds barred discussion at a high level about where things are going, and most importantly the risks involved in the change and what could potentially go wrong.

In my experience IT projects are seldom open and honest about what changes the firm is hoping to make with the new technology, either with themselves or with others. Project failure, despite it being so common is simply not considered an option. This whole area is something to explored at another time. But the issues of openness in general is relevant to this particular discussion.

For example, in a few cases I have seen projects essentially run 'secretly' with the the new product or service being delivered as a fete accompli (or so they think). The other common approach is the co-operative approach, where management tries and listens to everyones views/needs and to accommodate those views/needs. Neither approach works.

In the former approach (withholding information about the full or true nature of the project) you almost guarantee significant and often very successful resistance at roll out. In the latter you run a high risk of ultimately losing control of your destiny. The truth is you meet everyones needs, nor should you try.

But maybe these two approaches, and all those in between mask the true path to success. To be clear honesty is as always the best policy, and organization both big and small are terrible at keeping secrets. Either the truth will out at an inopportune moment - or just as bad people will simply put their own (usually negative) interpretation of events onto the situation. If perception really is reality, then you have serious issues across the board. Honesty, even if its brutal (quite different to uncaring or malicious) is essential.  For example, telling folks up front that the purpose of this IT project is to provide support for a headcount and cost reduction and will likely involve the restructuring of some business units - isn't going to go down well, but at least its the truth and people can work with that. Either to find timely new employment elsewhere to support themselves and their families, or to find a new role and adventure in the changed organization. But honesty and clarity, though important isn't enough. Folk have to want to change, they have to be excited about the change, they have to be uncomfortable about the status quo. They also have to embrace the risk and be committed to making the change - accepting that all will not go smoothly, there will bumps in the road ahead - but they have the drive and vision to navigate a road through.

To be continued (maybe)

Getting to the point of change

One of the key things I have observed over a couple of decades in the IT world is that even though change in organizations if often imperative, it seldom happens. Deliberate planned change, no matter how essential seldom occurs.  I have seen countless major IT projects involving information and processes undertaken, hundreds of millions of dollars spent on software, hardware and services - and yet the status quo remains at the end. Take a typical SharePoint project that was all the rage 5 years ago, these projects were going to transform the way organizations managed and shared information - making companies more efficient and collaborative.  Few of these projects delivered on that promise.... It wasn't Microsoft fault, in fact the same is true of most projects.  Though there are many reasons projects fall short of expectations, poor project management, poorly set expectations, the over reliance on technology to fix business problems etc - I think the number one reason is. People don't like change.

A firm I have worked with needs to change. It is profitable (sort of), it has grown like many in this sector over the past 10 years or so from start up to employing a few hundred people. It's established, it works and its unlikely to fail anytime soon. It has a window of opportunity that will close soon to make a step change to the next level. It's competitors are not doing so well, customers like the firm, it has a good reputation and good products. But for the last several years its business has stagnated, and when this window of opportunity closes the firm will likely move to a slow and ultimately terminal decline. It needs to change now to secure its future and to grow.  The firm has brought in new management, it has a new and ambitious strategy - in fact the firm knows EXACTLY what it needs to do to transform itself into a bigger stronger and better company. But despite all the talk, all the meetings, all the planning, all the spend - its not changing.

Like many firms it is run by a charismatic and very smart CEO who knows where the company needs to go. But the staff of the firm, see things differently. The staff are comfortable, life is good enough for them, the company is good enough for them, the way they work has worked well enough to this point, so why they say, do we need to change? Or rather they don't openly question the need to change. In fact they openly and volubly support the change, but they never seem to do anything about it. Their day to day concerns always seem to take priority. Risk is scary, risk means things might go wrong and change means changing, and they don't want to change. Even senior hires who enter the firm full of enthusiasm and passion for change are fairly quickly reigned in by their subordinates, pulled into the nitty gritty of today's work - and not the future shaping work they need to do.

The challenge for any leader or advisor is to communicate a NEED to change to a willingness and PASSION for change. Folks who are complacent need to be re-energized, reminded of the the enthusiasm and passion they first had, excited about the next chapter, and eager to turn the page and close this chapter out.  In tech projects this sort of thing is usually poorly understood, dismissed as 'arm waving' or 'management theory' - but without it nothing ever changes.

I would love to see and maybe even be a small part of changing this mindset - or at least developing new tools and processes to better enable it. Enterprise technology today (and anyone who has heard me speak or read my research over the years will know my position on this one!) is way ahead of the folk that buy it - its potential is incredible, but failed or disappointing IT projects remain the norm. Surely its time for the industry as a whole to re-examine where its at and maybe look again at the success and failures of the 90's era of Change Management & Re-Engineering. Much was wrong then, but not all - many lessons were briefly learned but then all too quickly forgotten. I believe its time we need to start this discussion again, pick up the pieces and stop accepting mediocrity, stop tinkering with the system and move again to mindset (to quote Tony Robbins) of massive determined action. Tech for tech's sake is of very limited value, the Silicon Valley bubble that is disconnected from the real world is once again a bubble full of hot air ready to pop. If ever there was at time to change, it is now.