Norms and Rules

October 13, 2009 by
Filed under: Leadership, Process, Project management, Quality 

I was chatting with someone the other day about my upcoming trip to Germany (I’m actually writing this one in the departure lounge). He was over there during the summer, and as a way of helping me ensure I had a good time, he noted “just remember, there are social norms over there, but there are no social rules”. Makes me ponder the relationship between the two.

We have all sorts of rules in project management and software development, and they span the spectrum of enforcement from mild suggestions to commandments. Once an organization gets to a certain size, they almost always attempt to deal with that growth by putting in place more rules to follow, in the name of consistency (and hopefully, that consistency is positive). We can see rules in the smaller shops as well, particularly when someone has ‘gotten the religion’ that a particular practice is universally good to do.

While there are some that would fit into this category, like regular backups and configuration management, most are far less universal.

Nonetheless, these rules are identified as ‘the way we do things here’. Sometimes, these are even communicated to the new people that start there as the business grows (but not nearly most of the time). Most often, even if they are the stated rules of engagement, a quick check confirms that what is actually done differs considerably from this guidance. Far too many people aren’t even aware where to find the guidance in many shops.

Sometimes, there needs to be rules in place in order to satisfy some qualification or certification, to attain some level of maturity, or to build and ship products in a particular domain. These rules are generally derived based on a great deal of thinking and experience, rolled into a structure that a) the project teams can follow and b) the auditors can audit compliance to.

Usually what happens is that a) the project team slavishly follows the structure for qualification or b) they produce the documentation to satisfy the letter of for qualification, even though they clearly fail the intent. Remember, I said usually here. I have actually run into a couple of situations where the right standard is applied in the right way to support the business properly, but I have yet to fill a single hand with instances.

In the consulting game, confirming that the rules are in place is a great way to generate consulting revenue, but rarely helps the client in getting better. This confirmation can help them demonstrate their achievement, but anyone who’s been in the business for a while can recall stories about qualifications that have been achieved that have not really been earned.

A long winded way of saying that even if there rules, it is never a primary concern to me as I work with organizations. What I’m interested in is the norms, what is actually happening on projects. This is the true starting point, regardless of whether your intent is to eventually get a certificate for your lobby or claim that you are one of the most mature shops around. That starting point, that baseline, is what matters first and foremost. I might ask to look at the standards, but only to see how thick the coat of dust is on them.

There are norms of behaviour, and norms of performance. Understand what is currently being done and how projects are currently performing, and you have already provided a benefit to the client.

How is that a benefit? Several reasons.

First, in every shop I have ever worked in or consulted to, the ‘what is being done’ varies dramatically from project to project (or even between people within a project), far more than most people would realize. This variation is not necessarily bad, it can even be a very positive sign that people are doing the right things, but usually it exposes the delusion that there are consistent practices in place (and the deeper delusion that these practices are actually the ones that have been identified as the standard).

Second, objectively identifying the norms of performance is an eye opener as well. many shops tend to muddle through their projects, with little or no insight into the costs of their less-than-perfect behaviours. Without this awareness (and the numbers can be staggering and defendable), there is little reason to invest in improving. Indeed, the idea of training or adjusting behaviours will only be seen as a cost that doesn’t support project delivery, and who would want to spend money doing that?

Understand which rules really apply, but use this as a context in which you look at the norms of behaviour and performance. This gives you a starting point to work from and an understanding of why you would even consider changing, but most importantly, it ensures that your efforts fit with the culture that currently exists. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    In our brief one day session with Clarrus, we identified the key areas to focus on, and drilled down to discuss the best approach to take in each area. Rather than a sanitary discussion of best practices, we arrived at a practical, specific set of items to implement – I think we made significant progress as a development group.

    — Daniel Miller, CEO, Miller Software