There is a Japanese proverb that addresses the issue of action or, as we would put it today, Execution: “A vision without action is a daydream. Action without vision is a nightmare.”

We all know imaginative people who have great ideas about how things should be and a solid understanding of how things actually are. Since they know the starting line as well as the finish, they are able to clearly mark the surest route. Yet we also know people who tend to focus only on one or the other. They are more likely to get lost along the route. Those with a meaningful vision for the future can move the organization very far ahead. Those with a realistic understanding of the present rarely struggle as they line others up for the journey.

When I asked John Thompson, the very successful former executive at IBM, former chairman, CEO, and president of Symantec, and now CEO of Virtual Instruments, what advice he would give aspiring innovators, he expressed a sentiment very similar to this Japanese proverb. He told me that he would recommend first that they never stop dreaming. Then, he said he would tell them, “Innovation is about dreams, but don't ever assume that just because you have great dreams, they will happen automatically. You have got to be focused on the execution part, too. People who dream big and execute well are the most successful people in this industry, no question about it.”

Effective innovators know that they—or their teams—need the right mix of skills to both envision and achieve. They also recognize the essential elements of effective execution—quality and timeliness. And they know that they must balance them without compromising either.

Meeting the Highest Standard for Our Astronauts

I started my career as a scientific programmer with IBM. At that time, IBM had a contract with NASA for technological support and software development. I had the great good fortune to be assigned to work on software for NASA's last three Gemini spaceflights. My husband Werner and I met and worked on this same project. As a young programmer, it was an incredible honor and challenge to contribute to such a critical mission. I realized how important this assignment was when I started working with the project manager who trained all the astronauts. He told me about the horrible things that could happen if there were errors in our software products. Not only could errors damage our country's reputation worldwide, they might even cause the death of our astronauts. This responsibility frightened and motivated me.

I became relentless about having zero defects in my programming. My assignment was to develop onboard computer code for the Gemini flights, and my husband's assignment was to develop the mainframe computer programs for ground simulation of those same flights. Our mathematical calculations required fifteen-digit decimal point accuracy, with absolutely zero tolerance of any errors. My program and my husband's program both had to produce the very same results—all fifteen-digit decimal points.

The very high standards and self-discipline we had to embrace made us much better programmers. We were determined to deliver our software programs flawlessly. This entire experience taught me why a zero-defects standard was so important and that we could ultimately achieve it. The impact on all stakeholder reputations and the potential cost in lives and money from defects in any of the spaceflights would be insurmountable. So, I worked around the clock to make certain that my software was delivered ahead of schedule and with zero defects. Because of my early training, I steadfastly maintained the same discipline, applying it in all my work throughout my career.

Flawless Execution

The notion of acceptable fast failure that we discussed in prior chapters is sometimes misinterpreted. I have seen teams mistakenly apply it to the way they approach their projects, believing that an innovative mind-set is somehow at odds with a focus on quality. I don't mean these teams knowingly introduced quality issues just to get the job done faster or more cheaply. However, they dismissed concerns and even ideas about improving execution quality, believing that innovation required a willingness to “let the chips fall where they may.” In other words, the team wanted to break away from the cultural legacy of risk aversion that normally slows progress. Yet they did so in a way that lowered quality standards and led to mediocre execution. This is not the same as “embracing failure.” When we make predictable mistakes, we waste time and resources. We also lose support and credibility. Failure is acceptable when it allows us to learn something new, not when it happens because we are ignoring the lessons of the past. Acceptable failure is a matter of raising our sights, not lowering our standards.

Many people don't think of flawless execution as an achievable outcome. In fact, it isn't always achievable. But it should always be our goal and our aspiration. At the same time, however, we must also be true to the cost and benefits of a business case as our guiding principle. Sometimes it is a judgment call regarding the cost of the error to the business versus the cost of zero defects. If we are traveling on a plane, we definitely want zero defects. We don't want to be the passenger of an airline that settles for a Six Sigma defect rate.

By simply striving for that ultimate ideal, we sometimes reach it. And when we don't, we can reflect on why and learn something new. A commitment to flawless execution makes us good today and even better tomorrow.

Flawless execution applies to projects, to operations, to any activity in any kind of business. And in some, as Ming Tsai points out, flaws in execution are very visible and immediately apparent to all. On the other hand, when it's all going right, that's immediately apparent as well, with one of the rewards being a rush of instant gratification:

