I recently watched a BBC show called “Dream homes”, that basically talked about how to help people who had problems to decorate their awful house into a dream land within a limit budget. Normally, from the beginning, the house-owners and the show organizers came out a plan, say “budget 80 grand”. When the procurement and engineering work started, with some changes happening, the budget always went up dramatically to double or even higher. Then they had to give up something in their original plan in order to cut down the cost. Along with the whole program, there were many changes, such as change of the engineering design, “shopping-list”, construction implementation. Sometimes, money were saved and sometimes lost by these changes. This show made me think of our software development projects that included lots of changes every release, every week even everyday. These changes might be initialized by business owners, end users, project managers, or development team. People in this show did not feel like being good at the change management that touched me off thinking about what good practices that we can use in project change management and how to use them.
Insight a traditional project change management approach, a change typically goes through at least 6-7 steps of a process from it is born to its end.
- Change initiation
- Change classification/Define
- Risk/Impact assessment
- Plan
- Change approval and notification
- Execution/Implementation/Test/Monitoring
- Change acceptance/record/closure
This process made sense to me theoretically, and I did went through several times of the whole process when I was an IT manager in a large organization. It certainly “worked”. However, I observed several phenomena that were either waste or dragged the whole thing to the opposite direction of the goal of the change. E.g.
- People focused on a very detailed plan and it turned out none of the many times of execution actually went step by step following the plan.
- Documentation maintenance was paid very much attention even than the actually the change itself, however two years later, no one actually went back to see any of those documents. I can tell the main reason behind the concreted documents was that people did not want to get into trouble if there were anything wrong concerned the change.
A process/plan driven management approach might caused the above problems. The underline reasons are that human-beings keen to protect themselves and achieve personal achievement firstly if you do not bind their performance with your organization’s value and achievement. However if people could be trained by value/goal driven thinking align with reactive/adaptive project management approach, those problems would be solved.
In a typical IT change project, however it is big or small, going through with the structure of the process is not a bad idea, meanwhile, put too much assumption or make the plan very much details could kill creativity and flexibility during the implementation of the change itself.
Software development project could be a bit different in change management. It is not easy to achieve the same understanding of cost-efficiency of each change, so it normally came to the situation, business stakeholders and development team went for slightly different direction during the implementation of a change. It might be worse, if there was change during the process of making a change. So, certainly it would be very inefficient to go through a whole process every time.
So what would be a good idea? When there was a change that was initialized, team can regard it as a task and put it into development task list, we can think it as a functional task, or defect or whatever it is easy for the team to understand. Then re-prioritize the task list and rank this new task (change). When team estimate the workload of this task, its impact on the existing system need to be considered. Sometimes, it might be just less costly if a change could be combined into some existing tasks that they have similar priority.
People who manage change plan should consider which option could put more business value into the software application and what the goal was to finally achieve. When people driven by value or goal, with a simple plan in hand, they could be very flexible during the implementation, so that the process and documentation just played a helper role rather commander.
Tips:
- Sometimes, business stakeholders and development team could not easily have the same understanding the cost of a change. In this case, splitting the change into several tasks could make it easier to understand.
- Use any chance such as meetings, daily catch up, project Wiki to communicate with the team about the changes that would be made and notify every sponsor and stakeholder.
- IT need provide enough information for business to understand the cost and impact of a change and co-work to make a correct decision.
- Make a change plan more goal-driven and not too detailed so that team can be more creative during the implementation.
- Communicate more if it is possible, maybe development team can demonstrate a completed task that was not the complete change to business, so that team can check if they were going to a correct direction.
- Risk and impact assessment is necessary however it does not need to be very formal or be written as documents.
- The closure of a change should be able to be demonstrated in the real application.
Back to the beginning, if the house-owners could manage their changes in this way and well prioritize their task list and considering any change as one of task, their job might not be that painful, they might just get a fairly dream home.
