Meet the Candidate: Change Management and Software Development Management

Welcome to part two of our User-Generated Content. Today, we’re hearing the views of a candidate, Ed, whose primary background is in Software Development / Software R & D Management as well as Operations / General Management for technology companies. Hi particular expertise is in leading change and transforming the capability and productivity of the teams he’s been responsible for. His exposure to technology includes Conditional Access Software, PCs, Peripherals and Storage Software. He’s been directly responsible for strategic leadership, change management and thought leadership, and his management efforts have been at the heart of some great success stories – with one former employer improving market share from 3% to 35% as a result of the software produced under his management. Now seeking new permanent employment, we invited Ed to write an article for us on the complexities of Change Management within Software Development, and here’s what he had to say.

“Organisational Change takes longer than you think” but don’t get depressed.

The biggest mistake made by any beginner trying to lead their first organisational change is to underestimate the time taken to complete the change. Just attempting organisational change means you are probably a skilled and experienced operator in your field. You recognise that there is a problem, you believe you know what needs to be done and you believe you have the capability to do it. So finding out that you underestimated the time needed to make the change by a factor of 2 or 3 can be devastating to your career and personal esteem.

The kind of change I’m talking about is adopting a new ERP (Enterprise Resource Planning) system like SAP, adopting a new product lifecycle or project management process or introducing defect or change management. Often these changes will be accompanied by a new Computer System, and the second biggest mistake, after underestimating the time the project will take, is to assume that the majority of the change is the new system rollout.

Often you will be under intense management pressure to make the change and improvement quickly. So like a good leader and manager of change you turn to MS Project and create a project plan for the implementation of the change. This is where the rot starts to set in. It is always possible to map out the change like a project and demonstrate that it can be completed in maybe 6 to 12 months. WHAM your boss has a plan, your commitment and the worst months of your professional life, so far, start here.

OK so you think you are a good project manager and you’re not going to fall into this trap. Well the truth is that most project plans get their accuracy from the ability of the PM to compare the individual tasks to ones that the same teams have done before, and the big problem is that, by definition, you never made any of these organisational changes before. So until you have completed three or four organisational changes you won’t have a good feel for how long the tasks take.

The truth is that in a sizeable organisation changes like the ones I have described above take 2 to 3 years to make. Here comes the tirade……….. “Our market moves too quickly”, “We can’t dedicate people to process work for that long”, “We just don’t have time”, “Our business cycle is 4 months, 3 years is 12 business cycles”. In any modern industry which is going places, some or all of the above are true. So below you will find some pointers to help square this circle.

1. Understand the reasons for change. Are they idealistic or operational?
An idealistic change such as “Our largest customer won’t buy from us any more unless we get ISO9001 certified” or “we need to move all production offshore” can require fundamental change in many areas of the business. Operational problems like “80% of our software releases require rework” are more likely to require several small operational changes. Both require a good understanding of what you do right now and what is considered best practice in similar businesses, but don’t approach operational problems with fundamental business change. Cumulative or persistent operational problems can identify a need for fundamental change, but it’s important to recognise the difference.

2. Don’t fix the parts that aren’t broken.
Make sure no ‘nice to haves’ or ‘pet projects’ make it into your change project. Markets aren’t dominated by nice to haves, and competition aren’t annihilated by pet projects.

3. Don’t be frightened of introducing the process before the system.
If the change needs a new IT system, introduce the new process using paper-based processes, Excel spreadsheets or existing systems with paper or Excel covering the cracks. This will iron out the new process and simplify the system requirement and design phases.

4. Getting the most out of your pilot.
Don’t be afraid of using the most urgent and deserving project as your pilot for the new processes. If the project is the one that really needs the organisation to work differently then it will help people to understand why they have to change what they do. Getting that understanding and support will drive a swift change. Don’t let system introduction delay this (see point 3). Systems add lots of risk. Processes that are well designed to meet the needs of a project should not add much risk to that project. Caveat: This is not the right approach for safety critical systems.

5. Take the people with you
New systems take a long time, but for many change projects the longest tasks will be “people do something different” ones. Involve affected groups from the start; listen to their input. Model the new process against what they do today. Package the required changes into understandable, justifiable and saleable chunks. Don’t compromise on time spent ensuring staff understand and agree with the change. Staff have to be both willing and able.

6. Process serves the business, not the other way round.
There are no prizes for uniformity. If one part of the business can work differently without damage to the business as a whole then let it.

If you follow these pointers you will get change started earlier, apply change where it’s needed, improve system design and get excellent buy-in from staff. One last point: You may find that the pilot works well, but you have trouble proliferating the change across other projects. If so you need to keep reviewing the reasons for change and the need for uniformity.

Change does take time, but don’t get depressed, find the best pragmatic route through the people, processes and systems, and you will be doing the best thing for the business as a whole.

If you agree with Ed and would like to find out more about his background, or would like to set up an interview with him, please contact us here.

Keep your eyes peeled for the next instalment.