Did you forget your: Username / Password ?

Microsoft

TechWell

Home

Behaviorally Speaking

Behaviorally Speaking – Implementing Standards and Frameworks

Written by Bob Aiello

Monday, 21 September 2009 00:00

Implementing Standards and Frameworks can be a lot harder than most people realize. It’s easy to assure your boss that you are using IEEE 828 (for CM Planning), but actually making it happen is usually very difficult. Many people don’t understand the most commonly used industry standards and frameworks, and even fewer know how to apply them in the trenches. Another common mistake is to pick the wrong standard or framework to implement and then suffer defeat as your efforts fail. Here are some important things to keep in mind if you want to successfully implement standards and frameworks.

Start with the goal in mind  Some companies have a contractual obligation to use a particular standard or framework. This is not bad per se, but often these companies forget to clarify the real goals in implementing these best practices and instead focus on just complying with their contractual obligations to use a standard (e.g. ISO, IEEE, EIA) or framework (e.g. CMMI, ITIL, Cobit). This is very unfortunate because standards and frameworks should be selected based upon the goals of the effort (e.g. SOX compliance) and not just be a rubber stamp to get the auditors to stop writing memos to your boss.

Choose wisely  All standards and frameworks are not alike. If your focus is IT Service management then you will likely want to adopt ITIL and then reference other standards (e.g. IEEE) or frameworks (e.g. Cobit) as needed. If you are working for a government agency or defense contractor then you probably need to implement a number of IEEE standards and achieve at least level 2/3 within the CMMI.  

The myth of Level 5 It is very common now to have people say that they work for a company that is CMMI Level 5. I have learned to be very wary when I hear this. Often, the person saying this does not know a thing about the CMMI framework and wouldn’t be able to implement a single process area (or KPA for us old timers accustomed to the CMM). Just because a company has one project that is certified at CMMI Level 5 does not mean that the team that you are working with knows anything about the CMMI Configuration Management process area functions "to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits".

So then what is a work product?  Many people also do not understand what the CMMI requires when it specifies that the "work products that may be placed under configuration management include plans, process descriptions, requirements, design data, drawings, product specifications, code, compilers, product data files, and product technical publications."  

Understand why it is difficult  Standards and Frameworks can be difficult to implement for many reasons. Many standards and frameworks indicate “what” to do, but not “how” to do it. For example, do you know the difference between configuration status accounting and configuration audits? How exactly do I implement this? The short answer is that status accounting refers to tracking your code from requirements to deployment and having a clear idea of how each component evolved over time. Many standards use terminology like “tracking changes for each configuration item, which is anything but intuitive”. Configuration Audits means that you check your embedded version IDs into each configuration item and confirm that the versions in productions are correct (and implicitly that you can find the exact source code in your source code repository). I have written many articles explaining how to do this in build engineering so drop me a note if you want me to point you to some links. 

Start at the right size and scope  I have worked on implementing standards on projects that were companywide compliance efforts so that the Bank could pass a SOX audit. I have also worked on smaller efforts where the development team just wanted to stop making dumb mistakes. Understanding the size and scope of your project is essential in achieving success with standards and frameworks. 

Harmonize and tailor  I have written a number of articles on harmonizing and tailoring. Harmonizing means that you compare standards and frameworks to find the same practice described in more than one reference. This often helps you understand the practice better and also validates that two (or more) authorities agree that this is a practice that you should do (e.g. configuration auditing). Tailoring means that you trim down the standard and eliminate the steps that you do not need. Agility has taught us that volumes of documentation don’t make good systems and having extra steps that are not necessary is also bad. You want to implement to implement standards and frameworks in a way that is Lean and Agile.  
Where did we go wrong?  I am fortunate to be allowed to participate on a number of standards working groups and I am currently a member of the IEEE’s management board (for standards). I believe that we have to examine the fact that some standards are just incredibly difficult to read and understand. Have you figured out the difference between a configuration control board and a change control board? The language of a standard is often obtuse with few practical examples. The standards writers believe that they must work this way since standards are often used in contracts and the language must be very concise. That does not mean that you will always understand how to do the task when you read the text describing it.

Frameworks make the same mistake
The same is true of many frameworks. I have spoken with technology professionals whose companies gave up implementing the CMMI long ago. (I also lived this experience myself twice.) The company spent a year trying to implement the CMMI, only to give up the effort completely. (Many of these companies are now Agile enthusiasts.) Just this week, I spoke with someone who had attended classes in ITIL v3, but never managed to plow his way through the multivolume treatise that is published by the itSMF. The Cobit framework is also very concise, but hard to understand unless you find your way to the control practices.

Conclusion Achieving success with standards and frameworks requires that you have a clear definition of your goals and that you select the most applicable standards and frameworks. Learning to harmonize and tailor the standard is essential. Finally, making certain that you understand exactly what the standard specifies is a key requirement for success. Make sure that you share your own experiences with standards and frameworks – especially if you would like some help with understanding exactly how to operationalize and successfully implement standards and frameworks!

Bob Aiello is the Editor-in-Chief for CM Crossroads and a Software Engineer specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at raiello@acm.org or link with him at http://www.linkedin.com/in/bobaiello

Set as favorite

Bookmark

Email this