This post is really a note that provides words to go along with the PowerPoint slides used in a presentation I am to make at the CIPS Ontario 2005 AGM on Thursday, 2005 September 22. A reduced size version of each slide is embedded in this post. If you would like a copy of the full presentation - Standards of Practice Presentation.

I’ve been involved with software practice standards for several decades. I worked on methodologies back in the 1970s. I was responsible for standards and procedures within the systems department of a Canadian energy firm in the 1980s. In the 1990s and into the 21st century I have worked with clients on the procedures they should follow in connection with software, its acquisition, development, installation, and maintenance. I bring to the subject a considerable amount of baggage. But it has only been in the 21st century that I began to have confidence in the net value of best software practice standards. This talk is offered as a brief introduction to the world of software practice standards.

I have been writing on this broad topic in CompterWorld Canada for several years. All of my columns are listed on my Recent Publications page. Many of them are directly relevant to the material in this presentation.

I already alluded to the fact that we have advanced to the place where it’s practical to consider using the best of the current software practice standards. It’s possible. I believe that it will also be increasingly necessary. Can is being replaced by should and must.

Next on my list of topics are a few words about four standards that are winning increased acceptance in the software world. My top-4 list starts with project management, includes service delivery, recognizes the work on maturity models, and concludes with a governance and control standard.

I go on to provide general information about standards. There are best practices, recommended practices, and eventually required practices. Overall it’s possible to view software practice standards as falling in one of four categories: Governance & Control Standards, Acquisition & Development Standards, Service Delivery and Support Standards, and then a catch-all of Infrastructure Standards used by the other standards.

Professional face a number of challenges. The professional must bridge the gap between a standard designed for an organization and a standard that can be used to guide the work of the professional. Through it all, I’m convinced that IT professionals will be paying increasing attention to standards - they are coming.

I close on an interesting note: standards are the stuff of left brain thinking. That will be necessary for success in the 21st century. The effective professional must also learn about the creative right brain. The whole brain will be required.

There have been a number of attempts to develop the definitive system development methodology. There was a period in the 1980s where there were several competiting methodologies. They cost big bucks, filled an entire bookcase, and were fiercely resisted by actual developers. The overhead was high and the approach was inflexible. Almost all of them ignored the Uncertainty Principle for Systems - users will not be able to determine what they really need until after they begin to use a new system. But all of that is, or should, be in the past. Today’s best practice standards don’t demand high overhead or impose unnecessarily rigid procedures. It can actually make sense to selectively use current practice standards.

I can remember back when Xerox was selling the Ethernet. They ran advertisements where all you had to do was plug your computer into an IT utility outlet, just as you plug into a power utility outlet. It’s taken us a long time to get to the place where it is reasonable to approach IT thought it were a utility service. There are a number of promising approaches. IBM is pushing Service-on-Demand. There is a more general push towards Service Oriented Architecture, and Grid computing. It’s still not as easy as plugging into a power outlet, but it is becoming more and more practical. With it comes a growing demand for reliability and predictability. Creativity and innovation in service definition will be sacrificed on the alter of reliability and predictability. Best practice standards are one of the better ways to achieve the reliability and predictability that are being demanded.

All of this pales beside the question of professional trust. I am biased - trust is absolutely critical to my success as an IT professional. Winning trust has two key elements. First, clients (users) must trust your intentions. We have Codes of Ethics to cover professional intentions. Second, clients must trust your competence. Clients, for good reason, are more willing to trust professionals who have demonstrated they understand relevant best practices. Admittedly, there is a gap between understanding good practice and successful competition of all tasks, but understanding good practice is an important first step. It all comes together with a professional society that identified important best practices, and professionals who are committed to appropriate use of relevant best practices. It’s not perfect and it’s not foolproof, but it will be an important first step.

I would make a last point about the growing importance of best practice standards in IT. Our organizations are more and more dependant on IT. Virtually everything that happens in today’s organizations is touched by IT in one way or another. At the same time, we have invented words like “coopetition” to describe a world in which connections between organizations are growing. IT can be a great enabler of such connections, or can make them practically impossible. It’s not mostly a question of technical standards. It’s mostly questions about compatible processes and procedures. What should happen if a connection is broken? What should happen if changes must be made to a connection? XML and similar technologies can help with the technical connection, but compatible best practice standards are at least as important.

