Someone recently asked me, "What is the best way to implement your software?" Although this question was related to project management software, the principles apply to any type of software implementation or development for that matter.
I’d like to propose three keys that will help project managers avoid common pitfalls when bringing about change in their organizations:
- Expect Incremental Improvement
- Override the ‘Smart Guy’ in the room
- Communicate, Commit & Club
Expect Incremental Improvement
Everyone has heard the analogy about how to boil a frog. There is even a Wiki entry for it. This principle holds true when bringing about change in your organization. All software implementation or software development projects are bringing about change – they are solving problems, and ultimately will require some change in behavior.
Be patient. If you try to go straight from A to Z in one well-designed initiative, you will probably fail. If you impose the end-goal on a team who is just coming to grips with the concept that they need a better solution, you will probably fail.
This does not mean you shouldn’t think ahead. Go crazy with your vision of what this solution should ultimately do. Build your big RFP covering the all potential functionality known to man. But then, and this is the important part, prepare to throw 95% of your good ideas overboard and ask yourself this question, "What is the simplest way to get to the minimum acceptable improvement needed right now?" Once you have an answer to this question name it "Phase 1" and lock onto it with laser-like focus. You are going to need that focus as your whole organization tries to derail the initiative.
Override the smart guy in the room
This may sound like a recipe for failure. It’s not. The smart guy in the room is the person who, while you are trying to get something done, will dream up all manner of complicated scenarios that he or she perceives will be ‘absolutely essential’ for any successful system to have. This is an easy trap to fall into. The arguments made for ever more complexity will be intelligent and reasonable. The motivation for this behavior is complex and varied. Let’s just say that your smart guy is either really smart, or good at promoting the status-quo while appearing to be on board with change.
To override the ‘smart guy’, you must deliver these messages over and over and over:
- Phase 1 is the minimum acceptable improvement. Phase 1 is the beginning, not the end.
- Phase 1 is the proof of concept – we have to prove that we can do something simple before we can do something complex.
- We are designing for the masses, not for the exceptions.
When objectiions or needs outside of the scope of Phase 1 are presented, ask questions like, "what percentage of time does that particular circumstance occur right now?" or "how are we handling that right now?" There are times when a real need must be addressed through added complexity. However, if exceptions occur less than 5% of the time, affect less than 5% of the people, or worse… have never happened, throw them out or put them in a subsequent iteration. Remember, the goal is to bring about change in simple digestable chunks.
Communicate, Commit, and Club
With your developed plan for what Phase 1 success looks like, you need to remind your team why this project is happening in the first place, what the problems are that need to be solved, and how this solution will ultimately address them. You need to be very clear that even though there is a big vision ahead, you’re not attempting to address every need at once.
Commit the team to proving incremental success with Phase 1. Explain clearly what the expectations are for all people affected by this implementation. Remind them again that everybody agreed to solving a problem a certain way and now change is required to start down the path of solving that problem.
You still need someone with enough clout to impose the change on all involved parties. This may come in the form of rewards, pleasant reminders, or an assurance that an executive is looking at the new system on a regular basis. Eventually you need to be prepared to reject anything that falls outside of the new process (this is the club).
With @task, I see the most successful organizations closely following these principles as they implement our project management software. Does this work for you? I invite you to sound in on your observations of successful software rollouts.