As 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.
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), 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 than "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
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 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
1. "Constructing a Configuration Management Best Practice", by Mario Moreira, Dec 07, published at CM Crossroads
