How Long Should a CMDB/CMS Take to Build? Part 2: Culture and Understanding


This is part two in a series of understanding  CMDB and CMS deployment times.  Last post, we talked about people.  Here, we'll discuss people in an interactive collective workplace context:  in other words, corporate culture, and why corporate culture can be easy, or very very difficult, to understand and change.


And before we get too far, you must realize I did not graduate from any School of Business Science.  So there's probably some theorum or corollary  that describes what I'm getting at here.  Something like the Blake-Mouton  grid but with cookies.


So I won't be solving all your cultural change problems in a blog.  I'm here about why understanding corporate and human culture, or not, matters so much for TCD (total cost of deployment).


Solution Architecture and Service Delivery often take the fall for being late or underdelivering.  Why?  Much of the actual TCD goes unaccounted for.  A scenario: consultant shows up, clock starts ticking.  Shortly a missing or broken process is revealed to impede the project.  Tech consultant is then pressed into the role of business process engineering consultant, then burns the rest of the time on one or two of these process problems.  Maybe,  obtaining approval to touch some piece of the infrastructure, or trying to fast track a three-week change request into three hours.   Project gets behind.  Customer gets unhappy, Vendor gets blamed.  Free stuff is demanded.  What happened?  The consultant told the customer to "prepare" so this wouldn't happen.  Wasn't the problem understood or properly prioritized?   Delivery is relied on when they arrive. They have "done this before" or "should" know how to fix these kinds of problems.   Big mistake.  Organizational issues in the mirror look smaller than they actually are.


Why do people and cultural change remain the biggest variables of the deployment, the most difficult to get right, and the hardest to estimate?  Pragmatically, it's difficult to measure.  Scientifically, it's poorly understood.  Rhetorically I suppose one could answer "lack of mutual understanding".  Especially that "mutual" part - you understanding them is not enough.  You must strive to not be merely heard but understood as well.   Understanding is not just the first step to effect cultural change - it's the thing.  Going from an informal to a formal process for say, change management, can be really earth-shaking culturally, especially if a profound understanding of the people and culture are ignored, misunderstood, or  underbudgeted - and if they don't understand where you are coming from.


This is serious stuff - we're messing with  people's ideologies here.  And not just who-moved-my-cheese ideologies.  Ideologies like associating personal self-worth with job performance,a very strong ideology among many - in part because people tend to become attached to eclectic parts of their job, ironically,  those parts that have no safety net, that depend on human talent, to get done properly.


I have seen trouble even in well-planned and executed projects, because the project carried before it an apparent air of distrust or an implication that humans were no longer doing a good enough job so "control" was needed.   And the project had none of those things, the people just weren't  in on what was happening.   Even good people who do a good job can take it personally or feel misjudged or that they've failed in some way if they go unassured for too long.  Ignored long enough, these good people's fears will develop into a fight and you won't understand why.  This is the kind of stuff that can tsunami project schedules.   People who feel in on things  tend to produce a lot more.


Address common, as well as valid, concerns:  "Alice, you do a great job, but even with 99.98% accuracy, that .0200 is worth about a million dollars a year.  That not only justifies the cost but demands that we implement this automation to stay competetive.  You didn't do anything wrong to 'cause' this project. "  If you can say this sincerely and without  patronization, you'll get very far.


Still, cultural change is an enigma in some organizations.  Culture?  What do you mean "culture"?  It is what it is.  (an actual response to me from a manager of long ago).  How does one change what one can't understand, let alone measure?  I'm sure most of you understand your organization well.  What you may want to get a fresh look at is, is corporate culture grown or constructed?  That mattters in your approach.  What parts of your organization and culture can and cannot change? 


It's how you think about it.  And this doesn't merely depend on the nature of the force applied and the malleability of the material being worked.   Complex dances like the Change Management Tango or the Incident Cha-cha cannot be beaten into being; they are not rough structures forged in a foundry and bolted together!  They must be grown, nurtured, filed at at odd angles, sanded a lot, to produce the right result.  Think of your project as constructing a precision instrument, not raising a barn .  These are the nuances of cultural change, not the blunt strokes of an .mpp file.  Approached improperly, the vicious old theory X minimal effort/maximal clarity cycle rears its ugly head.  Zombified IT, there's a good ITIL replacement:  Obey…obey…


And you can't buy this cultural change off with a few all-hands meetings or a prop- uh, I mean an advertising campaign .  Pep rallies thinly disguised as running interference for a no-choice change might just deserve the derision and sabotage that come their way.  Which could be a lot. 


To effect real cultural change, your people must not just hear but believe.  You can make people do the former but not the latter.  DO bother to show them the numbers,  your assumptions, your heart - why you believe this is good for IT and the business because your people are a part of both.  Even if they look bored.  Don't assume they read all your memos or that memos will change corporate culture.  If you can't do these things, your project probably has a higher risk of failure.  And, while a business is not a democracy (unless you're an elected  government),  there are some things it behooves one to be democratic about.  And I'm not talking about voting.  I'm talking about involvement and communication!


These are the types of obstacles you face.  Any history you care to read teaches us that the best intentions of human engineering have often run aground on the unpredictable shoals of human behavior.  Don't skimp on the research or buy someone else's.  Configuration Management Systems are in today's time still hand-made.  But the parts are getting much better.


Next time we'll look at process engineering, an almost-as-mysterious and as difficult-to-estimate as cultural change.  Whether you're planning, implementing, or operational, I hope I've given you some small insight as to how important and unwrangly TCD really is and what success really means organizationally.  Can you relate?  Do you agree?  Maybe what your TCD numbers were?  Please reply and let us know how you feel.  Thanks.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Showing results for 
Search instead for 
Do you mean 
About the Author
Jody Roberts is a researcher, author, and customer advocate in the Product Foundation Services (PFS) group in HP Software. Jody has worked ...

Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.