What Good Is Strategy Without Action?

Watching professional sports this past weekend, I found myself thinking about insanity. And it’s not the insanity of sports or the fervor of the face-painted fan. It’s the insanity of business practices!

You’ve heard the classic definition of insanity, right? It asserts that insanity is defined as doing the same thing over and over expecting a different result. Our sports teams seem to understand this concept. Most teams, with the exception of the New York Giants this past Sunday, change their attack, their strategy, if it isn’t working. Racing teams change the set up and pit strategy if the original plan is not working. How about business? Do businesses today change what is not working? Let’s look at the similarities of sports and business so we can understand the differences.

Sports and business seek winning scenarios. They plan, they strategize, they train and prepare and they invest in an approach that they believe will prove successful. But what happens if the play book or the racing strategy is not working on a given day? What if there is an unforeseen factor that has been introduced that changes the outcome of the proven approach? Let’s call this a variable. Sports franchises change their approach. They try something different. How about business? Does business change their strategy? Will they have the courage to admit the error of their approach and change strategy? Perhaps. But I would like to ask a more fundamental question: Do they really know when their strategy is not working? A football team has a scoreboard that provides immediate, albeit lagging, feedback. Does business today have a measurement system that provides them meaningful indicators of the success or failure of their strategy? And even if they do, one must determine if the measurement system achieves a balance between lagging and leading indicators. It must be linked to the drivers of the business, cascaded through the organization so it is meaningful to the entire company and finally, management must have the strength and commitment to follow through on altering the strategy in response to these indicators…follow through before market share and market capitalization suffer. NOT to respond is, well, insanity.

We Don’t Need No Stinkin’ Customers

Two thoughts (only two, that’s all I can handle on a Saturday) came to mind this afternoon. First, an experience I had with the advanced program that granted me my master’s degree. A couple of months ago I was delighted to share my experiences using Six Sigma for information technology with a class that was soon to graduate into the real world of technology. During the audio presentation which I conducted remotely from my home in Minnesota one master’s candidate asked about the “standard” sigma level for information technology. In response I suggested the answer would be apparent once I completed the entire presentation.

The second experience I’m pondering is an article I read in Computer World magazine this morning. In this article a reader shared his experience with a programmer who held to the philosophy that he didn’t need to ask the user or customer what they wanted or needed in their business application. It was this contractor’s perspective that he “told the customer what they needed” and had no intention of talking to the customer. Ouch! Yeah, the project fell short of customer expectations and the programmer was unceremoniously dismissed.

It’s exactly that attitude that I must deal with regularly. And it’s probably that perspective that brought about the question about the “standard” Six Sigma level for IT. Here’s the lesson: There is NO STANDARD. The challenge is to take the time to:
1. Understand your industry
2. Understand your competition
3. Incorporate the business requirements into the solution you are building
4. Achieve a performance level that meets your customer needs.

How do you do all this? Oh well, geeze! Maybe we have to “TALK TO THE CUSTOMER.” To understand the “appropriate sigma level” we need to understand our industry and how the business makes money in that industry. It can’t hurt to know what the business challenges might be, including the competition in the marketplace. As a process guy, I’m also going to suggest that perhaps you need a mechanism to capture these customer requirements (initially captured as CTQ’s -Critical To Quality) and be certain you can deliver against those. This isn’t rocket science (OK, if you work for NASA it is). It’s simply common sense.

My final admonition to the virtual class I was conducting was simple: “Lose the IT-centric attitude. It’s about the business - not IT.”

Quality: Been There. Tried That!

One of the more challenging issues with which I deal is the people component of the People-Process-Technology trilogy. Any consultant that impacts the culture of an organization will admit the people component is the most difficult.

So, it will come as no surprise that one of my greatest challenges in dealing with IT is the experience some IT people may have had with “QUALITY”. I often hear something like, “Quality, Smaulity. We tried it and it didn’t work.” OK, so Total Quality Management (TQM), Six Sigma, ITIL, and perhaps Kaizen have sometimes earned bad reputations. But this is often because some organizations look to these initiatives only for short-term gain. They then fail to integrate the concepts of these proven methodologies into the way they do business.

All the big three automotive manufacturers have used Six Sigma and other “improvement” and “quality” initiatives. But ask yourself why Toyota or Honda is doing so well in the marketplace. Is it only the effect of lower cost production capabilities? Or, is it something else? Toyota adopted the quality concepts of Shewhart, Deming and others and incorporated them into the very fabric of their organizations. The Toyota Production System (TPS) is part of Toyota’s culture. It influences every decision. It is not just part of the manufacturing process but an instrumental component of the way they do business. In TPS, quality is not a point solution put in place to resolve an isolated issue, but a way business is conducted. This raises improvement from a utility or even as a governance guideline to being a critical part of the culture.

Some say that even if an improvement effort worked it never really “stuck”. Well, I agree. There’s is no reason to improve a process if it isn’t going to “stick”. Why spend the time, money and resources fixing something if it’s not going to last? Just accept the fact that your process is broken. Then you may devote all your time REACTING to situations. However there is a better way. Once you have established the improvement, design a control plan (see figure).



The control plan, the output of the final step of the Six Sigma DMAIC process, provides the means to:
• Prevent “backsliding”
• Preserve the project investment
• Empower process owners
• Ensure the process indicators are reported and matured as the process matures
• Design reports that meet the needs of specific customers
• Nurture the “Learning Organization” for cultural change

