"Aha!" Moments: Serendipitous Early Value Encounters in CMDB and CMS projects

My Social Media Manager Heather asked me to consider writing a customer success story for one of my blog posts.  I decided to try to raise the bar even further.  This is a compilation of many customers' success stories, albethem small successes.  I'm talking about "Aha!" moments, success they didn't know was coming and generated an "aha!" moment.


Early, informal value realization, aka “aha!” moments, found early in a CMS or CMDB project can act as value tiers, financing time and credibility for the more difficult-to-realize, longer-term ROI.  Especially if your funding and sponsorship is dependent on volatile management moods and economic fluctuation.  Look for aha moments whenever you can - they will usually reward you and your project in ways that are hard to predict.  And, very occasionally, negatively, in those types of environments where No Good Deed Goes Unpunished or where the messengers, especially bearers of bad news, are still killed - you know who you are.


Informal research (my own experience and anecdotes from my customers and colleagues) indicates that some engagements are more successful because value was realized and documented early and often. This is paradoxical, because the business transaction funding the project is usually measured only on the final value realization i.e. fulfilling the sponsored use cases. However, if no value is shown before the primary use cases are successful, organizations typically do not do as well success-wise. It is unclear as to which way the correlation goes, in other words, whether the lack of early success lead to a loss of project momentum, vs. if a project with a weak link has inherently fewer aha moments.


Apparently, “aha!” moments can be almost as important as the overall drivers, even though these are rarely formalized or anticipated. However, aha moments alone cannot sustain a project. The primary use cases must be delivered.


