Picking an SCM standard or framework can be a daunting task. Should you go with ITIL, CMMI, CMII, IEEE, and ISO or create a hybrid using pieces of each? Then you have the question of compliance with edicts such as Sarbanes-Oxley to contend with and whether your standard or framework leads you to compliance. There is also the issue of office politics when the quality assurance group begins performing internal audits as you move toward reaching the goals of the standard or framework you have chosen. Not only will some in the organization resist, the audits can expose managers' and supervisors' shortcomings to the organization. This can result in distrust of the auditors, whether they have ulterior motives or not, and make implementations more difficult. Unfortunately, there is no clear cut way to pick the standard or framework that will work best with your group or organization. You have to know your organizations maturity and its ability to basically expose shortcomings in a constructive way. After all, making the organization better should be the number one goal.

Let’s use CMMI as an example to illustrate the point I am trying to make.  All organizations start out at level 1 and can go as high as evel 5.  I believe when picking the standard or framework and ultimately implementing it you should follow the adage: “shoot for the stars and hope you reach the moon.”  What does that mean when it comes to picking the correct standard or framework?  Well, each team, group, or division will be at different levels in documentation and implementing processes and procedures—some will be very formal while others appear to be flying by the seats of their pants.  In addition, each team, group, or division will be using the metrics and lessons gleaned from data they are collecting to make things better.  Some will have nothing at all.  I think most people would admit this is the case in their organizations—that some of their management excel at this and some need help understanding why it is important.

What you need to understand is that in any organization, groups may be operating at a higher level in the CMMI maturity model than others.  What you want to avoid is pulling those groups back just to reach a certain point in that model, if a group is level 3 in its practices, that’s fine, even if the other groups are at level 1 or 2.   The ultimate goal should be to get everyone up to the highest level possible, not shoot for a certain level for everyone.  Let’s say you have twenty distinct teams, twelve operating at level 3, four operating at level 2, and four operating at level 1.  To get level 2 certified, you simply have to get the four at level 1 up to level 2, rather than trying to get the four at level 2 to level 3, and the four at level 1 to level 3, and so on and so forth.  Like anything, teams and groups mature at different speeds and to different levels depending on many factors, including experience, desire to improve, and acceptance of change.

Another issue that one has to be cognizant of is why you are pursuing a particular framework or standard and who the driving force is behind the mandate.  This is where office politics can come into play.  We all wish that arguments and pettiness could be left at the door when the betterment of an organization is at stake.  Unfortunately, that is not always the case when dealing with varied interests and motives that exist in an organization. Obviously, everyone should want to do things better, cheaper, and more efficiently in an organization, but competing interests and motives can get in the way.  Some will use the push toward process improvement as their own personal agenda to point out everyone’s shortcomings and how perfect they are.  While they audit others with stringency not even seen in the military, they're letting their groups get by with little if any issues being raised.  This can be avoided by putting the quality assurance group at the correct level in the organization.  I would recommend making the QA team a direct report to the CIO, if not the CEO, of the organization.  This can be helpful when teams and groups are less than accommodating.  However, this will create a fine line for the QA group since it does not want to be seen as shoving this down the throats of the organization.

This brings up another point I would like to make.  Where is the desire to be certified or reach a certain level by a framework or standard being driven from?  Is this a top-down movement or has the movement come from below.  Either way can present its own issues and problems.  If this is being driven from the top, it can be seen as just another corporate initiative gone awry or another brainstorm that has failed like the last five attempts at process improvement.  If it is coming from the ground up, it may not get the attention or the sponsorship of key people to have a chance at success.  There has to be a collaborative approach with all parties being involved in the upfront decision making on what needs to be done to actually make things better.  Because, at the end of the day, all groups—whetherIT, marketing, accounting, research and development—should seek to improve the bottom line of the company.

Some may think that these things could never happen to their team, group, or organization, and I hope none of you have gone through the many pitfalls that can occur when picking a standard or framework to use at your company.  The main thing I think anyone or any group should consider when picking a framework or standard is this, “Are we doing this for the right reason or are we doing this because it has been mandated to simply to check off a goal.”  Picking a standard or framework is easy, making it work for your organization...that’s another story.