Tag: Change Management

  • Agile development and change implementation

    While I’m on the topic of change management and how it isn’t very different than plain old good management, I feel like I need to address one additional aspect that people often get wrong. Initiating a big change is hard and it’s nearly impossible to get everything right. This difficulty can cause an organization to stall in the middle of its change process, or worse still, never get its changes off the ground at all. People can worry so much about trying to get everything right at the start, that they never actually start! These people are missing a key insight, though. They are almost guaranteed to not get a big change completely right, at least not at the start. So instead of spending so much time planning perfection that you never actually get started, plan instead to make some adjustments and corrections as you go. I look at this sort of like the agile development process for software.

    Instead of the traditional software design approach of getting all the customer specifications, defining all the other interfaces and requirements, producing the proper flowcharts, and pseudo-code, all before writing any actual lines of source, the agile approach relies on rapid development cycles with frequent releases between customer and vendor. These frequent releases and testing cycles allow bugs and requirement misconceptions to get caught early and fixed before they are too buried in the code to be easily changed. Fundamental tenets of agile development (thank you wikipedia) include valuing:

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

    While the items on the right are important, agile development places more value on those on the left. Agile development processes are now expanding beyond software to other areas of engineering and development as well. Rapid releases, real time customer interaction and results assessment, and teamwork development are all agile tenets which translate easily to other endeavors including change and general management.

    Agile Development cycle
    A simplified description of the Agile development process.

    Planning is important, as are defining initial requirements and defining your end point in terms what outcome defines success. But planning, even 100% perfect planning, doesn’t guarantee success. In some cases there are too many variables, too many complex systems, that it is impossible to plan everything with 100% accuracy before starting. In these cases, I say borrow something from the agile programming model. Define your needs, define your end point and make a first release. Test, evaluate, repeat, until success. Don’t let lack of predictability or perfection prevent you from making a needed change. If you can’t solve everything at once, that’s OK; solve what you can and evolve from there.

  • Change Management – Another Instance of Management 101 Getting it Wrong

    Change Management is a idiom often heard these days where I work. I’m sure you know what it refers to – the process of implementing change in an organization and converting employee’s initial reactions of fear/anger/doubt to ones of discovery/understanding and ownership. The management steps used in this process involve opening up the avenues of communication to explain why the change is being made, providing training as needed, dealing with resistance, aligning employee and company needs, obtaining buy-in, implementing, and repeating – or some variations thereof.

    I never bought into this approach and have recently figured out why. First off, it starts the communication and gathering of input process too late – only after the decision has been made. In reality, employees should be part of the problem formulation and solution formation from the start and not only after the powers above have declared some particular change is needed. My second objection is more fundamental in that this approach espouses certain kinds of activities and communication approaches only during major change, when in reality the proper change management approach is simply a good every day management approach. Since the default is to do today whatever you did yesterday, nearly every decision made represents some kind of change. Why do we worry about communicating with employees, aligning needs and strategies, and getting buy-in only when we see some decision as part of a change management process and not otherwise? It just doesn’t make sense. Good communication and employee involvement make good management sense always – whether or not the company is going through a major change.

    It is not so much that the basic change management approach gets it wrong (and I’m sure some change management proponents adopt more sophisticated approaches which solve my implementation objections), it is more that it implies you need to worry about good management practices only during a big change and not otherwise. It is this implicit tolerance of bad management practices being the norm that I find the most troublesome and fundamentally bad for the organization. Good change management is simply good management. It doesn’t need to be separated into its own discipline.

    By all means, communicate with employees, get their opinions, align their needs with those of the company, and monitor the implementation of new projects, but do this early and do it al the time! Manage this way and you’ll never have to talk about the change cycle or change management again.



    Although not a particular fan of the “change management” dogma outlined above, Scot does believe in the Systems/Software Engineering approach to change control in projects. His life changed significantly for the better when he discovered CVS/SVN, for example, which he now uses extensively for his personal projects, both software and written.