CM Is a Cost Center, Not a Revenue Center
Let's face it, unless you are a member of a consulting
service or produce CM products for sale, CM will not gain you anything
monetarily. Nothing. Nada. It is not our job to "produce" or to create revenue.
In fact, when CM is present in an organization, they have to devote a
significant amount of direct and indirect fiscal resources to fund CM. Why
would any sane manager do this?
We sputter and try to justify ourselves with ROI and
increased quality of final product. We point to study after study that says a
lack of CM is directly related to many product failures. We use all of the
normal, "Of course we have value to the company!" arguments. We point to
government regulations and process improvement efforts all requiring CM. We point to our historical charter of activities,
"Identification, Control, Status Accounting and Audit." When it all comes down
to budget time, those organizations that "get it" will direct resources to CM and
those that don't, won't.
So what are we really? We are the pain in Management's
side when they try to cut corners. We are paranoid and proud of it. We nit-pick
and make sure everything is done properly. We are the conscience of an
organization.
CM is like Accounting in a lot of ways. Accounting can be
done simply when things are small and grow to more and more complexity as
organizations grow. They start out just making sure the company gets paid what
it is owed and pays what it owes to others in turn. In a timely fashion. Things
get a little more complicated when inventory, regulatory requirements,
licensing, etc. get brought into the Accounting realm.
CM makes sure the proper CIs are used to generate the
final product, that QC receives a controlled copy for testing and that we can
integrate the appropriate third party components into our product consistently
and reliably. CM, along with Accounting, ensure that all expiration dates and licenses
are tracked. CM, along with Legal, ensure that all third party licenses are
compatible with each other and with our products.
CM monitors component changes for unplanned or unexpected
changes. We may or may not be the one responsible for deciding what to do with
them, but you can bet we will be tasked with either doing the "repair" or
monitoring it. We set up automated builds, track both planned and unplanned
changes though the codebase, identify what has changed for use by others in
generating release notes and firewalled regression tests, and last, but not
least, explain what CM is to new hires who don't have a clue.
So why is it so hard to justify CM? We are the Accounting
function of Engineering, so why do we keep having to justify not just our tools
and infrastructure, but ourselves.
Accounting makes sure we get paid for products we sell and/or license. We make
sure the products we produce are available for sale. We are not even alone in
this; Quality has just as hard a battle for funds and resources as CM. So let's
take a step back and look at the big picture.
The diagram shows a representation of the 5 key component
groups within a Development Organization. It shows the relationship between
Development and CM to be much more intimate than with either QA or QC, just as
the relationship between QA and QC is more intimate. Management permeates all
aspects of the organization.
In this diagram, only Development can be considered to be
a Revenue Center; all others, including any not
shown on the diagram, are Cost Centers. This is why Development generally tends
to get the, "What Development wants, Development gets," response when other
groups try to enforce anything that
drops productivity. We all have to keep in mind that the end product is what
pays our salary and benefits. Management worries about Profit and Market Share.
They worry about Competitive Deadlines as the first to market generally holds
an advantage, regardless of quality or feature set. This is why each of the Cost Center
groups must justify themselves in terms of Process Improvement first, Meeting
Customer Expectations a close second and only then in terms of overall quality
improvement. Of course, if a company has been bit by poor quality products
enough in the past, the Customer Expectations (or lack thereof) may make it
much easier to get Quality related justifications looked at seriously.
So what is
the basic Development Process? The second diagram shows the basic process flow
with the same color coding as above. Let's try to expand these somewhat as
bullet points:
- Management determines the basic product needs
and customer expectations.
- Requirements are elicited and documented
describing the details of the product, or the changes needed to the product, in
order to meet needs and expectations. For the sake of simplicity, this is
assumed to occur in the Management sphere, not CM, though CM will be used as
the repository.
- The requirements are reviewed by QA to ensure
they are objective, testable and non-conflicting. This function is occasionally
performed in a Peer Review situation with QA participation.
- Designs are created or modified to meet the
requirements. The Development group will be responsible for this activity,
though once again CM will be used as the repository.
- In parallel with the Design effort, the
appropriate test plans are designed. These take into account the necessity to
track back to the sourcing requirements.
- The designs, both product and test plan, are
reviewed by QA to ensure they implement the requirements. If allowed, they also
ensure that the designs do not exceed the requirements (prevent scope creep).
This function is also occasionally performed in a Peer Review situation with QA
participation.
- Development implements the designs and performs
Unit Tests and Peer Reviews as appropriate. All development artifacts used in
the implementation are considered Configuration Items (CIs) and are versioned
in a CM controlled repository. CM, in the form of Build Management, also
performs the controlled builds of the product that are to be tested by QC and
released by Release Management.
- In parallel with Development, QC implements the
tests necessary to perform the test plans. Depending on Development
Methodology, some testing may be performed in conjunction with Development's
implementation of the product.
- Depending on the implementation period, QA may
perform reviews of the implementation to ensure design compliance and to
prevent scope creep. If the period is short enough, this may be an exit
criterion instead of an on-going activity.
- QC Performs Integration, System (Functional),
End-to-End, Interface (External), Performance and Load Testing as appropriate
for the product. Any defects found are recorded in a Defect/Issue/Enhancement
Tracking (DIET) system whose content is owned jointly by QC and QA, but whose
repository is owned by CM.
- In parallel, and as an exit criterion, QA
reviews both the tests performed by QC and the results obtained from the
execution of those tests. QA, in conjunction with QC, issues the Go/No-go
decision to release the product.
- CM, in the form of Release Management, performs
the actual release of the product to Production.
Note that CM only has one block on the Development Process
Flow diagram, but is referenced repeatedly as a background set of activities in
the bullets. This is one of the reasons CM has to be justified by others,
especially by Development, for it to be taken seriously in many commercial
firms. At first glance, Development can do their own versioning and builds, and
Quality can do everything else. The fact that CM and the repositories "owned"
by CM should last past the life of a product are not things the current product development effort needs
to worry about. This is something only Management and Quality might be
concerned with, and Quality sees it somewhat as a conflict of interest for it
to do the CM functions.
Where does CM really live in the Development Process Flow?
We live "above" it. We pervade it to a large extent. We are, to a large extent,
the process watch dogs and the whistle blowers. We hold tight to the product
assets and assist QA in bringing a halt to bad practices. We are the cops who
just gave you a speeding ticket and are asking for raises, newer and faster
cars and better radar. Organizations with an effective CM program do produce better and faster with an
overall better quality of product in the end. But prove it before the fact? Not
gonna happen - unless there is already a belief that it will.
A Final Note
No keyboards were actually destroyed during the creation of this
article; however one UPS did give up its smoke to the cause. It was
buried by IT with full honors.
Ben Weatherall is currently based in Fort Worth, Texas where
he practices Practical CM on a daily basis using a combination of CVS
and custom tools to support a modified Agile-SCRUM development
methodology. He is a member of IEEE, ASEE (Association of Software
Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), NTLUG
(North Texas Linux Users Group), and PLUG (Phoenix Linux Users Group).
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
