How Long Should a CMDB / CMS Take To Build? Part 1: People

For some time I've been exploring the value of a CMDB and CMS.  A big part of the TCO value equation is the  TCD, Total Cost of Deployment.  TCD is often underestimated - note how little Google has on the subject.  Why?


 



  • Not everything that matters gets estimated

  • TCD tends to be estimated optimistically or "carved" to fit  budgets

  • The number and complexity of problems are often underestimated

  • The straightforwardness of fulfilling the first few use cases are often overestimated


 


And isn't all this "estimating" really a euphemism for "we don't know"?  If we knew we wouldn't have to estimate.  Estimation has an inherent connotation of uncertainty that we don't like.  We all want complex things to be simpler, more transactional, more commodotized, than they really are:


 


C: "Nice CMDB.  I'll take it."


V: "That'll be one million dollars.  Where do you want it delivered?"


C: "Dock 2."


V: "Ok.  What color?"


V: "Fast."


 


No really, what should you expect your CMDB deployment to be like?   What should we be focusing on estimating?


 


What we like to use to estimate CMDB deployment aren't  the biggest or most important variables.  We like to focus on things like, how long do other deployments take.  How long will it take to install the software.  How long until the hardware arrives.  When can we get everyone "trained".  All good and proper project management, can't do without it.  A deployment project is focused on consulting time and cost, hardware schedules, definable things.  


 


But the two most important factors are also the two most difficult to measure and change are people and processes.  And these are also the biggest variables in estimating time to full implementation of a CMDB or CMS.  In this series, this post will start with the most biggest variable, people.


 


Implementing a CMS is much more than getting the solution deployed, or getting some discovery done, or even getting some providers and consumers onboarded.  It's about changing the way IT works. To that end you absolutely must start with what IT is - not a data center or even a collection of infrastructure and apps - IT's an organization, and organizations are built around people, process and culture.


 


Deploying a CMS will touch almost everyone in the IT organization, because the CMDB almost always follows the implementation of some other initiative such as change or release management or other IT-wide scope.  As ITSM initiatives go,  so goes the CMDB.


 


The Kicker:  The ITSM ecosystem of applications, plus the CMDB to facilitate exchange of configuration data and the common view of IT services, forms the CMS.  Now this should sound like a much harder project than implementing a CMDB.  It is, that's my point.   Without thinking of your CMDB this way, you are likely to do some of that dangerous underestimating of the effort of getting ROI out of your CMS after your consultants have left the building.


 


In my next post I'll explore and  ask you why cultural change is the most important part of the deployment and the most difficult to get right and the hardest to estimate. 


 


Questions, comments, complaints, 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.
Search
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 ...
Featured


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.