Optimistic Memory

This morning on a radio talk show I heard a phrase for the first time - 'Optimistic Memory'.  The person was (I think) referring to having a more favorable recollection of past events than perhaps was warranted, and failing to accurately recall said events with the proper scrutiny and measurement.

This is not unique, or particularly interesting I suppose, who hasn't fallen victim to having a kind of selective remembrance of prior events or circumstances, be they jobs, athletic 'achievements', or past romantic interests.  Heck, I even know a guy in the HR blogosphere that describes some of his past girlfriends as 'South Beach models'.  But I digress.

But the actual phrase, 'Optimistic Memory', sounded really distinctive, as I had never heard the dull old concept described in such a manner.  Consequently, minutes of diligent research ensued (one Google search), that led me to a National Institute for Computational Sciences (I never heard of them either), page containing the following definition for 'Optimistic Memory (allocation)':

Optimistic Memory Allocation means that Linux is willing to allocate more virtual memory than there is physical memory, based on the assumption that a program may not need to use all the memory it asks for.

So in layman's terms, the concept of Optimistic Memory in a Linux computer system has less to do with looking backward than with looking forward. It is a kind of design that attempts to release computing resources using an 'optimistic' assessment of the need for said resources.  It says - 'Ok process ABC, you are asking for X amount of resources, and I only have 50% of what you are asking for readily available, but I will go ahead and let the process start, because I am pretty sure you really don't need all the memory you are requesting. 

It is in a way the exact opposite of what systems folks are trained to do, and what often experience suggests when planning projects, estimating costs, and assessing risk. I am sure we have all heard the old standards of 'Take the initial estimate and double the time/resources/costs' mantra when in project scoping or solution design phases.  

But why is that the case?  Are we (the collective we, surely I don't mean you personally), really so bad at truly understanding new technology, estimating our own skills and capability to utilize new tools, or assessing the organization's capacity to adapt and change?  Are we simply tying to cover our own flanks by making the dire error of actually underestimating the level of effort to do anything? 

I don't know, but sometimes I think that our inability to see things positively, to actually employ some 'Optimistic Memory' in the face of change or innovation or new technologies is a handy anchor to keep us safely in port instead of actually venturing out to the open water. Better to keep the staus quo than try and fail perhaps.

Horrible post, I know.  But it did start out optimistically, and that has to count for something.

Explanations by Geeks

There is a classic principle called Occam's Razor that suggests that in a complex situation, when faced with competing potential solutions, that the simplest solution, the one that introduces the least number of assumptions and variables but still results in the desired outcome or proof -  is generally preferable.

I think that an appreciation of the concept of the Razor is important for folks that are charged with designing, deploying, explaining, and exploiting new technologies in organizations and for Human Resources departments that perhaps have traditionally been somewhat technology averse. Technology types and the geeks among us that love to spend time extolling the virtues of the 'latest and greatest' new tools sometimes have a tendency to want to talk about big, complex solutions since we are able to envision the end state, a kind of nirvana of interconnected and interacting systems and processes that will put essential information at the fingertips of those managers/leaders/employees that need it, all in real time, and in cool and colorful interactive dashboards.

While it is important to appreciate and understand the end-state vision we can't lose sight of the current realities in many organizations - employees swamped with day-to-day responsibilities, using tools that while not necessarily are the latest and most exciting, are at least familiar and comfortable, and often unable (or unwilling) to support large-scale change in a sweeping and transformative manner (that makes the geeks happy).

Don't forget that small victories and improvements might be needed to establish some credibility, start opening the organization's minds to looking at process and technology in new ways, and serve as an important foundation for instilling the kind of environment of curiosity and creativity and change that the geeks are after.

Start small.

Maybe even as small as 'better staplers and scissors'.

Note : Picture credit - Viktor Koroma from the 'Sex, Drugs, and Office Supplies' series.

Note 2 : The HR Happy Hour Show is live tonight talking about the law and social media with the 'I Fought the Law' show, 8PM EDT.

Satisfaction Guaranteed

Buyers of enterprise software have typically have had very few, and mostly unpalatable options available to them to remedy a systems implementation project gone awry.

Let's say the company is seven months in to the project, the software is either not functioning properly, the project team is either understaffed, incapable, or dysfunctional, or funding has been withdrawn.

What are the options?

1. Cut bait - Scrap the project, send away the consultants, don't renew the software and maintenance licenses, and perhaps write-off the project costs to date, (and possibly look for a new job). The project was important but not important enough to cripple the organization.

2. Vendor wrestling - Needed when the primary cause of the problems are software bugs. Hopefully you have enough juice to lean hard on the vendor to get some action on outstanding issues, and while you are at it maybe you can wring some free training credits or a couple of passes to the next user conference out of them.

3. Clean the decks - Sack the consultants you are working with, install a new project manager, form a new 'core team', and re-launch the project.  Toss in a (second) big kick-off meeting and make a few stirring speeches about lessons learned, and a need to change processes, etc.  This might work. Maybe.

4. Re-open the vendor evaluation - This is the old 'it's not me it's you scenario'.  Maybe the organization did not take enough time in the vendor selection process and a 'fit' between the client's needs and the solutions capabilities did not materialize.  Starting all over again with a new solution might work.  Or it might not.

5. Sue - Who can the organization sue?  The software vendor, the consulting partners, maybe both.  There are some celebrated and high-profile cases of organizations suing for damages over failed enterprise software implementations.

6. Get a refund - What? Refund?  There are no refunds in enterprise software are there? Typically not.  But this week Halogen Software, a leading provider of Talent Managment software announced a new 'money-back guarantee'. According to the company:

After using one of our assisted implementation programs to bring any one of our products into your organization, if you’re not happy with it, we will refund in full your unused subscription fees – as long as you let us know within 6 months of your purchase date

Halogen is the only vendor in this class that offers such a program, and I think it's uniqueness is a testament to Halogen's faith and track record of excellent customer support. 

But it is also telling that in projects that can be incredibly complex, expensive, lengthy, and risky that having a guarantee of any kind is extremely unusual. Full marks to Halogen for having the courage to offer such a guarantee, we will see if any other vendors follow suit.

Does anyone have any knowledge of other enterprise software vendors that offer a comparable guarantee?

While you contemplate the question, have a look at my favorite 'refund' scene, from 'Breaking Away'