Section 9.2. How to Make Change Succeed

9.2. How to Make Change Succeed

Progress comes not just from making changes, but from making smart changes. However, it is often difficult to tell the differenceand no organization should be entirely comfortable with change. It's often difficult to tell the difference between a real, substantive change for the better and a management fad that will cost time and effort, but yield little or no reward. Using the techniques in this section can help you demonstrate to the people in your organization that the practices you want to implement are appropriate, and help you to get your proposed changes accepted by the project team and the organization's managers.

However, while these techniques are useful and proven, they are not cure-alls. It's possible to run across organizational problems or roadblocks that are beyond your ability to fix (for example, there may not be enough money to hire a test team). The Achilles' heel of the approach to improving organizations that's described in the first part of this book is that there are people who will resist change for irrational and emotional reasons, and, if they have more power than you in your organization, you simply may not be able to make the changes that your projects need.

You can't stop people from being averse to change, and you can't always stop them from shooting down your ideas. Even if your ideas make perfect sense, you may still be unable to implement them simply because there is someone above you in your organization who feels uncomfortable with your proposed changes. However, if you are creative, forgiving, and flexible, the most daunting organizational problems can be addressed and sometimes even overcome.

One important element for successful change is understanding how the people in your organization think about and react to changes. Good planning, along with some understanding of the psychology of the people affected, will help convince people to accept them. By understanding the ways people think about and react to change, and by applying certain techniques that may make them more comfortable with the changes, you can improve your chances at successfully changing your organization.

9.2.1. Prepare Your Organization

Before you can begin to implement changes, you need to deal with the attitudes that will cause people to reject those changes. It's up to you to figure out your organization's culture. Try to feel out the sorts of arguments that you will run into, in order to get a feel for your audience. Then you can tailor your pitch for changeand it really is a sales pitch in many waysto your organization.

There are several possible strategies that you might use to "sell" your change to the people in your organization, depending on the environment in which you are working. Here are a few that have been effective in the past. There's no single solution to any of the problems in the previous section, thoughyou will have to use your own judgement to figure out an approach that will work with the people in your organization. With luck, you can start to combat the poisonous attitudes in your organization that would stand in the way. Of course, even after all of this, there's no absolute guarantee that you will actually be able to change your organizationbut at least now you have a better shot.

9.2.1.1. "We've always done it like this"

Organizations uncomfortable with any kind of change are the hardest to deal with. In this situation, it often makes sense to make it appear as though the change you are making isn't a change at all. Pitch the effort as preserving the status quo: "We've always built software like this; now we're just writing down the best practice so we apply it consistently."

This is especially helpful in growing organizations, where you can talk about a need to write down how things are done already, in order to help new people adjust to the environment. It's important to remember that people have a need for consistencywhen your actions are aligned with past projects, it's much easier to persuade others in your organization.

This strategy can also be pitched as a training program. All organizations must train people, so it's possible to pitch your improvement effort as a way to bring them up to speed by writing down how things are done.

Keep in mind that this approach is not completely honestyou're trying to pretend that a change is the same as the status quo, and may be taking advantage of the fact that few people in your organization have sufficient understanding of how software is developed in their own organization to see the difference. But this approach can often buy you enough time to get people used to some of the changes that you want to make.

9.2.1.2. Be positive about the work that's already being done

When people are in denial about the need for change, it is often because they need to see themselves as successful and do not want to admit that their past projects have been less-than-perfect. Use this feeling to help you implement your change by praising the work that's been done in the past, and positioning the change as a way to build on those past successes. Keep your tone positive when talking to people about the need for change.

Find examples in past projects of things that went well that support your changes. For example, you may have had a positive meeting at the outset of a project generally viewed as a success in which the team dealt with scope issues. This can be the kernel of justification for an effort to build a vision and scope document for a future project.

If anyone in your organization has ever discussed the sorts of things that you are proposing, you'll be in better shape. You can use these people to help you make your case by showing them that you are building on their ideas. This can help you build consensus among the project team and in the organization.

9.2.1.3. Take credit for the changes

It usually helps to show that the changes you are proposing have worked in other organizations. But if your organization suffers from NIH syndrome, this approach could be damaging. It's counterintuitive, but it may make sense for you to act like you thought of the changes yourself.

