All enterprises have a set of goals either explicitly stated in a formal business plan or implicitly stated in the culture and conversations within the senior management team. The CIO needs to know these business goals. Make sure you know them by heart.

Once the CIO discovers the enterprise's goals, the next step is to define an IT strategy or strategies to accomplish these goals. Remember, a strategy is simply a way of using the means or capabilities available to a business to achieve its goals. Often, a business executes its strategy by building or enhancing systems to do the things called for by the strategy.

Strategic IT Questions—Starting from Scratch Good strategy starts with asking the right questions. Strategy is the result you get from answering the questions you ask. Strategy that comes from answers to the wrong questions is useless strategy even if the answers themselves are correct. This is what is meant when people say generals often have great strategies to fight the last war instead of to fight the war they are in.

Generals, and all the rest of us as well, have a tendency to ask questions that are no longer all that relevant. We ask questions pertaining to the details of a situation that is now passed. We tend to ask these questions because we already know the answers. We learned them from our past experience. The trick is to learn from our experience and yet remember that the future will be different in some important respects from our experience in the past.

Here are some questions to ponder as you think about your IT strategy:

To define your IT strategy, begin by listing a set of desired performance criteria that IT should meet in order to enable the enterprise to accomplish its goals. Robert Kaplan and David Norton in their landmark 1992 Harvard Business Review article, "The Balanced Scorecard—Measures That Drive Performance" defined four perspectives that create a comprehensive view of an enterprise's performance (see Chapter 5 for specific applications of the Balanced Scorecard to IT performance measurement and management). Define the desired performance criteria that you expect IT to meet from these four different perspectives:

Brainstorm a large list of criteria under each of the four perspectives. Then review the lists and select four to eight of the most important performance criteria. If you can position IT to deliver capabilities that meet these criteria, the IT organization has accomplished its mission.

For instance, the CIO may define financial criteria such as build the new systems for X dollars and be able to operate them for Y dollars per year. Customer measures could track activities that provide customers with Web-based capabilities to do a range of activities such as look up products, enter orders, and pay bills. Business criteria track things such as how well systems handle a certain level of transactions per minute, how well they scale up to manage additional transaction volumes, and how quickly they can be learned by new users who need them to do their jobs. Learning measures demonstrate how well a system provides users with the data and reports they need to assess and improve their performance on an ongoing basis.

Next, look for ways to achieve these performance criteria in dramatically new ways. Ask the question, "What seems currently impossible, but if it could be done, would dramatically change the way we do business?" Look for ways to use systems to change the business landscape, to give the enterprise a significant competitive advantage by doing something new and different.

Systems can be used to open up opportunities to either increase revenue or decrease costs. Systems can increase revenue by:

Systems can decrease costs by:

The ways in which systems accomplish these opportunities will either create structural change in the way an industry operates, or it will support and enhance traditional industry products and procedures. Great competitive advantages can be gained if ways are found to create structural change in an industry. This is what changes the business landscape; it is said that all you need to do is to be 10 percent new in any field to start a fortune. Companies that create structural change become leaders in their industries.

Remember, a system is always people, process, and technology—not just technology. Define and design the process first, and then put the people and technology into place to support it. At the same time, keep in mind the capabilities of the people and technology available, and design a process that is realistic given those capabilities. In other words, adjust your ends to your means. Good strategy starts with a clear understanding of what is possible.

One last point to remember about strategic IT projects is this:The executive sponsors on the business side need to remain actively involved with the project in an oversight and advisory role throughout the project's life cycle. If no senior managers take an interest in this role, then either the goals that the IT strategy addresses are not really that important to the business or people believe the strategy is flawed and doubt that the goals can be accomplished. In either case, you as the CIO should be aware of this. If that is the case, change your goals or your strategy if you want to remain part of senior management in your enterprise.

