Do all of your project managers deliver the same information to their team and management?  Do all of your developers use common tools and techniques?  Do all of your testers follow the same patterns for creating test cases?

Process improvement is an interesting, and sometimes overwrought term.  We can all benefit from ‘excellent practices’ but the counterbalance is that ‘excellent practices’ are the result of steady improvement (six sigma or CMMI style) over ‘common practices,’ and many IT people reject the basic idea of ‘common practices’ altogether.

So what is this idea that some people love, while others despise? 

It is the radical notion that an activity or output that is valuable in a particular situation is also valuable in other (similar) situations, and that you can use proven value from one project to guide and inform staff members working on another (similar) project.

The problem isn’t collecting this guidance.  Everyone is willing to have their idea considered as ‘the best practice.’  The problem is getting other folks to learn, practice, and improve upon that guidance.  They already have a way of doing things, and your ideas may not appear to be all that much better.

One way to attack a ‘common practice’ is by saying “My situation is not similar to yours, so your practice is not valuable to me.”  This is occasionally true, but often it is a claim made by a person who thinks his or her way is just fine, thank you, and doesn’t need the ‘improvement’ offered by others.

Another way to attack a ‘common practice’ is by saying “Your idea is not better than mine, so I won’t adopt it.”  This gets really fun when one person or the other starts trying to create measurements to prove how much better they are.  Don’t get me wrong.  I like measurements as a way of driving process analysis.  However, those measurements have to measure the things that really matter: can you make more money?  Can you deliver to the business better?  Can you cut costs?  Otherwise, the measurements are unlikely to have any relationship whatsoever with stated company strategy or goals. 

To whit: I’ve seen folks quote numbers that talk about the drop in the number of defects if you follow ‘process X’ when that process substantially increases the development time needed to produce a system.  This is fine if you don’t mind increasing costs or sacrificing agility.  Executives and managers get to decide what the priority should be between agility, scalability, reliability, flexibility, and performance.  Here’s a radical idea: we should ask them.

More to the point, should an organization even create a ‘common practice’ guideline at all?  Is there value if asking people to perform their work in a common manner?  Most would say “yes” but I’m willing to bet I’d get a wide array of responses if I asked “how detailed” that common practice should be.

So, to add to the different quality attributes, I add the attribute of process consistency.  What is the value in making sure that your systems are created in a consistent manner? 

It’s a fine line.  What do you think?

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

3 thoughts on “Is there value in consistency?”

Leave a Reply

Your email address will not be published. Required fields are marked *

eighteen − twelve =

This site uses Akismet to reduce spam. Learn how your comment data is processed.