Chapter 1 opened this book with a discussion of the CIO's two primary responsibilities: (1) to ensure the stable and reliable functioning of the enterprise's IT infrastructure—meaning all the application systems and all the hardware and software on which those systems depend; and (2) to continually evolve and enhance the IT infrastructure so that it remains properly aligned with the enterprise's evolving business needs. These responsibilities ensure that the enterprise has the IT capabilities it needs to carry out its business strategy and to respond effectively to threats and opportunities as they arise.
This chapter builds on these foundations to address IT tactical agility. In the high-change, high-risk, and highly competitive global economy in which enterprises compete today, CIOs can make their most valuable contributions by evolving and enhancing the IT infrastructure so that it stays aligned with business strategy. This is where CIOs must devote the bulk of their attention and their time. Although the CIO still remains responsible for the reliable day-to-day functioning of the IT infrastructure, that responsibility is not a "C"-level job anymore. CIOs must delegate IT operations to direct reports and partner with service providers to whom they can outsource selected IT operations.
It is no longer about the technology itself; it is about how well the CIO uses it. It is no longer about squeezing more efficiency from internal IT operations; it is about how well the CIO responds to external opportunities. Running an efficient and cost-effective IT organization has fallen off the list of the CIO's high-value strategic contributions because so many enterprises have learned to perform them as basic disciplines. Senior management simply expects this kind of baseline performance from the CIO. Enterprises have used IT to increase internal efficiencies within their organizations over the past decade. CIOs and their IT organizations have learned to become much more cost effective in the way they run their operations.
IT alignment with the enterprise is the new focus where the CIO can add the most value. With the rates of change in most enterprises, IT alignment work has become a full-time job in a way that was not the case even 10 years ago. Today enterprises live in a high-change world where advantage goes to the most agile enterprises, not just the most efficient ones.
The conditions for operational efficiency keep changing and enterprises must learn to adapt and keep up with their markets. Just doing the same old things the organization has always done more efficiently brings less and less return when customers lose interest in those things.
Enterprises need to be agile to keep up with their markets, and IT organizations must be agile to stay aligned with their enterprises. As enterprise strategy evolves over time, the CIO must constantly assess strategic changes and their impact on the IT organization. Does the existing infrastructure support the new business strategies? What new capabilities are needed? How can existing systems best be leveraged, and what new systems are needed?
Let's start by defining a tactically agile IT organization as one that senses and responds to environmental change efficiently and effectively. The two operative concepts here are "senses and responds" and "efficiently and effectively." In other words, IT organizations must (1) constantly collect and analyze information to detect change and (2) respond appropriately when changes are detected.
Agility is an ongoing process, not just an occasional event. An agile IT organization is not an athlete one day and then a couch potato the next day. An IT organization cannot be agile unless all its members are agile, so agile work principles need to be understood and practiced by everyone.
The diagram in Exhibit 3.1 outlines the process flow that creates agility throughout the IT organization. Note that agility is composed of three sub-processes or activity loops that all run concurrently.
Loop 1 encompasses environmental monitoring and responsive decision making. The people in this process are responsible for making the decisions that deliver successful IT alignment with the business. This is where CIOs focus most of their time because this is where they deliver the most value to their enterprises.
The focus of the environmental monitoring and decision-making process must be to identify, analyze, and respond to the "nonstandard inputs" as shown in Exhibit 3.1. This is because the most profitable opportunities for better alignment of IT and business often arise from agile responses to new or unexpected events (nonstandard inputs). The CIO needs to know when transaction processing volumes increase or decrease at unexpected rates and when system processing or operating errors occur at greater than expected rates. These events usually signify a need to improve an existing IT operation. The CIO also needs to know when new competitors enter the market and when sales of certain products increase or decrease faster than expected. Events like these often signify a need to create a new system or work process.
For example, consider the response you would make to the unexpected news that sales of your enterprise's new product X were increasing much faster than had been anticipated and also that customers who bought product X were two-thirds more likely to then purchase product Y within the following 60 days. The way you as the CIO respond to this unexpected news and the speed with which you deliver needed IT support will be a determining factor in how much success your enterprise can achieve.
The CIO needs to consider the IT components that support product X and determine how to scale them up faster than originally planned to handle the extra sales volume. Then decide what new IT support can enable the enterprise to best exploit the emerging opportunity for sales of product Y and how soon that support should be in place.
In responding to this unexpected news you as the CIO might decide to launch two projects. One project would accelerate the build-out of processing capacity for the systems that support product X. The other project would develop new systems to address the emerging opportunity for product Y and other follow-on product sales. The IT organization's level of agility is measured by how appropriate your decisions are and how well you and the IT organization can carry them out.
After making a Loop 1 decision, one or both of the other two loops engage to act on your decision. Loop 2 focuses on improving existing operations—delivering efficiency. Loop 3 focuses on creating new operations—delivering effectiveness. When used in combination, the IT organization can use these three loops to sense changes and respond efficiently and effectively.
A close examination of the agility process diagram reveals several important features of Loops 2 and 3 that contribute to an agile IT organization. First, notice that data from the environment and customer demands are handled by a set of standardized operating processes. They handle most of the input reliably and efficiently.
The IT systems that drive the standard operating processes (SOPs) of the enterprise should be as automated and reliable as possible. They are the basic transaction processing systems such as ERP, order management, and production scheduling. Make them stable and scalable to handle the fluctuating transaction-processing loads required to support the enterprise in performing its day-to-day operations. Give them robust error handling capabilities that prevent bad data from entering the enterprise's systems. These systems identify, isolate, and set aside bad data or "nonstandard input" for appropriate people (not computers) to examine.
The agility of an IT organization is directly related to its ability to handle nonstandard input. Automated transaction processing systems handle the standard input so people can focus on everything that is nonstandard. This is where people bring the most value and where they should spend most of their time. People need to be skilled in analyzing nonstandard input to determine its cause. Nonstandard input comes from one of two conditions.
The first condition results from errors in the input data or in the system operations. If there are errors in the data or system operations, people use Loop 2 to identify root causes of the errors to fix or improve the relevant standard operating processes and the systems that support them.
The second condition occurs when the input data is correct and it represents a new trend or an event that was not anticipated when the system was built. New events occur as business conditions and markets change and there are no standard operating procedures to deal with the occurrence. In this case, people use Loop 3 to make assessments about whether it represents a threat or an opportunity.
Their work often results in the creation of a new operating process in response to this type of nonstandard input. If successful, the new process is added to the existing stack of standard operating processes. In this way the standard operating processes themselves continue to evolve as the enterprise evolves—this is the agile process that maintains IT alignment.
Clearly, agile people in an agile IT organization must be skilled in the tasks called for by these three process loops. Let's take a more detailed look at each loop by first mapping out the activities that are involved and then discussing some of the tactical skills and technology needed to do these activities well.
Flying a jet fighter plane in combat is perhaps the epitome of agility. A fighter pilot named John Boyd devoted his life to understanding and teaching the skills of agility. He fought in the Korean War and then went on to become an instructor teaching the best U.S. and allied pilots in advanced air-to-air combat tactics.
Over the years he articulated what he had learned about the best way to deal with fast-paced and complex environments. Boyd encapsulated his teachings in a learnable and repeatable process that shows individuals and whole organizations how to compete and win in any high-change situation. He named this process "Observe—Orient—Decide—Act" (OODA)—also known as the OODA Loop or Boyd Cycle.[24]
The monitoring and decision-making activities of Loop 1 in the agility process are well described by the Boyd Cycle. The next sections describe the four steps in the Boyd Cycle and show how they can be applied to the tactical operations of an IT organization.
There are four steps in the Boyd Cycle, and the first step is to observe. This involves collecting and communicating information about the environment. In an IT organization this includes information such as performance statistics for all systems, project status for all development work, and budgetary status.
The second step is to orient. This is the most important activity because it is where information is turned into understanding. Understanding is used to build an appreciation of the situation and its possibilities. The next two steps depend on this appreciation of the situation.
Translated in terms of an IT organization, the first and second steps mean that the IT operating environment is described and relevant measures are plotted over time so that performance trends become visible. The progress of the different system development projects are summarized showing key project completion statistics such as money spent, deliverables produced, and time and budget. Also lay out other expenses in areas such as systems operation, staff training, and salaries. With this information people can assess the situation and look for new threats and opportunities in the IT environment.
In the third step, decide, people (1) investigate different responses to threats and opportunities and (2) create and evaluate plans for implementing different responses. In an IT organization, that means creation, evaluation, planning, and budgets for different system architectures and development projects. IT staff members consult with people from the business units who will be users of potential new systems.
Choosing the most appropriate plans leads to the fourth step—act. Depending on the decisions made in the orient and decide steps, the act step results in a tactical action that either improves an existing process (Loop 2) or creates a new process (Loop 3). In the act step, action is taken with either favorable, not favorable, or indeterminate results. These results are picked up in the observe step and the loop continues.
Note that the Boyd Cycle does not require people to cycle through all four steps all of the time. It is not a lock-step sequence. For example, the decide step is not needed when an environment is well understood. People can simply cycle quickly between orient and act steps in a series of rapid responses. At other times people may decide not to act at all but just observe and orient, waiting for an appropriate opportunity to act. It is better to think of the Boyd Cycle as an interactive network of activities with the orient step at its core instead of a fixed sequence of steps, as illustrated in Exhibit 3.2.[25]
Let's take a closer look at the orient step because it is the most important. People form a picture of the world in the orient step, and this picture of the world drives the decisions and actions that follow. Good orientation is central to one's ability to take effective tactical action and achieve desirable results.
The orient step needs the most support from business intelligence (BI) capabilities. The real world unfolds in "an irregular, disorderly, unpredictable manner" as Colonel Boyd put it. Effective CIOs watch their business and IT environments and make decisions about how best to respond as day-to-day and week-to-week situations unfold. Dashboards and other Web-based reporting systems significantly improve outcomes in this step.
Another major concept of the Boyd Cycle implies that everyone in an agile organization has a common understanding of the organization's purpose and its major objectives. In military organizations this is known as the "commander's intent" or the "mission orders"—people are told what needs to be done but they are not told how to do it. They are not micromanaged; instead they are trusted to do the right thing.
The Boyd Cycle expresses common understanding of purpose with the notions of implicit guidance and explicit guidance. When the IT staff knows what the CIO expects of them and when they possess accurate, timely information about their own performance, then they can take their own corrective actions as demanded by the situation without waiting to be told what to do.
If the CIO defines performance objectives for the IT organization and makes performance data available via dashboards and other BI systems, people do not need to be micro-managed. They can see for themselves what the situation demands and act appropriately. In this way the CIO provides implicit guidance to the IT organization. As shown by the heavier lines on the Boyd Cycle diagram, the best CIOs most often make use of implicit guidance.
CIOs provide explicit guidance when they make decisions to change IT strategy and stop or start IT development projects. CIOs use explicit guidance when the rules of the game change. When this happens people need to be informed of the changes and told how those changes affect their jobs and performance expectations. Once this happens people readjust, and implicit guidance again takes over to guide their actions.
As CIO you need to make sure that you clearly explain what you expect from people in your organization. Define clear performance measures and expected results. Implicit guidance works very well when people know what the CIO expects of them and when they get regular and accurate performance reports. Implicit guidance is more efficient than explicit guidance because it requires less of the CIO's time once the performance expectations are in place.
Some combination of three leadership errors is troubling your IT organization if the CIO always has to tell people what to do and how to do it: (1) The CIO may not have clearly defined expectations; (2) People are not getting timely performance reports; and (3) The CIO may be changing course and starting new projects too frequently.
These three leadership errors push the CIO into excessive use of explicit guidance practices. People cannot be agile in an explicit guidance environment because they are always waiting for the CIO to make decisions and tell them what to do. The CIO who constantly resorts to explicit guidance practices to get things done in the IT organization must find ways to address the reasons causing this unhealthy situation. Your organization cannot be agile until you address these issues.
Depending on the decisions people make in the orient and decide steps, an IT organization is constantly called on to act. At the highest level, action can be thought of as activities that fall into one of two categories. The first category includes tactical activities that improve existing operations (Loop 2). The second category includes activities that create something new (Loop 3).
In addition to being a universally applicable performance measurement, Six Sigma provides guidelines as IT organizations and project teams move through the activities they need to improve their operations and their products (see Sidebar on the following page). A five-step process guides IT teams through these Six Sigma activities: define, measure, analyze, improve, and control. [26] The process is shown in Exhibit 3.4. It is known as DMAIC (first letter of each step) and is pronounced "dee-MAY-ic". Let's take a look at the activities in each step.
Most of the CIO's work begins with definitions. The define step begins a Six Sigma project and produces three important documents. The first document is the project charter. The charter lays out the business case and the problem statement. It also clearly defines the project scope so that the project team knows exactly where to focus and what they should avoid. The charter also articulates the goal or mission of the project and the specific objectives that the team needs to achieve in order to accomplish the goal. Operationally, the charter lays out project milestones that indicate to the team where and when they should be achieving other sequential steps in the DMAIC process. Finally, the charter describes the roles and responsibilities of the team members, the team leader, and the project executive sponsor.
In addition to the project charter, the second document produced in this step defines and documents the customers that will be served and their needs and expectations. The needs and expectations of the customers tell the team what to measure and improve. The third document is a high-level process map that shows the tasks involved in the process and the inputs and outputs of each task. The high-level process map shows everyone involved with the project the exact sequence of tasks that are candidates for improvement.
In this step the project team creates a data collection plan and then collects data that measures the current state of the process or product targeted for improvement. The data collected reflects customer requirements and shows how often the process actually meets customer requirements. The data also shows the activity levels of key tasks in the process.
After collecting the data the team calculates the existing sigma measurement for the process. This obvious step of collecting data and documenting the current situation is often overlooked or done poorly because the project team thinks they already know what is wrong and they want to get on to fixing the problem. Good data collection gets the project off to a start in the right direction.
In this step the project team applies statistical analysis tools to discover and validate root causes of problems. Many of the tools used in this step come from total quality management. The team uses cause-and-effect diagrams and frequency distribution charts to pinpoint the sources of error in the process being investigated. They use scatter diagrams to test the strength of correlations between one variable and another in the process. They use run charts to track the performance patterns of various tasks and of the process overall.
As they pinpoint problems, the team then formulates options for eliminating or reducing these problems and compares the different options. How difficult is each option? How much will each cost? What impact will each option have on improving the sigma measure of the process?
In this step the team leader works with the project's executive sponsor to select a group of improvement options. They choose the options with the best chance for success and with the greatest impact on the process.
With the sponsor's backing, the DMAIC team implements the selected improvements to the process. Best practice calls for the team to implement the improvements one at a time or in small groups of related improvements. After implementing each improvement the team should collect process performance data and recalculate the sigma measure—hopefully the sigma measure improves. Recollection and recalculation ensures that either the improvements actually provide valuable results or they are discontinued.
Once a team makes process improvements they need to regularly monitor the process to assure that the improvements stay in place and remain effective. The DMAIC project team defines a set of measurements collected on an ongoing basis to document performance levels of the improved process.
In addition, the team creates a response plan that lays out corrective actions if ongoing performance measures indicate that the improvements are beginning to slip. Over the longer term, the greatest benefit from the Six Sigma approach is that organizations reap the very real benefits of process improvements that continue to improve and thus deliver more and more value.
In the first phase—Define—the CIO helps people identify a goal and the objectives or performance requirements that need to be achieved to reach the goal. In this phase they create several conceptual designs of business processes or systems that will attain the specified performance requirements and objectives. Then, based on application of the seven strategic design guidelines (see Chapter 1 pg. 11) and ROI analysis (see Chapter 8 pg. 343), they select a preferred conceptual design.
Based on this conceptual design, people move into the next phase— Design. This phase expands the conceptual design out to the level of detail necessary for accurate evaluation and implementation of the proposed new system or business process. Teams test the selected technology and procedures for their suitability and create detailed specifications and plans to guide the work of implementation.
In the third phase—Build—people focus on executing the implementation tasks as rapidly as possible to deliver the required systems and roll out the new business procedures called for in the design specifications. As the new systems and procedures go into use, objectives are achieved and new situations unfold. People continue working toward their goal by cycling through sequences of these three steps as appropriate. This Define-Design-Build process is illustrated in Exhibit 3.5.
This process of sequential steps increases the momentum of the project at each step. The change, or delta, in the momentum and focus of the project can be objectively measured as work moves from one step to the next.
When done successfully, this sequence of steps produces an increase in forward momentum that is as clear as walk-trot-run!
The concept of management by exception is nothing new, but in the context of the agile IT organization it is absolutely central to the way the organization works. The agile IT organization lives in a world of continuous and enormous flows of data. How does it process this data without becoming overwhelmed? The agile IT organization works by using standardized operating procedures (in effect an autonomic nervous system) that handle all routine transactions automatically with little or no human intervention. The organization devotes most of its people's time (its conscious nervous system) to handling only the exceptions or the nonstandard inputs.
In an agile IT organization automated business process management (BPM) systems immediately notify appropriate people when exceptions or nonstandard input occur. People analyze exceptions, not computers. If there are errors in the data, people track down root causes and fix them.
When the data is not in error but indicates the appearance of something new, it is very important to have people in the exception-handling loop. This puts them in immediate and intimate contact with the data indicating a change that could be an emerging threat or opportunity. Using implicit guidance they make decisions and act quickly. If changes of strategy are needed, the CIO gets involved and issues explicit guidance. Exhibit 3.6 illustrates the system dynamics of the agile IT organization.
Efficient operation of existing systems and evolving the IT infrastructure to align with ever-changing enterprise needs are the two main activities of any CIO. The IT profession has gotten very good at the first activity, but the second activity is still a high-risk undertaking. CIOs must demonstrate a high degree of competence and success in this activity to deliver the value their enterprises expect from them. The competitive, global economy requires most enterprises to constantly adapt to changes and reexamine their business strategies. Keeping IT aligned with the business regularly calls for the creation of agile new systems and procedures. The next four sections examine this topic.
The process of creating new IT systems has traditionally been described by various development methodologies. The problem with most development methodologies is that they are unnecessarily complex and often too cumbersome to apply in real life. An agile IT organization needs an agile process for developing new systems and enhancing existing ones.
Agile development processes have to be powerful yet simple enough so that people can understand and use them when they need them. They should also be flexible enough so that they can be tailored to meet the demands of any specific development challenge. The Define-Design-Build development process addresses these needs.
When you think about what is needed to create something new it all boils down to just three basic steps. First define what you are going to create. Then design how to create it. And then you build it.
One can further divide each of these three steps into sub-steps, but this only increases the complexity of the process and reduces the likelihood that people will understand or use it effectively. Define-Design-Build provides an uncomplicated framework to guide development work for any new business process or system. It also provides a reliable way to estimate development times and budgets.
From the perspective of the CIO and other senior executives who sponsor a system development project, Define-Design-Build is a way to manage project risk. In the Define phase small amounts of time and money are spent up front to qualify a business opportunity—5–10 percent of the total project cost.
If findings warrant, the enterprise then spends only a moderate amount of further time and money in design—15—30 percent of the total project cost. In the Design phase, a small, prototype system is created to prove that the opportunity is real and justifies a larger investment.
The Build phase is where enterprises spend the most of the time and money—60–80 percent of the project total. Notice that the decision to move into the Build phase is made with the greatest amount of information (and the least risk). The nature of the business opportunity and the solution system that will exploit that opportunity are well established by that time.
From the perspective of the project leader (the system builder), Define-Design-Build provides a way to navigate through the complexity of creating a new computer system. The system builder is truly the person on the hot seat who needs to get things done. The CIO and the system builder use the Define-Design-Build process in combination with the strategic system design guidelines and the tactical principles for running projects to structure the work sequence. The process lets them set reasonable time limits within which to investigate situations and make decisions in the Define and Design phases.
After making decisions about system design and budget, this same framework provides a set of tactics for the system builder and the team leaders to employ during the Build phase. Core techniques employed in the Build phase give structure to the work and enable the system builder to effectively focus and lead the effort.
From the perspective of the people on the project team Define-Design-Build is a clearly defined and manageable repertoire of techniques for completing new projects. People who participate in each of the three project phases know which of the core techniques they are expected to use as the project moves toward completion. They can focus on mastering these techniques. The CIO should emphasize that IT staff members work together on tasks in small groups so that the learning and use of techniques among team members is more effective than if they worked alone.
Define-Design-Build is a three-step sequence that could also be described as "Move it! Move it! Move it!" In order to support an agile IT organization in a high-change world, systems must be built with a quick and iterative process. The project team must strictly adhere to the time boxes for each step in the development sequence.
Complexity is as much perception as it is reality, and a disciplined, fastpaced approach is the best way to handle complexity. When the CIO allows project teams too much time to contemplate the situations facing them, team members begin to perceive excessive amounts of complexity and sink into that dreaded state called "analysis paralysis".
Agility means learning to deal effectively with complexity. People learn to become agile when guided by a discipline for developing new systems in a fluid and coordinated manner. They learn by participating in project teams with people trained to use the Define-Design-Build process.
Define opportunities, design systems to exploit those opportunities, and quickly build those systems. As success with one opportunity opens up other opportunities, address each new opportunity using and refining the Define-Design-Build process. Your IT organization will build great credibility and momentum in this way.
The Define-Design-Build process depends heavily on the use of appropriate time boxes for getting things done in each of the three steps. Agile processes need to be quick. Regardless of the task at hand, an agile response must be a fast response. Time-boxing sets limits to the amount of time that can be spent on a task, and the job is shaped to fit within the constraints of that box.
Time-boxing helps keep a project moving along at a brisk pace. As the saying goes, "The job will expand to fill the time available." Therefore we respond to that tendency with time-boxed constraints on all development activities. Allocate only a certain amount of time and money to each of the three steps. People learn to manage the scope and pace of the work to meet their due dates and budgets. Set the scope and pace of work in each step of the project to conform to the time and budget constraints shown in Exhibit 3.7.
If a step in the sequence is not completed in a timely manner, the process and the project itself is in danger of breaking down. People must stay on track. These constraints provide the implicit guidance to keep project teams from wandering too far off course or getting in over their heads.
The activities in each of the three steps can be accomplished by using an appropriate combination of just a few of techniques. I call this small set the "core techniques" because they are the basic techniques that every systems developer should understand and be able to use. Regardless of the specific technology being used and regardless of the specific business process being addressed, these core techniques remain relevant and applicable. The set of six core techniques are:
Joint Applications Design—An inclusive process that combines ideas from both business and technical people to create new system designs.
Process Mapping—Exploring and mapping out business workflows.
Data Modeling—Defining the data used by business workflows.
System Prototyping—A way to model and validate both the user interface and the technical architecture of a system.
Object-Oriented Design & Programming—Designing and specifying the structure and working logic of software that will be created.
System Test & Roll Out—Testing, training, and implementation of new systems.
These techniques are well known in the IT profession so training and reference materials are widely available. People on project teams must be able to apply an appropriate combination of these techniques as needed within the time boxes defined for each step of the Define-Design-Build process. Combinations of the core techniques create the agile tactics needed to develop systems within the short time frames required to support organizations in high-change environments.
This section takes a look at the application of the six core techniques and how their use drives the Define-Design-Build process. Every CIO must be familiar with these techniques. Although CIOs do not perform the actual work of developing new systems, they must be conversant with the proper application of these core techniques to lead their organizations effectively.
Just as the game of basketball relies on use of techniques such as dribbling, passing, and shooting, the game of developing information systems depends on its own set of basic techniques. The CIO can objectively measure the skill levels of IT project teams by how capably team members apply these techniques. By skillfully applying these techniques in combinations most appropriate to different situations, an agile project team can always produce competent—and sometimes even brilliant—results. CIOs must see to it that their people are trained in these techniques and that every project team has people skilled in applying the right mix of these techniques to succeed with their project.
The joint application design or JAD technique enables a project leader to create an inclusive process that brings together the knowledge and insights of all the team members. The JAD techniques lay down a set of rules that govern how the team leader leads, how team members interact, and how the team approaches problems. These rules stimulate the creative problemsolving abilities of the team and allow the team to generate a stream of ideas that then become the raw material from which the system design emerges.
JAD is a direct response to the overwhelming complexity of the design tasks that we face in business today. People individually analyzing parts of a problem either alone or in isolated groups cannot develop competent or adequate system designs on a consistent basis. However, using the JAD rules, project teams with the appropriate mix of business and technical people can come up with competent system designs every time. A basic set of JAD ground rules is shown in the following list:
Attendance of all team members is expected. If any team member cannot be at a JAD session, then reschedule the session.
Check your baggage at the door. Everyone has a stack of problems and personal issues. Leave them out of the JAD session.
Start and end sessions on time. Everyone is busy these days so treat the time spent in JAD sessions as valuable and respect people's schedules.
Every session must have an agenda. At the beginning of each session review and confirm the list of issues the group will address and the deliverables it will create.
Everyone is of equal rank while in the JAD session. Everyone on the team is equally important in what they have to contribute or else they would not have been asked to participate.
Team member comments will be kept confidential. In order to participate freely, people must know that statements they may make will not be repeated outside the session to people who could hurt or embarrass them.
Deal with issues, not personalities. We can discuss issues and evaluate solutions to them in a rational and creative way only if we ourselves are not personally being discussed or evaluated.
Everyone participates, no side conversations. It is through the combined insights and ideas of the whole group that good ideas emerge. Side conversations are distracting and disrespectful to the group.
Reach consensus or request "a decision from above". If the JAD team cannot come to an agreement on a particular issue, then it must outline several possible solutions and ask for a decision from the executive sponsor of the project.
Process mapping defines a set of steps for identifying the work processes that occur in an enterprise and the connections between these processes.[27] The team first identifies the highest-level processes and then the subprocesses within each high-level process. They define the data inputs required by each process and list the sources of the data. Their work also defines data outputs generated by each process and lists the destinations of the data outputs.
This technique uses diagrams to create a visual map of the tasks in any process and the data that flows between the tasks. This visual map creates a common reference framework for business and technical people to discuss issues and discover opportunities for process improvements. Process maps are far more effective than written documents because they use graphic means to communicate a lot of information quickly and accurately. Exhibit 3.8 shows an example of a process map diagram.
The data model defines the entities about which data needs to be collected. The entities are usually identified while using the process mapping technique. Entities such as customer, product, and invoice can be found in the data flows between different business processes. The data model then defines the properties or attributes that must be known about an entity. For example, the entity called "customer" has attributes such as customer number, name, address, and credit limit.
Data modeling also produces a visual diagram called an entity relationship diagram or ERD. Like the process flow diagrams produced by the process mapping technique, the ERDs provide another visual method for communicating a lot of information to the business and technical members of a project team. Everyone on a team can spot-check the entities on the diagram with which they are most familiar to ensure accuracy. Exhibit 3.9 shows an example of an entity relationship diagram.
There are two kinds of system prototyping. The first kind of system prototype is a system's user interface model. By looking at the process mapping diagrams the project team decides which tasks will be fully automated, which ones will be a mix of human activity supported by a computer, and which ones will be completely done by humans. By looking at the data model they can see what data will be handled by each task.
The prototype of the user interface builds upon this knowledge to create the layout and sequence of computer screens to support the tasks where humans and computers interact. The user interface prototype also illustrates how the users of the system can navigate between screens, and it shows the layout of any printed output generated by the system.
The development team designs this kind of prototype by using an interactive slide show displayed on a computer screen that allows the system user to move from one screen to another via keyboard, mouse, or other commands. It shows the business people what they will get when the new system is built. The interface prototype is something tangible and participative that people can work with, respond to, and make suggestions for improvement.
The second kind of system prototype is a technical architecture prototype composed of the hardware and software components that have been selected to build the system. This prototype demonstrates how well the system components will work together. The selected software is installed on the selected hardware. Links are then established between the different software components. The team passes data back and forth under different conditions to measure the hardware and software components' ability to work together and handle the expected number of users and volumes of data.
The architectural prototype shows the technical people what issues they will face when they build the system. It allows people to verify that the technology they have proposed to use in building the system will work as advertised and meet the performance demands of the new system. Exhibit 3.10 illustrates the idea of the two types of system prototypes—the technical architecture and the user interface.
Object-oriented design (OOD) and object-oriented programming (OOP) are the latest incarnation of a set of techniques that have been evolving for the past 30 years in the systems building profession. The purpose of these techniques is to enable the design and programming of stable, reusable software that is easy to debug and easy to modify.
The object-oriented techniques are analogous to the engineering techniques an electrical engineer uses when designing a piece of equipment such as a cellular phone. The cell phone is specified as a collection of component parts. Many of these parts are integrated circuit chips (IC chips) plugged into a motherboard. Each IC chip is defined by the inputs it accepts, the operations it performs, and the output it creates.
Software objects are the equivalent of the IC chip in this example. A system is composed of interacting software objects just as a cell phone is composed of interacting IC chips. The popular concepts of Web services and services oriented architecture (SOA) are based on the use of object-oriented programming. Web services are composed of programs (objects) from existing systems that communicate with each other by sending inputs and receiving outputs over the Internet using agreed-upon XML formats.
Once the object-oriented design has been completed, the programming is a relatively straightforward process of writing code to meet the design specifications for each object. All the hard decisions about how the objects operate and interact to drive the system are made in the objectoriented design. The choice of the programming language influences the design of the objects to some extent, but the object design is largely language independent.
The system builder can manage the programming effort very effectively by simply tracking the programming progress object by object. Generally, objects can be programmed in one to three days. They can be programmed in any order and could all be done in parallel if there are enough programmers available. In this way, new programmers can be added to speed up the programming process without causing confusion and loss of project control. Exhibit 3.11 illustrates a sample object model diagram.
Project teams use this collection of techniques to test the system in a thorough and orderly manner to find and fix the bugs and then to roll the system into production. System test and roll out techniques allow people on the project teams to first test each object individually, then to test the groups of objects used in each system function, and finally to test the entire system.
The programmers who program each object first perform unit testing on the object. When an object passes the unit test, it is checked into a system test environment. People familiar with the specific operations that the system is designed to perform create test scripts and use these test scripts to put different parts of the system through its paces. They write test scripts that exercise the different features of the system in a wide range of usage scenarios. The entire system is assembled and tested as more and more parts of the system come together in the test environment.
Once the system has passed through the test environment with all the bugs fixed, the team follows a regular sequence in rolling out the system. The first step uses a beta test or pilot group of people who begin using the system for their normal jobs. The pilot group participants define a range of system modifications that fine-tune the operation of the system and improve the ease with which it can be used.
Finally, the system rolls into production. Appropriate training always anticipates and supports the roll into production so that people who depend on the system are not left to cope with the change entirely on their own. The system testing sequence is illustrated in Exhibit 3.12
Now let's explore the details of how project teams combine and use these six core techniques in each step of the Define-Design-Build process. By combining selected core techniques they create useful tactics to get work done and achieve the development plan objectives.
It is amazing how often the Define phase is overlooked or badly performed in the rush to get a project started. Yet this phase forever after either guides or confuses the project team. When performed well, it provides clarity and greatly increases the chances of project success. When performed badly, confusion reigns, and the project has very little chance of success.
The purpose of the activities in the Define phase is to align the system development project with the business strategy. In this phase, the business executive who sponsors the system development project clearly spells out the goal or mission of the project by working with the CIO and the system builder to identify the performance criteria that the system must meet.
The project goal should not be a technical goal. It should be a business goal—something that provides a significant business benefit or a set of benefits. It should be stated in a format that identifies an action to be taken and states the expected benefit from that action. Some examples are:
Strengthen and grow the national accounts program by acquiring customers in vertical market segments A, B, and C.
Reduce the complexity of the steps involved in the warehouse receiving process to make product available for sale immediately after delivery.
The goal answers the question, "Why should we do this project?" It is a qualitative as opposed to a quantitative statement. Everyone affected by a project quickly understands a well-written goal statement. A goal statement should not be longer than a sentence or two. Do not confuse a project goal with a vision statement. A vision statement is a much broader statement about the organization's purpose and aspirations. A goal is one of the things an organization must accomplish in order to bring its vision to life.
Once a project goal has been defined, the next step is to create a strategy to accomplish it. By definition, the strategy uses the means or capabilities available to the business to achieve certain objectives—in this case, the project goal. Businesses often implement strategies by building systems to obtain the new abilities they need. The sponsoring executive works with the CIO and the project's system builder to define the strategy and the high-level or conceptual system design.
To define a project strategy, begin by listing a set of desired performance criteria that the system should meet in order to accomplish its goal. Chapter 1 discussed how Robert Kaplan and David Norton in their famous 1992 Harvard Business Review article, "The Balanced Scorecard— Measures That Drive Performance" defined four perspectives that create a comprehensive view of an organization's performance (more on this for the IT organization in Chapter 5). It's helpful to describe the system's desired performance criteria from these four perspectives as well:
Financial Perspective—What financial measures should the system achieve?
Customer Perspective—What do external and internal customers want from the system?
Business Perspective—What business processes must the enterprise excel at to accomplish the goal?
Learning Perspective—How do people continue to learn and continuously improve their ability to accomplish the goal?
Brainstorm a list of performance criteria for each perspective. Then review the lists and select three to six of the most important performance criteria. These are now the measures of success for the project. A successful project builds a system that meets all these criteria.
Next, strive to achieve these criteria in dramatically new ways by asking the question, "What seems impossible now, but if we could make it possible, would dramatically change the way we do business?" Look for ways to use systems that change the business landscape to give your organization a significant competitive advantage by doing something new and different.
The conceptual system design literally embodies the strategy the CIO uses to create the system. Whenever possible, good conceptual designs build on systems and procedures already in place. The conceptual design is the highlevel outline of a system.
Referring to the seven strategic guidelines for designing systems in Chapter 1 pg. 11, generate several different conceptual designs for systems that meet your specified performance criteria. Express the design as a workflow diagram or a process model.
Further define the high-level activities in the workflow by specifying the data that goes into and out of each activity. For each activity, estimate the volume and frequency of the data flows and the source and destination of each data flow. In addition, define the types of people (if any) who will perform the work for each activity. How many people are needed? What are the skill levels of the different types of people? Exhibit 3.13 shows how the system process flows for a proposed e-business system.
Next, decide which activities will be automated, manual, and part automated and part manual. As a rule, people like systems that automate the rote, repetitive tasks and empower them to do problem-solving and decision-making tasks more effectively. People are the spark that animates the system, and technology's role is to support that spark.
Evaluate the computer systems infrastructure that already exists in the organization. Look for ways to build on existing systems that work well enough. The most cost-effective new systems are those that adapt existing systems and deliver valuable new capabilities to an organization quickly and with a minimum of expense.
To get started, select the simplest combinations of technology and business processes that meet your specified performance criteria. Balance the need for simplicity with the need to increase the capacity of the system to handle greater volumes of data and the ability to add new functionality as the business grows. Refine and improve the system as you get feedback and ideas from others.
Conceptual system designs should respect all of the seven strategic guidelines discussed in Chapter 1. Under some circumstances there may be reasons to violate one or maybe two of these guidelines. The only guideline that can never be violated is the first one—closely align systems development projects with business goals.
If the system devised to accomplish the business goal violates one or two of the guidelines, the executive sponsor and the CIO both must acknowledge these violations and provide justification. A system design that violates only one guideline is acceptable. If it ignores two guidelines, there must be very good reasons for doing so. If it ignores more than two guidelines, the conceptual design is fatally flawed and should be reworked.
When looking at the new workflows and the information system designed to support those workflows, the system resolves into a set of high-level components. Each component should be devoted to the performance of a closely related set of tasks, such as storing and retrieving data, helping customers find a product, placing an order, or shipping products to customers.
The building of these high-level components becomes the set of necessary and sufficient objectives to create the system you have designed. Projects generally use between three and nine high-level components or objectives, and all other components resolve into sub-components of these high-level components. Strive for no more than three to nine high-level components because most people cannot quickly comprehend or easily remember more than seven (plus or minus two) things at a time. Clarity of system definition and the related objectives is critical to the success of the project.
If the Define phase produces a system definition (the conceptual system design) so complex that only a genius can understand it, then it is useless. Project team members will not be able to use it effectively to guide their work in the next two phases. Without a clear system definition, people on the project team will have different interpretations about what the project is meant to accomplish. People working on different objectives will find it increasingly difficult to coordinate their actions, and the level of tension and argument will rise as the project continues.
The objectives selected should each be achievable in nine months or less. Each objective should provide value in its own right. An objective should not be just an intermediate step that depends on the completion of a subsequent step to be of value. Select objectives that can be achieved quickly because they begin providing value and repaying the cost of the project before it is even finished. Once achieved, an objective becomes a base from which other objectives can be achieved.
Avoid defining objectives that lock the project into a rigid sequence of development activities. The real world rarely goes according to plan, so an agile plan must be flexible in order to adapt as reality unfolds. Begin work on a handful of objectives at the same time (work on objectives in parallel). Structure the tasks needed to achieve one objective to be independent of the tasks needed to achieve other objectives. This provides maximum flexibility because delays in achieving one objective will not affect the completion of other parallel objectives. This way the system builder can shift resources from one objective to another as needed, and the project continues to move forward.
The system conceptual design shown in Exhibit 3.14 has four high-level components numbered on the diagram. Each of these components provides value in its own right, and work on each component can proceed independently of the others. These four components become the four objectives for the system development project to create the system shown in this conceptual design.
Once the set of project objectives have been defined, a high-level project plan can be created. Create a section of the overall plan for each objective. In the section of the plan devoted to each objective, list the major tasks necessary to achieve that objective. There will be tasks related to designing and building the deliverables necessary for each objective. Show the dependencies between the tasks and between the objectives. The plan now reflects the strategy being used for building the systems needed to accomplish the business goal. The plan also defines the time boxes for the Design and Build phases of the project.
Estimate the total project budget by calculating the time and cost needed to achieve each project objective. Each task that is part of the plan for an objective will require some number of people with appropriate skill sets for some period of time. Each task will also require certain technology and perhaps other expenses, such as travel, hotel rooms, and meals. Create a spreadsheet to show the project cost by task for each objective.
After estimating your costs, do a cost-benefit analysis. If it is hard to quantify the different kinds of benefits provided by the system, take this as a warning that the goal of the system has not been well defined or is not very valuable. If the costs of the system outweigh the benefits, find a cheaper and simpler way to accomplish the goal. Avoid the use of expensive technology with more features than are really necessary to get the job done. Exhibit 3.15 shows a summary overview of the work in the Define phase.
The agile CIO consistently requires five specific outputs from the Define phase work before moving forward to the Design phase:
A clear statement of the business goal to be accomplished.
The performance criteria required from the system. These criteria usually fall into four measurement perspectives: (1) financial results; (2) customer expectations; (3) critical business operations; and (4) learning and continuous improvement. These identify and communicate the conditions of success that the system must meet.
A conceptual design for a system to accomplish the business goal and meet the performance criteria. The system design is composed of people, process, and technology. The conceptual design is the embodiment of the strategy being used to attain the goal.
A definition of the project objectives that are needed (necessary and sufficient) to build the system. Objectives are those items that must be built to create the system outlined in the conceptual design.
A cost-benefit analysis verifying that the project is worth doing. The senior business executive responsible for accomplishing the business goal that the system will address must confirm that this analysis is valid.
The purpose of the Design phase is to flesh out the conceptual design and create the detailed technical system specifications. The phase begins with the system builder reviewing the project goal, the conceptual system design, and the project objectives with the project work group. The work group is composed of business and technical people who have the necessary mix of business and technical skills and experience needed to do the detailed system design.
It is important for people to understand senior management's intentions and the project's goal. Specific issues relating to the project objectives and budget can be investigated during this phase. If necessary, some adjustments can be made to the project objectives in light of the findings that come out of this phase. Work in the Design phase falls into three activities:
Create detailed process model diagrams for the new system.
Define the logical data model.
Build and test the system prototype, that is, the user interface and the technical architecture.
Divide the total time allotted to the Design phase among these three activities. Allocate the necessary time to competently complete each activity but avoid the temptation to spend extra time excessively analyzing and checking and re-checking the results that come out of each activity.
It is important to keep the people involved in these three activities working together. System process models, system data models, and system prototypes are just different aspects of the same system. The designs for these three activities must be created in concert or they will not function properly when assembled. The three design teams must work simultaneously.
Use the joint application design (JAD) technique to integrate the work of people who focus on the three different activities. As the process team defines the details of the business process flow, the data modelers can record the data needed by the process. As the process requirements and the data volumes become clear, the technical architecture can be defined and tested to validate how well it supports the process and the data. As the process flow, the data model, and the technical architecture are defined, the prototype team can design the user interface needed to fit the process flow and handle the related data.
Business and technical people commonly experience a communications gap. The CIO is ultimately responsible for assigning a qualified and competent system builder to lead each development project. The system builder is responsible for creating an inclusive design process that involves both kinds of people and bridges the gap between them. Both business and technical people commonly rush to conclusions about how a process should work or what kind of technology should be used. The system builder must be a person who is able to tolerate ambiguity and set an example by reserving judgment and taking the time allocated to explore and select the best of the different design options. When this happens the creative power of the people on the project begins to open up.
The system builder pushes the project teams to keep looking for the simple underlying patterns that define an effective business process. The system builder leads the search for elegantly simple ways to support the process with technology. Remember, more complex system designs are harder to build and less likely to succeed.
Spend the first part of the Design phase in JAD sessions where business and technical people explore different process designs. People from both disciplines should "think outside of the box" and generate as many ideas as possible. The team then selects the most useful ideas and fits them together into a coherent, detailed map of how work will be organized and flow through the business process.
After sketching out the process workflows, the JAD sessions focus on how technology will be used to support this process. The design team starts by defining how people in the process will interact with the technology supporting the process. Often, designing this user interface takes the form of creating a sequence of screens like a storyboard that illustrates what people will use in their jobs as they perform their work.
When designing the user interface, look for ways to automate the rote and repetitive work. People don't like to do this kind of work—it is usually boring and computers do these kinds of tasks very well. Look for ways to empower the problem-solving and decision-making tasks. Design systems that give people a rewarding work experience.
If the JAD team decides to use a packaged software application, that package should be brought in and installed in a test environment. Script out realistic usage scenarios and load the databases used by the package with a sampling of real data. People, who will both use and support the package, need to evaluate it by working through the usage scenarios.
The technical people responsible for building the system should sit in on the JAD sessions. As the design unfolds, they should be selecting technology—hardware, operating systems, databases, and other software that will effectively support the system being designed. They should participate and listen to what the business people need for doing their jobs. They should not, however, slow down or confuse the design process with excessively technical questions or long dissertations about hardware and software.
During the Design phase it may become clear that a given performance criterion cannot be met. It may become clear that the initial conceptual design from the Define phase is not quite right and must be modified. Accordingly, certain project objectives might require redefinition. The project goal must remain unchanged but the specific objectives needed to accomplish the goal can be changed as needed. The system builder is the liaison between senior management and the project work group at every step in this redefinition process.
As the detailed design specifications emerge near the end of the Design phase, everyone involved should have a clear idea of their work and the time they need to accomplish it in the subsequent Build phase. The system builder assists each team to figure out how they will do their work and how long it will take, challenging them to set ambitious but achievable time frames.
Encourage teams to break their work into discreet tasks that take one week or less because the week is the standard unit of time in business.
Teams must strive to accomplish something of measurable value each week to maintain their momentum. A project plan that clearly lays out performance expectations for every person every week is a valuable tool for coordinating and monitoring the work of building the system. A plan at this level of detail is also the best way to arrive at an accurate and realistic project budget for the Build phase.
As the project teams each create their specific task plans to achieve the objectives assigned to them, the system builder combines these plans into the overall project plan. In a process somewhat analogous to the manner in which a general plans a campaign, the system builder plans the sequence of activities that will lead to the successful building of the system specified in the Design phase.
Divide or segment the overall project plan by objective. Devote a section of the plan to each objective. The system builder determines the best sequence for achieving the project objectives and arranges the project plan to reflect this sequence. Then the task plans created by the project teams assigned to each objective are inserted into the sections of the project plan devoted to their objective.
Look for opportunities to run activities in parallel. Flexible, agile projects accomplish more work this way. When projects run activities sequentially, a delay in one activity causes a ripple effect that delays all the other activities queued up behind it. When activities are run in parallel, a delay in one does not delay the others.
In well-designed project plans, deliverables from activities running in parallel come together at the end and combine to achieve the objective. Running activities in parallel allows project teams the opportunity to finish one activity and then shift resources over to help out other teams that experience delays. Delays are inevitable on any project. Any plan that fails to account for delays and provide team members the flexibility to effectively respond to them is a plan whose timetable and budget will quickly be thrown into disarray.
If doubts arise about the viability of the project or if the revised budget has grown too large, reduce the scope of the project or cancel it altogether. At this point only 20 to 40 percent of the total project cost will have been incurred. The business has yet to commit the major effort on the project. Pay special attention to projects with viability or budget issues whenever they occur.
It is all too common for organizations to run the Design phase as a poorly done research project. Teams spend a great deal of time in detailed analysis of what already exists but produce only sketchy designs for the specifics of the new system. Debates break out on many aspects of the design of the new system, but no one can agree on clear answers and critical decisions are not made or are pushed into the Build phase.
Use the Design phase as an opportunity to reduce the risk on a project before committing large amounts of time and money. The more detailed the design specifications, the better the chances for building the system on time and on budget. The broader the understanding of and support for the system among both the business and the technical people, the greater the likelihood that the system will be used effectively and produce the desired business results. Exhibit 3.16 illustrates the activities in the Design phase.
The agile CIO expects four detailed deliverables from Design phase work before approving a project for the Build phase:
A detailed design and map of the new business process flows supported by the system. Make sure there is agreement among the people who have to work with the system that it will meet the performance criteria expected of it. The specifications for the business process are created using the process mapping technique and captured in documents such as process flow diagrams and process logic descriptions for each step in the process.
A system data model that accommodates the data identified by the process map. The data model should be created using an entity relationship diagram (ERD) that other people on the project can understand. The model should also record the volume of data that will be handled and the frequency with which different types of data will be accessed.
A system prototype that specifies both the technical architecture and the user interface. There should be a development environment in operation where all the components of the technical architecture are installed and working together. This technical architecture must be capable of handling the anticipated data volumes and user demands. Define the user interface needed to support the process logic in the relevant steps of the process flow. There must be a complete set of screen layouts, report formats, and specifications for all aspects of the user interface.
A detailed project plan and budget that accurately reflects the time, cost, and resources needed to build the system. No plan can predict the future or anticipate all obstacles, and no budget can accurately estimate every cost. However, plans and budgets built up from the detail task level and structured to provide as much flexibility as possible are essential to guiding the project to a successful conclusion.
The project effort really ramps up in the Build phase. The full complement of people is brought on to fill out the project teams. Consequently, the weekly cost or "burn rate" on the project rises significantly in the Build phase. Unlike the previous two phases, the cost of false starts and wrong turns now adds up very quickly.
This is where your system builder vigorously exercises project leadership skills. Activity must be tightly focused on the completion of those defined tasks necessary to achieve the project objectives. In this phase, good design and planning pay off handsomely.
The initial work in this phase creates the system object model from the combination of specifications from the data model and the system prototype. This activity is often started in the Design phase as part of the detail design and budgeting process. By completing the work at the appropriate level of detail, the project teams produce very exact blueprints of what they will build. This strengthens the teams' understanding of and confidence in their ability to complete the work according to plan.
System blueprints take the form of the screen layouts, database design, system object model, and detailed technical architecture diagrams. These documents guide and structure the work that creates the actual system. The system builder and the team leaders track their progress every week using these documents to discuss relevant details.
Teams create and test system database and software in the system development environment. The development environment created in the Design phase supports the prototyping of the technical architecture and the user interface with the actual hardware, operating systems, and database packages used to build the system. Pre-programmed application software packages used for parts or all of the system also are installed and tested in the development environment.
Once programming begins, record progress at the object level using the object chart as the reporting tool. Circle an object as work begins. Everyone can see how long the work should take. Color in objects when work has been completed. People can see software development progress at a glance by looking at the object model. When problems develop the system builder and team leaders can use the object model to quickly see what issues affect each object. They can then focus on specific solutions for welldefined problems.
If software development projects are not tracked at this level of detail, people resort to the infamous "percentage complete" method. Under this method, large multi-week tasks quickly become "70 percent complete" (whatever that means). Then the last 30 percent takes four times as long to finish as the first 70 percent, and nobody can figure out why.
The system builder effectively coordinates and focuses activities on a fastpaced project through the project office. The CIO uses the project office to accurately manage a portfolio of IT development projects. The project office employs a skilled staff dedicated solely toworking with the system builder and the team leaders to update the project plan and budget as work progresses.
The system builder is analogous to the general manager of a business unit, and the project office is like the accounting department. The general manager does not have time to keep the business unit's books nor is that the general manager's job. But if no one keeps the books, the general manager loses touch with where the business really stands and this inevitably leads to bad decisions.
There is a pervasive tendency for people to hide bad news such as delays and cost overruns. Trouble results unless leadership takes active steps to counter this tendency. People should not be penalized for reporting bad news. On the contrary, leaders who give their people permission and encouragement to report delays and potential cost overruns as soon as they perceive them improve the entire project's chances of success because problems are seen earlier and everyone has more time to react.
Early reporting gives everyone more time to respond and respond effectively. The project office staff exists to help people keep track of actual project progress and make good decisions with the information the project office provides. Indeed, one of the best ways to get into trouble is to hide bad news because when the truth finally does come out, then there is usually very little (if any) time to respond effectively to the situation.
As major system components or subsystems are delivered, they are beta tested with a pilot group of business people who were involved with the Design phase of the project. In this way they already understand and accept the need for and benefits of the new system and that makes them effective beta test personnel.
Expect to make adjustments to the system architecture and to the user interface during the beta test. People who operate the system architecture will need to tweak different operating parameters to get the best response time and stability from the system. People who designed the user interface will need to sit down with the beta test group of business users and listen to their ideas for improvements to certain screens.
Business people in the pilot group smooth off the rough edges as they test the system and make suggestions for adjustments. In this process, advocates for the system emerge from among the beta test group. They will feel a personal connection to the success of the system because the system takes on a look and feel influenced by their suggestions. These people sell the benefits of the system to the rest of the enterprise and often become the ones to train their co-workers in using the new system. Exhibit 3.17 shows the operation of the Build phase.
The CIO relies on a mixture of information from the updated project plans, budgets, personal visits, and investigations into projects that attract attention. Effective CIOs cannot spend undue time in their office reading e-mails and writing reports. Effective CIOs hold regular meetings with all their system builders to review progress on projects, and as problems arise, the CIO continuously assesses when to get personally involved and when to delegate to others.
Inevitably, obstacles arise and delays happen. The agile CIO demands flexibility in the project plans and uses people skilled in the core techniques. System designs that use simple combinations of technology and business process to achieve multiple objectives are more likely to be built on time and on budget. With system designs like this, CIOs can quickly shift resources from one project to another because the same skill sets and technologies are being used. In this way, the agile CIO retains options to deal with the obstacles and delays that occur.
Agile CIOs expect three critical deliverables from the Build phase work:
A working system that matches the design specifications and meets the performance criteria. Schedule the building of the system so that the process delivers something of value to the business every 30–90 days. This means that certain pieces of the system must be finished and put into use before the entire system is completed.
A complete and updated set of technical design documents. The design documentation is analogous to the wiring diagrams and structural plans of a building. This documentation enables the IT organization to build enhancements and make repairs to the system in the future. The documentation should include at least the object model, the data model, an organized library of program source code, and diagrams and descriptions of the overall process flow of the system.
A complete set of user and operating instructions. The people who operate and maintain a system are different from the people who build systems. The people who operate a system need to know how to bring the system up, bring it down, and carry out performance tuning, troubleshooting, and operating maintenance. Assign the people responsible for operating a new system to work with the development team during system rollout to define the needed operating and maintenance documentation.
Four real projects from my own experience seem like the best way to examine what works and what doesn't when it comes to developing new systems using the principles discussed in this chapter. All were prominent, multimillion-dollar system development projects. I was the overall project leader or system builder on three of them. On the fourth I was one of four team leaders—there was no system builder. These four projects span the years from the early 1990s to the early 2000s; two were major successes, one was an utter failure, and one, though not a complete failure, was not a complete success either.
These projects used a range of technologies—IBM mainframes with COBOL and DB2, Sun servers running Java and Sybase, and Windows servers with SQL Server databases accessed through Windows PCs and Web-based thin clients. Although the technology and the business goals were different for each of these projects, I began to see consistent reasons for project successes and failures. A timeline analysis of these four projects demonstrates the importance of the agile principles discussed in this chapter. These timelines illustrate practical lessons I learned the hard way.
I learned that the seven strategic system design guidelines and the six principles for running projects really work and that there are consequences when they are ignored. I also saw that the core techniques (the skills of the game) were applicable each time regardless of the technology being used. These guidelines, principles, and core techniques represent a body of knowledge that must be understood and applied to successfully create a new system.
Finally, I saw that there is a basic, underlying sequence to the process of building computer systems. That sequence is Define-Design-Build. Depending on the system development methodology or the consulting firm facilitating development of a new system, there could officially be a much more complicated process in place but that added complexity leads to trouble. Simplicity and clarity are the keys to success in multidisciplinary projects prone to different interpretations by both business and technical participants.
Define-Design-Build remedies the tendency to make projects more complex. In a more complicated development process the Define phase might be divided into two or more steps with important sounding names such as "Preliminary Needs Analysis" or "System Concept Justification". The Design phase may also be fractured into three or four steps with more fancy titles and the Build phase can be broken into a further number of steps.
This added complexity neither increases people's chances of success nor changes the basic sequence of events that have to occur. First, one must still define what is to be done. Next, one must design how it will be done. And lastly, one must build it.
The following charts in Exhibits 3.18 through 3.21 are maps of the four projects. They show how each project unfolded over time. Study the sequence of activities and read the notes that explain these activities for an overall appreciation of each project. Underneath every chart is a brief description of what happened. Look for the ways that successful projects consistently applied the principles I present in this chapter, and try to pinpoint where the failed and partially successful projects lost focus.
What can be learned here? To begin with, every project needs a qualified, full-time project leader or system builder who has full responsibility and day-to-day authority for running the entire project. Working with the senior businessperson sponsoring the project, the system builder identifies a specific business opportunity and defines the system performance criteria needed to exploit that opportunity.
Projects should focus on developing new system capabilities not already available in existing systems. For the best results, combine new technology with existing systems to create new systems. Avoid re-creating functions that already exist in older systems that work well enough. You run up too many costs and deliver too little value when you rip out existing systems and replace them with new technology that does essentially the same things.
By building upon existing systems, a much simpler set of new technology can often be used. PC workstations can be used to run terminal emulation software, giving people access to existing mainframe systems. New applications can be Web- or server-based. The whole mix of new and old applications can be integrated under a single graphical user interface by giving each application an icon that users click on to switch from one application to another.
Employ the time boxes suggested in the Define-Design-Build process and move the project along at a fast clip. It is very important to set and maintain a brisk pace on a project to prevent it from degenerating into a sluggish and indecisive voyage to nowhere. Use the overall time boxes for each phase and then subdivide these boxes into smaller boxes for each of the major activities defined in a phase. Further subdivide those activity time boxes into task-level time boxes. The trick is to define time boxes that are both aggressive and realistic.
Both of the projects that succeeded shared a very effective approach. Simply stated, this approach first focuses the development effort to create a breakthrough deliverable—a deliverable that proves the system and wins over lots of supporters. After achieving the breakthrough deliverable, make every effort to exploit it quickly by developing more system enhancements and new subsystems to address further opportunities opened up by the breakthrough.
[24] Robert Coram, Boyd, The Fighter Pilot Who Changed the Art of War, (New York: Little, Brown and Company, 2002).
[25] Material on the Boyd Cycle or OODA Loop can be found on the Internet and in several books. Two authoritative Web sites are www.belisarius.com and www.d-n-i.net. Robert Coram's book referenced above is also a good source. Another insightful book written by one of Boyd's associates is: Chet Richards, Certain to Win, (Philadelphia: Xlibris Corporation, 2004).
[26] George Eckes, Six Sigma for Everyone, (New York: John Wiley & Sons, 2003) 29.
[27] A classic book on the technique of process mapping is written by Tom DeMarco, Structured Analysis and System Specification, (Englewood Cliffs, NJ: Yourdon Press/ P T R Prentice Hall, 1979).