Guideline 1: Closely align systems projects with business goals. For any systems development project to be a success it must directly support the company to achieve one or more of its goals. No new system can be effective until the CIO has first identified or created the business opportunity that will make the system worth building, and no new system will bring any sustained benefit to the company unless it supports the efficient exploitation of the business opportunity it was built to address.

Guideline 2: Use systems to change the competitive landscape. Look for tasks and activities that seem impossible today, but if they could be done, would fundamentally and positively change the ways the enterprise does business. Put yourself in your customers' shoes. In the words of the Nordstrom's motto, think of what would "surprise and delight" your customers. Look for opportunities to create a transformation or value shift in your market. Find ways to do things that provide dramatic cost savings or productivity increases. Then place yourself in your competitor's shoes and think of what course would be the least likely to be foreseen or quickly countered or copied. As long as you are able to do something of value that your competitors cannot, you have an advantage.

Figure 1.3. Strategic Guidelines for Designing Systems

Guideline 3: Leverage the strengths of existing systems. System design embodies strategy. When existing systems have proven to be stable and responsive over time, find ways to incorporate them into the design of new systems. The purpose of strategy is to use the means available to the organization to best accomplish its goal. Build new systems on the strengths of older systems. Nature uses the same principle in the evolutionary process. New systems provide value only insofar as they provide new business capabilities. Time spent replacing old systems with new systems that do essentially the same things will not, as a general rule, provide enough value to justify the cost.^[4]

Guideline 4: Use the simplest combination of technology and business procedures to achieve as many different objectives as possible. A simple mix of technology and process that can achieve several different objectives increases the probability that these objectives can actually be achieved. This simple mix reduces the complexity and the risk associated with the work and spreads the cost across multiple objectives. Using a different technology or process to achieve each different project objective multiplies the cost and the complexity and reduces the overall probability of project success.

Guideline 5: Structure the design so as to provide flexibility in the development sequence used to create the system. Break the system design into separate components or objectives, and whenever possible, run the work on individual objectives in parallel. Try to prevent the achievement of one objective from becoming dependent on the achievement of another objective. In this way, delays in the work toward one objective will not impact the progress toward other objectives. Use people on the project who have skills that can be applied to achieve a variety of different objectives. Using the same technology to achieve several different objectives makes it much easier to shift people from one objective to another as needed because they use the same skill sets. The project plan should foresee and provide for an alternative plan in case of failure or delays in achieving objectives as scheduled. The design of the system you build should allow you to cut some system features if needed and still be able to deliver solid value to the business.

Guideline 6: Do not try to build a system with a level of complexity that exceeds the organization's capabilities. The beginning of wisdom is a sense of what is possible. When defining enterprise goals and the systems to reach those goals, aim for things that are within reach. Set challenging goals but not hopeless goals. The people in the IT organization need to have confidence in themselves in order to rise to a challenge. Avoid exhausting their confidence in vain efforts to reach unrealistic goals.

Guideline 7: Do not renew a project using the same organizational approach or the same system design after it has once failed. Re-doubled hard work and effort are an inadequate response for ensuring the success of a project after it has once failed. People are usually demoralized after the first failure and will not rise to the challenge of doing the work again unless there are meaningful changes in the project approach. The new approach must clearly reflect what was learned from the previous failure and offer a better way to achieve the project objectives.

For six years I was the CIO of a member-owned, national distribution cooperative named Network Services Company (NSC) that served customers such as national restaurant chains, national property management companies, and healthcare companies. NSC provided products and supply chain services related to food service disposables, janitorial and sanitary supplies, and printing paper.

The strategic use of IT resulted in significantly increased sales revenues by enabling the company to enter several new markets. It also reduced operating expenses and provided the internal productivity needed to handle the business growth with only minor increases in staffing levels.

