This blog details 10 issues I have experienced in the past when organizations I have worked for, or with, have implemented large scale change
Recently the Company I work for Tieto announced a merge with Evry. We will become TietoEvry. Over the years I have seen many mistakes happen in different companies making large scale strategic or operational changes.
I would hope our organization avoids these issues in the run up to our new merger and I would hope anyone considers before implementing large scale change.
1. Planning Strategies
All too often I have seen big changes happen without proper planning; management have an idea, may have a few focus groups, or get outside consultancy and a new direction is born.
The big mistake can happen when this is done without fully understanding the impact of change, which is where enterprise architecture comes in. We have a whole range of skills around understanding business motivation, and analyzing business risk and change. Our modelling techniques when properly applied can enable us to help management understand the true impact of change. A good Enterprise Architect can act as the right hand of the business stakeholders.
If you build a strategy without involving enterprise architecture (and this does happen) then you may be limiting its effectiveness. You may be implementing an inefficient plan, or in some cases even an untenable one.
Its important to involve enterprise architects at the beginning of any planned organization change and throughout it. A good EA has tools, and insight into the change process and can provide all manner of methodologies that can help.
2. Solving the Big Problems
Before releasing a major direction change for a company its important to have solved the big problems – and to have a plan not only on what you want to do, but how it is you want to do it. In defining the plan to move forward its important to at least have a partial idea of where you are – understanding the current state helps you understand how to move forward into the future.
I previously wrote on planning work with Archimate – Fundamentally the concepts I introduce could be used, but with large scale change its important to start building strategic layer thinking. I would define current and future state architecture as well as the transition between them – in ArchiMate terms this would be defining plateaus and plenty of implementation architecture. The time you spend planning ahead of time is small compared to how fast you can burn time when nobody in the organisation has clear direction after a strategy announcement and just waits and sees what will happen.
A good approach is rather than just announcing change and stating it will happen, engaging teams before hand and get them to help. Taking a conversation where you say “We are assessing a number of options – if we take this option, what would be the impact to you – and what would we need to do to make it work?” will help you see pitfalls that may not of been evident and it also gives a level of engagement and commitment to an idea.
When merging companies, or making changes that will have major impacts on the jobs of employees, there are of course some limitations to how far you can take such an approach. Even if you cannot engage the entire company, a good enterprise architect will help.
3.The Aspects of Architecture
I have spoken about the IT Architecture Aspects before. As with all architecture changes, a new strategy necessitates us to think of our architecture aspects:
- Processes & Roles
- People & organization
- Information & Governance
- Tools & Technology
For each of those areas we effectively need to explore what, why, who, how and when. This can be approached with different levels of methodology. Some EA’s model these aspects using languages like ArchiMate and are able to give detailed analysis of the impact of change across the different aspects. Its very easy to miss key elements when you are not thinking about how the different aspects interact with each other.
4. Feeling Engaged
Its important for teams to have a solution minded approach to issues, rather than a problem minded one. I have to be careful with this one myself; I tend to think in terms of problems – not because I am negative, but you do need to identify a problem in order to be able to solve it. If a team has a problem the same team should also think about potential solutions, or we can handle it as an architecture concern.
Its amazing how a few individuals can derail the success of a strategy. At one point I started running a new architecture team that was implemented amidst many other changes. In order to manage the scale of change I decided I needed to engage a small core team of 5 architects and they would manage the larger team of around 100 people. I was distributing authority, because I am only one person. My plan would have worked well, except for one person. I would set direction for my team on a Monday morning, and in the afternoon the core team would set direction for everyone else.
What happened was one person in the afternoon meeting would complain about everything. Effectively that one person turned the entire strategic focus from being solution oriented, to being a firefighting one. It was negative and it was hard to get people engaged in creating a positive change. My core architects were stressed and every little thing then began to be questioned. Even more time was wasted.
In the end because I had to manage that problem and for a while my work was significantly increased. I didn’t allow this to continue for long, but my point is, that if I had known the trouble spot to begin with and taken efforts to get that guy on board with the new strategy, the strategy would have been faster and easier to implement. If one persons argues an hour in a meeting you invited 100 people to – you have lost 100 hrs of time and will have collateral damage.
There’s a balance to be had. Where you see a negative influence, you need to deal with it fast – preferably in a positive way. A passionate person can be your undoing, but when you manage to get the same person on board they can be your biggest advocate. Its good if you can identify passionate people up front.
5. Role Management
When I look at different companies and reasons for failure of strategy execution sometimes it can be traced back to Human Resources / Line management processes and adherence to them. Any job role has a set of expectations and those core role expectations are the ones that need to be assessed and measured. When this isn’t done what can happen is over time as the organization changes, roles change. This can give an enterprise architecture headache as you see an organization that appears to be fully staffed in different functions but in fact isn’t. When trying to decide a new team structure this can be a problem.
For example if technical specialists become architects without proper training and assessment you end up with a group of architects who will know technology but not have the skills to be able to fully describe an architecture or manage it. The transformation from role to role may have happened for a variety of reasons.
I once in the past came into a project with over 40 architects, of which none of them could actually describe architecture outside of creating basic technology views in Visio.
If you were to run a team with 100 architects, and you think the workload only needs half that, last thing you would want to discover is that in rationalizing teams you have broken other areas of the organization because the job those resources were actually doing was not what you thought at all. Before making such decisions its essential to really understand what all roles and responsibilities in the organization actually do.
6. Consistency in leadership
For change to be effective it needs to be understood and aligned within the leadership of a company. When a CEO announces a change of course everyone in management normally want to do the best to support it, but sometimes their own personal goals and targets can restrict this. IF a CEO gives a set of goals to hes leadership team the leadership team needs to filter those goals down to the level below them. and that level needs to cascade the relevant goals further down.
I have seen in the past in some companies goals at the top level that look very different to the lower levels. If a board member has 10 goals around growth, and development in different areas, but his/her direct report only has a financial target – much of what was intended will be lost. Even if PowerPoint presentations fly around the place with all the original board goals. Much of what is in PowerPoint gets forgotten over time. The formal review mechanisms need to include the goals from the board in some form; if you are expecting the subordinates to meet them. The formal review process is actually what impacts peoples earnings and career development.
In one company I created an architecture view that showed 5 levels of management together and their goals, and only financial goals existed below the third level. I asked my manager at the time why this was, and was told that the management didn’t want targets that they couldn’t easily measure, because it would impact their bonuses. This was bad.
If your HR processes are clear and measurable, and someone takes the time to ensure that goals are aligned as we filter down an organization then when change comes we can more clearly ensure that change is effective. Wen building a strategy clear expectations need to be laid out to every level of the organization and if need be working practices and processes revised.
7. Unclear HR
People tend to stick with doing what they are comfortable with but unless goals change and people understand their own personal role in a new strategy people will not be fully invested in it.
What can be worse is when the change then happens – often some roles disappear. This is where hero’s are born – and a hero in enterprise architecture is not always a good thing.
Heroes do their best to mitigate the chaos around them by assuming the responsibilities of roles that do not belong to them and seemingly get things done. I have a love/hate relationship with this. I applaud the effort and intentions. However, this can break things in many ways for many reasons including:
- Roles informally transform: if a role informally transforms it means you have created a deviation from the intended strategy; and the way the company is something else. Your organization is not running as intended.
- Processes start to break: At this point you will start to detect the issue if your processes are properly measurable – because you will see they are not running as anticipated; the correct people are not doing the correct things. The outcome may appear to be good but the working practice is unlikely to be efficient, and where you aren’t following process you are likely creating risk
- Understanding resourcing hot spots becomes impossible, because people are covering them up. For example if a sales team suddenly looses the services of a translation team, they may have people who can do the translations in their own team. If they do that without properly escalating out the fact they are doing that work there are a couple of possible issues –
- Firstly they might not do the job as well as a professional service.
- Secondly, they have then become unwittingly accountable for that translation.
- Thirdly, they have added to their own workload and stress. I’ve seen this break good intentioned people.
- Fourthly, The line manager may understand this change in role but if its not formally built into the role then in adding the responsibility to the resource means the focus is suddenly shifted from the intended job role to something that is invisible to the organisation on a whole. If that same resource is spending a week doing translations in a sales case, he is also spending a week not doing sales.
- Fifthly, This isn’t scalable. If a sales resource is bridging the competency gap filled by another missing role in the organization bringing in another resource to assist won’t be as effective as it should. Different heroes will extend themselves in different ways and this becomes quickly immeasurable.
In bad situations I have seen line management become reliant on heroes. If you are a line manager and can only use one or two of your key resources for a specific task the chances are something is wrong. Either your operational processes are broken, or your HR processes are. As a line manager this has to be escalated and actions must be taken to rectify this, or what will happen is over time, you will lose your hero as they become overwhelmed; and you will be left with worse resources, until the quality of work becomes so low that the continuation of business is untenable.
This may sound a little controversial but we need to eliminate the need for heroes. If our strategy ensures we have clearly defined roles and KPIs, and we put in processes to ensure they are followed the need for heroes is significantly diminished.
Its important to be aware that having measurable KPI’s in an organization doesn’t mean you become any less flexible. It means you are keeping track of the things that matter. Its possible to have a good balance of discipline and flexibility.
I can imagine some people thinking what I said about Hero’s is wrong – because we all have responsibility to do what we can to further business right? Yes we do. but there’s a right way to do it. In an organisation I would say everyone has a responsibility to identify and escalate risk where they see it – I would also say, sometimes we do need to step outside our roles and get our hands dirty when its needed. Of course communication and collaboration is important. Collaborating with our coworkers to help them is important – but we should always be mindful of our own roles and goals, and of the process.
9. The Importance Of Process
Process is important because it enables us to scale, have common direction and measurement, whilst managing risk. Sometimes process is not well defined which needs to be addressed. When a professional escalates they do not normally just complain; its far better to offer a solution rather than a problem. Its also important to have perspective. Everyone thinks that their area of business is important, but its rarely as nearly as important as the business of the whole organisation.
Properly defined business interfaces need to exist between different parts of the organization, and between the organization and the outside world. All these things need to be measurable. If you are running a business with many service areas, as well as the underlying processes, you need overarching processes to hold those units together – not only the company level standard processes, but also processes that address the end to end needs of the customer.
When transforming the organization you need to also be considering from the outset how you are changing process. If a process is not communicated well, is difficult to follow, does not cover all the use cases necessary, or simply doesn’t work, or isn’t helpful these are all failures of process design that need to be addressed by a process team. Processes can be agile and flexible if they are well defined – they don’t have to be a monolithic. Process often gets a bad reputation because its often poorly designed and implemented.
10. Communicating Change
The first thing I would say about this, is do not talk down to your resources. Treat people with a level of respect and intelligence and they will, to an extent, do the same. Of course there are legal implications of what you can and cannot communicate, and over communicating can be problematic too. If you stress people to the point they are worried about their jobs efficiency goes down unless in the same time you are communicating exactly what needs to be done in order for people to keep them. A plan that is effectively designed between management and an EA will go a long way towards quietening discontent.
Having a plan defined with architects before announcing huge changes goes a long way to calming fears. A company can loose many man hours if they announce the change and then do not follow up with direction as to how the change will be handled and implemented quickly afterwards.
The direction “Business as Usual” has a limited effectiveness. Uncertainty is a productivity killer. People sometimes will worry – they will stall – they will be reluctant to implement some initiatives because they will be concerned of effectiveness.