Happy Standardization

April 26, 2012 | Author: PM Hut | Filed under: Project Management Best Practices

Happy Standardization
By Bruno Collet

Standardization is a slippery slope but, when done properly, can bring many benefits.

Notable benefits of standardization include:

Facilitate collaboration within the organization by normalizing common practices
Facilitate improvements by establishing a sound foundation
Share best practices by incorporating them in the standard
Share know-how, particularly across teams and with newcomers, by documenting the standard
Be verifiable by defining controls and providing evidence for these controls

However, it’s easy to get standardization wrong. Poor standardization will typically lead to unrealistic one-size-fits-all processes, or prescribe in such detail that people will spend a lot of energy to do things that do not add any value, or find excuses to avoid applying the standard. In fact, a poor standard is worse than no standard at all. What’s more, many organizations get ensnared in complicated standards that provide control (or the illusion of) at the cost of effectiveness, efficiency, and employee satisfaction.

I’d like to describe what I think are the 8 key success factors for standardization.

Understand the underlying reason
Reasons for standardizing are usually categorized as internal or external. The typical internal reasons range from reducing the cost to better managing the risks to improving quality, which are the business-level translation of the benefits mentioned above. The most common external reason is the need to comply with a regulation or industry certification. These reasons often mingle; a good standard should satisfy both internal and external requirements.
Agree on the scope

What are we standardizing? Project management? Software development? Just like any project, standardization can suffer from scope creep. Processes are interdependent and it’s a challenge to standardize a part without affecting the whole. We have to manage the standardization effort as a project; specifying scope, constraints, and so on, or we’ll easily slip toward an unmanageable reorganizing of the whole organization.
Determine the optimal level of detail

Choosing the right level of detail for a standard is probably to most important success factor. Choose a weak standard and it will not yield the benefits. Detail the standard too much and it will be impossible to apply.

This aspect becomes particularly tricky when the standard applies to multiple teams or projects that have different needs. In this case, we want to allow differences when they are justified and iron out the rest. Concretely, the standard should focus on the commonalities of the various projects and teams in scope, and give these teams the freedom and the tools to define their own implementations of the standard while complying with the basic rules. Similarly, the standard can be split into multiple standards to better fit the different situations. Again, the key here is to place the standard at an appropriate level to benefit from standardization while respecting the specificities of projects and teams.
Establish the desired degree of control

To what extent is the standard enforced? Is it a set of guidelines that teams can choose to apply or not and change at will? Does it define mandatory controls that teams have to abide to? The answer of this question lies in the underlying objective of the standard. The higher the need for control, the more policy-oriented the standard will be.

Like for the level of detail discussed previously, we can define a two-level standard that includes both mandatory and optional elements. This standard would be part policy and part guideline.

Note that, in my experience, guidelines alone usually fail to trigger changes. Particularly at the beginning of the effort, target teams must feel a “must have” pressure in order to give the standard a chance. After they discover that the standard makes sense (read: helps them do their work), the policy aspect can be relaxed.

In process terminology, we often refer to adaptive vs. prescriptive, which is just another way to express the desired level of control.
Identify and manage stakeholders

It’s critical to gather stakeholders that represent all areas that the standard addresses. Relying overly on the sponsor (someone from management ) to direct the standard is a typical mistake. If, for example, the standard caters to software development process, you have to select stakeholders representing the different roles involved in producing software, such as developer, analyst, tester, project manager, client, and many others. Moreover, you have to ensure that their relative power in the organisation doesn’t guide the standard: the opinion of a developer is just as important as the opinion of a manager. Failing to do so will alienate categories of stakeholders, who will later resist the adoption.
Leverage existing organizational assets

A common (big) mistake consists in bringing an external standard, usually materialized by a book or by a website, and applying it as such. It’s almost always a guaranteed failure. Avoid bringing in new stuff for the sake of it. Easier said than done; it’s very tempting to piggyback on “recognized standards” with big names, and usually much easier to “sell” to management.

Instead, try leveraging existing organisational assets such as processes, deliverables, and so on when they make sense. Actually, many organisations already have some sort of standard; they just don’t know it because it’s not documented!

To leverage existing assets, I suggest documenting the current practices, identifying those that could be part of the standard, and improve it from there. In this way, people will better relate with the standard.
Make it easy to use

What is the standard made of, concretely? What does it look like? The standard should describe the target processes, it terms of activities, deliverables, roles, and so on. Instead of a lengthy document, it should be easy to read and to navigate. Think about what would be the best channel to reach the people who will really be using the standard. Maybe it’s a document, or a Wiki, or something else, or a combination.

Similarly, make sure you include an example in the standard so that users can visualize what it looks like when it’s applied properly and understand how it will help them. Training material is also part of the package describing the standard.
Adopt and adapt

It’s usually unrealistic to produce a perfect standard in the first shot. Aim for a version 1.0 that is good enough to be put in practice and then expect to make a number of adjustments. It also helps overcoming resistance because people are put to contribution to make the standard evolve.

I’m sure we could list many more factors for successful standardization, but in my experience most of them are subordinate to those mentioned above.

Bruno Collet combines business acumen with technology know-how. His successful track record comprises Daimler-Chrysler, Siemens, and Loto-Quebec, with roles such as management consultant, project manager, SAP consultant, and software architect. Bruno Collet’s skills are firmly grounded in academic excellence by achieving an MBA at John Molson School of Business and a Master of Computer Science. He maintains a professional website: brunocollet.com.

Share this article:

This entry was posted on Thursday, April 26th, 2012 and is filed under Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Institute’s 2013 “Pulse of the Profession” Survey

Personal Time and Project Management Tips From America’s Top Universities

5 Things To Do On Your Small Project

The 7 Project Manager Personalities: Which One Are You?

Project Management - Organizational Influences

The Inconsistency of Agile

PMP Certification Mindset and the Training Dilemma

Chromatophobia - Fear of Project Status Reports

Promoting Agile beyond software development

10 Project Management Pitfalls

Happy Standardization

feel free to leave a comment