During a four-year period the company's operating model went from almost no electronic commerce except for a little EDI activity to most of its revenue coming in as electronic transactions—from customer order entry to final invoice payments. During this time the company's revenue more than doubled and customers began requiring supply chain services they had never asked for in the past. We had to find new ways of operating if the company was to survive and thrive. This necessity brings out the CIO's resourcefulness and creativity, two essential components of good strategy.

Resourcefulness demands that the CIO work more efficiently and take new approaches. Sustainable creativity requires the discipline to adhere to the seven strategic guidelines mentioned earlier. Otherwise creativity becomes an end in itself, and it can take a CIO on fantastic voyages and flights of fancy that have no chance of success. The past 20 years of business are littered with highly creative, yet strategically irrelevant uses of IT that never achieved success.

NSC retained a prestigious management-consulting firm to assist in its strategic planning exercise. This exercise identified five goals for the business and suggested some strategies for accomplishing these goals. One of the business goals was to develop the e-business systems infrastructure needed to further integrate the member companies into the cooperative organization and allow NSC to better serve national account customers.

At the end of the strategic planning process, the consulting firm very strongly recommended that we build and operate our own state-of-the-art, Web-based, order entry and product catalog system. They offered to begin work on it immediately. That was what everyone else was doing at the time. It is what our biggest competitors were doing. I, however, strongly advised against this course of action because it violated four of the seven strategic guidelines.

The first guideline this approach violated was, "Use systems to change the competitive landscape."Web-based order entry systems were already in use by our competitors and it wasn't clear how much immediate demand there really was for them. It would only be a catch-up or a "me too" move on our part and yet, at the time, would have required the bulk of our IT development budget to build our own system. It seemed far more consistent with this guideline to make our major effort and expenditure in a different area that gave us potential to acquire new business capabilities not then possessed by our competitors.

The next guideline this approach violated was, "Leverage the strengths of existing systems." Web-based order entry systems were already available from e-commerce service providers who would let us lease the use of their systems for a small per-transaction fee and a modest up-front cost to get started.

Another violated guideline was, "Use simple combinations of technology and business procedures to meet the system's performance requirements." Building and operating our own Web-based order entry and catalog system meant a significant amount of technical complexity, and it was much simpler to use an e-commerce service provider for this.

"Do not try to build a system with a level of complexity that exceeds the organization's ability to support it" was the fourth guideline ignored by this advice. Initially, NSC had a relatively small IT group that focused on supporting a basic set of business systems running on a mid-range IBM computer. There were also a few people devoted to supporting e-mail, a simple Web site, and office productivity software running on a local area network. The sudden leap from what then existed to an expanded IT staff and state-of-the-art systems infrastructure operating 24/7 in real time over the Internet was clearly beyond the capability of the company to do all at once. It was better to grow into this over time.

So I used the seven guidelines to facilitate a process of selecting and combining different ideas until a truly resourceful and creative IT strategy emerged. The strategy called for construction of a suite of four systems that each provided value in their own right and worked together to deliver an e-business infrastructure with the performance capabilities we needed.

Those systems were built with a mixture of simple technology and offthe- shelf software packages. As a consequence, we spent only a fraction of what our competitors did. The first version of our e-business infrastructure was up and running in nine months, whereas our competitors took much longer to get their infrastructure in place. The four systems were:

In the following years we continued to enhance these systems with new features as needed. We used the capabilities these systems provided to form supply chain partnerships with new and existing national account customers. These systems allowed us to work cooperatively with them to lower their overall cost of purchasing and using our products without requiring us to just reduce prices on the items we sold them. The company was able to command slightly higher gross margins than its competitors because customers were willing to pay a bit more in order to get the customized bundle of value-added services that we could provide them thanks to the IT infrastructure we developed.

This strategy was particularly successful in growing the business in a new vertical market segments. One segment was the national building service contractor (BSC) market. These are companies that contract with property managers to clean office buildings, shopping malls, healthcare facilities—a very fragmented market that was consolidating into national chains.

