© Conrad Weisert, Information Disciplines, Inc., April 2, 2004
NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.
(IDI's Issue of the Month for April, 2004)
Almost all medium- and large-scale software development organizatons used to designate explicit responsibility for methodology development, dissemination, integration, and support. They would designate explicit responsibility for those functions under a "Methodology Administrator", a "Director of Standards and Practices", or sometimes a representative committee.
More recently, due partly to the work of the Software Engineering Institute, the older terms "methodology" and "standards" have been replaced by "process improvement" or "capability maturity".
I used to advise clients that the function, whatever they choose to call it, is self-justifying. Except under the most extreme bureacratic approach the modest cost of methodology infrastructure is amply repaid in a short time. Furthermore, there's a huge multiplier on the benefits. Even if a particular convention or guideline yields only a 3% improvement in productivity or quality, that 3% will be realized by almost all projects in the organization, current and future.
Once you accept that, it follows that process improvement administration should be the last thing an organization cuts when budgets are tight. You want your best people contributing globally to all projects rather than to just one or two projects. Under a participative approach all professional staff members have the opportunity to contribute to process improvement as a by-product of their project-specific work.
Contrary to that principle, in-house methodology infrastructure is being scrapped in one organization after another. It's been a long time since I last saw a recruiting ad or listed job opening for a specialist in methodology administration, process improvement, ongoing professional education, or (except for software testing) quality assurance. .
What accounts for the change? Why are software development organizations abandoning what used to be their most vital functions? Evidence points to multiple managerial causes:
The above analysis sounds awfully bleak, especially for those of us who believe that solid methodology infrastructure is essential to manageable development of either application systems or software products. Fortunately, a few indications suggest that the pendulum may be swinging back. I gave several hopeful presentations to that effect a couple of years ago, which turned out to be premature.
I wonder now whether the time has come. Are high-level managers feeling the pressures from ISO-9000 and SEI assessments? Does an organization feel sufficiently embarrassed by learning that its software development functions are a Capability Maturity Level Zero that it will take decisive action?
I'll leave the answers for a later article. Meanwhile, send me your opinions and tell me about your recent experiences, good and bad, with methodology or process improvement infrastructure.
Last modified April 3, 2004
Return to IDI home page
Return to Management articles