A Framework for Evaluating and Implementing Standards

as possible.  This ensures a more successful implementation of the standard.  These building blocks provide a framework for establishing a standard and ensure the standard has perceived value.  The building block levels are (but need not be limited to):   

    • Standard is defined

 

    • Standard has an implementable practice to support it

 

    • Standard has a policy that enforces it

 

    • Standard is being verified that folks are complying with it

 

    • Standard has metrics indicating the level of compliance to it

 

  • Standard and compliance metrics are being used by Senior Management  to manage the organization
mm0208-1

Keep in mind, that this should be a flexible framework.  The levels in between the "Define" and "Manage" do not have to be in the exact order.  If the policy gets established before the practice to implement it, that is fine, too.   

Define
The first level is to define and document the standard that is needed for the organization.  A standard is typically described as an explicit requirement that must be met.  One example can be that all of the applications under development must use a specific requirements tool.  Another example can be that the company must follow a set of financial processes. 

Practice
While it is a good start to define a standard, it is much more helpful to provide a practice on how to implement a standard.   A practice may include (but is not limited to) more guidance including the problem the standard is trying solve, the goals of the standard, the procedure for implementing the standard, the tools needed to implement the standard, and training on implementing the standard, and so on.  Expanding the first example (from "Define"), the practice would provide the procedure to use a requirements tool and provide a tool infrastructure for easier deployment and usage. 

Policy
Defining a standard and providing a practice to implement it will help those that may already see value in the standard.  However, unless there is an organizational policy that states the clear organizational need to follow the standard, then only a handful of people may follow it.  This policy should state clearly the roles in the organization that should implement the standard and the scope of the standard deployment.  The policy must also be announced and supported by Senior Management in order for the standard to be taken seriously.  Expanding the example, the policy would explicitly state that all project teams must follow the technology standard of using a specific requirements tool.   

Combining Standard, Practice, and Policy
If possible, establishing the standard, practice, and policy at roughly the same time is a great approach.  When the standard is introduced, there is a practice and policy that supports it. 

Verify
Now that the standard has been defined, there is a supporting practice to help implement it, and there is a policy in place supported by senior management, this implies an expectation of usage.  Establishing a way to verify if the standard is being followed is needed.  The verification process needs to be implemented by folks independent of usage to assure compliance.  This will identify in an objective way if people are following the standard (or which parts of the standard they not following).  If people within the organization know that there is a verification process in place that will check on them, then they will have much more motivation to meet the standard.  Expanding the example, an independent verification role will verify if project teams are using the requirements tools to capture requirements and therefore aligning with the standard.   

Metrics
Now that we have a verification process for

About the author

Mario  Moreira's picture
Mario Moreira

Mario Moreira is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “Adapting Configuration Management for Agile Teams” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “Software Configuration Management Implementation Roadmap.” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at http://cmforagile.blogspot.com/ . You may reach Mario by email at Mario.Moreira@cmcrossroads.com.