This page is powered by Blogger.





Contacting Us
Mike Tarrani
Linda Zarate
Kate Hartshorn

Who We Are
TEAM Zarate-Tarrani

Our main weblog
Notes from the Field

Our other pages
Mike's home page
Linda's home page
Kate's home page

Simpatico [we]blogs
Dan Gilmore
Robert X. Cringely
Jakob Nielsen
Julian Bond
Deborah Branscum
Lisa Rein
Ed Yourdon


Wednesday, January 23, 2002


As promised, a real-life story with names omitted to protect confidentiality:
The consulting engagement was to meet client requirements for software configuration management. They wanted two sets of deliverables
  1. Assistance in selecting the best SCM package for their organization
  2. Processes and procedures for SCM
The project was not sponsored by the development manager, nor was the development manager enthusiastic about SCM. I was able to get development of change control policies, processes and procedures included in the statement of work.
The following occured:
  • The SCM project was scrapped. This came as no surprise for two reasons: (1) the sponsor had no control over development, so had no hope of implementing processes and tools to support those processes without the full support of the manager in charge of development (not to mention the developers themselves), and (2) the process didn't make sense for an organization that was squarely at CMM level 1.
  • The change control policies, processes and procedures were delivered to the client. However, the sponsor did not appear to have either the initiative, power or leadership abilities (pick one or more reasons) to implement it. Since the sponsor was responsible for issue management and tier-1 support, integrating change control would have been a nice evolutionary step torwards process maturity.
Lessons Learned
  1. Do not undertake a project for a client that you know is doomed to failure. This seems obvious enough, but it's done all the time. A former boss, Don Holman, who is one of the top operational process engineers in IT consulting, once stated that "consultants have to draw the line and refuse to be a party to malicious compliance." I like that term, malicious compliance, because it's exactly what we did to the client. As consultants we should consult, which means being forthright in our opinions of ideas and initiatives hatched by well-meaning clients who have budgets that are larger than the big picture that they sometimes miss. It's our responsibility to say no to half-baked ideas. And some of the goals of this project were half-baked indeed:
    • sponsor didn't have any control over areas or resources critical to the SCM portion of the project's success
    • lack of commitment to change control processes, which was probably due to a lack of appreciation for just how critical those processes were to issue management and RAS (reliability, availability and support)
    • no executive sponsorship - the project sponsor was a mid-level manager in a politically-charged organization
  2. Never attempt to implement a tool until a process is in place. A fool with a tool is still a fool.
Tomorrow I'll dredge up another episode from the past and share it in the hope that someone will be able to use it to bludgeon the pointy-heads out there into submission.