Our systems provided BSC customers with both e-procurement capabilities and daily updated sales history reporting. Their managers could get online reports that showed consumption of supplies by job site, by product, and by manufacturer over any time period they specified. Our e-business systems provided customers with key tools that allowed them to manage operating expenses and realize the economies of scale that supported their profit margins. By partnering with us, customers avoided the expense of building their own supply chain management systems.

I structured the development and rollout of these systems into phases that each took three to nine months, as shown in Exhibit 1.4. Each phase created a set of production subsystems that became the basis upon which to build further subsystems or enhancements. As these phases were completed, we were able to take stock of the changes in our markets and respond appropriately to opportunities as they presented themselves.

A strategy is not worth much if people do not understand it. One of the main purposes of strategy is to provide a common framework that everyone can use to organize their activities and visualize how their own actions move the company toward its stated goals. People need to see how the strategy translates into a believable sequence of steps that gets the enterprise closer to its goals.

The best way to do this is with charts and diagrams. Something is wrong with either your strategic understanding or with the strategy itself if you cannot illustrate it in a few clear diagrams. The next two exhibits illustrate and quantify an IT strategy that could have been used at NSC to move the company toward its new business model. Exhibit 1.6 shows how the four e-business systems components would develop from existing IT infrastructure and evolve over several years. Exhibit 1.7 shows more detail to illustrate the activities in a particular year. It also quantifies the timelines and budgets for development projects in the second year of this proposed strategy.

Figure 1.6. Phases of IT Strategy and systems

Figure 1.7. Timelines and Budgets for Year Two

The actual strategy used by NSC was different from the one depicted in these exhibits. The point is that, as CIO, I was able to play an important role in shaping the company's strategy by presenting my ideas in this kind of graphic format. This format allows people to quickly grasp the essential outline of a proposed strategy, and it facilitates productive discussions about possible modifications or alternative strategies.

Note that the phases of this proposed strategy are each three- to ninemonths long. Good IT strategies deliver tangible benefits within time frames like this. Note also that each phase builds upon the deliverables of the previous phase to continue to build out the systems infrastructure needed to support the enterprise's changing business model.

After illustrating and quantifying the IT strategy it becomes the CIO's message to the world—a message to be communicated constantly to a range of different audiences. When you do this job well you begin to feel like a candidate running for elected office because in a sense you are. You must solicit the approval of enough people to make your strategy a reality.

The execution of strategy is all about getting things done. And to get things done you need the active cooperation and participation of a lot of people, all of whom have slightly different agendas. The CIO must constantly explain what is in the IT strategy for them and why they should actively, vocally support the IT strategy.

The CIO also listens to people's responses and makes adjustments to IT strategy when necessary. Remember that the business goal (the destination) usually remains steady over a two- to four-year period but the way to reach that goal (the strategy) can change as the situation unfolds. Listening to how people respond to your message is the other half of sound communication. The message needs to evolve so that people buy into it. They buy in and become supporters of your strategy when they know you are listening to what they have to say.

Inside the universe of groups with which the CIO communicates, a smaller subset of people either builds or uses the systems called for by IT strategy. The CIO must pay even more focused attention to these groups.

With these people the CIO moves beyond communicating the strategy and listening to feedback. Spend considerable time one-on-one and in small group settings explaining the details of the tactics being used and why those tactics can deliver success, and make sure people get the training they need so they can perform the tasks that the tactics demand of them.

People want to be part of a winning project. They want to understand how the work will be done (the tactics being used). When they understand the tactics and believe those tactics can bring success they buy into the project wholeheartedly. Then the CIO steps back and lets them do their jobs. When people do not buy into a project they require constant supervision and cajoling to get anything done. An unwillingness to participate also tells you something very important. It tells you that your tactics may well be flawed.

Remember, tactics are composed of sequences of techniques. Every job and profession has a core set of techniques; in the IT profession some of the core techniques are process mapping, data modeling, and object-oriented design and programming (see more about these core techniques in Chapter 3). Make sure you know what techniques are required for the tactics you use, and make sure people receive adequate training in those techniques.

