Blogs

3. Challenge the Process – Principle 2: Experiment and Take Risks

Risk taking is one of the expectations of a great leader. However, the risks need to be manageable and have an acceptable probability of loss. Some time ago I was involved with an E2.0 initiative where there was a choice between a new, fancy, bleeding edge tool and one that had been tried and true for at least 10 years, evolving incrementally with new functionality and extensions. My IT/IS staff were all over the newly released app because it integrated social media, collaboration, communities, and repositories with a slick visual interface and underlying DBMS. All of the tech folks felt that this sexy new tool would run circles around the other tool and provide them significant opportunities to learn. The interface was extremely difficult to understand, unless you had been trained as a pilot on a B-1 Stealth Bomber. The tool had been installed for less than 6 months in a couple of dozen firms, but none of them would have included the Fortune 1000.

On the other hand the knowledge worker stakeholders, managers, auditors, and executives were much more comfortable with the product that had been established almost a decade ago. The app was current; it wasn’t some dog from the last century. However, the interface was actually designed by information engineers and architects who understood usability engineering. The software tool was slightly conservative, easy to navigate, lacked glaring and highly contrasting colours, and provided unambiguous menu selection items. Justifiably so, it worked well, was well-tested, and contained context sensitive coaching embedded in the product. The tool had been installed for many years in hundreds of firms, including a terrific representation of Fortune 100 firms.

In the middle stood the newly formed ECM/ERM business unit, consisting of new hires, current stakeholders who had been transferred and comprised of about one third folks from IT/IS. This would be this business unit’s first major deployment since it was formed. The ECM/ERM leader was a seasoned Director with operational business experience. The newly appointed Director wanted to increase the probability of a successful deployment, will minimizing the risk of a career limiting fiasco.

So the battle began. IT wanted to unduly influence the outcome of the choice by selecting untested “glitz and bling,” while the actually workers wanted a tool that worked. The costs were comparable, so price was not the sticking point. The business unit held the purse strings, but these stakeholders wanted the IT folks on side for support, scaling of the app across a widely dispersed geographical space, and multi-level (line staff, managers, and executives) deployment. The ECM/ERM business unit needed a success.

We asked for at least three rock solid references from each vendor and followed them up. To our surprise two of the three sites for the new tool basically said, “run screaming into the woods if you want to choose this tool.” We found balanced responses from the well established vendor, where a number of weaknesses (that were not critical) had been highlighted, but benefits and strengths were very well explained. We had our IT/IS folks talk with their counterparts in all six firms. To our astonishment, as we dug deeper into the new “blink & bling” product, we discovered a plethora of “undocumented enhancements” (sic), user hostile interface functionality, exceptionally poor customer support, and very poor technical support. Finally, the ECM/ERM Director presented the bottom line in a meeting between the stakeholders and the IT/IS support. The stance boiled down to a simple business value proposition:

Did the company wish to acquire a tool that would work and help make business processes more efficient and effective, or did the firm wish to become a beta test site for a tool that did not work out of the box and where our staff would be unpaid testers for an application still under development?

Even the IT/IS staff voted for the well-established, but somewhat conservative tool. All parties were interested in supporting the firm to be profitable and achieve its mission. The risk had been considered, and no one could afford the obvious loss the firm would incur with a tool that was so experimental, as to be dysfunctional.

Based upon this story, do you feel the ECM/ERM Director would have experimented if the risk had been lower? Actually, yes, the Director had been willing to generate small wins and learn from experience, but the essential mission of the organization was not to explore uncertain applications as an adventure. The mission of that business unit was NOT “to go, where no one ha gone before.” During a period of economic collapse, the firm needed to be steered won a firm and stable path of success.

Small wins were still possible with the choice the firm made. The decade old firm’s tool had a stable API (application program interface), and used RPCs (remote program calls) that subscribed to international standards. Other tools were identified that might increase functionality and interaction with other current tools, while minimizing a “cowboy” approach where data could be lost or compromised. The Director helped the stakeholders and IT folk to identify a number of elements that were important to their work, such as a wiki application, but were not critical for acquisition and deployment.

A suite of interfaces were created where data could be entered once through either application, and be available though the other app. The IT staff continued to be challenged and were able to experiment with new tools to help keep them curious and engaged. The “experiment” was controlled” and could not bring the firm to its knees if the application did not work. After a year, some of the side apps where showing excellent results, while the stable core E2.0 application provided the trustworthy first line of knowledge diffusion and business support for the firm.

Of course, all parties in this endeavour learned from the experience. A tighter relationship based upon trust and integrity evolved between the stakeholders and the IT/IS staff. The Director facilitated a renewed sense of ownership of the processes, systems, and data/document artifacts. Everyone was learning to apply the new core E2.0 system to increase efficiency and effectiveness, while many folks were able to experiment with new media distribution, digital assets, on-line elearning, and business networking with the customers. The Director had created a climate for learning and had stimulated many of the stakeholders to embrace experimentation through a low risk option. The firm had become hardier, and more robust. There was flow!

I will be unavailable until the beginning of November, but when I return we will touch upon Csikszentmihalyi’s concept of process flow and study Kouzes & Posner’s Practice # 4: Enabling Others to Act – Principle 1: Foster Collaboration. Your feedback would be greatly appreciated for some of the topics I am trying to convey.