Don't talk about the changes as a process improvement effort that standardizes the way you build software. Instead, step away from the big picture and concentrate on solving individual problems. Justify the changes as if they are solely in response to specific problems in your organization, and not as tools that are standard across the industry.

Some people are understandably uncomfortable taking credit for the ideas of others. But while you may not have come up with the idea of a vision and scope document or a project plan yourself, you did have the idea of applying it to a specific project in your organization.

This may seem manipulative (although that's not necessarily a bad thing). But it doesn't have to be. A project manager can help the whole team take credit for changes as a way to motivate them and help them move forward. This is especially useful when combined with being positive about the work that's already been done. A project manager might say something like, "Folks, we've done a great job with these first five work items. I'm very proud of what you've done. But I'm convinced these next three are different in nature from those five and we need to approach them differently than we have in the past. Here's how...." It doesn't matter that the proposed change is a tool or technique from a book; it can still be pitched as a change that builds on the work the team has already done.

9.2.1.4. Make the changes seem straightforward

When someone feels that a tool or technique is "too theoretical," what he is really saying is that he's never heard of it before, doesn't fully understand it, and can't immediately imagine an actual situation in which it would work. He typically talks about the "real world," and he may feel like you don't necessarily live in that world, if you're proposing a change that has not been directly borne out by his experience.

Be careful in this situation. Consider someone who has been in the industry for a long time, but has not come into contact with these ideas before. It's likely that he has seen countless projects fail, and has come to grips withand possibly built his career aroundthe idea that a lot of projects simply go wrong. By telling him that there is a straightforward way to fix this problem, you are challenging a fundamental assumption in his career. He will rightfully take that personally, and you must take his feelings into account.

If this person is senior to you in your organization, this also becomes an issue of credibility. If you put yourself in the position where you are questioning the experience of someone senior to you, he will want to know where your credibility comes from. It's a mistake to say that your credibility comes from doing research; a better approach is to look for corroboration from within your organization and your projects to prove that your ideas are valid. The best way to handle this situation is to build consensus among your peers. It's much easier to have this conversation with a senior manager when your credibility is already validated by the people around you, and when it's clear that the organization's culture is ready for the change.

Another way to approach this situation is to pitch the changes you want to implement as technical tools, rather than as core software engineering concepts. Most people who have been in the field for a long time are used to routinely applying new technical tools that have never been tested in the organization. This is also a good way to gain consensus among the programming team for your ideas.

9.2.1.5. Build support from the team

If you can bring the programming team on board, you have a much better chance of convincing the rest of the organization to follow. In most organizations, people who do not have technical skills often defer to the programmers any time there is a disagreement. If the programming manager in your organization is on board with the improvements, he can pitch an improvement as a technical change instead of a more general, far-reaching process change. Once the programmers start demanding changes, they usually get their way.

There are a lot of project problems that the team is very aware of. When the scope creeps, the programmers have to tear down code they previously built and replace it with code that is patched together and not built as well as they would like. The programmers would much rather fix a bug before a client sees it. Poorly defined requirements lead to changes and frustration. All of these problems are exactly the ones that you are trying to fix.

Show the team that you are working to help them. For example, using Wideband Delphi estimation and building a project schedule may seem needlessly "bureaucratic" to themuntil you show them how it will help them avoid working overtime later on in the project. By showing that there are clear benefits to what you are doing or suggesting, you can avoid some of the knee-jerk reactions from your team against your changes, and instead get them on board.

9.2.1.6. Show that the changes will save time and effort

When someone talks about a change adding too much bureaucracy, what she usually means is that it takes time and effort that she is not used to spending. This is where an explicit justification is necessary. That justification is not about showing them charts, graphs, or numbers; rather, your goal should be to show how you are working to reduce the overall effort required for the team to build the software.

People do not want to come to meetings unless those meetings are proven to work. You need to convince them that for every hour they spend in a meeting, they are shaving off at least an hour at the end of the project. It's not hard to make an intuitive case for this, as long as you tailor it to each individual person that you are talking to. Explain the impact of the problems on each person's work, and show how the tool will reduce that impact.

For example, if a technical support manager is balking at attending inspection meetings, point out that you are trying to get more defects out of the software so she'll have to deal with fewer support calls about them. Programmers are often concerned with scope creep because it requires tedious and unnecessary rework; show them how a vision and scope document or use cases will help to reduce the time spent on rework.

9.2.1.7. Work around stragglers

There are some people who simply cannot be convinced that a change is worthwhile. They resent being given any extra work. They may even be against the entire project for entirely selfish reasons. For example, it's not unheard of for a programmer who is highly skilled with a particular platform or technology to sabotage efforts to migrate the software to an entirely different platform, simply to protect his expertise. Some stragglers don't even look like stragglersthey may be "heroes" who are used to waiting until there is an emergency before jumping in and saving the day. But whatever the reason, if someone is firmly against your changes, you are not going to be able to bring them on boardat least not by yourself and not now.

Before working around a straggler, see if you can bring him around. One good way to do this is to have a respected team member talk to a straggler so that, instead of ignoring or working around him, you're putting him in a situation in which he can learn to be more productive. Unfortunately, not all people will be convinced, even by those they respect.

The way to handle stragglers who refuse to adopt your changes is to work around them. Build consensus among everyone else on your level in the organization. Don't worry too much about people who oppose you for reasons that can't be dealt with: if your changes eventually become part of the organizational culture, they will either come on board or leave on their own.

Again, the idea of consistency is very important in this situation. If someone takes a public stand on an issue, she feels an enormous psychological need to remain consistent with that opinion. This means that if you push someone who is initially opposed to your ideas, she will feel pressured to fight harder and harder against you: the more she argues against the change, the less she feels like she is "allowed" to change her mind without losing face. On the other hand, if you leave her alone initially, you give her an environment where it could be much easier for her to come around later.

You can also use consistency in a positive way. It is very important that you have gained a real (and written, if possible!) commitment from the people around you before you try to pitch your change upward. Not only will this help you show senior management that you have real support, but it will also help people to stay committed, because they feel the need to remain consistent with their past decisions.

It is important not to go to senior management too early. If you do, you are essentially going over the heads of everyone around you who has not already committed to your change. This is counterintuitive: you have a solid case for change, and you know that you can convince your boss to make it, so why not just go there first?

The problem is that the ideas you are pitching are very powerful and often very convincing. It is often possible to implement wide-reaching changes that affect many people in your organization without actually involving them at all, simply by going over their heads. The minute that one of those people sees additional work that you have managed to get assigned to him without first asking him, he will turn against the change. Had you given him a chance to come on board first, he probably would have seen the benefits and supported you; now he's working against you, simply because you backed him into a corner.

This isn't about the personal aspects of them supporting or not supporting you. If the changes that you are making are good ones that will increase productivity, then people will probably jump on your bandwagon once they recognize the value of the changes. Everybody wants to be part of a winning team, and the key is to make it easy for them to join your team. If people have an adverse reaction to what you are saying, let it gothey'll come around later.

Once you have a real consensus, you can go to senior management. It will be clear to them that the entire culture is asking for this. One of the most important principles of organizational change is that changes do not stay in place without support from senior management.

9.2.1.8. Stick to the facts

People respond well to someone who speaks directly to them and who does not have any hidden agendas. Be clear about your motives; make sure that you talk about the costs as well as the benefits of any change that you suggest. You must make an effort to understand your audience: being a straight-talker to a sales manager is much different than being one to a programmer, so you need to really think about who you are presenting these ideas to before you do it. Learn their perspectives and frame your arguments in ways that are interesting to them. Another important part of being a straight-talker is having a solid grasp on the ideas behind the changes that you are making. If you really understand them, then you can put the ideas into terms that anyone else can understand.

"It's too risky" can be the best possible objection that you can hear. It means that the people you are talking to are listening, thinking about implementing the change, and coming up with ways that it could go wrong. They are really thinking about what it would take to do what you are suggesting. This means that they can be convinced with facts, not just persuaded with emotions and politics.

In a situation like that, you can get approval to start a pilot project, and show the benefits of changes on that pilot. You can present research that shows that the changes you want to make are accepted industry standards. You could get approval to study the problems that exist in the organization, and plan an improvement project to come up with an answer to those problems. You can figure out how much the projects cost in terms of time and effort, and show how your changes will reduce those numbers. And, most importantly, you can show how it's even riskier to keep things the way they are. That's a productive conversation any way you look at it, because you'll come out of it with a list of problems that you need to address with your improvement effort.

(Unfortunately, "It's too risky" can also be the worst possible objection that you can hear. It could mean the person you are talking to has shut you out, and is no longer listening. When this happens, you can't make any more progress from this angle.)

9.2.2. Plan for Change

Once you have made some headway in overcoming resistance, the most important way to ensure the success of your change in your organization is to plan for the change. Planning for a change is similar to planning for a software project, in that the scope must be defined and tasks need to be assigned to people who will carry them out. By treating a change to your organization like its own project, you can use the same planning tools as you would for a software project.

There is a fundamental difference between a project to change an organization and a project to build software: the bulk of the effort in a software project is devoted to building work products, while the effort in changing an organization is focused on training (or retraining) the people who will then turn around and build the software differently. But in both cases, the scope should be written down and agreed to, and the resources assigned and trained.

9.2.2.1. Create a vision and scope document

The way to make a successful change is to ensure that the problem you are solving is the most important one that the organization faces. Before people in your organization will accept a change, they must be convinced that the change is necessary. To an eager project manager who wants to implement new tools and techniques, this can be a frustrating situation. But it's actually a good thingif people are too willing to accept changes to the way they do their work, then any changes you make will quickly be replaced with the next popular idea to come along.

In Chapter 2, the vision and scope document was introduced as an important planning tool that helps ensure that each of the project's features addresses a specific user or stakeholder need. Each person's needs are written down, and each of the planned features is tied back to one of those needs. The document is then reviewed by everyone who will be affected by the project, to ensure that all of their needs and concerns are met.

A vision and scope document can also be used to plan a change to the organization. Table 9-1 shows a typical outline for a vision and scope document.

Table 9-1. Vision and scope document outline for a change project
Problem Statement Project background Stakeholders People affected Risks Assumptions Vision of the Solution Vision statement List of changes Changes that will not be implemented

This document is developed in exactly the same way as described in Chapter 2. The stakeholders are identified, their needs elicited, and the scope of the change is defined.

There are just a few differences between this outline and the one for a software project:

Instead of a "Users" section, there is a "People affected" section. This section describes the specific people in the organization who will have to change the way they do their jobs. This is the first important reality check for a project manager attempting to make changes. It is very easy to think about changes in abstract terms, forgetting that real people will have to change the way they work. It's even easier to gloss over the fact that people will be affected when you're selling the change. This section helps everyone be clear on who is affected from the very beginning. Listing the affected people in the document also ensures that they are included when it is reviewed, which allows them to have a say in how they do their jobs.
Instead of listing features that will or won't be implemented, this vision and scope document lists changes that will be implemented. Each of the changes in the "List of changes" section should include a full explanation of exactly what changes will be made. For example, if use cases are to be implemented, include the use case template that will be used and a description of any elicitation tasks and other tasks that will be performed in order to create them, as well as any additional resources that will be needed.
There is no "Scope of phased release" section. If the changes need to take place in a certain order, that should be incorporated into the description of each individual change.

Writing a vision and scope document before making the actual changes allows the project manager to gather evidence that those changes will address real problems in the organization. It is important to point out specific instances that other people will agree are problems. A successful vision and scope document will show everyone in the organization that there is a real, troubling problem. If you only include real evidence in the document, an objective reader will see that there is a serious problemand by proposing a change that will fix it, you can throw them a rope by offering a real solution.

9.2.2.2. Inspect the vision and scope document

Once the document is written, it should be reviewed by all stakeholders and everyone in the organization who will be affected (see Chapter 5). This will accomplish several things. It will make sure that the changes you are proposing really solve the problems that they are supposed to solve, because they will be documented as needs in the "People affected" section. But more importantly, it will ensure that the change is communicated to everyone who needs to see itand by incorporating their feedback, you will help gather consensus among them.

This is a check both for you and the other people who this affects. It is important for them to see that your changes will help them. But it is also important for you to choose the changes that will do the most good in the organization. It is much easier to propose an unnecessary change in a meeting than it is to do it in writing. By writing down the rationale for all of the changes, you can make sure that people see that there are real problems to be solved, and that you are proposing solutions to those problems.

The reason it is important to write down the rationale for each change is that it is tempting to try to "fix" a problem that doesn't really exist, simply because the change is easy to implement. Many people decide to make a change or implement a certain practice, and then "find" problems to justify it. (In much the same way, if you lose your keys in the dark, it's easier to search for them under a streetlight because it's easier to see.) By identifying the rationale for each change, you can find the real problems that need to be fixed. This helps you prioritize your changes, in order to address those problems that hurt the most.

The audience for the review should be as large as possible, to ensure that everyone who is affected by the change sees that it is coming. The review will give them ample opportunity to give their input. People are less likely to react irrationally to a change if they are given a chance to give input when it is proposed. Most importantly, since everyone who is in a position to object can be included in the review, you can get those objections out in the open early. That way, you can address their objections early on. Many people object to changes simply because they were blindsided; by asking for their input before the change is implemented, you can avoid that problem. Once the vision and scope document is approved, it is much less likely that there will be surprises later on.

9.2.2.3. Schedule the changes

Once the team has approved the scope of the changes that will be made, it is time to implement those changes. By updating the project schedule to include those changes, you can make it more likely that they will actually be carried out on the project.

Building changes into the project schedule is an effective way to "seal them in" to guarantee that they actually happen. Many changes unravel because while everyone agrees that they are a good idea, they never actually make it into practice. By adding tasks to the project schedule that reflect the change, you ensure that time and resources are dedicated to implementing it. You also help the team members see that the change is coming, and give them time to plan for it.

It's also important to allocate time for training. You may understand the details of the new tools and techniques, but many of the people on the project do not have that advantage. Make sure to include meetings to introduce the team members to the new practices. If additional training sessions are necessary, schedule them as well. Plan to give the other people in your organization the time they need to learn how to use the new tools and techniques. This may mean adding time to tasks that will be done differently than in the past, due to the changes. (Allow time for a learning curvepeople will not be as efficient at using the new tools and techniques initially as you hope they will become after some practice.)

For example, if you are implementing code reviews, you should add training and review meetings to the schedule. You should also extend the programming tasks, in order to allow the programmers time to make changes found during the review. When the schedule acknowledges that additional time should be spent on these tasks, the programmers are much more likely to actually perform the code review tasks.

Note: A more detailed process for scoping and planning an improvement project is described in Making Process Improvement Work by Neil Potter and Mary Sakry (Addison Wesley, 2002).

9.2.3. Push for Consensus

It's difficult to change an organization alone. It is much easier to make a change if you have the support of others in your organization. Identifying potential allies is an important step in changing an organization. The most effective way to change an organization is to build consensus within your project team, among your peers, and up through the management chain.

People will be more positive about your change when they see that other people are already on board with it. If you can recruit early supporters, it will be easier to bring other people around to your way of thought. The best way to convince someone to make that investment is to show that there is already a consensus among the software experts in the organization.

The first step in generating consensus is to find people who also recognize the problem that you are trying to solve. This should not be hardif your organization's problem is serious enough to warrant a change, there will probably be other people around who have noticed this problem as well. Put aside for now the fact that people may not believe you have a real solution; it's sufficient to start with a basic agreement that there is a problem.

Many people feel that change should either be "top-down" (meaning that the changes originate from management) or "bottom-up" (meaning that they originate from the team). However, while it is absolutely critical that you have the support of your organization's senior management before implementing a change (unless it is for a change that affects only your project), there is no need to make this decision while still generating consensus. If you can convince a senior manager that there is a real problem and that you have a solution, that person will be a very valuable ally. But it's also important to convince people who are on your level in the organization. To many senior managers, the most convincing argument is that several people who report to him agree on something. This is why it is especially useful to get multiple people on different levels of the organization to agree that your changes will improve the way software is built.

Once you have found people who recognize that there is a problem, you can work to show them that you have a solution. An effective way to convince people to join your effort is to show them that you are not just suggesting change because you don't like the way things are done: you are also helping them with problems that they wish would be solved. Most people are never really asked if they are having trouble. Take the time to listen to each person's complaints. If you can show someone that her problems are not her fault but, rather, could be attributed to something external (like a lack of planning or change control), she will be much more open to your solutions.

It's not enough just to find people on the team who are willing to talk about their problems. There are many people who just love to complain about work. It's easy enough to get people like this to talk about what's wrong, and even to acknowledge that there are endemic problems. But once it comes time to make real changes, someone who has not really bought into your solution may disappear from your effort at the first sign of resistance. Also, beware of people who come around too easilyit may be that they are simply easily swayed, and will abandon your effort for the next big idea that comes along.

Gathering allies is also a good reality check for your change effort. If you cannot convince even a small number of people that there is a real problem to be solved, and that your proposed change will solve it, then that is a good indicator that you will run into serious problems when attempting to sell your changes to the rest of the organization.

Give yourself a lot of time to do this. Organizations do not change overnight, and consensus is not generated with a single meeting. It is important not to steamroll anyone. If someone has an objection, make sure that he feels that you are taking that objection seriously. 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.

9.2.4. 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 otherschoose 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 technology 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 problemsif 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 candidate 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 there are deadlines, and where the projects are much bigger. And they are not necessarily wrongyou have not stress-tested your changes. Just because a change is successful in the least risky environment possible doesn't mean that it will be successful in the rest of the organization. That's not to say that the pilot project is not an important tool; it simply has its limits.

Note: More information on piloting changes can be found in The Art of Project Management by Scott Berkun (O'Reilly, 2005).

9.2.5. Measure Your Progress

Measuring your improvements is a critical part of changing the way your organization builds software. Measurements provide a way to track progress, as well as a way to communicate this progress to senior management and the rest of the organization.

There are two important ways that most project managers want to improve their projects. They want their projects to cost less, and they want fewer defects in the final product. Showing improvement in both cost and quality provides powerful evidence that the changes you have made are working.

9.2.5.1. Measuring cost

The most common criticism that project managers receive when trying to improve the way they build software is that the new procedures and changes cost too much. Therefore, an astute project manager will gather the actual number of hours that the changes cost. This information should be gathered during a pilot project and any other time changes are implemented.

Every activity that you have inserted into the development process in order to build better software should be measured in terms of time and effort. You can track this information in a spreadsheet (see Figure 9-1).

Figure 9-1. Spreadsheet to measure the cost of improvements

Each activity performed over the course of this project is measured in terms of the total calendar time that elapsed while the activity was performed ("Hours"), the number of people involved ("People"), and the total number of person-hours (see Chapter 4) that were expended in both preparing for and performing the activity ("Effort"). In addition, the week, activity name, and participants are listed. This is not a difficult spreadsheet to maintainin the example above, the project manager only had to add one to three lines per week to the spreadsheetbut it is very useful for showing that the benefits of the changes were worth their costs.

This information is easy to gather, and it will be valuable when it comes time to judge whether the benefits of the improvements were worth the cost. You can put the cost of the improvement in context by using the project schedule (see Chapter 4and if you do not have a project schedule yet, it is more valuable to build and maintain one than it is to gather this data!). From the schedule, you can find the calendar time elapsed over the course of the project, and the amount of effort performed over the course of the entire software project.

One goal is to show that the effort required for the improvements is relatively small. By adding up the effort in the spreadsheet and dividing by the total effort in the schedule, you can calculate the percentage of the effort that your improvements cost. Many of the tools and techniquesespecially ones that are typically labeled "bureaucratic," such as inspections, code reviews, and developing a vision and scope documentrequire a very small percentage of the project's effort. And it is often not hard to point to specific results (like problems that were avoided by developing the vision and scope document, or defects that were found during an inspection or code review) that, had the tasks not been performed, would have clearly cost more time than they saved.

Another goal is to show that even though the improvements took time and effort, they did not add calendar time to the schedule (since the final due date was not delayed). This is not hard to do, if your organization has done another project of similar size or complexity in the past and you know how long that project took to build. If the tools and techniques were effective, that project should have taken more calendar time than your project. Subtract the total number of hours required to build the current project from the total number of hours required to build the similar project. If this result is much greater than the number of hours spent on the improvements, it shows that the improvements saved more time than they cost. (The earned value metrics in Chapter 4 are also helpful when comparing two projects.

In addition to comparing projects, you can also compare tasks within a project. You can compare the hours or effort required for a specific task with the benefits of that task. For example, if another project in your organization took 3 months (13 calendar weeks, or 520 hours) developing a feature that eventually had to be scrapped because it did not meet the needs of the users, you can show that far fewer than 520 hours would have been needed to develop and inspect a vision and scope document that could have prevented the wasted effort.

9.2.5.2. Measuring quality

One straightforward way to measure the quality of the software is to measure the total time and effort required to test the software. This metric covers all of the effort expended, from the time that the programmers deliver an alpha build that they consider complete to the time that the test activities yield results that the senior managers agree are acceptable for release (see Chapter 8 about the release readiness process). This measurement should include not only the testing activities, but also any work programmers do to fix defects that are found. If the testing team finds requirements or scope defects, this number should also take into account time and effort spent on activities performed by the project manager, requirements analysts, stakeholders, users, and anyone else involved in fixing that defect.

Any tools and techniques that you put in place in order to improve the way software is built should reduce the time and effort required to test the software. To use this measurement, use the schedule to figure out both the calendar time and the effort required to test the software as a percentage of the total calendar time or effort required for the entire project. You can then compare these numbers to other projects of similar complexity. If these numbers decrease over the course of several projects, your improvements are working. In many cases, the change will also lead to fewer delivered defects (but it can take a while to observe that effect).

It is important to select projects for comparison that match the current one in complexity. This means that the comparison projects should use similar technology, require similar expertise from the team, and preferably use many of the same team members. This works especially well when comparing maintenance releases of a single software project.

9.2.6. Bring In an Expert

Sometimes the best way to make sure that your changes are implemented effectively is to bring in an expert. There are many consultants who will assist in improvement efforts and train your organization to implement the tools introduced in this book. Sometimes, corroborating your improvement initiatives with an expert's opinions is just what people in your organization need, to feel reassured that the ideas have merit.

Experts and consultants are especially helpful in training people in a wide range of specific techniques, including estimation, inspections, code reviews, unit testing, and project planning practices. They can also be pivotal in helping to establish metrics, testing, or requirements efforts. What's more, there are many pitfalls that inexperienced project managers and organizations can fall into: experts can identify these pitfalls and help you avoid them. In this way, bringing in a consultant or expert can more than pay for itself.

Perhaps most importantly, experts' training sessions are morale boostersthere is little that can get a team more excited about a new technique than training them all at the same time on it. Everyone feels like they have a common understanding, and the culture changes to accept that idea much more quickly than it would have, had it only been introduced by someone internally.

Don't be afraid to go outside of your own organization to get training. Some project managers are tempted to develop their own training programs, but they often underestimate the effort involved. Doing it right is extremely time consuming, and it's likely that you won't do nearly as good a job as someone who has used and refined his training many times. In addition, you'd be reinventing the wheeljust like programmers with NIH syndrome do with regard to new practices.

When an improvement effort seems to lose some steam, an effective way to get it back on track and renew the organizational commitment is to engage in group training about process improvement techniques, and raise general awareness about your efforts. Hearing from an outside authority figure that you are on the right track can be enough to gain support from those who might not have agreed with you in the past.

When you bring an outside expert into your organization, the fact that this person is paid to give advice will cause many people to treat this person as an authority figure. People naturally defer to an authority. In many organizations, bringing in an expert will cause people to change their minds, even if that person is saying the same thing you already said. Even if you are in an organization with NIH syndrome, bringing in an outside expert or a consultant can help bring people around. By hiring an expert, the organization already has committed to listening to the person. The expert's advice can immediately become "how things are done here," because money has been authorized and spent on the expert. Once money has been spent to obtain an expert opinion, people are much more likely to take suggestions for change seriously.

Note: More ideas on organizational change can be found in Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister (Dorset House, 1999). Information on the psychology of influence, attitudes, and persuasion can be found in Influence: Science and Practice by Robert Cialdini (Allyn and Bacon, 2001).