It's important to point out that by flawless execution I don't mean “zero errors,” but rather “zero negative impact” to the customers and business. That is, ensuring that mistakes do not cause disruptions. In the world of IT infrastructure, for instance, we can architect solutions to have continuous availability. This design recognizes the inevitability of issues such as hardware failure and builds in compensatory mechanisms that immediately take over to avoid service interruption. We can apply the same principles and planning to projects. For example, we always had very thorough alternate recovery plans in case our execution failed. Sometimes half of our plan was devoted to preparing for the possibility of rollback and recovery.

Several years ago, my State Street team introduced our 21st Century Technology Infrastructure solution in Europe. It was a multiyear project that involved establishing a regional data center in a new office location in London. The data center was outfitted with state-of-the-art IT infrastructure specified by our global technology blueprint strategies for server, storage, network, and other infrastructure disciplines. Setting up the data center had taken a tremendous amount of work and planning, including the participation of 300 infrastructure specialists across the globe. Yet, the first business milestone was still ahead: the migration of 1,800 employees from various London-area sites to the new office headquarters location. In addition to moving the employee desktops, systems, and trading floor environments to the location, the team also needed to consolidate and migrate several hundred different business applications located in six local technology centers into one new regional data center. These applications were accessed by thousands of State Street employees in fourteen different locations and by hundreds of our clients with direct network connections.

Our goal throughout the project was to design and implement a plan that would make the transition entirely invisible to our end-users—customers and employees. They would not know that we did it. We achieved this by analyzing the business processes and understanding the components (people, applications, data and facilities, and more) and interdependencies between them. This provided a detailed foundation for comprehensive migration planning, scheduling and testing, and for contingency plans to ensure rollback capability, if needed. As planned, the team successfully migrated all 1,800 end-users, the several hundred business applications, and hundreds of clients without a single interruption.

Although not all innovation projects face this type of technical and logistical complexity, most do face considerable complexity of some sort. I believe that an innovator's attitude toward such intricacies often determines how successful they will be. Some people get lost in complexity, for example. If they move forward at all, it is painstakingly slow and inefficient. Others dismiss any hint of complexity, irritated with those who may bring it up. They prefer to charge ahead and let the chips fall where they may.

The most successful, I've found, are leaders who move forward with both realism and confidence. They don't try to address all of the complexity on their own. Instead, they structure their team and their plan to do so. They set high standards for performance and ensure that team members develop plans to address the risks and quality issues that might be encountered. They integrate these into a detailed implementation and contingency plan that is communicated to the entire project team and all stakeholders. In other words, effective innovators aim for flawless execution.

Rapid Value Delivery

Quality is just one of the essential elements of effective execution. Timeliness is the other. Timeliness is more than simply being on schedule. It is having a sense of urgency about delivering value quickly and effectively. In any endeavor, the sooner we can deliver value, the better. The world is moving much faster. When businesses want something done, they want it done now. Technology people must be able to respond with the required speed. This is why rapid value delivery is so important. If we can deliver a portion of the requirements quickly, the business can use that immediately. Then, we can make adjustments along the way instead of waiting until the entire project is completed.

In innovation, when our goal is to establish competitive advantage, speed is even more essential. Clearly, we cannot sacrifice quality to achieve speed. But there are plenty of things we can do.

The first is to break a large initiative into smaller phases that each deliver value. This is unlike traditional project planning and execution, where value is delivered at the end after all the individual pieces are brought together. Rapid value delivery, instead, proceeds in a series of small bursts, each of which delivers value to the customer and provides input for the next phase. This is a very important distinction, and one that is not made as often as we might expect. In fact, people with a very clear vision and a comprehensive solution sometimes go about achieving it using a traditional approach. They make very real progress toward their goal, but they do not focus on doing it in a way that creates immediate results and business value. The traditional approach may seem to be a faster, simpler, and surer way to reach their goal, yet it rarely is. There are always complications that we just can't predict, and sometimes we encounter changes that can overturn our original assumptions. Short bursts that quickly bring about immediate benefits will demonstrate the value of our solution and keep us tightly linked with sponsors, customers, and other stakeholders. Each phase, then, becomes more than just another step toward our goal. Improvements are experienced at each stage. And our strategy is continually affirmed.

Generally, we want to begin with the quickest win we can find that is able to stand on its own and provide an achievable and valued benefit for our customer. It may be one feature that we can provide to all customers, or it may be new functionality that we can provide for one customer. It doesn't matter if it's small; what matters is whether it provides demonstrable business value, as quickly as possible. This then becomes the scope of that phase.