CIO leadership styles are judged by the decision-making processes they use. The more open a CIO's decision-making process, the more opportunity to get the commitment and active participation of those who will actually do the work. If done effectively, an open decision-making process is an extension of the communication, explanation, and training you provide.

The CIO, however, remains ultimately responsible for setting and carrying out the IT strategy, and some decisions need to be made by the CIO alone. People expect the CIO to make the tough calls when there is no consensus among lieutenants, when there is not enough information, and when time is short. But otherwise people do not like dictators.

The best, most competent people in particular, want an active voice in the decision-making process. As the leader of the decision-making process, the CIO's role is to see that timely and accurate information is available and that people get a chance to examine it, ask questions, and voice their opinions. The CIO's role is to ask questions that focus people's attention on the important issues. Keep people from wandering off subject, bemoaning past mistakes, and discussing personalities instead of issues. When the CIO acts as a participatory leader, consensus decisions usually emerge that combine the collective wisdom of the entire management team. Encourage people to take ownership of their decisions and act on them without your constant oversight.

In my experience there are five elements that create an effective decisionmaking process. They must all be present because their cumulative effect produces the best participatory decision-making process. Those five elements are:

Much has been said and written about the need for a project management office or PMO. In actual practice many IT organizations pay lip service to the idea and do not have full-time qualified staff devoted to the PMO. They expect already overworked project leaders to also do the work of the project office. The PMO provides weekly updated project plans and budgets as well as accurate reports of operating expenses to date. As discussed in the section on the six tactical principles for running projects, these activities are a full-time job. Expecting project leaders to do this in their spare time is like expecting business unit managers to also do the business unit's bookkeeping and accounting in their spare time.

Dashboards are a way of displaying the most important information about a project in a layout that can be quickly scanned and understood by everyone, not just data analysts, engineers, or accountants. Project leaders should not be overloaded with detailed data or have to spend the time and effort reading through reports and piecing together data just to get a clear picture of what is happening. By way of an analogy, a racecar driver needs a quick display of the car's key performance indicators, not a detailed dump of engine statistics.

Regular weekly meetings are the forums where project leaders responsible for implementing IT strategy come together, review up-to-date project plans, budgets, and dashboards, and make decisions. The CIO has frequent informal, one-to-one meetings throughout the week with individual project leaders, but projects also need regular full group meetings so that everyone can stay current with the big picture and understand how their individual projects combine to enable effective execution of the full IT strategy.

The CIO sets the tone and the pace of these regular meetings. The tone must be positive, focused on issues not personalities. Everyone must feel empowered to voice their opinions and share their ideas. The pace of these meetings should be brisk. These are not leisurely (or boring) recitations of routine reports. The CIO focuses discussion on important issues with the aim of making decisions and taking action. If not much has happened in a given week the meeting can be short. If much has happened, the meeting is longer. Attendance is mandatory because the group only discusses serious issues and everyone lives by the decisions made at these meetings.

Leaders who really want the benefits of a participatory decision-making process encourage and respect the obligation to dissent. I tell my own staff that part of their job is to make sure I don't go off on a tear and do something stupid. That means they need to speak up if they see something I miss. I may be so focused on one aspect of a situation or so in love with some idea that I miss something that could lead to serious trouble.

This concept is put to good use by organizations such as the U.S. Marine Corps.^[6] These organizations have learned over time that only a frank discussion of issues and options can consistently produce competent results. Decisions lose consistency when people believe that their role is merely to keep their opinions to themselves and rubber stamp whatever the boss thinks is a good idea. If that is the case, lots of bad ideas will find their way into actions that only lead to failure.

Trust is the glue that holds any group together—a glue that is hard to create and very easy to destroy. People speak up when they trust they will not be penalized. People follow a leader when they trust that the leader will not set them up to fail. Leaders get things done because they delegate authority and resources to people they trust to do the jobs that need to be done.