Here are a few of my favorites.


    When the aha moment happened

    Source of the aha moment

    Why the "aha"?

    The Value of the aha!


    Problem awareness

    These kind of broad projects illuminates the business cases throughout the organization.


    Take the example of the "email from corporate",  an email notifying all employees of a new project.  It's unread by many due to the large number of such announcements. Until something happens that involves them, the project is only dimly visible to much of the organization. The “aha!” moments happen when you start interviewing people (known as "surfing the organization".) When the conversation starts with “Why are you here” and ends with “Can I play too?”, the value of the project has been successfully evangelized. But this is not the aha.


    When people begin answering the planning questions – questions like “what is your process for documenting applications?” – and the answer is “Well, we really don’t have a process for that.” – People begin to realize that there is a broken, missing, or inefficient process for which the CMDB use case can improve.

    When people become more aware of the problems facing their organization, at a higher level than their function. From the individual’s perspective, the the organization’s "ubiquity" is reduced.  It becomes a bit more personal.


    This can enable intangible value ranging from motivation, morale, and incentive to participate, to developing interests in the company’s higher functions – adding momentum not only to the CMS project, but in part to the entire organization.


    Infrastructure awareness

    During interviews, we have sometimes uncovered missing firewall rules, missing hardware redundancy, and missing security rules. We would ask something like “what is your firewall policy for this DMZ?” And the technician would log on to the firewall or look through their spreadsheet, and say “I don’t see it.”. they would call their buddy or their manager and discuss it, then would turn to us and say “We’re fixing that right now.” Or “We’ve got to open a change for this”.  Cha-chingCool.

    Risk is directly reduced by correcting redundancy and security-related issues.


    Identifying infrastructure Single Points of Failure

    Initial baseline discovery has found the actual infrastructure to be contrary to a stated configuration. This is not only due to dating, but understanding, and differences between planned and implemented solutions.


    For example, a single point-of-failure was found for a mission-critical application requiring redundancy down to the network level. Connectivity to the application’s database was found to flow through a single router.  The Senior Geek we were working with assured us this was impossible and that the tool had to be wrong somehow.  A few phone calls to his Alpha Geek and and some probing, the single point of failure was confirmed.  The Alpha Geek and his team were later praised for uncovering a critical point of failure so early in the project.  We looked pretty good too.  Cha-ching.Cool

    Risk is directly reduced by the identification and subsequent correction of situations falling short of documented or expected implementation.

    Depending on the significance of the differences, finding these kinds of things often is a big boost to the credibility and confidence for a fledgling CMDB initiative.


    Discovering non-standard / unauthorized hardware and software

    Often, unauthorized software or hardware configurations place production at risk. For example of a software risk, non-standard software or patches installed on production servers. Actual examples of “risky” hardware:

    1. finding a part of a production application running on a desktop

    2. finding personal network hardware on a production network

    3. finding a part of production running on the CIO's desktop at his residence!Cool Cha-ching!


    Reduced risk to production applications


    Security and auditing

    SNMP was often found to be running with the default community string, even after the Security staff has assured us that all their devices are not on the default value. Also, where insecure protocols such as telnet are disabled by policy, and found to be enabled.

    Some SMEs, when approached, are skeptical of the discovery results. Only after verification using another tool will action be taken. Often, this has the net effect of increasing trust in the product.

    Risk is directly reduced by identifying missing or default security credentials. However, the amount of value varies widely depending on where the breach in question was located. For example, a breach found in a DMZ would be more valuable than one found in an internal-only network.


    Confidence in the CMDB contents usually increases with these kinds of discoveries because they are often visible to management and other groups.

    Dependency Mapping

    Unexpected Host and Applications Dependencies

    When we start putting the topology views together for the core service models, we sometimes discover application relationships that make a difference. For example, during DR planning, a customer found a mission-critical application to depend on a “non-critical” application. It was realized that the non-critical application was made critical by this discovery. A change in plans was made to accommodate moving the newly-critical application at the same time as the mission-critical application.

    Outage avoidance is more than risk reduction – had the situation not been found and corrected there would have been an outage. This is a direct improvement in quality, both statistically for risk and cost-wise operationally.  Even if the ROI is hard to quantify there is no doubt that ROI occurredCool.  Cha-ching.

    Impact Analysis

    New Application-level Dependencies

    As in the previous scenario, we sometimes uncover additional dependencies when we begin testing the impact analysis correlation rules.  Usually it's in the form of gap identification with the application owners, e.g. "Hey, where's the ABC app, huh?"  But you should take relationship identification any way you can get it.


    Outage avoidance as described above.

    Training, both formal and informal


    Interaction with application SMEs


    Interaction with customer management


    Interaction with technical staff (network, security, DBA, etc.)

    New Use Cases

    When you have good stuff, everybody comes to you and asks you to make it do everything you ever told them it could do.  It can be quite overwhelming.


    The team begins linking the concepts learned in training to begin solving their own problems. Matrix teams such as those found on CMS and CMDB projects often bring new valuable and challenging use cases to the table.


    So there's a risk of “scope creep” as students try to use resources already allocated for the primary use cases to their own use cases, or if the project attempts to take on too many use cases too early, before it has sufficient momentum to succeed. A lot of aha moments can increase project momentum, in a way, increasing time-to-value of the primary use cases along with it. It is worth a mention here that, as a CMDB matures, it can take on those additional use cases.  So Aha moments aren't exactly scope creep repellent, but they make the smell more tolerable.


    However, too many use cases early on tend to starve the project due to lack of delivery of the primary use cases.  Don't run before you walk.

    With a reliable means of capturing these use cases, the CMS grows in value by further decreasing cost of implementation and increasing time-to-value through experience. All consumers benefit by a collective body of expertise.

    Ultimately, aha moments alone are insufficient for a project’s success, but the do seem to play an important part.


Yeah, you caught me, this is part of a paper I already wrote.  So I'm a little drier here than my previous posts.  That's ok, I've been pretty "wet" so far.    But this is serious stuff when you get down to it!  My pontification (and YOUR COMMENTS, PLEASE!) should add up to something greater than poking fun at dumb stuff and waxing philosophic about mundane topics like Configuration Data Provider Rationalization (another juicy topic coming soon!)


If this is interesting to you, please let us know.   Our blog isn't really a blog until we get our user community actively involved and discussing these topics, which are really little more than starting points.  Please take a quick moment to let us know if you agree, if we suck, or what.  We'd appreciate it.

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.