Page 235 -

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
maintain—in the example above, the project manager only had to add one to three lines
per week to the spreadsheet—but 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 4—and 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 techniques—especially ones that are typically labeled “bureaucratic,” such as inspec-
tions, code reviews, and developing a vision and scope document—require 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. Sub-
tract 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 num-
ber 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.

UNDERSTANDING CHANGE 227