Design and Change Management

I have developed a few strongly-held architectural beliefs, and one came up in conversation last week, during a spirited discussion on minimal quality requirements for a[ny] data mart.

I have developed a few strongly-held architectural beliefs, and one came up in conversation last week, during a spirited discussion on minimal quality requirements for a[ny] data mart. I hold that the data copied from source to destination must be provably correct and complete with little effort. When agile-ly rolling staged deliverables into production, I may not have all the attributes in place for full flexibility of drill down, but if you have [say] 1248 records in the source system, representing $154,238.54 of transactions, you better have exactly the same amounts in the reporting tool – easily checked with a simple hash total. There should be no inbound filters or transforms – save that stuff for the meta data and/or presentation layer.

How exactly does this relate to “design”?

I delight in obsessing over the details of layouts (screens, forms, & slides) and page formatting (specifically for the printed page) – possibly a bit too much, but it’s ultimately about user acceptance. If an application / report / presentation / document looks like it was thrown together, with extraneous messaging or ornamentation – well, people will use that as an excuse to write the piece off as complicated and/or incomplete. Often, when introducing new systems, tools, metrics, and/or processes, you are introducing significant change in people’s lives. There is always natural resistance to change – resistance that looks for anything to latch onto and call into question. Like rubbing a cotton ball over a rough surface – teeny imperfections will snag & fluff their attention, and distract from the view.

It’s much the same with my data mart example; these analytical wonders often expose uncomfortable truths or (more likely) opportunities that were there all along, just hidden from view. For the unbelievers, or those wishing to delay the [potentially] bad news, any excuse to question the validity and accuracy of the data will do. Do yourself a favor – a simple hash total proving that 100% of the data got from point A to point B helps limit the fingerpointing and focus debugging attention on a simpler set of scapegoats.

Change Manage the “Big Stuff”

Pay attention to the details of the design, how everything fits together – and obsess over the nits that will detract from the core message. This pays off big when nothing happens. Well, maybe nothing that you don’t want; communication with zero distractions lets you focus on the elephants in the room, where your change management energies will be best spent.

The design is successful when all the angsty conversation is about the new process you are introducing, the meaning behind the metrics – not the fact that the type is too small or the multiple fonts make something hard to read – or the numbers just don’t add up.


Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010.

Jim MacLennan
Jim MacLennan is Senior Vice President and Chief Information Officer at IDEX Corporation, a Fortune 1000 manufacturer that sells highly engineered products in a variety of markets worldwide. MacLennan has responsibility for Corporate IT services for all IDEX business units, and also drives innovation through initiatives that leverage Information and Technology as growth drivers for the industrial manufacturing space. He regularly publishes his observations and insights on the intersection of business and technology - check out his work at www.cazh1.com.