Leveraging virtualization technology was always a fundamental part of our Blueprint strategy and key to our vision of a 21st Century Technology Infrastructure. We executed against that vision in small but meaningful steps along every front. For example, when a new storage virtualization technology became available, we decided to leverage it for all unstructured data, such as corporate e-mail and personal file storage. This allowed us to consolidate the many local storage environments, which were difficult to manage and recover, and locate them in enterprise or regional data centers.

We began with one data center and a few local buildings in the Boston area to validate the business case and demonstrate the benefits. It was a huge success with plenty of immediate benefits: savings in data center space, utility expenses, technology and facility equipment cost, and staffing cost and improved responsiveness to new business and regulatory requirements globally. Once this phase was completed and the value of the project demonstrated, we continued the project for all buildings, all regions worldwide.

Selecting an appropriate scope is a matter of judgment and experience. However, I find that even very experienced people often start with a scope that is larger than it needs to be. This creates more risk, complexity, and delay than is really necessary.

Too often I've seen what we call scope creep take place in projects. Every time a customer or user brings up a suggestion, it's added to the list of items to be completed, without priorities attached. In this way, the project is expanded well beyond the initial requirement. The key in these situations is to prioritize all the requirements in the list based on criticality to the business, and then separate them into phases. Obviously, there should be flexibility in case the business requirements change. Management of the scope requires sound judgment and communications with the customers and project team. Focus is the key. Plus, I always recommend thinking first about the smallest and simplest way to provide value. It may be enough.

After we define scope, we want to take a baseline measurement of current performance or capability. That's not always possible, especially when we're introducing something entirely new. However, as we discussed in Chapter 4, Promote, it's important that we do our best to assess our “before” state so that we can have a fact-based “after” comparison. The new solution must be better than the old one if it is to demonstrate value. Whenever possible, we want to quantify in advance the result that our customer wants, expects, and is willing to pay for. That allows us to align our own goals and investment accordingly.

Once we have finalized our scope and determined our baseline, we can use rapid experimentation to test our assumptions and complete a proof-of-concept to validate our approach. Rapid experimentation means giving promising ideas a chance, but doing it in such a way that we minimize up-front investment. In this way, we don't waste limited time, energy, and resources. By quickly putting ideas to the test, we can confirm or dismiss key assumptions up front, and then either accept and integrate the idea or move on to another.

One way we did this at State Street was to establish an Innovation Lab. With the lab in place, we were able to test new technologies in the free thirty- to ninety-day test period offered by many technology companies. We were set up to evaluate the new technologies quickly without buying them, generating metrics and information for our business cases.

The rapid experimentation approach also encourages those who come up with ideas to keep trying, because they know their efforts will be given a chance—even if that chance occurs in a narrow timeframe. The innovator never forgets, however, that while rapid experimentation allows us to fail fast and learn fast with minimal investment, the experiments are performed with meeting project goals in mind. For example, rapid experimentation does not necessarily imply that we're developing throwaway solutions. Our goal is to minimize up-front investment, not waste it! As soon as we know our direction, each step we take is an investment in the future. Having an end-state architecture in mind, even during the early experimental activities, can speed progress and minimize costs as we proceed.

Throughout this process, we must remember that timing is everything. I believe in doing whatever we can to meet our delivery date, with the single exception of cutting corners. There may be ways to prioritize and temporarily omit less critical functionality, and then add it in immediately afterward. When we work with our customer and stakeholders to assess trade-offs like this, we typically arrive at an agreeable solution.

Once we were migrating into a new system which wasn't yet able to meet the processing time allowed to generate certain reports—we were missing the 3:00 a.m. delivery time by 45 minutes. We needed to buy some time before we could tune the system to meet this requirement. We asked the business area exactly when they needed the reports, and they told us by 6:00 a.m. We renegotiated the delivery time to somewhat later than 3:00 a.m., since no one really needed the reports until later anyway.

Similarly, I think it is very important that we never let our focus on speed lead us to dismiss the concerns or ideas of others. There is always time to listen to legitimate concerns and to do what we can to resolve them constructively, in a way that is acceptable to the largest number of stakeholders.

Nor should new ideas, which will come along the way, be dismissed in the name of urgent delivery. New ideas should always be encouraged, and if there is no time to test them at the moment, they can be catalogued and reconsidered later, in the same way that less important functionalities can be added after the primary implementation is complete and the system is operable. In other words, an effective innovator can recognize both issues and opportunities without impacting the delivery timeline.