When trust breaks down action grinds to a halt. Nobody makes a move without first getting written permission. Nobody grants permission without first doing a full investigation. Matters soon deteriorate into superficial public posturing and conspiratorial whispering in private. Everyone becomes afraid of being made into a sacrificial victim to atone for the mounting list of failures that inevitably result from the breakdown of trust.

Strategy is about defining a way to reach a desired destination. Tactics are about competently executing your chosen projects. Somewhere between high strategy and the tactical details embedded in the operations of any particular project lies that place where you must first choose your projects. This is a place where the CIO learns to see opportunities and risks from an operational perspective and develop an appreciation of their potential.

CIOs can choose from many potential projects to implement their strategies, but how do they select the project with the best strategic fit? Time teaches successful CIOs how to master this operational art. Mastering the operational art has been described as "knowing when a tactical move can deliver strategic results."^[7] Effective CIOs develop a keen sense of the operational art. They see opportunities to employ available means to achieve breakthrough results. Where others see only obstacles, masters of the operational art see openings.

To illustrate this, I once worked for a company that had just won a contract with an important new customer. But to get the contract we lowered our prices and agreed to a 12-month contract term instead of the threeyear term we usually requested. We also agreed to only a portion of the customer's business because they had already awarded the other portion to one of our competitors. By playing us off against our competition, they wanted to see how we both performed before awarding a longer exclusive contract to either of us.

At a senior management meeting one day we heard that this new customer was showing up on the slow pay list. They had agreed to pay us within 15 days, but were actually taking from 45 to 60 days in some cases. We knew they were not a credit risk, so why were they taking so long to pay? It impacted our cash flow, increased borrowing against our bank line of credit, tied up collections staff, and further lowered profitability on the account.

Upon hearing this the CFO said the customer had violated the terms of their contract and they should either pay all of their past due amounts right away or he was going to put them on credit hold and we would not ship them any more product. The sales VP protested the harshness of that recommendation and began arguing for extended credit terms.

He said part of the problem was that the customer's line managers who ordered our products had to personally review all our paper invoices and type them into their accounts payable system before they could be paid. Many of those managers were so busy handling their rapidly growing business that they sometimes had to work evenings and weekends just to complete administrative tasks like approving our invoices.

I saw an opening. I saw an opportunity to use our IT capabilities to provide a service that would help the customer streamline their ordering, receiving, and payment process. I saw a way to increase their managers' productivity, differentiate us from our competitor, and help us win all their business without having to further drop our prices. What was this opportunity?

By using our EDI system we could send them electronic invoices that arrived before our delivery trucks. The electronic invoices would be automatically imported into their payables system. Then their managers could call up our invoices on their system and check off line items as they unpacked our shipments. If everything was consistent, the press of a button released the invoice for payment. If there were problems we would learn about them sooner and could fix them faster. Once this new receiving process was in place we could then move on to provide the customer's managers with our online product catalog and order entry system to speed up the ordering process and further reduce errors.

Implementing this idea cost me no more money than what was already in my operating budget. The customer liked the idea. We had a pilot program up and running within 60 days. The customer began to see us as a true business partner and not just an anonymous supplier.

In my own experience and in talking to and reading the works of people who know even more than I do, I find that boldness is based on the ability to understand the difference between a smart, calculated risk and a foolish gamble. A smart, calculated risk is an action that is not a certain success but one that has potential to deliver extraordinary rewards compared to the risks taken. A foolish gamble is one that delivers a small reward at the cost of risks bearing dire consequences.

CIOs need to clearly understand the potential upside of a project in comparison to the magnitude of its downside. Unless there is literally nothing to lose, never take a risk where the magnitude of the downside could overwhelm your ability to recover and exit from the situation intact enough to try again another day.

