Information Technology Reference
In-Depth Information
What Form Must a Measurement Repository Take?
At BOND, the measurement repository became the collection of Manage-
ment briefs across the projects. During the formal appraisal there was an
issue raised about the adequacy of this measurement repository because it
was distributed and wasn't actually a “database.” One of the interviewed
project personnel responded to this issue by stating in his words:
It works better for us this way because we carry the measures forward.
This response I believe hit right at the main issue on how measures were
actually used in the organization to meet the stated objectives.
His point was they were using the measures to make
decisions
every day that
tied back to the objectives as stated in the process. This included
decisions
that
could affect the immediate performance of the project, and
decisions
to
improve the processes currently in use on the project, as well as to help
Senior Management with bigger company-wide
decisions
.
This practical and effective approach can be contrasted to the Measurement
Repository described in the LACM case study in Chapter 3 where the data
collected was disconnected from the real work and therefore not used to help
in making real
decisions
in the organization.
Nothing in the CMMI says your measurement data can't be distributed, nor
does it say what format it needs to take. This is a
decision
each organization
needs to make given its business situation. You can pick the standard mea-
sures you want all projects to report and you can dictate how they are
collected and stored on all projects, or leave some of these
decisions
up to the
project.
In many Agile organizations, I find these decisions are often left up to the
project teams, but as organizations grow, there is benefit in specifying more
common measures and approaches across the projects as LACM did. This
also helps management see consistent data at Senior Management reviews.
As BOND matured, the Senior Managers realized this and increased stan-
dardization of measures across projects.
Agile approaches help us gain more accurate
project-specific measures
because
they involve the team that understands how real projects work. Experience
has shown this can be of great benefit in validating higher-level schedule and
progress assessments. Agile techniques also help in getting the needed com-
mitment from those who must execute the plan. Measures that flow up from
an Agile team tend to be more accurate because they take into consideration