Managing scope is a critical discipline and a hallmark of those who execute effectively. Good scope management allows us recognize the difference between quality—which we want—and perfectionism—which we usually can't afford. Quality is a matter of achieving zero defects relative to our scope. Perfectionism goes beyond our scope, looking to achieve ends that are not within our current mission. There's nothing inherently wrong with going beyond, unless it threatens to interfere with our goal. Effective innovators ensure that team members focus on achieving the core mission and temporarily shelve additional features that will impact the cost, timeliness, or complexity at that particular stage of the innovation.

Finally, a successfully executed project looks ahead to the needs of those who will use the new solution. The training and education that accompany products and services need to be part of the plan. They are very important to customers, to the sales force, and to all others who have to understand the newly incorporated capabilities so that they will be able to fully utilize them. The developers also need to set up a mechanism for feedback about user friendliness, and it can be built into training programs. That way they can quickly determine how easy or hard it is for people to learn the new product or services.

Putting the Pieces Together

I always like to say, “Quality is not perfectionism, and urgency is not panic.” As innovators, we need to develop and exercise the kind of judgment that can help us recognize the difference. We must also recognize that execution is not simply a matter of carrying out the plan. Execution is about achieving the results. I think this idea is captured beautifully in the expression “The operation was a success, but the patient died.” John Swainson, president of Dell Software, also provides a great industry example:

Innovators with advanced skills execute their projects in a way that quickly and closely aligns them to the wants and needs of their customers and markets. They use the twin principles of flawless execution and rapid value delivery to capture the buy-in and enthusiasm of their customers and to continually fine-tune their strategy and approach. Tom Mendoza has an interesting take on the interplay of strategy and execution:

Execute: Levels of Effectiveness

Server Certification Process

The following is a brief but exemplary story about the power of effective execution. It began with a series of complaints from our application developers about the excessive time needed by the technology infrastructure group to “certify” a server, which included ordering the equipment, installing all the systems and applications products on the system, and connecting the equipment into the test environment for the developers to utilize. In a company the size of State Street, with a vast technology infrastructure, this was no small issue—and what's more, it was a recurring one.

The process in place at that time required developers to begin by submitting a request for an “environment” needed for their application development work. Once that was approved, the infrastructure group began the lengthy process of getting the server hardware and software ready. But after listening to feedback from a number of our internal customers, I assigned a process engineer to review the entire procedure, and to conduct an assessment of its effectiveness and quality control. When we reviewed the engineer's assessment, we saw that there were 108 separate steps in the server certification process. Moreover, it involved several different technology functional areas, with no single owner of the entire process.

So, there were four major issues. The first was the 108 steps, which simply took too long to complete. The second was the waiting time between consecutive steps. The third was that most of the 108 steps were performed manually. Not enough automation was involved. The fourth was that no single functional area owned the request and certification process. That meant the request could sit unfulfilled for too long, since no one was accountable, and no one was monitoring the total time it took. So now it was quite obvious that prompt action was necessary. And as innovators, we saw that the “problem” offered us a huge opportunity for improvement.

Immediately, we assembled a global team with representatives from every functional area involved. The team's initial goal was to cut the time needed for the entire process in half and to reduce the number of steps in the process. To reach that goal, we first assigned an owner to the server certification process, creating a new department made up of existing employees, and calling it Server Integration Services. After months of hard work, the team was able to reduce the 108 steps to approximately 52, and to reduce the average elapsed time between a request and a server certification by more than 50 percent. Then, with some further effort, we were able to further reduce the steps down to 25. At that point, I challenged the team to develop a way to have no human intervention at all from the initial requester to final completion and delivery. Our team finally was able to complete any simple server certification request within one hour by total automation with no human intervention. For the more complicated requests, the delivery time became just a few weeks, yielding a tremendous improvement over the old system.

We did continue to use some people for part of the process, but they were assigned to monitor each request and to insure that all requests were processed as quickly as possible. These monitors would notify the functional group in the event that they observed anything slowing down the process. Later on, we were also able to automate much of our monitoring as well, yielding even more savings.

Along the way, we did not stop when we reached our first milestone. Every time the team completed a stage, we immediately established another goal farther down the path. Finally, we set the goal that would have been unimaginable at the beginning of our initiative—the one-hour turnaround from a request to a certified server, without human intervention. And, as I noted earlier, our team eventually achieved it for all simple server certification requests.

Here you can see all the principles at work: listening to identify both a need and an opportunity, leading by tackling the problem, positioning the initiative within the company's cost-cutting strategy, promoting the team's achievements as each milestone was reached, connecting with all the technology teams, committing to a remarkable goal, and finally, executing so flawlessly that the savings and streamlining occurred without any adverse impact on the business.

Execute—Concrete Steps for Putting This Discipline into Action