Quality WILL work. The concepts upon which our modern improvement methodologies are based are over 50 years old. Their legacy is proven. And improvements can have lasting impact. Organizations need first to accept the cultural implications. They then need to ensure the improvement stays in place by applying the common sense principles of a control plan.

So What’s a Half a Million Dollars Among Friends?

If you’ve ever stepped into the middle of a project (see Stepping into the Middle of a Configuration Management Project: Watch Where You Put Your Feet) you’ll appreciate this post. You know you need to avoid stepping in poo with one or both feet. Unfortunately, often you can’t see the poo regardless of how experienced you may be. Somehow, you need to find out if there are any legacy issues that are hidden from view. Such intelligence could make or break your professional survival.

Years ago I was brought in on a project that, unknown to me, had the distinction of wasting nearly half a million dollars in the previous year. It didn’t matter how many questions I might have asked at the outset, how many people I had talked to or how thoroughly I researched the proposed approach, the only one who was really understood the details, an obscure financial analyst, was not talking. It was only by accident that I stumbled across this guy. No one else that had been associated with the project had insight to the finances - or, perhaps more accurately, no one was willing to talk about it as they, amazingly, didn’t consider it relevant. When I confronted my sponsor with this information, I was told that the project team had simply done a poor job of project management. The sponsor was not the least bit surprised at the magnitude of the dollar figure. Even more amazing, this person didn’t consider the information to have any material significance for our task at hand and seemed a bit perturbed that I had taken the time to dig deep enough to uncover what could be described as nothing less than a colossal failure.

Management excused this as poor project management and a lack of control over the contractors. Well, NO KIDDING! But this very issue was one of the reasons, if not THE reason, the program was meeting resistance. Funding for our program was originally intended to tap available business unit budgets to augment a portion of the annual IT budge. Had I known about this red herring earlier I would have taken a completely different approach. As it was, the project was already underway and, because of the lack of funding alternatives caused by this legacy of waste, had languished for nearly a month while we worked to gain business unit support. IT had already lost credibility and resurrecting a failure under “new management” wasn’t going to restore the faith of the company in IT.

What bothers me about this is not so much the waste or even the failure of the original project (which failed to show ANY deliverables at all) but the seemingly ambivalence of those who DID know toward the half a million dollars! Why is it OK to dump this kind of money on a project and have nothing to show for it? Why wasn’t this information discussed with the new project team right at the outset? Why didn’t the project sponsor understand that this piece of information was critical to success of the new project? Where was corporate governance in setting guidelines, review boards, steering committees and project performance standards? Considering the magnitude of this failure, why was current IT management still employed? Shhh…we’ll just keep this information amongst us friends. OK?

Is IT Abdicating Responsibility?

Tell me if this scenario sounds familiar. You have grounded a great opportunity to build a fully integrated roadmap to implement IT Service Management. You have at your disposal all kinds of preliminary assessment and planning data. You have an internal team that is committed to making this work. Everyone is trained, motivated and there’s even an initial budget that should carry you through the next six months. But, as you engage, you begin to realize that something is amiss. While that spark, that drive, the compelling reason for the project is recognized and acknowledged by all concerned, even senior management, something is still missing. I submit the following as possibilities:
• The sponsor and executive sponsors selected an experienced expert (YOU) to “do the magic”. As a program manager you have all the responsibility but NONE of the authority to be effective. For whatever reason, senior management doesn’t recognize their role in the success of the endeavor.
• The program is built upon a foundation of reckless investments in the previous year(s) and cost IT credibility with the business. Consequently, the budget for the improvement effort is restricted to the funds available to the IT group. No additional funding will be coming from the business units. Thus, the business has no "skin in the game" and no reason to cooperate.
• Due to poor project management preceding your involvement, the business is tired of IT and refuses to be open and forthcoming with the program manager. As a result, the objectives are not clear, the deliverables become a mish mash of conflicting and non-prioritized tasks improperly sequenced and destined for failure.

Regardless of how skilled, experienced or savvy a program manager may be, if roles and responsibilities for all stakeholders are not clearly spelled out, from the “C” level down to the individual task roles, the chance of success are minimal. Oh, yes, you may make some incremental improvements in selected processes. You may even succeed at raising the maturity or capability level of one or two processes. If that was the objective of your role, great. You’ve accomplished what you set out to do. But if your tasks, your deliverables were to drive a holistic change in the way IT functions, it’s not likely you will be successful. Everyone in the IT and business hierarchy must understand their strategic and tactical responsibilities. These need to be detailed, reviewed regularly and those responsible held accountable.

Though I say a skilled and experienced program manager cannot make magic happen I suspect that this person, if truly experienced, will be incredibly selective about the projects he or she takes on. They will ask these questions at the outset and then proceed to ensure that once the levels of responsibility and accountability are defined, they will have the authority, directly or through a steering committee or executive sponsor, to ensure accountability. Assuming he or she has the option to be selective, the program manager will understand the critical success factors and will take every effort to mitigate risk by identifying the key roles and responsibilities and getting the commitment that those responsible will follow through.

Too strategic? I make no apologies. That’s what holistic and continuous improvement is really about.