On 15 Aug 97 Joe Podolsky wrote one of his wonderful jottings in LO14692.
Several responses to Joe's Jotting were included in LO14702, LO14707 and
LO14726.
Joe wrote:
>The responsibility for credibility, good or bad, is ours, not the
>customers'. Credibility is a matter >of perception. Credibility is in
>the eyes of the beholders, our customers and users.
This conclusion, which accurately reflects the Sloan article, makes me
feel uncomfortable. It seems very reductionist - is any "responsibility"
in a complex system like the IT / Senior Management / Business Client
triad be the "responsibility" of only one party? For example, if the
business user works in a very transactional culture, that
get-it-done-today is likely to collide with the more reasoned, project
management oriented, culture of a well run IT group. How often have you
seen development managers deliver a product that is 80% finished, poorly
tested and poorly documented, because they wanted to delight the customer
who is pushing hard for a system needed in his or her transactional world.
Now, we all know that eliminating errors early is much less costly, that
thorough systems testing will help avoid nasty performance and stability
surprises and that sufficient documentation will ease the pain of support
and enable the development team to handoff support to the Service Group
earlier and more smoothly.
In IT shops that practice very close developer / client relationships, the
result can be very expensive. As more and more low quality, high
maintenance applications are rapidly delivered to delight "the" customer,
a complex dynamic emerges. Business users have demand for IT resources,
but to continue to meet their needs, they must constantly hire more and
more programs. Of course, all that hiring feeds back negatively to
productivity and to quality. Eventually, Senior Management of the firm is
likely to step in when IT costs exceed the local benchmark (e.g., % of
revenues). Why are more programmers always required? Well, first, they
are still working on finishing the last delivery.
In fact, we have experienced a phenomena that Ken Cooper of Pugh-Roberts
calls the lost year. The project is reported to be 90% completed, then
seems to hang at 90% for as much as a year or more. Dynamics models
usually show that the "lost year" is tied to continuing to a) discover
work that was not specified or considered in sizing, and b) to ongoing
discovery of rework (which can equal as much as the full project
estimation!). If something is not done about the quality issue, fewer and
fewer developers are able to work on "new", and instead must constantly
focus on fixing bugs, adding enhancements (frequently, features that were
dropped to get the product out the door). A separate feedback loop
results from the developers inability to turn products over to a separate
support group. The interrupt-driven nature of support is antithetical to
the social stream of consciousness nature of software team development.
Further, turn-over is likely to increase as developers remain responsible
for supporting more and more legacy (in some cases, we estimated as much
as 80% of a developer was actually spent in customer support).
My point is that there is another customer, one that is too often ignored
by everyone in the organization - the Stockholder. The CEO needs to
become a proxy for the stockholder and force a more rational decision on
what quality constitutes "good enough". In transactional businesses,
there are many opportunities with very large revenue potential that may,
in fact, justify sloppy delivery. The Nike way - Just Do IT. However,
where there is strong binding by IT with a transactional culture, the
danger is that all projects will be treated as RAD efforts, without regard
to relative value to the organization.
Don't get me wrong. I like the article, Joe's Jotting and the comments
that Joe forwarded to the list. Building credibility from perceived trust
and perceived technical expertise is spot on. However, the dynamics of
the IT / Business User / Shareholder or CEO dynamic is so strong, they may
overwhelm the issues of credibility. Even after enhancing credibility by
following the many sound pointers in the jotting and the comments, the
external feedback from increasing competition for limited resources may
set back the credibility of IT once again. It is common to hear the
business manager complain about how expensive IT is, even though their
pressure for fast delivery, and the impact on costs, is a significant part
of the system driving higher costs.
Just my thoughts.
-- MikeMichael A. Gort Mail18081@pop.net (203) 637-9279
Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>