To illustrate, let me relate the story of the "great generator gamble". I have run the IT operations at several companies. I was once in charge of the IT group at a company where the CEO had gone on a tear about cutting expenses. He denied requests from managers to replace broken office lamps, he checked to see that people booked tickets on the cheapest airlines, and he began micromanaging everyone's operating budgets.

One hot summer day we experienced power brownouts in the office park where we worked. Then suddenly the power went off altogether and the building went dark and quiet. The computer room stayed lit and our systems stayed up, but we should have immediately heard the roar of the generator out back as it kicked in to power the office. The generator did not come on and we realized our systems were running on the batteries of the UPS unit (uninterruptible power supply). We had only about 30 minutes of power. If the power grid did not come back on in the next few minutes we would have to start an orderly shut down of the systems while we still had time to do so.

The power did come back on. We looked at each other and thanked our lucky stars. We called a service technician to check out the generator right away. He found that although the generator turned on when we ran our monthly tests, the fail over switch that sensed when the power grid went down was not working. We replaced the switch.

Then we ran another test that weekend. We turned off power to the building to see if the generator came on. The generator came on but within minutes it overheated and shut itself down when subjected to the full load of carrying the office. This started a sequence of tune-ups, repairs, and tinkering to try to get the 18-year-old generator to actually work under real conditions. After another few days and several more tests my staff and I realized the old generator could not be trusted. I drew up a budget request for a new generator.

The CEO refused to spend any money. He insisted that we find a way to make do with what we had. In a meeting to discuss the situation he told me the generator light in his new Cadillac car had recently come on and the dealer wanted him to spend a lot of money to fix it, but he had ignored the advice and the problem went away.

For the next month and a half we saw more studies, more tests, more generator part replacements, and more meetings. Under the CEO's direction, the CFO got involved and started an inquisition to determine what he called "the true facts of the case". Everyone, including me, retreated to their offices and began writing CYA (cover your a--) memos. It was clear that if anything went wrong everyone would be potential scapegoats in the finger-pointing that would ensue.

The CEO was determined to hold the line on spending and make his profit targets for the quarter. Deferring a new generator purchase was one way to do this. The upside was that he looked good and made his budget numbers. The potential downside of his choice would have been catastrophic. It was bad enough if the power went off during the day, but what if it went off at night or on a weekend? The batteries of the UPS unit would last for half an hour and then our systems would experience a hard crash.

All our service warrantees explicitly excluded coverage for damage from a hard crash, and we would probably have to replace much of our systems hardware infrastructure. Because our off-site disaster recovery project was also not fully funded it would take weeks to restore our systems. In addition, several of our most important customers had begun using certain of our systems to support their own internal operations. And we had promised them they were properly backed up and covered in the event of power or equipment failure.

The CEO did not use participatory decision making nor did he encourage or respect an obligation to dissent in his meetings. Any trust that might have existed among members of the management team quickly disappeared. After two months of high risk and drama a decision was finally made at the beginning of the next quarter to replace the old generator. I left the company soon thereafter.

Answers to these questions help people connected with a project make accurate assessments and take appropriate corrective actions. Three main areas of concern need to be investigated on any development project:

Goodness of the System Design Notions that good designs must include state-of-the-art technology or complex processing logic are entirely misplaced. The goodness of a particular system design is measured by the combination of two probabilities. The first is the probability that the system will meet the performance criteria that were specified for it to accomplish its business goal or mission. The second probability is the probability that the system can be successfully built.

The best system designs usually do not use state-of-the-art technology or complex processes for the very reason that newness and complexity tend to introduce uncertainty. Uncertainty reduces the probabilities that the system will perform as expected or that it can be built on time and on budget.

The goodness of a system design can be accurately predicted by the extent to which it respects the seven strategic guidelines for designing systems. If a design omits only one of these guidelines—as long as it is not the first guideline—it may still be a good design. When a design disregards two guidelines there had better be very clear and convincing reasons. There must also be well-thought-out preparations to compensate for design omissions. Designs that disregard three or more of the guidelines will fail. The probability of building a successful system that violates this many guidelines is about the same as the probability of winning the lottery.

