Category Archives: IT Leadership

Centers of Excellence and the Third Form of Innovation

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.

Tagged , , , ,

Beyond Mere Measure

The game is always changing. The fundamental rule of the game is that playing the game changes the rules.

At some point, every business will reach a point where it realizes the way it’s playing the game isn’t leading to the results it desires. So the leadership in the business will do what any reasonable person would do, investigate why. The answers are never easy. Oh, there’s easy answers out there such as, “We need to hire better people.” or “We need to invest in better tools to do our jobs.” These answers are technically valid but inappropriate. They assume the problem with performance is around affordance and capacity instead of facing the five devils of organizational underperformance: Imitation, Inertia, Suboptimization, Change of Game, and Shift of Paradigm (Gharajedaghi, 2011). Frankly put, hiring better people and investing in better tools may end up empowering the business to do the wrong things righter. The business may have been designed in a way to manage and resolve problems that may no longer be relevant. In the words of Stafford Beer, “Acceptable ideas are competent no more, but competent ideas are not yet acceptable. This is the dilemma of our time.”

This, of course, is a central concern to IT. No work is done in the business that doesn’t rely upon IT in some way. So whether the business flippantly decides to invest in better tools (this is code for a new enterprise-wide IT project) or carefully investigates what has happened (hopefully using the Balanced Scorecard methodology), IT will have a role to play. Perhaps IT will play a leadership role in the conversation. One hopes it would, as either lack of leadership or incompetent leadership from IT dims any business’ prospects.

Let’s just assume that the business is following the Balanced Scorecard method. It defines its perspectives. It builds its strategy map. With these things built, the organization will need to construct its measures. The first rule of management is that one can’t manage what one can’t measure, so to manage change, it becomes necessary to build measures. The risk of implementing measures is that doing so introduces a meta-game, the measurement game. We’ve all seen this. We’ve seen the underperforming IT department point to three or four nine uptime as a measure of its success and the rest of the business shake their collective heads, wondering if IT will ever “get it”. This isn’t just something IT is guilty of. To prevent the “chasing measures” game from occurring, there must be a recognition of emergent properties that cannot be directly measured. Usually cooperation and coordination, commonly known as teamwork.

I remember watching a local Telco/ISP that I worked for put together a brilliant advertising campaign. This company was one that was perpetually always the bridesmaid and never the bride. It lagged behind its competitor and had a mediocre reputation in the community it served. The Marketing department found a weakness in its competitors product and exploited it mercilessly. Its marketing campaign was so successful that it met and exceeded every measure it had on the books by far. Unfortunately for the company, there wasn’t any coordination and those responsible for delivering service hadn’t built out any capacity and drowned under all the orders. At one point, it was taking this company six weeks to turn on internet service for new customers. That company’s reputation never recovered. There’s a new rumor of its buyout every month. I suppose it will only be a matter of time.

Well, at least the Marketing department can rest safe in the fact that it did its job well even if the company didn’t. This is the insidious side of what Jamshid Gharajedaghi refers to as Type I measures. These are your quantifiables: how much uptime, how much revenue, how little turnover. They don’t tell larger stories and they incentivize behaviors that may run counter to the business’ objectives. To pull from sports, is your star player incentivized for winning scoring titles or for winning championships? What is needed is a recognition that there is more to the story than Type I measures. These are your Type II properties, your emergent properties that come from interaction. Type II measures are your unquantifiable but still very real measures. In our individual lives, they’re happiness, success, love. These are all emergent properties that come from a relationship between one or more entities; sometimes other people, sometimes the environment. We can’t measure happiness or love but we know it when we see it. We know when we’re more or less happy than previously. In the organization, they’re things like coordination, teamwork, grit, success. They’re extremely important. Who knew? Dr. Deming once said, “The most important figures that one needs for management are unknown or unknowable but successful management must nevertheless take account of them.”

In IT, what are our Type II measures? Being laterally positioned in the business, they’re probably the scariest measurements we could ask for. It’s safe to sit behind standard measures, but that’s why mediocrity is so prevalent, it doesn’t require courage. Pardon the sports metaphor but IT is the point guard of the business and so our measures are similar. Are we setting up the business for success? Are we leading and getting other departments in position to score? Are we coordinating seemingly disparate efforts that, despite organizational opacity, impact each other directly? These are our Type II measures. Just as the successful point guard isn’t just a masterful coordinator, they have leadership properties, so must IT lead. If someone’s head isn’t in the game, they’re there to help them snap out of it. If people are out of sync, they’re there to coordinate efforts. Sometimes they’re scoring and at others they are enabling others to score. They are truly laterally positioned. The same is true for an effective IT.