Effective project management has been essential in IT since day one. The Project Management Institute is dedicated to helping project managers succeed. They have identified a Project Management Body of Knowledge, and have published a Guide to their PMBOK. This PMBOK Guide is really an organized and thorough collection of best project management practices. Demonstrated mastery of that Guide is at the heart of the certification offered by the Project Management Institute. Project Management Professionals, i.e. those certified by the Project Management Institute, can be trusted to understand the PMBOK Guide. This collection of best practices has been accepted by the Institute of Electrical and Electronic Engineers as their standard for project management.

Important Aside: The IEEE has published a CD containing their top 40 Software Engineering standards, including the PMBOK Guide. The cost of the CD is only a few hundred dollars. In the world of standards, that’s a great bargain. Standard setting bodies largely fund themselves by selling copies of their standards. There are cases in which a standard costs more than $10 per page, … and that’s US dollars!

The next item didn’t begin as a standard. The Information Technology Infrastructure Library began, and is still today, a library of practice guides. ITIL in normally use refers to the Library volumes which describe best practices for IT service delivery and IT service support. There is growing pressure, from a number of sources, driving IT organizations to follow the ITIL best practices for service delivery and support. Outsourcing is one important force behind ITIL. If all of the practices are unique to an organization and its outsourcing vendor, then the organization would find it very difficult to switch vendors. It has become a near competitive requirement in the outsourcing business to follow the family of ITIL best practices.

ITIL began as a tool developed by the UK central government, for use by IT units within the public sector in the UK. Its use spread beyond the public sector and beyond the UK. The current version of ITIL (version two) is being followed widely in Europe, and its use is growing in North America. There is a British Standard (BS 15000) that guides the use of ITIL in service delivery and support. There is soon to be an International Organization for Standards version of BS 15000, planned to be ISO 20000. And ITIL is currently undergoing a revision, with a project ITIL3 due in 2006.

The Capability Maturity Model for Software was developed by the Software Engineering Institute of Carnegie-Mellon University. Most of its work was, and is, funded by the US Department of Defense. One positive side effect is that all SEI documents are available for free use by the entire world-wide IT community. This work is really an effort to collect and codify best practices in the software and systems area. The practices covered range across the entire software/system acquisition and development spectrum. The US DOD has exerted a powerful force to encourage its suppliers to advance along the maturity scale - they refuse to deal with vendors that have not advanced far enough.

The current version of the model, CMMI, Integrates what were formerly separate Maturity Models for Software and Systems. There have been a number of efforts to define a best practices acquisition and development model. They are all coming together in ISO 15504. But you will continue to find great information on the SEI website.

The last of the big four best practices is the control and audit standard developed by the accountants and auditors. CobiT, or Control OBjectives for Information and related Technologies, divides all of IT into 23 key processes. Everything that IT does falls somewhere in that collection of 23 processes. A maturity model is provide for each of those 23 processes. Viewing IT through the CobiT framework can be a very useful exercise. Problems, gaps, and challenges show up when an IT shop reviews its maturity rating for each of these 23 processes. That can be a good thing, in and of itself. But the financial community now faces a very strong requirement to demonstrate that the process used to produce all financial numbers is not subject to abuse. CobiT has been accepted as the “gold” standard in relation to Sarbanes-Oxley and our Bill 198.

It’s time to stand back from my top-4 and consider standards in general. There is considerable acceptance of the idea that “standards” come in different flavors. The normal evolution is from practices which have been observed to be “good”, at least in certain contexts. The next step up is often an organized and systematic collection of best practices. There may be a range of best practices which could be applied in different circumstances. When translated into a “standard”, this becomes what I call a Practice Guide. Responsible professionals who work in the area need to understand the Practice Guide, but there can be a wide range of valid reasons why a Practice Guide is not followed. The professional’s responsibility is to understand the Practice Guide, and then selectively apply it. Next up is what I call a Recommended Practice. It become the default approach that all professionals should consider. Deviation from a Recommended Practice is possible, but requires an explicit argument. Finally, there are Required Practices. They must be followed by responsible professionals unless there are clear, compelling, and documented reasons why those Required Practices are not being followed.

