Sponsors

Microsoft


TechWell

We have 858 guests and 3 members online

Home Implementation Excellence Framework for Evaluating and Implementing Standards

Framework for Evaluating and Implementing Standards

E-mail
Written by Mario Moreira   
Saturday, 11 October 2008 19:00
oct08frameworkbig.jpgAs I was thinking about writing this article, a song came into my head, "War, what is it good for".  Instead of the word ‘war', I sang, "Standards, what are they good for?"  Is just having a documented standard enough or do we want to know that it is fully implemented?  Do we want to understand the value of a standard and see if it is really being used to manage the organization?  It is important to understand how to evaluate the standards that you have.  Does your organization provide the building blocks for a successful implementation of a standard?  With that being said, I hope to provide you with a framework that can help you answer these questions and help you evaluate and/or implement standards effectively. 

When I see standards within organizations, IMHO many do not comprehend that just calling something a standard does not necessarily make it so to folks within the organization.  There is effort required to create a standard that is valuable to the organization.  On the other hand, I see de-facto standards that people do not recognize as a standard.  This has to do with the drivers of the standards.   

Drivers of Standards
Typically standards are driven by (and not limited to) external drivers, senior level internal drivers, and ground level internal drivers.  It is important to understand the drivers so that you determine the context of the standard and where the value is perceived. 
  • If the standard is being driven externally like Sarbanes-Oxley (SOx), then this forces an organization to follow the standards irrespective of whether those within the organization see the value.  However, externally driven standards like SOx, need to be followed to avoid potential financial scandals.  This is seen as a value from those outside the organization since potential investors perceive that the organization is being managed in a financially sound manner.
  • There are standards that are driven by senior level Executives in the organization such as Senior Management.  The unfortunate thing is that there are typically dozens to hundreds of standards that are driven by senior management which makes it hard for the employees to grasp their meaning and application. To make matters worse, many of the employees within the organization may not even know that they exist or, if they know that they exist, they do not know what they should be doing about them since there is not always guidance on what to do about them (other then "just follow them").  While, this is seen as a value to the Senior Management, if they do not provide implementation details to the standard (a.k.a., a practice) and manage to the standards (e.g., is the standard making their organization better and more value added), then it is only a standard by name.
  • Then there are standards which are driven by the ground level folks in the organization.  Often times, these are not defined as such, but may be seen as de-facto standards.  Sometimes this is known as a grassroots standard since it is driven by folks at the individual contributor level.  An example of this is that when a project team uses a particular technology, other project teams see the value in using the technology and then the next thing you know, most other project teams are using the technology.  This is because teams see the implicit value in using the technology and it becomes a de-facto standard even if it is not listed as an organizational standard.
Building Blocks of a Standard
In all cases, if you really want to institute a standard, it is important to provide as many building blocks 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.  To understand more about the key aspects of a practice, consider reading the article entitled, "Constructing a Best Practice". 

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 following the standard, it can be beneficial to track metrics so that there is an organizational level understanding of how compliant the organization (and specific divisions and groups) are to the standard.  The metrics should be made visible and quite possibly tied into the employee performance measures.  This further ensures that the standard gets followed.    

Manage
Now that most of the building blocks are in place: the defined standard; the practice to implement the standard; the policy that requires use of the standard; the verification process that shows if the standard is being followed; metrics to indicate the level of compliance throughout the organization; the final building block indicates if management truly understands the need for the standard and actually uses this data to manage the organization. An effective manager will use the data to run the organization and assess the value of the standard, as well.  Is the standard having the intended affect?  Are people complying?  By evaluating the data and asking the right questions, Senior Management should be able to assess and reassess the standard, modifying, as necessary, to more effectively obtain the desired result, or remove it if it is not working.         

Combining Verification, Metrics, and Manage
These latter three building blocks of a standard lead us directly into the enforcement of a standard.  Quite frankly, without enforcement, most standards will not have any value (other than the de-facto standards mentioned in the "Drivers" section early in this article).  Enforcing the standard shows that the organization is willing to put time and effort into ensuring the standard is being followed. 

Summary
A standard is only as good as its perceived value.   Knowing who the driver of the standard is helps determine the context of the standard and where the value is perceived.  Understanding the building blocks of a standard can help you evaluate if existing standards are really set up for success or just for show.  Do you want your standard to be standard in name only, or do you want to see the organization really understand the standard and actually implement it?  Also, applying the building blocks can help you implement a successful standard, one that is understood, implementable, verifiable, and used to manage the organization.         

References
"Constructing a Best Practice", by Mario Moreira, Dec 07, published at CM Crossroads http://www.cmcrossroads.com/articles/implementation-excellence/constructing-a-best-practice.html


Mario Moreira is a Columnist for CMCrossroads Journal, a VP of Technology & Methodology, an Author of CM publications, and has worked in the SCM field since 1986.  He has experience with numerous SCM technologies and processes and has implemented SCM on over 100 applications/products, which include establishing global SCM infrastructures.  He has 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 has released a new SCM book entitled, "Software Configuration Management Implementation Roadmap".  It can be found at www.wiley.com, www.wileyeurope.com, and www.amazon.com (search for Mario Moreira).  It includes step-by-step guidance for implementing SCM at the organization, application, and project level with labor-saving templates on CD.  You may reach Mr. Moreira by email at Mario.Moreira@cmcrossroads.com


Trackback(0)

Comments (0)add comment


Write comment

You must be logged in to post a comment. Please register if you do not have an account yet.

busy
Last Updated on Thursday, 23 July 2009 12:54
 
509 Bandwidth Limit Exceeded

Bandwidth Limit Exceeded

The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later.