All work is enabled by IT. We must help the business recognize this fact. We must not halt at our measures, which are very important and must be included in every discussion, but recognize that they, like a compass, really point to our Type II properties. How successful is IT? Only as successful as the business it supports.

The Art of Synthetic Simplicity

IT is in the business of creating synthetic simplicity. We’re called upon to unravel complexity and deliver services that improves productivity or improves organizational knowledge. The nature of IT’s work lives in the world of abstraction and representation. This is in contrast to other business units that interact with their environment in very concrete terms. This means that the challenge of relating to IT isn’t bound up the technical components that make up the concrete portion of IT’s work. Every industry is complicated. In terms of technology IT is no different than a mechanic or an electrician. Every specialization has a vocabulary and perspective that requires initiation to understand. What separates IT is the abstractive nature work they must perform as well. In a sense, it’s the difference between talking to a geometer (such as a carpenter or architect) and a topologist. And yes, there are applications for topology in the business.  At least with a geometer, their work is rooted in familiar concepts such as distance and angles. Compare that with trying to discuss with someone who performs a chunk of their work utilizing homologies. IT is home to the topologists and philosophers of the enterprise. And, as I will make the case, the ecologists as well.

Let’s take a fairly universal experience as an example: building a student registration application. Most everyone in the United States has experienced student registration. It is, for the most part, a straight-forward experience. Students have requirements to graduate, classes fill those requirements, classes have rooms, classes have teachers, teachers have students. But once one starts managing students, one must discuss managing teachers, and once one is managing teachers, one begins to touch payroll and benefits. Not to mention scheduling. There’s also weird circumstances to handle as well. What about teachers that are also students (if you’re a university)? What about pre-requisites? Sabbaticals? Student-teaching gigs? Complexity creeps into the room and takes a seat next to you. Its invisible but palpable grin bears down on you. You might end up with a case of scope creep. This is going to take longer than everyone expected. The end result will need to be a simple interface. A package of workflows. A suite of reports. The end user will need to experience synthetic simplicity. There’s a reason that it’s a rite of passage for an IT worker to design a student registration application.

What it will take to get there is a team of business analysts working with your department, interviewing subject matter experts and holding charrettes. Business architects, programmers, and database modelers all working to build ontologies, business logic, business domains, and other attendant artifacts that reflect a perspective regarding your business. They’re building a system to absorb the complexity of student registration. This work of unraveling complexity and then repackaging it in an ordered and maintainable system requires a nexus of collaborative creativity. This is generally something the business has a very hard time relating to. The work is esoteric and abstract.

In a very real sense, complexity hasn’t been reduced by IT, it’s been displaced out of the business and into the realm of IT. This is good news though, complexity scales much better within IT systems in comparison to manual and unmanaged processes utilizing human middleware. At scale, it’s certainly less costly although not always in the sense that it will reduce your operational expenditures. There’s a number of ways to be costly outside of mere OPEX.

To manage scope creep and avoid building a monolithic and monstrous enterprise application, boundaries around the application must be created.  Modules for communicating with other systems must be built. This means that the subtle work of IT is bound up in the act of naming; that is, the drawing of distinction between systems and the background environment.

So take the student registration application built and managed by IT and add to the mix a payroll and benefits application, a curriculum management application, so on and so forth and you can see emergent complexity begin to unfold. IT doesn’t merely manage systems and applications, they manage a sophisticated ecosystem. And right it should be because it’s an abstracted mirror of the enterprise. It is the representative ecosystem of the organization along with its entities and relationships. Tending to good stewardship, IT must rely on practices such as application portfolio management and governance.  They must be baked into IT’s processes and procedures. This is a big deal. Unfortunately, it stands in stark contrast to the order-placement relationship we have had with IT in the past. It’s also quite different from our own individual experiences as consumers. Quite frankly, it just looks like red tape. While tempting to dismiss, the imperative of a healthy ecosystem cannot be ignored.