Where are we today? Both PMBOK and ITIL are in the form of Practice Guides. Responsible professional need to understand these Practice Guides, but there will be a number of valid reasons why they are not being followed. Both CMM and CobiT are in the form of maturity models. In that form, they don’t really fit as either Practice Guides or Recommended Practices. The IT standards which have advanced to the Recommended Practice level tend to be standards about standards, or meta-standards. CSA 12207, the practice standard being considered by CIPS, is such a meta-standard. It divides the acquisition and development of software into 17 processes. It’s value is to provide a common frame of reference that everyone involved with software can accept. Every professional with responsibility for helping to select applicable software practice standards should work to understand 12207. Lastly, we are not at the place where any standards can be accepted as Required Practices.

I find this to be a useful representation of the software standards landscape. At the highest level, there are standards about governance and control. CobiT does a good job covering that territory. CobiT does not attempt to explain how to achieve the different maturity levels it describes. It describes possible end states. Other best practice standards must be used to determine how those objectives are to be achieved. The bulk of work in software falls naturally under the “system” or “service” category. CMMI and related best practices cover the system side; ITIL covers the service side. Supporting these three software standards categories are what I call Infrastructure Standards. The PMBOK is a good example of such a standard - it applies in IT and elsewhere. There are a number of procurement, quality, and security standards which are naturally grouped here. One very positive step which can be observed in this framework is that there is a growing recognition that all of these standards must work together. That’s relatively new, and a very positive sign in favor of moving towards more standardized practice.

I’ve got a logical and a practical concern with maturity models. They clearly strike a responsive cord in business. You identify your place on the maturity scale and your path forward is clear - you advance from your current maturity level to the next. Many IT organizations are following the resulting clear, well-defined path. The logical assumption behind these models is that there is a single dimension along which all organizations should mature. That threatens to be a rash over-simplification. Notwithstanding the theoretical problem, the clear path forward which comes with maturity models has won the day in many organizations. It may be a theoretical over-simplification, but it works as a way to identify the path forward. I’m also none too happy with the choice of “maturity” as the adjective to use - it would have been better to call them “performance” levels. But the name has stuck. A last point about maturity models is that they can never become Recommended or Required Practices. They can be effective guides to practice, but nothing more.

My last background point concerns the difference between an organizational standard and a professional standard. The organizational standard will apply to teams, departments, or divisions within the organization. A professional standard will guide and govern the conduct of the individual professional. The IT reality is that almost all software practice should be guided and governed by an organizational standard. All of the standards I have discussed are organizational best practices. The professional can be expected to be knowledgeable about relevant organization practice standards. The professional can be expected to guide, council, and advise that relevant organizational standards be carefully considered. Few professionals are in a position where they can impose a practice standard on their organization. This tension between the professional practices and organizational practices is inevitable in fields such as IT. So long as our professional services are delivered in a group setting, this tension will continue.

What does all of this mean for you as a responsible IT professional? Many of the traditional roles in IT will be governed by practice standards. Business wants predictability and reliability from IT. Best practice standards take us a considerable distance down that path. IT will either being to deliver utility like service, or the outsourcing vendors will be able to make a compelling case to senior management. Get used to it - best practice standards will apply to more and more in IT. You’ve got a choice. Do you lead, follow, or resist? Unless you are very close to retirement, or independently wealthy, resistance would not be wise. The real question is whether you want to play a leadership role. You can’t get so far out in front that the troops lose sight of you, but you do need to move to the front. That mean educating yourself, and thinking long and hard about whether or when to apply best software practice standards. I always find it easier to embrace discipline than to have it enforced.

I’ve been positively impressed by Dan Pink’s “A Whole New Mind”. He argues that success in the 21st century will require both the discipline that is natural to the left brain and the creativity natural to the right brain. His argument, and I find it compelling, is that good left brain work can be outsourced, and will increasingly move to low cost suppliers. But what will distinguish business success in the future is the creative spark that is added by the right brain. Apple is the classic example. They do good left brain work, but it’s not all that distinguished. Apple’s success can be largely traced to the right brain sizzle they add to their solid, predictable, reliable left brain steak. This poses an interesting professional challenge. How to develop strength in both left and right brain work? An even more interesting organizational challenge presents itself. How can one organization fairly and equitably recognize and reward its left brain and right brain IT professional? There are no simple answers. Building viable answers will continue to challenge IT professionals.