Page 233 -
P. 233

someone has an objection, make sure that he feels that you are taking that objection seri-
                          ously. It is easy to get frustrated with disagreement; try to find ways to help the people
                          who disagree with you, rather than simply ignoring or going around them. If someone
                          disagrees with you, it may be that he sees that there is a more important problem that you
                          should be concentrating on instead. Show each person that you are trying to keep his best
                          interests in mind. Try to learn what his biggest problems are and work to solve them.
                          Use a Pilot Project to Build a Track Record

                          The best way to build credibility in your organization is to show a real track record of past
                          success. Running a pilot project is an effective way to build a track record.

                          A pilot project is simply a project that you have selected on which you will test specific
                          changes before rolling them out to the rest of the organization. Before running a pilot
                          project, make sure that the changes that you want to implement are limited in scope.
                          Making more than a small number of changes at a time is usually difficult to manage.

                          Choose pilot projects carefully. You will want to select ones that will have a visible effect but
                          carry little risk. Some tools and techniques are easier to implement than others—choose the
                          “low-hanging fruit” by selecting the changes that you feel are most likely to succeed.

                          The best pilot projects are ones that are likely to succeed. A good candidate project might
                          involve problems similar to ones that the team has solved in the past. It should use tech-
                          nology the team is already familiar with. Avoid projects that have a higher risk of failure,
                          such as ones that implement new technology or involve new, unproven team members.
                          Even if a pilot project fails for a reason that has nothing to do with the change being
                          piloted, there is a chance that your change will be blamed for its failure.
                          During the pilot project, keep careful records of any project problems or issues. Keep
                          senior management in the loop for any serious problems—if it looks like the change is
                          causing the team to miss a goal, it is better that the news come from you, and that it come
                          as early as possible. It is helpful to adopt a scientific attitude toward the project: treat it as
                          an experiment (preferably one with a high likelihood of success), and be as objective as
                          possible about the outcome.

                          If your pilot project is successful, you now have a valuable publicity tool for your change. It
                          is no longer “theoretical,” because it was successful in the organization. And it’s much less
                          likely to be seen as “risky,” because the change has shown to be successful on a project.

                          However, it is important to keep in mind that a pilot project is not necessarily a cure for an
                          organization that resists change. The very characteristics that make a project a good candi-
                          date for a pilot can also cause it to be vulnerable to criticism. By selecting a project that is
                          smaller in scale and less important than most other projects in the organization, you invite
                          criticism that the tools and techniques you are piloting might work in a small and low-
                          pressure environment, but would fall apart under more difficult conditions. They may
                          claim that the new tools and techniques would never work for more difficult projects in
                          which users, stakeholders, and clients are putting pressure on the programmers, when



                                                                                   UNDERSTANDING CHANGE  225
   228   229   230   231   232   233   234   235   236   237   238