Managing the ecosystem of enterprise applications that drive the business is a complex affair in its own right. Analogous concepts such as dealing with invasive species and other disruptive elements like pollution hold true for IT as well. What manifests in response are processes and procedures for ensuring that the healthy ecosystem the business has created with IT isn’t put at risk. Concretely put, it’s not unlike making sure that seeds and plants from Hawaii don’t leave with you when you depart. The unplanned introduction of new systems can, over time, consume disproportionate resources resulting in the inhibition of innovation elsewhere. One of my favorites examples is a training database for a major pharmaceutical company. Built by someone outside of IT, it eventually contained millions of rows of training data.  It was a three table Access database joined on the comments field. IT wasn’t looped in until it was on the verge of collapse. Had it collapsed, the penalties from the FDA would’ve been immense. Additionally, the media would’ve pilloried the organization. This was a real thing. Imagine the cost associated with it. This is the stuff of legends.

As with all things, governance should be elegant and graceful. In practice, it gets a bit messy. But evolution is messy. It is IT’s responsibility to avoid a Kafka-esque nightmare. It’s the enterprise’s responsibility to understand and communicate their problems, working with IT as partners to find solutions. Mature businesses leverage IT’s unique lateral position, perspective, and skills to lead. An indicator of a organization’s prospects begins with a look at the health of the IT department and how well they manage the business’ application ecosystem.

Data Management, Waste, and You

Data catastrophes usually come in the form of clumsy fingers. Sometimes it’s a user. Sometimes it’s an IT administrator. The recovery process is straight forward, right? Find the backup. Restore it. Resume eating Bonbons. Of course not. Technically, backups are easy. In practice, they’re amazingly difficult. And it has nothing to do with technology.

Backup sites tend to behave like digital versions of the junk drawer at your home. Just on a massive scale. The business, unwilling to part with data, just wants to back up everything. IT is left trying to sort out massive amounts of data, much of which it knows nothing very little about in terms of importance and relevance. Time to recovery? Point of recovery? Forget about it! And the money spent on storing it? Dizzying. Organizations that don’t treat their data as an asset (complete with value depreciation) often fall into either of two camps: those that continue to pour money into saving everything or those that are reluctant to spend money on storage. If you’re in former camp, good luck finding anything when you’re saving everything. If you’re in the latter camp, you’re going to eventually inadvertently push important data out of the system, losing it forever and not knowing it until time comes to use it. Both approaches are costly, one just defers the cost until later. It’s in every business’ best interest to manage their data as an enterprise class asset.

If our offices reflected the way we managed data, we’d find ourselves unable to navigate to the restroom with all the clutter. The individual practice of saving everything you’ve ever done on a computer rolls up into massive and gnarly enterprise problems. We also institutionalize it within our databases. Some of the best minds in the world have worked on trying to assist in resolving this problem of the human condition, this need to hoard data and save it forever, ignoring the diminishing return on value that much of it represents. Since we all struggle with data management, there’s an entire industry built around helping businesses with it. So, with costs starting somewhere in the low six figures, you can acquire yourself a data deduplication system where you can deploy some of the best mathematics in the world to assist you in managing this problem. This buys you only time at the cost of extra money as data deduplication is costly. The dike is built but the waters continue to rise.

Like backups, the value of deduplication is marginalized without a coherent plan to address on how to manage data as an asset. And managing data as an asset is a challenge unless one takes a systems approach to data management. The imperative of a systems approach to data management is that IT is laterally positioned within the business. We’ve had a number of years of experience within the industry with service-oriented architectures and even longer with extract-transform-load operations. We’ve built data warehouses. We’ve written an uncountable number of reports. We’ve long recognized the flow of data throughout the organization. There’s no one better positioned than us to lead our businesses into these brave blue waters. What is required of us is that we evolve that model to understand the flow of work, or even better, the flow of value creation throughout the enterprise. We need to understand what is required by each of the subunits to do precisely the job they need to do. As any analyst can attest, what is required likely doesn’t match what is done. This is how IT must provide the leadership necessary to put together a comprehensive plan of data management that treats data as an enterprise asset replete with backup schedules, archival schedules, records management, and more.

To that end, it’s time we resurfaced the Viable System Model and applied it to data management. Stafford Beer’s model dissects the organizational model from a systems perspective and describes the necessary subsystems required for an organization to be viable; that is, to remain effective within its particular ecosystem (or market). An excellent introduction to VSM can be found here.

As we progress into our respective data management programs, we will need to align each organizational unit with their appropriate system or systems, discover what states each system requires to maintain control (referred to as variety) and how each system interacts with the others. That leads right to discovering what data is needed to support control and what data needs to be ignored (referred to as attenuation). Understanding what data can be attenuated is key. Coordination and control systems can consume only so much information at a time. Oversupply of information leads to costly delays and waste. Most questions about data aren’t necessarily binary. That is, it’s not usually just a question of keep versus discard but, rather, how long to keep it and in what state.

