Why Change Fails?
The short answer: politics
- Many project problems are bigger than just your project
- You have to make changes to the way people in your organization work
- Your ideas on how to improve the way work is done will not always be evaluated rationally
Change is Uncomfortable
Nobody likes to think that they make mistakes. Making changes means talking about past mistakes – and admitting that they are mistakes! You may make a great case for change, and still fail to convince people to do it.
Because change is uncomfortable, people in organizations will resist it. Project managers who try to change their organizations run into several common excuses when trying to implement tools, techniques and practices.
We Already Build Software Well
“This is just the way software projects always go.”
- People know that there are problems with the schedule and quality, but think that nobody ever does any better
If you bring up past failures, you are trying to blame people. This leads to an environment where it’s not possible to admit that projects go wrong
“Not Invented Here” Syndrome
People intentionally avoid research or innovations that were not developed within the organization
- Yes, NIH syndrome really happens!
The idea that “we’re different” leads to immediate resistance to outside ideas. In some small organizations, it’s even worse: “Our ‘quirks’ mean we’re better.”
It’s “Too Theoretical”
When ideas don’t make intuitive sense, they are dismissed as merely academic. Many “hands-on” managers must personally see a practice in place before they will accept its value. Especially common in small teams facing growing pains.
It Just Adds More Bureaucracy
Any work other than programming is wasteful “busywork” that keeps the “real work” from getting done.
- “If I just add more programmers, it will fix all of our schedule and quality problems!”
Planning the project, writing down requirements, and holding inspection meetings is seen as just pushing paper around.
You Can’t Give Me More Work!
Asking someone to review a document or make an estimate is asking them to do more work. When you change the way other people work, they may just say no. For no good reason. And if they have more power than you, they may get their way.
It’s Too Risky
A manager who backs a change puts his reputation on the line. It’s safer to let a project fail in a way it’s failed before than to make a change that might not work.
- “Too risky” means risk to the manager, and usually not risk to the project.
How to Make Change Succeed?
Progress comes from making smart changes. Understand how people in your organization think about and react to changes.
- Prepare your organization
- Sell your change
- Account for common excuses in your “pitch”
Prepare Your Organization
- “We’ve always done it like this.”
- Be positive about the work that’s already being done
- Take credit for the changes
- Make the changes seem straightforward
- Build support from the team
- Show that the changes will save time and effort
- Work around stragglers
- Stick to the facts
Plan for Change
Create a vision and scope document
- Similar to the document for software projects, except it describes the scope of the change
- Inspect and approve the document to build consensus
- Add the changes to the schedule
Push for Consensus
Get project team members on board first.
- Managers are more likely to approve a change if the entire team (especially the programming staff) is behind it.
- Help people recognize the problem, then show that you have a solution.
- Organizations do not change overnight.