The fundamental reason for implementing new software is to drive behavior change. We are driven, like it or not, to seek constant behavior change in the form of increasing technical power. This is something Martin Heidegger pointed out in his last interview. It is part of the human condition to seek to diminish the cost of accomplishing tasks. We want to spend more time connecting with each other. We want to achieve greater results. We wish to remove the tasks that ask us to behave like automatons so we may focus on tasks that allow us behave like the humans we are. We are constantly looking to remediate matters of the human condition.
This drive, when properly harnessed by the organization, is a boon that can yield significant results. People are not only driven to seek improvement, we are also hardwired to connect and work with each other in collaborative settings. It’s been said by anthropologists that perhaps the only impulse greater than our propensity for violence is our desire for trade. Trade comes in many forms. We are interested in the trade of information, ideas, and perspectives that drives innovation. Of greater import, we are interested in how we can unleash transformative innovation using software, in particular, enterprise applications.
Sadly, innovation often gets confused with improvement.
If we inspect how we treat software, we will find that we usually look to the adoption of new software as something that just makes things go faster. Or sometimes cheaper. In accordance with our mental models of what work looks like, which is commonly informed by the factory floor of previous eras, we look to software as a reductive coefficient to our existing workload. It is used as palliative care for the discomfort of labor. This approach is problematic. This is due to the fact that a palliative approach to innovation leaves one vulnerable to competition. At the risk of chiming in on an oft-repeated refrain, mediocrity in a world of non-local competition puts one’s business at risk. An example I’m fond of repeating has to do with a company that produced car lifts. Faced with stiff competition, they continually retrenched until they were finally bought out. Turns out, it wouldn’t have mattered if the entire staff had worked for free, the cost reductions weren’t enough to make a difference. They didn’t need to do things better, they needed to do things differently. This is the rub. Businesses get stuck trying to do the same thing faster or cheaper without understanding that the world they’re competing in has changed. Just ask Gateway what it was like to compete with Dell when Dell started to use the internet as its primary sales portal.
To co-opt and repurpose a concept outlined in Michael Geoghegan and Paul Pangaro’s paper, “Design for a Self-Regenerating Organization“, there are three forms of innovation/improvement. The first form is efficiency improvements, or more appropriately labeled, waste elimination. This is the work of something like Six Sigma, as noted in the paper. The second form is invention, or the remediation of existing problems through new solutions. The third form, and least common, is the opening up of new semantic spaces. That is, the understanding of the world through new terms, a new language, and in doing so, exposing new problems for the other two layers to address. As pointedly demonstrated in the paper mentioned above, organizations are optimized for addressing efficiency improvements, invention less so, and very poorly oriented to the third form innovation. Organizations struggle so mightily with developing new ways to understand the world that it’s the business lifecycle that tends to refresh the ideascape within the marketplace. Like nature, the marketplace is amoral and doesn’t care if your business just went out of business (caveats for the 2008 crisis). Of course, businesses want to persist and be great, that’s why Jim Collins’ book, “Built to Last” is so popular. People want to beat the odds.
Beating the odds requires that organizations move beyond mere efficiency gains as a mode for improvement. In fact, it should look beyond invention as well. It should seek to understand in new terms what the business is seeking to accomplish. In practical terms, the business needs to understand what it is seeking from its people and transitively, its software. It needs to compare those expectations against the expectations of the environment the organization operates within to understand whether or not the two are in alignment. As argued convincingly in “The 5th Discipline“, systems thinking is a highly recommended approach for attending to these efforts.
Vigorously attending to the work of understanding the world in new terms is of absolute importance to any organization, especially before it makes a commitment to capital expenditures for an enterprise application overhaul. Rip and replace methodologies are expensive to perform and even more costly in the long run. This is due to the fact that a major commitment to change such as overhauling an enterprise application is a considerable opportunity for innovation. Not seizing the opportunity to change means a second capital expenditure down the road to overhaul the very system implemented. Or worse, if not attended to.
Enterprise applications aren’t cheap, especially the queens of the business, the ERP. They’re particularly prone to project failure. Most surveys show that ERPs have a 30% chance of being delivered on time and on budget. A 70% failure rate for projects is a dismal number indeed. A significant amount of emphasis has been put on exacting rigor on the implementation process. There’s a proliferation of PMPs within IT. CompTIA has their Project+ certification. Business analysis frameworks have risen up. Despite these noble, and entirely necessary efforts, the numbers haven’t wiggled much. We are, more or less, at the same failure rates as we were ten years ago. A few years ago, it appeared that the failure rates were on a downward march but in 2009, those numbers started to climb back up to where they were.
Perhaps the problem isn’t entirely around project management rigor but around the fact that businesses tend to be larger messes than imagined at the inception of the project. Project budgets and deadlines are, at best, educated guesses. They have to be. Think of it this way, remodeling an old home is a risky proposition. How many times does a contractor walk-through an old home, review the blueprints and design documents for the remodel and complete the project according to the original time estimate? The reason for this is that no one knows what one is going to find when they start peeling back the walls of a 50 year old home. Both the contractor and the home-owner understand this. The same holds true for enterprise applications. Who knows what you’re going to find when you start asking questions? Perhaps the reason that the project is late and over-budget has to do with the fact that the business is a larger mess than anticipated. Ask any business analyst that has participated in an major enterprise application overhaul effort. The skills needed is part oral historian, part archeologist, part gumshoe, part stenographer, part facilitator, part diagrammer, and part therapist. Walking into any department as part of a major implementation team is an uncertain proposition. One must be prepared to kick over rocks, ask difficult questions, and to stick with them until satisfactory answers are reached. Given the human element, especially with the usual adversarial stances toward other departments and IT, building trust, an element commonly associated with time, is a critical tool. Trust, unfortunately, doesn’t recognize deadlines.
If an organization has decided to commit to an enterprise application overhaul effort before seeking to understand itself and its environment, then the project is already at significant risk. The odds of success of a project truly is a mirror of the culture of the organization. This is why it’s so important to craft a culture that reflects that values and approaches of something like Lean Services. A culture of continuous improvement lessens the front side work of the application overhaul effort, particularly around building trust so that accurate narratives that deliver a catalyst for innovation can be captured. Without insight, murky waters will swirl around what actually needs to be accomplished at the local level. The risk is that the necessary change will not be tended to. What will happen is that the application overhaul team will deliver the same process on a new platform. Under the constraint of a looming deadline, innovation is not incentivized. They will do the wrong things righter. Deadlines incentivize this kind of approach. The main measure of a project is, was it accomplished on time and on budget? Not, did it actually deliver the right kind of change? Deadlines are the bread and butter of projects. One can’t expect behavior that isn’t systemically incentivized by process measures. The seeds of innovation has to be planted well ahead of the project itself.
The recognition of this has been a driver for organizations implementing centers of excellence, particularly around business process management and business process improvement. Application overhaul efforts need be incubated for extended periods of time in a center of excellence long before the project trigger is pulled. This might seem to be a little counter-intuitive. In particular because centers of excellence are commonly associated with the first form of innovation, waste elimination, whether it is along the lines project management, business analysis, or otherwise. To refer again to the Geoghegan and Pangaro piece, an essential component to the ability of an organization to evolve is the presence of a protected area where the learning of new ways to describe organizational phenomena takes place. A center of excellence is a candidate space for this very thing
If one imagines a center of excellence as a centrally located circular node in the organization, the outer ring of the center of excellence must be attendant to the first form of innovation, efficiency and quality. Individuals and departments will need to interface with the CoE. This, of course, gives the CoE much needed authority. The more successful the CoE is, the most legitimate its efforts are in the eyes of the organization. Ask yourself, if this is the only thing the CoE delivered, what would its lifespan be? The value delivery would diminish over time. This is due to the fact that the CoE will have been created to address very specific problems. By delivering training, certifications, guidance, and other forms of support, those problems will begin to evaporate. New problems will emerge, problems the organization lacks competency or language to describe. The core of the Coe must contain staff dedicated to voraciously consuming research, applying new ideas to describing organizational phenomena, and revealing new problems. People like your enterprise architects, business architects, business analysts and so on should populate this core. True innovation threatens the status quo. It threatens those that have made their livelihood using older forms of mental models. It is truly threatening to those that have succeeded in navigating up the hierarchical ladder; those that have the power to snuff out innovation. And they do.
This is where one gets those companies that, “just don’t get it anymore”. IBM in the 90s. Microsoft in the early to mid-2000s. Great ideas were killed and talent forced out because these great ideas didn’t jive with the way those in power thought.
Part of the reason for this is that new languages to describe organizational phenomena sound like gobbledygook to the uninitiated. This very blog post might sound like it to some! When confronted with mumbo-jumbo that doesn’t resonate with previous mental models, those in power may exercise their right to disempower the effort, either through shame or outright axing the program. Safety is paramount. Those within the center of excellence practicing the very difficult work of unfolding new problems must be able to do so without the interference of the business at large. This is a difficult proposition for the organization to accept, largely in part because it doesn’t figure either directly or indirectly into the value stream. “Just what are those eggheads in there doing? They better produce something soon or the CFO is going to cut funding.” Well, the CoE should honor their obligation to the organization and produce value but it cannot work on strict deadlines. Research takes a variable amount of time. But it must produce. We all must produce.
The organization will begin to feel the need to shift. Perhaps from outside pressures. Perhaps from algedonic signals like staff morale. Management will be begin to feel pressure. This is when the CoE must step in. One might argue that a CoE should do so before the pain begins but even a normative post such as this one must acknowledge practical realities, management will not have a reason to listen until the pain begins. Of course, the riskiest thing for the CoE to do is bring forth what they have been incubating and deliver their unique value. As noted in,”Design for a Self-Regenerating Organization“, the risk is that management and the CoE research team may not be able to communicate in the, “Pask-ian sense“. Why not try? It’s what they’re paid to do. Management should be compelled to honor their obligation as stewards of the organization and listen intently on what is presented. The CoE should be able to tactfully communicate why new modes of action and new models are required for continued organizational viability. This needs to be done in a way that, if possible, gently shifts the mental models of the management team. And management isn’t so bad. Turn-arounds happen all the time. Usually not through the hero CEO but through gritty and purposeful engagement by the entire staff. It all starts with an active, engaged, and connected management team. But before the cascade communications can happen, there must be understanding. That understanding will inform a plan. That plan will beget a program. That program will have a project (or more) to initiate change. But it all starts from somewhere and it must begin in a place free to explore organizational problems outside of the language of the institution.
When pressure abounds, there must be a place where there is a thorough understanding of the sources of pain and how to effectively address not the symptoms but the cause of the pain. Horizontally positioned units like a center of excellence is a perfect place to house an innovation incubator. Some organizations will have no difficulty in creating a center of excellence. They’re usually bigger. Other organizations, medium sized ones, have difficulties meeting operational goals already and they don’t feel like they can spare the staff. There’s ways around that, forming a team, setting aside sacred time, instilling a learning culture, and having crucial conversations. There’s ways even if one can’t formally assign staff to a center of excellence.
If you have a small staff, you probably already are a center of excellence. That’s why people love start up cultures so much. You’re locked in, focused, and don’t have an organizational blanket over you to suffocate critical thinking.
To revisit the staffing issue that invariably arises, sometimes, there’s just not enough seats for everyone no matter how they get arranged. But sometimes, the processes themselves are hopelessly broken and adding human middleware is just going to distort the business. How would you know? Many management techniques center around either adding or subtracting people or adding technology thoughtlessly. It’s never that simple. Address what is needed and how those needs to be reflected in the way work is done, and hence, the software. This will be what informs your application overhaul.
This should be a planned and methodical approach. Build sacred ground in your organization but build it in a way that there is horizontal access to every department. Select staff that is agile, motivated, and curious. Let them be not experts but rather, constantly seeking knowledge. You know the types. They’re the ones that are always asking to have a book club at work. Jim Collins, not Tom Clancy. Give them a mission. They must understand the nature of their work and its cruciality. Protect them. They can be perceived as a threat to those that have, “yoked the organization to their way of doing work.” (Geoghegan, Pangaro). They might even feel threatening to you! But the heart of agility lies in honesty and humility. Authentic professional relationships help minimize dysfunctional behavior.
Check in with them. The work they are doing should ultimately be focused addressing real problems. The third form of innovation requires some level of abstract thinking and work but it should ultimately boil down to real problems facing the organization. It is the third form of innovation that will feed the second form, invention, which will carry out the concrete solutions to the problems discovered in the abstract.
Finally, listen to them. They carry with them the seeds to your future. Without their work, your organization medium to long-term prospects are at risk. Remember, survival is not mandatory.