If you’ve built a data warehouse, you’ve likely asked many of these questions already. The goal would be to expand that work so that the data warehouse isn’t the fixed point that everything traces back to. One of the tricky tasks of IT leadership is to decouple programs from the technologies that support them. Failure to do so leads to very costly evolutionary programs or over-reliance on obscure systems. Think about California and the amount of money they’re spending on COBOL programmers to support their legacy systems today. Take the work you’ve done in building data warehouses and expand upon it with the VSM. Generalize it.

What is particularly attractive about applying the Viable System Model to data management is its neutrality in language and flexibility in application. It has a lexicon that is neither rooted in technology nor business language. It is intuitive to understand and is malleable enough to be utilized in most any situation.

There’s more to this than just backup schedules. Backups are just the start. Your programmers and analysts, once involved, are going to start revealing data waste all over the organization. Like a compass, that data waste will point you to institutional waste baked into stagnant business processes. You’ll be a catalyst for business process improvement. Or just business process management if you’re starting humbly. What it takes is a common framework and language that sets the stage for asking the right questions.

It’s critical for you to start this now. Why? Because we can no longer afford to blindly throw money at problems that require planning and management. We’ll let Peter Sondergaard from Gartner be the final punctuation mark.

Tagged , , ,

Humans are O(2^N): Dealing With Unmanaged and Human Induced Complexity

Once upon a time, I found myself pitted against a pack of fire-breathing dire wolves with only a spoon and cereal bowl to defend myself. Let’s try that again. Once upon a time, I attended the kind of meeting that every single IT worker  eventually attends. It’s the usual story, some folks outside of IT desired to automate a number of workflows that were, at the time, almost entirely manual. They wanted to make them go faster. So, of course, we needed to look at their workflows, so we sat down and had a meeting. We started to walk through the workflows, seeing where we could automate. As the meeting progressed, the number of exceptions, sub-processes, changes in status due to special attributes, judgment calls, and other decision points began to overwhelm all the participants in the meeting. It was maddeningly byzantine from soup to nuts. It didn’t take long before the complexity became apparent to everyone present and the individuals that had called the meeting eventually paused, looked at each other, looked at me, and told me that they’re going to have to go back and map all of this out and come back. Yikes! The question that entered no one’s mind (sadly, including mine) was this, “Who’s doing all this work currently?” The answer is human middleware.

Mark McDonald’s blog post has really stuck with me since I’ve read it. Organizations will use people to keep themselves from doing the scary and difficult work of changing the way they do business. The world has changed; the nature of work has changed, customer expectations have changed, and yet, the organization continues unthinkingly in the way it always has. With my own example, no one ever called a time out and said, “Who is the customer? Can they navigate this system without assistance? Why is it this way in the first place? Can we change? What are the consequences of changing it? Is changing it worth investing in?” Instead, we all (including myself, I’m quite guilty in this story) just wanted to automate the current existing process. There was no impulse to make it simple. To make it repeatable. The consequences, had we proceeded, would have been to create a digital Rube Goldberg machine. Digital paper shuffling is still just paper shuffling.

Some of the symptoms Mark describes we all see (from his blog post):

    • Inconsistent business processes, which create multiple versions of the truth, conflicting business rules, complex operational interfaces, and different ways to get things done. All of which create bottlenecks, backdoors, and conflicting answers requiring people to figure it all out
    • Baseline budgeting, that makes resources decisions based on a prior year’s baseline that bakes in inefficiencies and creates an incentive to keep and grow the middleware and budget as a symbol of executive influence or power.
    • Accretive change which is constantly asking for more, different, and additional stuff rather than favoring of keeping the organization capable and lean.

What’s the way out? Well, it will require an evolution of your organizational culture. Evolution doesn’t tend to be self-initiated, there’s usually some form of pain required. The good news is that the pain doesn’t necessarily have to come in the form of layoffs. It can come in the form of asking the tough questions we tend to shy away from. At the tactical level, good work can be done. If we go back to the example I led with, we shouldn’t have had just a simple meeting with workflow diagrams. We should’ve had some form of Kaizen event. We should’ve reframed the conversation from mere automation to true improvement. We should’ve asked the, “5 Whys”. We should’ve led with customer value instead of looking at merely improving efficiency, especially as some reductive coefficient to the current workload.

Complexity is inevitable but not all complexity is created equal. We should strive for the complexity in our organizations to be the end-result of simple rules being applied over and over again not as a result of unmanaged and informal processes. When we can place powerful computational resources at our backs, we can move people from being cogs in the machine to providing real value. They can start doing  things computers fail miserably at such as delivering empathetic and creative value. Fact of the matter is, computers suck at giving advice. Customers will need advice. They will need human contact. Is your organization using humans as humans or as fuzzy logic gates?

Note about the title: The title corresponds to the computer science concept of big O notation; that is, the understanding of the limits of algorithms as their set sizes approach a particular value. I have no empirical evidence that people working together are O(2^N), also known as EXPTIME. There’s probably a study out there. I just haven’t found it yet.

Tagged , , , ,

Silos are for Farms (and Nuclear Missiles)

If you were to take flight, land in the middle of some random organization in the United States, accost an employee in the hall, and ask them what are the biggest problems facing their organization, chances are they’re going to say communication is a problem. It may not be number one, but it’ll be in the mix if it’s not. Communication is such a great problem that there are many great thinkers that have made their careers off of trying to help businesses address this very problem.

Solving the great communication problem is something that many businesses work very hard at and spend a lot of money addressing. One of the most common solutions is to increase broadcast. It’s not uncommon to hear executives say, “We just need to tell more people what we’re doing.” Translation: “We need another email distribution list and maybe we should install Sharepoint!” The rub is that by cranking up what they believe is signal, they’re in turn boosting noise for many others. It’s simple to see why, one person’s signal is another person’s noise. The harder we work to resolve the communication problem, the further it seems to get away from us.

The key attribute of the great communication problem is that it’s a problem to be managed and not solved. Depending upon one’s location in an organization, the level of abstraction or detail that some piece of communication has may or may not be found useful by the reader. Operational workers see a mass email from their CEO discussing strategy as hot air and delete it. An executive trying to have a discussion with an employee about work conditions gets bored with details.  In their white paper, “Creating Lean Leaders”, Kaufman Global discusses the some of the problems associated with mega, macro, and micro processes. To appropriately manage the communication problem, we should really look into how we organize ourselves

There is a belief that for the modern employee to be successful, we need to group like workers with like. This is especially so in IT, there’s a database administration group, a system administration group, a network administration group, a helpdesk group, and so on. It’s not necessarily a bad thing, this. For one, it homogenizes performance. The cost of individual underperformance is managed by group effort. On the positive side, there’s opportunity for mentorship and growth as one hones their technical skills. And given the level of breadth and complexity of many IT undertakings, there’s some work that is just too much for one person to do.

But the cost of grouping like with like is that we begin to naturally create silos within the organization. For one, each group develops their own language. Inter-group discussions slow down as workers have to find a common language to discuss their problems. This is not only so in IT/non-IT group pairings. It can happen even in between IT groups. The second problem is that vital information doesn’t tend to slip beyond the confines of the group that manages that information. In all the bustle and labor of the day, we tend to become separated from the value propositions we’re employed to deliver and we focus on operational excellence. The easy example is the common-place gap between developers and those that maintain the environments their applications run on. It’s such a phenomenon that it’s near certainty that any IT conference will feature at least one joke about the other group. It’s not hard to imagine the frustration of application developers who feel that the sysadmins are hollowing out their application servers and creating poor performance. And it’s not hard to imagine sysadmins who feel the developers are greedy for resources and don’t think about the other needs of the organization. In reality both groups are probably right though not in such harsh terms and not to the extent they imagine.

It would appear that the natural thing to do would be to group individuals according to the services they are employed to deliver. So instead of having a pure database administration group, the DBAs would also group themselves with the developers and system administrators associated with their services as well.

This type of ordering isn’t new but it is still insufficient. And ludicrously rare to see even today. Common language and information problems get assuaged within IT but the larger problems of how well those services align with an organization’s strategic position and its individual value propositions still remains and will remain until the appropriate business partners have been engaged. Engagement isn’t quite right. They can’t just be engaged but receive decision rights. They need to be involved with IT in making decisions regarding the services they use. Enter demand-side governance. This seems scary to IT workers. The idea that non-technical people could influence technical decisions is scary. On the flip-side though, the idea that non-business people (in IT) could influence business decisions is also scary. So IT and the other departments agree to keep each other at arm’s length. The consequences of this behavior include the business not being able to enumerate its needs intelligently, long-running and underperforming projects, and IT deploying unusable tools to the business. Sound familiar? The guilt for failure to perform is uniformly distributed.

Business decisions are IT decisions and IT decisions are business decisions. This realization, or rather the lack thereof, is what keeps many businesses in a state of mediocrity. In 2005 (according to one study), only five percent of Fortune 500 companies had installed CIOs on their board of directors. I remember hearing the number is around thirty percent today. Amazing.

To bring this back around, it’s not enough to bring operational IT workers together with users to ensure operational excellence in terms of performance, uptime, and tool delivery. It’s absolutely imperative to get decision makers, people who have the ability to sign a check and spend some money, to make sure that the right things are being delivered. Get the managers who depend on the outcomes your tools are delivering in the room. Be prepared for questions like, “Why the hell are we even here?” Fair enough. To start, just answer that you need them to help you make them successful. Start with hygiene factor problems. Let them gripe about how terrible the software is, vigorously take notes, and bring them back to your teams. Find the wins that can build IT’s credibility in the business place. Don’t just go for low hanging fruit, go for real wins. With enough wins, the conversation can move from what they need to be making things better to asking what we need to do to make sure we’re doing the right things for the business and doing them in the right way.

Doing this well, doing it consistently, and doing it over the long term while greatly enhance your organization’s ability to truly deliver on their stated goals. If your CIO doesn’t sit on the board, you might be able to help them get there (although that depends on the business acumen of the CIO, an ability that only a percentage have today). If your demand-side governance teams are effective, you’ll be improving the communication situation in your organization. IT and their partner business units will be getting precisely the right information from each other at the right time in a manner that’s easy to digest and disseminate.


You’ll be better prepared to successfully roll out Sharepoint when the time comes.

Tagged ,

Getting Punched in the Hall

Last night I took a call from a friend who’s been tasked to architect an update to an aging infrastructure for a large organization. The state of their infrastructure was in such a state of disrepair that daily crises, lack of available parts, and lapsing warranties prompted the organization to migrate to new hardware.

His call was prompted by the fact that, in the preliminary work that he had done, the services he had moved consumed significantly more resources than was anticipated and by a wide margin. The vast disparity called into the question what it would take to bring overall performance in line with industry standards. The cost estimates were so far outside what was budgeted that the only recourse would be to prioritize services and proceed from there.

As I asked about simple stuff such as who has an understanding of what services are critical and which ones aren’t, he said something that really struck me, “You know, every day I walk down the hall and every day someone jumps out and punches me in the gut with a new issue. I can’t tell which issues should have priority. No one knows what the business critical services are outside of, ‘All of them.'” There’s the heart of it. There’s no organization agreement on what has priority in the place of business and without that agreement, decisions are temporal and political. In fact, I would theorize the vast state of neglect is symptomatic of a long history of failure to agree.

So you wake up and find yourself in an organization that has doesn’t have strong leadership. You’re tasked with improving conditions and have some budgetary support within your own business unit. After that, things drop off quickly. Petty bickering and in-fighting dominate meetings and decisions are put on hold. Nothing calls up professional fight or flight like the above situation. You’re ready to label the organization a ship of fools and jump ship to a more attractive offering.

Not all organizations are created equal. There’s nothing wrong with leaving but make sure you leave it in a place better than you found it. In this particular situation, I called upon the advise a Gartner analyst once told me,  “Don’t be afraid to be a little wrong. Few things prompt immediate engagement like correcting someone.” My advise was for him to create an informal catalogue of the services his organization provides (however incomplete), document the supporting infrastructure elements and, this is key, for him to order them by what he thought was the most critical. Then he should call a series of cross-group work sessions to refine the list and gain consensus, starting at the operational level. He would need to make sure to recruit individuals who are likely to be engaged in the work and who are, “Dedicated to winning the World Series, not to getting a better contract.”

Build informal groups that are dedicated to excellence within the organization, engage your peers, and build pockets of high-performance. Create a conspiracy of success with the peers you partner with to deliver service to your customers.

When dysfunction dominates an organization’s culture and puts a stranglehold on decision making, the answer isn’t to look up for the solution. The answer is to provide leadership yourself. It’s not uncommon for executives to become defensive when the business isn’t performing as it should and to point fingers at each other. Instead of mirroring that behavior at the operational level, it’s important to fill that void with strong positive leadership. By doing so, you’re organically changing the culture of the organization. When you are successful and bring about an improvement that each of the representative groups can take credit for, you stand a good chance of improving the probability that those that represent you on the board of directors will work together in the future. Success always has many parents. Positive leadership is remarkably resilient and contagious. All it takes is one person to convince a few others to commit to it (and the grit to remain committed).

Tagged , , , , ,