Progress Made in Building the System Successful development projects move along at a smart pace. The pace of progress must be aggressive or the project tends to lose its focus and begin to wander aimlessly as the world passes it by. An aggressive pace requires two things: (1) rigorous application of the six tactical principles for running projects; and (2) effective time boxing.

The CIO is responsible for applying the first tactical principle, which is to make sure there is a qualified full-time leader (system builder) for every project. It is then the responsibility of the system builder to effectively apply the other five tactical principles. There is no convincing reason to ignore any of these principles. When the system builder omits one or more of these principles, you need to do everything in your power to reinstate the missing principles. These principles are mutually reinforcing. Omitting even one principle creates a dynamic that undermines the application of all the others.

The second requirement for moving projects along at a smart pace, effective time boxing, means that the activities of each project team are organized to follow a clear "Define-Design-Build" sequence for developing systems. The activities in each of these three phases need to be completed within the time-box constraints and budgets appropriate to each phase. The system builder works with the project team leaders to set the time boxes, and the project teams keep up the pace to meet their selfimposed deadlines. See Chapter 3 for an in-depth discussion of the Define-Design-Build sequence for ways to promote a tactical, agile IT organization.

Competence and Confidence of People on the Project People charged with developing new systems must be competent and confident in order to succeed. Competent people who lack confidence move slowly. Confident people with no competence have even more trouble. Systems development people must possess both the know-how and leadership skills.

CIOs can measure people's qualifications. The first type of measurement determines the degree to which people working on the projects can make good tactical use of relevant analysis and design techniques such as process mapping, data modeling, and system prototyping. Good use of technique is everything for people working on or leading project teams.

The system builder and the team leaders need to understand and know when to employ each relevant technique. They must be competent in all relevant techniques and masters of a few of them. Individuals on the project teams must be competent in or masters of the specific techniques they will need to fulfill their roles on the team. The efficient use of relevant techniques allows project teams to complete their work within the aggressive time-box constraints that successful projects demand.

The second type of measurement determines the degree to which the system builder and the team leaders are capable of demonstrating the requisite leadership skills. After a period of watching someone in action, most experienced CIOs can make a fairly accurate assessment of that person's design and leadership skills. When project leaders and team leaders have these skills, good system designs emerge, effective leadership happens without rancor, and a visible air of confidence becomes evident on the faces of the entire project team.

Goodness of System Design Ask yourself and the system builder in charge these questions for each project. Whenever possible, ask these questions in the first 2–6 weeks (the Define phase) of the project:

Ask the system builder to explain to you which of the strategic guidelines for designing systems have been followed and which have not. For those that have not been followed, why not?

If all the seven strategic guidelines are followed, your system design is very good. It is acceptable if one of the guidelines is not followed— any one as long as it is not the first one. If two of the guidelines are not followed there had better be very good reasons, and extra precautions need to be taken to compensate for the increased risk. What are these precautions? If more than two of the guidelines are not followed, then the design is fatally flawed—the system cannot be built on time or on budget if it can even be built at all.

Progress Made Developing the System Ask these questions once the conceptual system design and initial budget have been agreed upon—the end of the Define phase. Ask these questions of yourself, the system builder, and the people on the project team as the project moves through the Design and Build phases.

Spot-check the project plan and budget from time to time. Have the system builder review the current, updated project plan with you and explain the situation on the project as of that week. Review the project budget—have the system builder show you the money spent to date on each subsystem and the estimate for remaining time and budget to complete each subsystem. How does the most recent estimate of time and budget compare to the original estimate for time and budget? Is it still worth the cost to complete the project?

Competence and Confidence of People on the Project Ask these questions of yourself, the system builder, and the people on the project teams: