What Remodeling My Home Taught Me about Change Management

Sometimes, it’s hard to visualize the importance of business analysis and change management. So here’s a story about a nutty place near where I live. There’s a recycling center just a short ways from my house and the experience at the drop off center is unlike any I’ve ever had. While I haven’t experienced enough drop off centers in my life to know what is standard, the way this particular place is set up boggles my mind. The experience is like this: when you approach the drop off center, you drive along like at a drive through at McDonald’s. There is a person waiting right before the drop off bins to solicit donations. To actually drop off your recycling, you pulls your car up alongside the building and unload. Sometimes there are a lot of volunteers to help you, sometimes there are not. Once your are done unloading, as long as there are no other cars in front of you, you are free to leave. The maximum number of vehicles that may be simultaneously unloaded at any time is about three. The inevitable queue that forms behind the cars unloading can stretch up to eight cars at a time and the wait can be as long as twenty minutes. This seems wasteful and not good for environment. What, with all those cars idling.

I’ve volunteered at this particular drop off center as one of those who helps unload the cars and I have some awareness of the reasons for why things are done this way. The center desires to maximize their chances for realizing donations from those dropping off their recycling and they wish to exact front side quality assurance by ensuring the right recycling is placed within the right bins the first time. This reduces the chances of a loss of revenue if one of their buyers rejects a bin for having too many inappropriate materials within it. This is precisely what you are told when you go through orientation as a volunteer there. There may be other reasons as well.

When I started to volunteer at this place, its primary center of operations was a semi-permanent structure in the form of a large framed tent. When it came time to design a new building for them to move, this would be the chance for a change of business process. Eventually, there was a permanent structure built for this recycling center in accordance with their business processes. The design of it is tightly tuned to the center’s current workflow. Which means nothing changed.

There’s simply no evidence of change. From the outside looking in, it appears that the building was ordered in accordance with their current practices with no thought of flow, customer experience, or even environmental good. Now that there’s a permanent structure, there’s almost no possibility to make changes.

You want a quicker drop off time? It can only be achieved through pre-industrial era means: adding more people. Seems pretty inefficient to me. There’s no parallelism of work. Work is performed serially in an assembly line fashion. It drives me batty.

I can’t imagine what it must’ve been like to be the architect for that project. Architects have long been frustrated with helping people move beyond what is to what could be long before there was anything remote to information technology. Architects and IT professionals could probably go to therapy together.

This example is illustrative of the challenges facing the business. IT professionals often see inefficient business processes in action. As Clay Christensen pointedly illustrates in, “The Innovator’s Dilemma“, business processes by their very nature are highly resistant to change. If they weren’t, they wouldn’t be processes. So when IT is approached with a software purchase or project outline for some in-house development, they’re looking to have a very special conversation with the requester. It’s a conversation that doesn’t come along very often. It often comes in the form of, “So what are you trying to accomplish?” It’s born out of a recognition that our business processes, whether we like to admit it or not, evolved against the tools available. Times have changed, technologies have changed, and organizational capabilities (hopefully) have changed. The iron is hot and the time to strike is now.

It’s not uncommon for the requester to balk at this conversation. They’ve worked closely with their colleagues, they know the nature of their business. In a sense, they’ve already had this conversation, so why are they having it again? My wife and I experienced something similar when we drew up our designs for an addition to our home. My wife took the lead on the project. We had a few conversations about what we wanted, she drew them up, I gave them a vote of confidence, and she took them to the architect. With no prior experience, we didn’t know we would go through a few iterations of needs analysis and design before we reached a final plan.

To be candid, it would’ve sucked if the contractor built what we had envisioned. There were lots of considerations we hadn’t made that the architect surfaced in our conversations. He asked us lots of questions. At first, since we were naïve to the process, there was an element of annoyance. We kind of expected the architect to just take our hand drawing and turn it into a design document for the contractor. We didn’t expect him to start asking questions. I had to laugh when I realized I was eating my own dog food! It took three months for us to finalize the design for the addition. Things started later than we would have liked and we didn’t get settled into our home until just before the first snowfall. But the final product was very satisfying. It met our needs.

Bringing a request to the IT department is not unlike the first hand drawing we brought to our architect. It’s just a starting point for a series of conversations. Business analysts and architects will want to ask a lot of questions. A rip and replace update of the existing workflows handicaps the organization from meeting its future needs. Are you remediating today’s problems or preparing for tomorrow’s opportunities?

Jerry Mechling at Gartner has an approach he refers to as, “Slow trigger, fast bullet“. While Jerry is concerned predominantly with the public sector, I believe there is a general value to this approach. While not all change management techniques are created equal, there is considerable value in any approach that slows down the change and includes a heavy amount of planning and preparation. I don’t mean requirements gathering. I’m referring to larger considerations such as understanding the kind of changes are we seeking for our organization, “What do we want to be able to do? Who do we want to be? Who do we want our customers to be? How do we deliver value today and is it sufficient?” There’s also budgeting for support and ensuring capacity for making the change itself. This question is most profound and often ignored. If your staff is already working at maximum capacity, what won’t get done while the staff is involved with telling user stories, testing, and so on? If there’s ever a time when the old patronizing view of professional staff ever works its way back into full view, it’s the usual response to this question, “They’ll just have to work harder.” Your project just failed right there. It will most undoubtedly be late, over budget, and not meet expectations. To be successful, IT must have the full support of their colleagues. Those colleagues can’t do that without adjustments or additional accommodations for their own work.

For most kinds of changes, the non-disruptive ones, there is little, if any, advantage to being the first mover (see “The Innovator’s Dilemma“). What’s most important is getting the change as right as possible, allowing for refinements along the way.

Our home was built in 1953. Long before we took ownership of it in 2007, the building underwent a number of changes in accordance with the then occupant’s needs. Many of these changes, because they didn’t affect the as-built, went undocumented. So, naturally, once the design was finalized and signed off on by the local permitting department, our contractor found issues that required change orders. On one occasion, our contractor called us in a panic thinking they had found a pipe filled with asbestos. Thankfully, it was just a whole bunch of gypsum. Why it was there we’ll never know. Those change orders begot an adjustment in deadline and budget.

The parallel with how the organization is structured is uncanny. Like it or not, those manuals on the shelf in many department are out of date with how things are actually done. As any new employee will tell you, there’s what the manual says and then what the senior staffer showed them. Job shadowing is where the new employee learns,  “How it’s really done around here”.

So when it comes time to purchase that groovy new software, IT and the other department will need to have a series of conversations. Yes, a series. Because change management is more than just installing software, it’s about organizational change. When it comes time to configure the software against your business processes, it’s going to be a lot like pulling back dry wall on an old, old home.

The field labeled, “IT”, contains within it a value chain analogous to the entire building design, construction, and maintenance chain. As any IT professional will gladly share, technical implementation is actually the easiest part of IT work! Consider carefully around how the IT budget is assigned. Are you budgeting for architects, project managers, and analysts? Or are you expecting the IT equivalent of carpenters, electricians, and plumbers to design and manage the construction of your new home from soup to nuts?

Tagged , ,

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 , , , ,

The Coming Culture Storm

Every technology follows the Gartner hype cycle and mobile computing is no different. Today, when we think of the unseemly consequences of mobile, they tend to be around issues like vendor lock-in or lack of device interoperability. The recent legal war between Apple and Samsung (really, Google) shows that there is still a lot to figure out. But there’s a subtle dark side to mobile computing that will test organizations in a new and totally unexpected way. It will challenge prevailing management models. It will force businesses to choose between a sinking quagmire of mediocrity or to opt for the high risk and rewards of pursuing excellence.

With the explosion of mobile devices and their capabilities has come an explosion in personal productivity. Mobile is driving down the transaction cost of “work”. On vacation? Use Tomo. Need a reservation? Use OpenTable. Need to report a pothole? Take a photo with your iPhone and upload it. Mobile is driving a wave of innovation and with it, an acceleration of information that demands a physical response. So much so that organizations are struggling to keep up.

We are so capable in our personal lives that when we show up to work to and saddle up to a locked down computer, we get the sense that our organizations are content with their employees being productive at a fraction of what they could be. We open up the main software that we use in our portion of the business (look here) and get to work. The application is clunky and violates the “3-click rule” all over the place. But there are hidden upsides to everyone using enterprise software.

The only reason anyone ever installs software is to facilitate behavior change. Enterprise wide software is an organizational wide mandate to comply and perform workflows in a uniform fashion. This has been a boon for organizations as variance on the quality of work is minimized. Errors can be made traceable via things like exception reports. In a way, enterprise applications took the factory floor model of work and digitized it. It might feel unfair but it’s accurate. Think about what happens when you’re configuring or crafting software. You sit down with the end-users and gather stories about how they do work and craft epics out of them. The agreements for how work will be done made in those meetings will be reified within the software. In a constrained environment where the capital for computing existed primarily within the organization’s IT department, this model was a perfect fit. When you started employment, you signed your employment documents, found your desk, and was assigned a user ID and a computer with the organization’s software already installed on it. Perhaps for no other reason than it was too expensive to bring your own device to work and challenge the status quo.

The challenge for traditional IT is that, today, those things are changing. Costs are so low and devices have been miniaturized to the point that it is not uncommon for today’s knowledge worker to have a smart phone, a tablet, and a personal computer. How can you not, as a business, feel a little jealous knowing how efficient your employees are outside the organization? Wouldn’t it be great to just capture a slice of the empowered productivity that is happening outside of your business walls? As employees, isn’t it frustrating to sit down at your desk and go 35 MPH when you know you could go 70?

The first compelling desire that begets a mobile device is to be unchained from the desk. This allows one to connect with people and compute at precisely the right time. But the immediate question after being unchained is always, “Why can’t I work the way I live? I’m being issued an iPad at work but at home I use a Google Nexus, why can’t I just bring that in and use it? I’ll be a lot more efficient. You won’t have to train me and you won’t have to answer as many support questions.” The old answers around enterprise IT such as cost containment just doesn’t hold water like it used to. Nothing’s changed. They’re no less true than before. What’s changed is user expectations.

Like it or not, IT is being driven to render affordances to the business in the same way that affordances were granted to the IT elite such as the in-house developers. Some organizations, depending upon the sector they operate, the people they serve, and the make-up of the talent pool the business draws from, might be able to just issue a standard device and tightly control what software is installed on it. My intuition tells me that, like the principles of erosion, both user and vendor pressures will continue to deteriorate the boundaries between personal and professional computing until businesses will be forced to justify why they don’t support a BYOD program (See Kurt Richardson and Michael Lissack’s brilliant piece on the status of boundaries).

One can’t discuss BYOD without making a nod to the fact that Bring Your Own App and its friend, Cloud, just snuck into the room too. For horizontal applications like word processing, there is no issue. Microsoft Word is the standard and every word processing app from Google Docs on through to Apple’s Pages have no problem. It’s the specialized applications that unlock personal productivity that will be present challenges to the organization. Take for example, Sugar CRM. Sugar is brilliant, for $30 a month, one can have a personal CRM in the cloud with complete mobile integration. For the individual, this is a productivity enhancement. For the organization, it’s a cloud-based silo. As one Gartner analyst put it, “Organizational silos create artificial and limited datascapes.” This is the dilemma of the era. Just as the early internet upended the retail supply chain and started to put bookstores, shoe stores, and other retailers out of business, vendors are using cloud to target mobile devices heavily and upend the usual relationship departments had with each other via enterprise applications. The kicker? There’s nothing anyone can do to stop it. In a standard compliance based culture, fear would rule the day. “We catch you storing business data in unapproved cloud based apps and there will be hell to pay.” Fear has a limited lifespan because it only takes courage to evaporate its power. Compliance through fear, of course, undermines the larger purpose of mobile and BYOD, which is to empower staff and unleash productivity.

Let’s continue with the Sugar CRM example. The risk footprint of having customer data in the cloud, for most organizations, is quite small. The downside to it is that access to the data is limited to the person that purchased the subscription and, depending on how much they like to share, a few colleagues in the business. If the organization has a master data management program in place, then having key elements of an organization’s master data locked away without the organization being aware of will run counter to those efforts. Locked away data has zero value to the organization as a whole. As Mark McDonald points out, information value is achieved only through flow, not as a fixed asset. Information parallels energy in this regard, its value lies within what it enables one to do. Data sharing is something that many classic compliance based organizations struggle with.

The underlying issue isn’t a technology problem. It’s a people problem. Organizations are closed networks of recurring interactions that yield commitments to action (Espejo, Reyes). How an organization arrives at those commitments to action is increasingly important. Technology is just revealing problems that have always existed. Choice is the norm in this new era. In the past, compliance based organizational cultures could rely on a monopolistic approach to computing and work. Not so with mobile, BYOD, and cloud. Even now, without mobile and BYOD in place, there’s no reason why someone can’t use Google Drive or SkyDrive and other cloud apps to do work outside of the usual work setting. If they’re not already doing it and it’s not okay to do so within your organization then the primary reason is fear. Fear is a poor means for control. Fear, if nothing else, discredits the organization. Fear is a tool of the weak. I would challenge every reader to truly inspect what makes their organization so special that unstructured data such as Office documents must be stored on premise. IT, and really, the business as a whole, is now informally competing with ten thousand vendors. What must now occur is that the employees in the organization must choose to commit to performing work in a uniform way that allows the value of shared information to be unlocked for the good of the whole enterprise. The key term here is choose. To do this, every organization must embark on a journey to move from an organization of compliance where fear is the dominant currency to one of commitment where shared purpose is the dominant currency. This is the imperative of the modern era’s dilemma. Successful organizations must commit to a culture of shared information to move beyond mere mediocrity and risk falling to the usual twenty year lifespan of the typical business. Yes, that’s right. Look around you, in 20 years’ time, the majority of businesses around you will be out of business. Riding the knife’s edge of mediocrity increases one’s chances of being gobbled up by the trash heap of history.

This journey is one fraught with significant amounts of fear, uncertainty, and doubt. Organizations with compliance focused cultures will be challenged with where to even start. There is significant risk. Empowerment without alignment will result in the coherence of the business being tested. People will go all which way and that. Coming at a culture of shared data obliquely is a shrewd move. This is because what we’re truly interested in has more to do with how people relate to each other and the organization than it does with data itself. It turns out that a great place to start is employee safety. Not the usual way of inspecting workplaces but sitting down with staff and asking them truly how to make their workplaces better and more productive and delivering on it. Compliance based cultures have appeared necessary in the past because organizations have struggled with employee-relationship reciprocity. Heroes in the business that are lauded are those that sacrifice the most. It’s time to exit the age of the individual hero and sacrifice. Ask anyone with LEAN training, cultures of heroism produce significant amounts of waste. It’s the age of the highly productive team and that means new ways of relating are imperative.

In IT, what are we called to do? These changes can seem very scary. Few predicted these changes would arrive with the speed they did and, for the most part, IT ignored them. Look at how dismissive people are of the Windows 8 interface today. Windows 8 didn’t innovate in this space. Apple did with OS X years ago. No one was paying attention when Apple set the standard. It looked like a silly migration of the iOS UI to the desktop. Well, Microsoft committed to the change too and now we know what the future looks like. Are we still going to be dismissive?

We have significant work ahead of us. Our ERPs assume desktop input. With myriad devices to support, we will be called to open up our systems (all of them, systems of record, systems of differentiation, and systems of innovation). Have we loosely coupled our systems? Did we lock our business logic into proprietary systems that won’t play nice with others? Do we have a service oriented architecture in place? Have we truly committed to it or have we just all agreed that it’s a good idea? Have we committed to mobile web concepts like responsive design? Do we have the network infrastructure in place to support the desire to compute from everywhere? Inspect the programs the staff in your organization are using today. If you were to give them a tablet today, would it achieve value beyond a bigger screen for email?

IT must commit to respond to these changing times by discarding its usual dismissiveness and start preparing the systems people rely to do their work to be supportive of mobile computing for a vast array of types, understanding that cloud will have a significant role to play in the way that people will do work. What policies, procedures, and guidelines will you have in place to ensure that staff engages with IT instead of going around you and building cloud based shadow IT systems? IT must become the trusted leader in the organization. The first step in doing this is honoring the concerns of your colleagues at large and working with them to find practical solutions. They too, must learn to honor your concerns as well. This can only come from dialogue and not discussion.

Organizational leadership at large must recognize that, no matter what IT does to facilitate these changes, a fundamental shift in the mental models we use for management must occur. How we see employee motivation and behavior must change as well. Outdated organizational systems that emphasize compliance are wasteful and disempowering. The modern, highly talented knowledge worker has employment choices and they won’t choose you. You mission and vision statement might mention excellence and that people are valued but are those values baked into your business processes and other organizational systems?

IT must lead in this era. There is no other choice. What it means to lead is achieve commitment to action when people can say, “No!”

I’ll let one of my favorite Gartner speakers play us out. The future is yours, all you have to do is commit to it. Every day.

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.

Viable System Model and Data Management: Practical First Steps

Approaching data management through the lens of the Viable System Model for the first time may feel overwhelming. It’s an entirely reasonable feeling to have (if you’re unfamiliar read Trevor Hilder’s excellent introduction). Learning the Viable System Model is like a learning new language. Learning it and then applying it to your work isn’t too different from taking a French class and then being asked to write a pen-pal in Paris.

I’d like to put together a scenario that we can use to walk through this.  Let’s play pretend. Microsoft publishes a sample Visio database diagram that models a fictional bicycle businesss named AdventureWorks that we can use. You may want to download it to play along.

You’re the new IT manager for a moderately successful bike manufacturer, AdventureWorks. After meeting with your staff to learn what challenges IT is having, you’ve decided that one of your biggest problems is data sprawl. You have massive amounts of uncataloged and unmanaged data that may or may not be serving the business. You have data sprawl challenges in terms of depth and breadth. You suspect that years of unmanaged data in your database has led to your applications performing slowly. Furthermore, it’s reported that different business units each have their own applications, each containing some amount of duplicate data. There is no agreement on what information is canonical and there are  problems with updated information not reaching everyone. The good news is that Sales, Human Resources, Purchasing, and Production have all been sharing an enterprise class application that uses the AdventureWorks database for some of their work. Starting with the AdventureWorks database seems like a good place to start. Without a lot of information at hand and desperate for something, you ask your database administrator if she has a database diagram and it turns out that we have one and it’s up to date. At a high level, the diagram looks like this:


Scanning the diagram, you’re able to piece together a bit about at least what the database reflects about the business. You also look for boundary changes. Boundary changes, or foreign key relations between the schemas that reflect business domains, such as between Purchasing and Production, implies channels between systems. You’ve decided that Production will be your starting point. Your team, having been versed in the VSM, starts with Production. Production appears to be a type 1 system, that is, it’s firmly in the role of operations.

Your analysts set up a couple of meetings with the folks in Production. Of course, the staff, having had bad relations with IT in the past with poorly implemented tools that either don’t do the job or do it inefficiently, are a little reticent but they accept the invitation. The first thing they bring up is the poor performance of the AdventureWorks database. It was only fast during the first couple of years but over time, it’s turned into a real dog and now sometimes they will get up and get a cup of coffee while they wait for a screen to load. Your team, knowing that the database is running on premium hardware and knowing that no data has ever been archived out of the system, starts asking questions about how long bike part information is needed for production. Production, whose focus is on absorbing variety from Sales and delivering on customer expectations, really uses most of the bike part information for tracking inventory and forecasting for parts purchases. Digging deeper, your analysts find that not all the inventory is tracked in the database. Because of poor relations with IT, newer business attributes associated with changes in how they do work are being tracked in an Excel spreadsheet. It was easier to use Office than try and ask for changes to the enterprise application. The work order module of the application isn’t being used either. Instead Production uses email to let assembly teams know when work is ready for them. People sometimes forget to check their email or they get buried under other emails. This leads to unpredictable delays and other challenges. As your team starts to wind down the meeting, Production mentions that they have challenges meeting the special requests from Sales. The Sales department frequently oversells limited issue models, ignores recently discontinued models, or special requests. Your team certainly has their work cut out for them.

Let’s go over what your team discovered in that meeting. The AdventureWorks database and application has issues attenuating data, absorbing variety, and amplifying effort. Attenuating data could be pretty straight forward. Your team will need to have a couple of meetings about how long certain data needs to persist and in what state with the coordination, control, intelligence, and policy systems that have channels with Production. Some information likely can be archived in a report somewhere and purged. Or it may be transformed in some other way that meets the variety needs of other systems.

The problem of the application absorbing the appropriate variety is a little stickier. Shadow solutions, like the Excel spreadsheet they’re using, are in place because of inefficiencies between Production and IT. Investigating how those processes work and fixing them will take some later brainstorming but, for the time being, you can document and implement the new tables and import the spreadsheet into the database. This information too, may or may not be necessary for other systems to do their jobs. Your team will need to investigate, create, and document as necessary.

The biggest area of issue will be how to amplify Production’s efforts. The application’s work order module is so painful to use that the Production team would rather roll the dice on email. In those inboxes, you have “unstructured data” relating to work orders intermingling with many other types of information. Sorting and prioritization are challenges. Assembly teams are out of sync as communication and teamwork is out of sync. This is a coordination nightmare and is likely being felt in other parts of the business. For example, Sales may be having to deal with failure demand, “Where’s my stupid bike!?” This could beget direct commands from a control system, an unsavory but potentially necessary experience. The easy question for your team to ask is how to make the application’s work order module work better so they don’t have to use email. The better question is, in general, what does Production need to improve the flow of work? The application’s work order module may end up just getting deep sixed. Saving a poorly built piece of software does no one any favors. In this context, flow is what matters.

There’s also the specter of the residual variety that Production continues to absorb from Sales in terms of difficult or impossible to fulfill orders being placed. This likely also impacts Purchasing as well. There are data and communication issues here that need to be investigated.

Your team, informed of a systems approach, will have come away with more questions than answers. This is a good thing because systems thinking is a holistic approach that isn’t satisfied with addressing symptoms. It will compel one to find root cause.

What the Viable System Model does in this case is provide the appropriate model and concepts for data management. By understanding who or what in your organization is responsible for operations, coordination, control, intelligence, and policy you can start to ask the right questions on what they need. You will also need to employ the concepts of variety, amplification, attenuation, as well as algedonic signals and the Law of Requisite Variety. In this way, you can carry on a conversation with them about their needs instead of continuing the time-honored IT tradition of mere order placement and fulfillment. Having those conversations is critical because the false dichotomy between business and IT is vanishing (some places faster than others).

Data management isn’t just about finding and deleting data that isn’t used anymore. Data management is about ensuring that the data needs of the organization are met. To be effective, data management needs to partner with business process management. It’s very difficult to discuss one without encountering the other.  Employing systems thinking and the Viable System Model will go a long way toward doing the hardest work of all, asking the right questions instead of merely looking for right answers.

Tagged , ,

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 , , , , ,