10

MANAGING IT PROJECTS

The Rural Payments Agency (RPA), an agency responsible for administering agricultural subsidies to U.K. farmers, blamed poor planning and lack of testing of their IT system for delays in paying out £1.5bn of EU subsidies. The UK government developed a complex system for administering the Single Payment Scheme, which maps farmers' land to a database. By the end of 2006, only 15% of the subsidies had been paid to farmers and, as a result a large number of farmers faced bankruptcy after not receiving due subsidies. Problems still plagued the system in early 2012 when the RPA CEO stated that the agency had deep-rooted problems that won't be corrected until 2014. His litany of the problems included inaccurate data sources of past, present and future schemes claims, a lack of standard processes and controls, ageing systems, unsuitable technology, and an organizational structure and associated corporate services that do not offer a good fit with the RPA purpose. The CEO concluded: “Our systems and tools are insufficient to allow us to deliver the level of customer service we expect and, across the agency, we don't have the necessary the commitment to our customer development. That is a long list.”¹

An independent watchdog group investigated the situation and learned that the implementation of the system began before final specifications and regulations were agreed on by the European Commission. The RPA then had to make many substantial changes in the system after implementation. Further, the investigation found that testing did not take into account the real environment, leading to unanticipated work to populate the database with what has now been realized to be often inaccurate data. Four separate governmental reviews have all been deeply critical of the system and its implementers. The July 2010 report commented, “the review process was made unnecessarily difficult by the RPA leadership resisting its commencement.”²

Where was the project manager for the project? Despite receiving three “red” warnings from the Office of Government Commerce during reviews, the implementation continued. Time was not built into the schedule for testing the whole system as well as the individual components. The components were not compatible with the business processes they were supposed to support.³ The system itself has cost £350m, which is considerably more than the original estimated cost of £75.5m. An additional £304m has been spent on staff costs to respond to the early payment fiascos. Further, £280m has been set aside to pay expected EU fines and £38m was lost in overpayments. Unfortunately, according to the June 2010 review of the system, it remains an expensive and inflexible resource.

This example highlights the possible financial and social consequences of a failed information systems (IS) project. Such failures occur at an astonishing rate. The Standish Group, a technology research firm, found that 67% of all software projects are challenged—that is, delivered late or over budget or simply fail to meet their performance criteria.⁴ Business projects increasingly rely on IS to attain their objectives, especially with the increased focus to do business on the Internet. Thus, managing a business project means managing, often to a large degree, an information systems project. To succeed, a general manager must be a project manager and must learn how to manage this type of risk.

In the current business environment, the quality that differentiates firms in the marketplace—and destines them for success or failure—is often the ability to adapt existing business processes and systems to innovative ideas faster than the competition. The process of continual adaptation to the changing marketplace drives the need for business change and thus for successful project management. Typical adaptation projects include the following elements:

• Rightsizing the organization
• Reengineering business processes
• Adopting more comprehensive, integrative processes
• Incorporating new information technologies

Projects are made up of a set of one-time activities that can transform the current situation into the desired new one. Firms seek to compete through new products and processes, but the work of initially building or radically changing them falls outside the scope of normal business operations. That is where projects come in. When work can only be accomplished through methods that fundamentally differ from those employed to run daily operations, the skilled project manager plays a crucial role.

Successful business strategy requires executive management to decide which objectives can be met through normal daily operations and which require specialized project management. Virtually all projects involve both information technology (IT) and information flow components Many projects involve the Internet, using Web applications in the systems design. Rapidly changing business situations make it difficult to keep the IT projects aligned with dynamic business strategy. Furthermore, the complexity of IT-intensive projects has increased over the years, magnifying the risk that the finished product or process will no longer satisfy the needs of the business originally targeted to benefit from the project in the first place. Thus, learning to manage projects successfully, especially the IT component of the projects, is a crucial competency for every manager. Executives acknowledge skilled IT project management as fundamental to business success.

This chapter provides an overview of what a project is and how to manage one. It begins with a general discussion of project management, and then continues with aspects of IT-intensive projects that make them uniquely challenging. It identifies the issues that shape the role of the general manager in such projects and help them to manage risk. Finally, it considers what it means to successfully complete IT projects.

WHAT DEFINES A PROJECT?

In varying degrees, organizations combine two types of work—projects and operations—to transform resources into profits. Both types are performed by people and require a flow of limited resources. Both are planned, executed, and controlled. The flight of an airplane from its point of departure to its destination is an operation that requires a pilot and crew, the use of an airplane, and fuel. The operation is repetitive: After the plane is refueled and maintained, it takes new passengers to another destination. The continuous operation the plane creates is a transportation service. However, developing the design for such a plane is a project that may require years of work by many people. When the design is completed, the work ends. Figure 10.1 compares characteristics of both project and operational work. The last two characteristics are distinctive and form the basis for the following formal definition:

All projects have stakeholders. Project stakeholders are the individuals and organizations that either involved in the project, or whose interests may be affected as a result of project.⁶ Project stakeholders include the project manager and project team. They also include the project sponsor who typically is a general manager who provides the resources for the project and who often expects to use the project deliverables. The customer is an important stakeholder group that shouldn't be forgotten. Customers are individuals or organizations who use the project product. Multiple layers of customers may be involved. For example, the customers for a new pharmaceutical product may include the doctors who prescribe it, the patients who take it; and the insurers who pay for it. Finally, employees in the organization undertaking the project are stakeholders with varying degrees of involvement. The relationships among the project stakeholders are displayed in Figure 10.2.

FIGURE 10.1 Characteristics of operational and project work.

FIGURE 10.2 Relationships among project stakeholders.

Source: Adapted from Project Management Institute, A Guide to the Project Management Body of Knowledge, 3rd ed., (Newton Square, PA: Project Management Institute, 2004), p. 25, Figure 2-5.

To organize the work facing a project team, the project manager may break a project into subprojects. He or she then organizes these subprojects around distinct activities, such as quality control testing. This organizing method allows the project manager to contract certain kinds of work externally to limit costs or other drains on crucial project resources. At the macro level, a general manager may choose to organize various projects as elements of a larger program, if doing so creates efficiencies. Such programs then provide a framework from which to manage competing resource requirements and shifting priorities among a set of projects.

WHAT IS PROJECT MANAGEMENT?

Project management is the “application of knowledge, skills, tools, and techniques to project activities in order to meet project requirements.”⁷ Project management always involves continual trade-offs, and it is the manager's job to manage them. Even the tragic sinking of the Titanic has been attributed, in part, to project trade-offs. The company that built the Titanic, Harland and Wolff of Belfast, Northern Ireland, had difficulty finding the millions of rivets it needed for the three ships it was building at the same time. Under time and cost pressures to build these ships, the company managers decided to sacrifice quality by purchasing low-grade rivets that were used on some parts of the Titanic. When making the trade-offs, it was unlikely that the company's management knew that they were purchasing something so substandard that their ship would sink if it hit an iceberg. Nonetheless, the trade-off proved disastrous.⁸

Trade-offs can be subsumed in the project triangle (see Figure 10.3), which highlights the importance of balancing scope, time, and cost. Scope may be divided into product scope (the detailed description of the product's quality, features, and functions), and project scope (the work required to deliver a product or service with the intended product scope). Time refers to the time required to complete the project, whereas cost encompasses all the resources required to carry out the project. In the tragic case of the Titanic, the managers were willing to trade off quality for lower-cost rivets that allowed them to build all three ships (scope) in a more timely fashion (time). In contrast, a successful balance of scope, time, and cost yields a high-quality project—one in which the needs and expectations of the users are met.

FIGURE 10.3 Project triangle.

The tricky part of project management is successfully juggling these three elements while on a high wire, which amounts to shifting the triangle's base to keep it in balance. Changes in any one of the sides of the triangle affect one or both of the other sides. For example, if the project scope increases, more time and/or more resources (cost) are needed to do the additional work. This increase in scope after a project has begun is aptly called scope creep.

In most projects only two of these elements can be optimized, and the third must be adjusted to maintain balance. For example, a project with a fixed budget and fixed deadline may need to restrict scope. Likewise, a project that must be completed in a short period of time, with a large scope, may need flexibility in budget to obtain the resources necessary to meet the goal. It is important that the project stakeholders decide on the overriding “key success factor” (i.e., time, cost, or scope), though the project manager has the important responsibility of demonstrating to the stakeholders the impact on the project of selecting any of these. In the RPA case at the beginning of this chapter, scope was a key success factor that was managed inappropriately, ultimately resulting in a much longer time and much higher cost.

But the key success factor is only one metric to use when managing a project. Stakeholders are concerned about all facets of the project. Measuring and tracking progress is often done by tracking time (How are we doing compared to the schedule?), cost (How are we doing compared to the budget?), scope (Does the scope continue to be reasonable?), as well as resources (How much of our resources have we consumed so far?), quality (Is the quality of the output/deliverables at the level required for success?), and risks (How are we doing managing the risk associated with this project?).

A successful business project often begins with a well-written business case that spells out the components of the project. The business case clearly articulates the details of the project and argues for resources for the project, For example, UPS prioritizes projects on the strength of their business cases and financial metrics. They also make non-financial considerations such as weighing international projects more heavily to spur the company's growth.⁹ The components of a business case and the financial metrics are discussed in Chapter 7.

The process used to develop the business case sets the foundation for the project itself. Therefore detailed planning, along with contingency planning, is an important part of project management. It is often in the planning phase that implementation issues, areas of concern, and gaps are first identified. Further, a strong business plan gives all members of the project team a reference document to help guide decisions and activities.

Project management software is often used to manage projects and keep track of key metrics. Programs such as Microsoft Project, Intuit Quickbase, Basecamp, and many others keep track of team members, deliverables, schedules, budgets, priorities, tasks, and other resources. Many of these programs provide a dashboard of key metrics to help project managers quickly identify areas of concern or potentially critical issues that need attention.

PROJECT ELEMENTS

Project work requires in-depth situational analyses and the organization of complex activities into often coincident sequences of discrete tasks. The outcomes of each activity must be tested and integrated into the larger process to produce the desired result. The number of variables affecting the performance of such work is potentially enormous.

Four elements essential for any project include (1) project management, (2) a project team, (3) a project cycle plan, and (4) a common project vocabulary. Project management includes the project sponsor who initiates the project and a project manager who makes sure that the entire project is executed appropriately and coordinated properly. A good project manager defines the project scope realistically, and then manages the project so that it can be completed on time and within budget.

The project team has members who work together to ensure that all parts of the project come together correctly and efficiently. The plan represents the methodology and schedule to be used by the team to execute the project. Finally, a common project vocabulary allows all those involved with the project to understand the project and communicate effectively.

It is essential to understand the interrelationships among these elements and with the project itself. Both a commitment to working together as a team and a common project vocabulary must permeate the management of a project throughout its life. The project plan consists of the sequential steps of organizing and tracking the work of the team. Finally, the project manager ensures the completion of work by team members at each step of the project cycle plan and as situational elements evolve throughout the project cycle.

Project Management

Two key players in project management are the sponsor and the manager. The project sponsor liaises between the project team and the other stakeholders. The sponsor is the project champion and works with the project manager in providing the leadership to accomplish project objectives. Often the sponsor is a very senior level executive in the firm and is someone who has influence with the key stakeholders and C-level team. It is the project sponsor that provides the financial resources for the project.

The project manager is central to the project. The project manager role is not an easy one since it requires a range of management skills to make the project successful. The challenge facing a project manager is to learn and apply these skills properly in the situations that require them. The skills include (1) identifying requirements of the systems to be delivered, (2) providing organizational integration by defining the team's structure, (3) assigning team members to work on the project, (4) managing risks and leveraging opportunities, (5) measuring the project's status, outcomes and exception to provide project control, (6) making the project visible to general management and other stakeholders, (7) measuring project status against plan, often using project management software, (8) taking corrective action when necessary to get the project back on track, and (9) project leadership. The first three of these skills are formulative; they require considerable planning and designing ability. The remaining skills are all about taking action and reacting. When a project deviates from its desired path, corrective action is needed to get the project back on track.¹¹

FIGURE 10.4 Project leadership vs. project management (PM) process.

Project leadership guides the other eight skills. Lack of leadership can result in unmotivated or confused people doing the wrong things and ultimately derailing the project. Strong project leaders skillfully manage team composition, reward systems, and other techniques to focus, align, and motivate team members. Figure 10.4 reflects the inverse relationship between the magnitude of the project leader's role and the experience and commitment of the team. In organizations with strong processes for project management and professionals trained for this activity, the need for aggressive project leadership is reduced.

A number of factors influence project managers and, ultimately their team's performance. These include organizational culture and socioeconomic influences. Organizational culture influences the leadership style of the project manager and the communication between team members. For example, a culture that rewards individual achievement over team participation may hinder a project team. Members might hoard information instead of sharing it. A leader who sets a good example for the team and who encourages teamwork has the opportunity to eliminate these barriers. Socioeconomic influences on projects include government and industry standards, globalization, and cultural issues. Trends external to the organization, such as changes in industry standards and regulations, usually affect all projects in varying degrees. Globalization trends create the need for projects that span time zones, oceans, and national boundaries, adding to already complex conditions. Cultural influences, such as economic, ethical, and religious factors, affect the relationships between people and between organizations. The project manager watches for these influences and makes decisions to minimize any negative impacts.

Project Team

The project team consists of those people who work together to complete the project. Business teams often fail because members don't understand the nature of the work required to make their team effective. Teamwork begins by clearly defining the team's objectives and each member's role in achieving these objectives. Teams need to have norms about conduct, shared rewards, a shared understanding of roles, and team spirit. Project managers should leverage team member skills, knowledge, experiences, and capabilities when assigning the team members to complete specific activities on an as needed basis. In addition to their completing team activities, team members also represent their departments and transmit information about their department to other team members. Such information sharing constitutes the first step toward building consensus on critical project issues that affect the entire organization. Thus, effective project managers use teamwork both to organize and apply human resources, to motivate an acceptance of change, and to collect and share information throughout the organization.

Project Cycle Plan

The project cycle plan organizes discrete project activities and sequences them in steps along a timeline so that the project delivers according to the requirements of customers and stakeholders. It identifies critical beginning and end dates and breaks the work spanning these dates into phases. Using the plan, the time and resources needed to complete the work based on the project's scope are identified, and tasks are assigned to team members. The general manager tracks the phases to coordinate the eventual transition from project to operational status, a process that culminates on the “go live” date. The project manager uses the phases to control the progress of work. He or she may establish control gates at various points along the way to verify that project work to date has met key requirements regarding cost, quality, and features. If it has not met these requirements, he or she can make corrections to the project plan and adjust the cycle as necessary.

The project cycle plan can be developed using various approaches and software tools. The three most common approaches are the project evaluation and review technique (PERT), critical path method (CPM), and Gantt chart. PERT identifies the tasks within the project, orders the tasks in a time sequence, identifies their interdependencies, and estimates the time required to complete the task. Tasks that must be performed individually and that, together, account for the total elapsed time of the project are considered to be critical tasks. Non-critical tasks are those for which some slack time can be built into the schedules without affecting the duration of the entire project. A PERT chart is shown in Figure 10.5.

CPM is a project planning and scheduling tool that is similar to PERT. Unlike PERT, CPM incorporates a capability for identifying relationships between costs and the completion date of a project, as well as the amount and value of resources that must be applied in alternative situations. The two approaches differ in terms of time estimates. PERT builds on broad estimates about the time needed to complete project tasks. It calculates the optimistic, most probable, and pessimistic time estimates for each task. In contrast, CPM assumes that all time requirements for completion of individual tasks are relatively predictable. Because of these differences, CPM tends to be used on projects for which direct relationships can be established between time and resources (costs).

FIGURE 10.5 PERT chart.

Gantt charts are a commonly used visual tool for displaying time relationships of project tasks and for monitoring the progress toward project completion. Gantt charts list project tasks. For each task, a bar indicates the relative amount of time expected to complete the task. Milestones (i.e., due dates) are noted with diamonds. At the start of the project, Gantt charts are useful for planning purposes. As the project progresses, the chart is modified to reflect the extent to which each task is completed at the time the project is monitored. A Gantt chart is displayed in Figure 10.6.

Figure 10.7 compares both a generic project cycle plan and the Project Management Institute's project life cycle with one for a typical high-tech commercial business and with one for an investigative task force. Notice that although each of these life cycles has unique phases, all can loosely be described by three major periods (shown at the top of the diagram): requirements period, development period, and production/distribution period.

Projects are all about change. They bring new products, services, or systems into organizations or make them available for the organizations' customers. These project deliverables need to be integrated into the organization's (or their customers') operations. Not surprisingly, the three major periods in the project life cycle correspond to Lewin's classic change model: unfreezing, changing, and refreezing. (This model was introduced in Chapter 4.) First, according to Lewin, people need to be given a motivation for change in the unfreezing stage. People don't want to change unless they see some reason for doing so. This is what happens in the requirements definition period when it is determined what needs to be changed and why. The project sponsor is often a key mover in providing answers to these questions. Then in the changing stage, people in the organization are made aware of what the change is and they receive training about how to take advantage of the new service, project, or system. In the project life cycle it is not possible for people to fully understand the change until the service, product, or system is designed or built in the development phase and they are then trained to use it. Those on the project team can better understand what the project deliverable is and why it was designed the way it was. Finally, the refreezing stage occurs when the organization helps the employees integrate the change into their normal way of working. This occurs in the deployment/dissemination period.

Common Project Vocabulary

The typical project teams include a variety of members from different backgrounds and parts of the organization. Often the team is made up of consultants who are new to the organization, a growing number of technical specialists, and business members. Each area of expertise represented by team members uses a different technical vocabulary. When used together in the team context, these different vocabularies make it difficult to carry on conversations, meetings, and correspondence. For example, a market research analyst and software analyst may use words unique to their specialty or attach different meanings to the same words.

To avoid misunderstandings, project team members need to commit to a consistent meaning for terms used on their project. After agreeing on definitions and common meanings, the project team should record and explain the terms in its own common project vocabulary. The common project vocabulary includes many terms and meanings that are unfamiliar to the general manager and the team's other business members. To improve their communications with general managers, users, and other non-technical people, technical people should limit their use of acronyms and cryptic words and should strive to place only the most critical ones in the common project vocabulary. Good management of the common project vocabulary, along with the project management, project team, and project life cycle are all essential to project success.

FIGURE 10.6 Gantt chart.

FIGURE 10.7 Project cycle template.

Source: Adapted from K. Forsberg, H. Mooz, and H. Cotterman, Visualizing Project Management (Hoboken, NJ: John Wiley & Sons, 1996). Used with permission.

IT PROJECTS

IT projects are a specific type of business project. Much research has been done to observe, understand, and help managers increase chances of IT project success. One industry saying is that there is no such thing as an IT project; all projects are really business projects involving varying degrees of IT. Sometimes, managing the IT component of a project is referred to separately as an IT project, not only for simplicity, but also because the business world perceives that managing an IT project is somehow different from managing any other type of project. However, projects done by the IT department typically include an associated business case; and even though the project owner may be an IT person, mounting evidence indicates that IT projects are just business projects involving significant amounts of technology. The more complex the IT aspect of the project is, the higher is the risk of failure of the project.

IT projects are difficult to estimate, despite the increasing amount of attention given to mastering this task. Like the case of the RPA's Single Payment Scheme most software projects fail to meet their schedules and budgets. Managers attribute that failure to poor estimating techniques, poorly monitored progress protocols, and the idea that schedule slippage can be solved by simply adding additional people.¹² Not only does this assume that people and months are interchangeable, but also if the project is off schedule, it may be that the project was incorrectly designed in the first place, and putting additional people on the project just hastens the process to an inappropriate end.

Many projects are measured in terms of function points, or the functional requirements of the software product, which can be estimated earlier than total lines of code. Others are measured in “man-months,” the most common unit for discussing the size of a project. For example, a project that takes 100 man-months means that it will take one person 100 months to do the work, or 100 people can do it in a month.

A recent study found that managing projects using the man-months metric was linked to more underperforming projects than managing projects using any other metric of size (i.e., budget, duration, team size).¹³ Man-months may be a poor metric for project management because some projects cannot be sped up with additional people. An analogy is that of pregnancy. It takes one woman nine months to carry a baby, and putting nine people on the job for one month cannot speed up that process. Software systems often involve highly interactive, complex sets of tasks that rely on each other to make a completed system. Further, adding people means that more communication is needed to coordinate all the team members' activities. In sum, additional people can speed up the process in some cases, but most projects cannot be made more efficient simply by adding labor. Often, adding people to a late project only makes the project later.¹⁴

IT PROJECT DEVELOPMENT METHODOLOGIES AND APPROACHES

The choice of development methodologies and managerial influences also distinguish IT projects from other projects. The general manager needs to understand the issues specific to the IT aspects of projects to select the right management tools for the particular challenges presented in such projects. The systems development life cycle (SDLC) is a traditional tool for developing information systems, or for implementing software developed by an outsourcing provider or software developer. Many steps in the SDLC are used by other methodologies, although not to the extent found in the SDLC. For example most other methodologies, to some extent, try to determine user needs and test the new system, even though these other methodologies don't perform all of the other steps in the SDLC. Thus, this chapter provides greater detail on SDLC than on the other methodologies. The SDLC discussion is followed by a short description of two key iterative approaches—agile programming and prototyping.

Systems Development Life Cycle

Systems development is the set of activities used to create an IS. The SDLC typically refers to the process of designing and delivering the entire system. Although the system includes the hardware, software, networking, and data (as discussed in Chapter 6), the SDLC generally is used in one of two distinct ways. On the one hand, SDLC is the general project plan of all the activities that must take place for the entire system to be put into operation, including the analysis and feasibility study, the development or acquisition of components, the implementation activities, the maintenance activities, and the retirement activities. In the context of an information system, however, SDLC can refer to a highly structured, disciplined, and formal process for design and development of system software. In either view, the SDLC is grounded on the systems approach and allows the developer to focus on system goals and trade-offs.

SDLC refers to a process in which the phases of the project are well documented, milestones are clearly identified, and all individuals involved in the project fully understand what exactly the project consists of and when deliverables are to be made. This approach is much more structured than other development approaches, such as agile programming or prototyping. However, despite being a highly structured approach, no single well-accepted SDLC process exists.

For any specific organization, and for a specific project, the actual tasks under each phase may vary. In addition, the checkpoints, metrics, and documentation may vary somewhat. SDLC typically consists of seven phases (see Figure 10.8). Each phase is carefully planned and documented. The first phase, project initiation, is where it is first considered, scoped, and carefully planned. Approval is acquired before proceeding to the second phase, after it is determined that the project is technically, operationally, and financially feasible. The second phase is the requirements definition phase, where the problem is defined and needs and prerequisites are assessed and documented. Often the requirements are determined by studying the existing systems. Again, approval is obtained before proceeding. The third phase involves the functional design, at which point the specifications are discussed and documented. The system is designed in conceptual terms. Approval is obtained on the functional specifications before technical design is begun.

At phase four, functional specifications are translated into a technical design, and construction takes place. Here the system is actually built. If the system is acquired, it is at this point that it is customized as needed for the business environment. Following construction is the verification phase, where multiple levels of testing are performed to ensure system usability, security, and operability. The tests verify that the system meets the specifications for which it is designed.

After acceptance testing, project sign-off and approval signal that the system is acceptable to the users, and implementation, the sixth phase, begins. This phase is the “cutover” where the new system is put in operation and all links are established. Cutover may be performed in several ways: The old system may run alongside the new system (parallel conversion), the old system may stop running as soon as the new system is installed (direct cutover), or the new system may be installed in stages across locations, or in phases. The safest way to convert from an old system to a new system is parallel conversion because if the new system fails, users easily can revert to the old system. The riskiest approach is direct cutover because there is no backup system to turn to in the event of problems with the new system. Usually direct cutover is reserved from smaller, less-critical systems or for systems that were not previously available. Another instance when direct cutover was a good idea was Dagen H (Högertrafik day) on September 3, 1967, when Swedish drivers were to change from driving on the left-hand to the right-hand side of the road. On Dagen H, all vehicles on the road had to come to a complete stop at 04:50, then carefully change to the right-hand side of the road and stop again before being allowed to proceed at 05:00.¹⁵

Finally, the system enters the maintenance and review phase, where the system goes into operation and an evaluation is conducted to ensure it continues to meet the needs for which it was designed. The system development project is evaluated using postproject feedback (sometimes called post-implementation audit) from all involved in the project. Post-project feedback brings closure to the project by identifying what went right and what could be done better next time. Maintenance and enhancements are conducted on the system until it is decided that a new system should be developed and the SDLC begins anew. The maintenance and review phase is typically the longest phase of the life cycle.

FIGURE 10.8 Systems development life cycle (SDLC) phases.

Agile Development

Several problems arise with using traditional SDLC methodology for current IT projects. First, many systems projects fail to meet objectives, even with the structure of SDLC. The primary reason is often because the skills needed to estimate costs and schedules are difficult to obtain, and each project is often so unique that previous experience may not provide the skills needed for the current project. Second, even though objectives that were specified for the system were met, those objectives may reflect a scope that is too broad or too narrow. Thus, the problem the system was designed to solve may still exist, or the opportunity that it was to capitalize on may not be appropriately leveraged. Third, organizations need to respond quickly because of the dynamic nature of the business environment. Not enough time is available to adequately do each step of the SDLC for each IT project. Newer methodologies designed to address these concerns use an iterative approach, as shown in Figure 10.9.

One of the dangers developers face is expecting a predictable development process when in reality it's not predictable at all. In response to this challenge, agile development methodologies are being championed. These include XP (Extreme Programming), Crystal, Scrum, Feature-Driven Development, and Dynamic System Development Method (DSDM). To deal with unpredictability, agile methodologies tend to be people- rather than process-oriented. They adapt to changing requirements by iteratively developing systems in small stages and then testing the new code extensively. The mantra for agile programming is “Code a little; test a little.” Some agile methodologies build on existing methodologies. For example, DSDM is an extension of Rapid Application Development (RAD) used in the United Kingdom that draws on the underlying principles of active user interaction, frequent deliveries, and empowered teams. It incorporates a project planning technique that divides the schedule into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline, and budget. DSDM is based on four types of iterations: study (business and feasibility), functional model, design and build, and implementation. These iterations occur (and reoccur) in cycles of between two and six weeks. In contrast is XP, a more prescriptive agile methodology that revolves around 12 practices, including pair programming, test-driven development, simple design, and small releases.¹⁶

FIGURE 10.9 Iterative approach to systems development.

While it allows speedy development and creates happy customers, there are some downsides to agile development. For large projects, it is difficult to estimate the effort that will be required. Further in the rush to get the project completed, designing and documentation might be underemphasized. Further, an agile development project can easily get off track if the customer representatives are not clear about what final outcome that they want.

Prototyping

Another iterative approach is prototyping. Prototyping is a type of evolutionary development, the method of building systems where developers get the general idea of what is needed by the users, and then build a fast, high-level version of the system at the beginning of the project. The idea of prototyping is to quickly get a version of the software in the hands of the users and to jointly evolve the system through a series of iterative cycles of design. In this way, the system is done either when the users are happy with the design or when the system is proven impossible, too costly, or too complex. Some IS groups use prototyping as a methodology by itself because users are involved in the development much more closely than is possible with the traditional SDLC process. Users see the day-to-day growth of the system and contribute frequently to the development process. In other cases prototyping is used as a phase in the SDLC to capture project requirements. Through this iterative process, the system requirements usually are made clear.

There are several drawbacks to prototyping. First, documentation may be more difficult to write as the system evolves. Second, users often do not understand that a final prototype may not be scalable to an operational version of the system without additional costs and organizational commitments. Once users see a working model, they typically assume the work is also almost done, which is not usually the case. An operational version of the system needs to be developed. However, an operational version may be difficult to complete because the user is unwilling to give up a system that is up and running, and they often have unrealistic expectations about the amount of work involved in creating an operational version. This reluctance leads to the fourth drawback. Because it may be nearly impossible to definitively say when the prototype is done, the prototyping development process may be difficult to manage. Fifth, since it is difficult to integrate across a broad range of requirements, this approach is really only suited for “quick-and-dirty” types of systems. Developers should rely on a more structured approach such as the SDLC for extremely large and complex systems. Finally, because of the speed of development, system design flaws may be more prevalent in this approach, and the system may be harder to maintain than when the system is developed using the SDLC. The advantages and disadvantages of the SDLC, agile development, and prototyping are summarized in Figure 10.10.

FIGURE 10.10 Comparison of IT development methodologies.

Other Development Methodologies and Approaches

A variety of other methodologies and approaches exist. These include rapid applications development (RAD), joint applications development (JAD), Object-Oriented analysis, design, and development, and the open sourcing approach.

Rapid Applications Development and Joint Applications Development

Rapid applications development (RAD) is similar to prototyping in that it is an interactive process, in which tools are used to drastically speed up the development process. RAD systems typically have tools for developing the user interface—called the graphical user interface (GUI)—reusable code, code generation, and programming language testing and debugging. These tools make it easy for the developer to build a library of standard sets of code (sometimes called objects) that can easily be used (and reused) in multiple applications. Similarly, RAD systems typically have the ability to allow the developer to simply “drag and drop” objects into the design, and the RAD system automatically writes the code necessary to include that functionality. Finally, the system includes a set of tools to create, test, and debug the programs written in the pure programming language. However, one must remember that “A fool with a tool is still a fool.” RAD is more than just using advance systems development tools. Rather, it is about making systems developers work more effectively.

RAD is commonly used for developing user interfaces and rewriting legacy applications. It may incorporate prototyping to involve users early and actively in the design process. Although RAD is an approach that works well in the increasingly dynamic environment of systems developers, it does have some drawbacks. Sometimes basic principles of software development (e.g., programming standards, documentation, data-naming standards, backup and recovery) are overlooked in the race to finish the project. Also, the process may be so speedy that requirements are frozen too early.¹⁷ As a result, systems developed using RAD may lack quality.

Joint applications development (JAD) is a version of RAD or prototyping in which users are more integrally involved, as a group, with the entire development process up to and, in some cases, including coding. JAD uses a group approach to elicit requirements in a complete manner. Interviewing groups of users saves interviewing and data collection time, but it can be expensive in terms of the travel and living expenses needed to get the participants together.

Object-Oriented Development

Object-oriented development is becoming increasingly popular as a way to avoid the pitfalls of procedural methodologies. Object-oriented development, unlike more traditional development using the SDLC, builds on the concept of objects. An object encapsulates both the data stored about an entity and the operations that manipulate that data. A program developed using an object orientation is basically a collection of objects. The object orientation makes it easier for developers to think in terms of reusable components. Using existing components can save programming time. Such component-based development, however, assumes that the components have been saved in a repository and can be retrieved when needed. It also assumes that the components in the programs in newly developed information systems can communicate with one another.

Open Sourcing Approach

Linux, the brainchild of Linus Torvalds, is a world-class operating system created from part-time hacking by several thousand developers scattered all over the planet and connected only by the Internet. This system was built using a development approach called open sourcing, or the process of building and improving “free” software by an Internet community. The brilliance of Linux was that Torvalds took a very powerful, but proprietary operating system, Unix, and rewrote it to make it available as open source. In fact, the kernel of Linux contains the statement, “Linux is a Unix clone written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net.” Torvalds managed the development process by releasing early and often, delegating as much as possible, being open to new ideas, and archiving and managing the various versions of the software.

Eric Raymond, the author of The Cathedral and the Bazaar, suggests that the Linux community resembles a great bazaar of differing agendas and approaches (with submissions from anyone) out of which a coherent and stable system emerged. This development approach is in contrast to cathedrals, in which software is carefully crafted by company employees working in isolation. The most frequently cited example of a cathedral is Microsoft, a company known, if not ridiculed, for espousing a proprietary approach to software development.¹⁸

Software is open source software (OSS) if it is released under a license approved by the Open Source Initiative (OSI). The most widely used OSI license is the GNU general public license (GPL), which is premised on the concept of free software. Free software offers the following freedoms for the software users:¹⁹

• The freedom to run the program, for any purpose.
• The freedom to study how the program works, and adapt it to your needs. Access to the source code is a precondition for this.
• The freedom to distribute copies so that you can help your neighbor.
• The freedom to improve and release your improvements to the public, so that the whole community benefits. Access to source code is a precondition for this.

A user who modifies the software must observe the rule of copyleft, which stipulates that the user cannot add restrictions to deny other people their central freedoms regarding the free software.

Open sourcing is a movement that offers a speedy way to develop software. Further, because it is made available to a whole community, testing is widespread. Finally, its price is always right—it is free. However, a number of managerial issues are associated with its use in a business organization.

• Preservation of intellectual property. The software is open to the whole community. It cannot be sold, and its use cannot be restricted. So the community is the “owner” of the code. Yet, how are the contributions of individuals recognized?

  Social Business Lens: Mashups

  Social IT applications are often designed with an open architecture to make them easy to adapt. One way organizations take advantage of this feature and create new applications is called mashups. Mashups are Web apps that combine other apps to create a new app, data, functionality, and even interfaces. The goal of a mashup is to be able to create new applications quickly using existing applications, data, and infrastructure. Some mashups are used internally within a firm, but others are set up on the Web and become a new app.

  An example of a mashup is Zillow.com, the real-estate Web site. It has relationship with numerous data providers across the country and accesses public records, which they use in their service. But in addition, Zillow uses Google's street-views, and shows the Google logo in that window. It also uses home data from walkscore.com, and again gives credit to that site for that data. In 2012, Zillow launched a social home-shopping site, called Neighborhood Advice that links the users' search for a home with information about their community of friends on Facebook. Zillow then displays circles on a map to indicate where the user's friends live or have checked in, enabling the user to locate areas where they have many, or few, friends.

• Updating and maintaining open source code. A strength of the open source movement is that it is open to the manipulation of members of an entire community. That very strength makes it difficult to channel the updating and maintenance of code.
• Competitive advantage. Because the code is available to all, a company would not want to open-source a system that it hopes can give it a competitive advantage.
• Tech support. The code may be free, but technical support usually isn't. Users of a system that was open-sourced must still be trained and supported.
• Standards. Standards are open. Yet in a technical world that is filled with incompatible standards, open sourcing may be unable to charter a viable strategy for selecting and using standards.

Applications written following the open source standards were initially rejected by corporate IT organizations. Executives wondered how code that was free, open, and available to all could be counted on to support critical business applications. However, a number of case studies recorded by OSI highlight the benefits of open source code. In addition to Linux, Mozilla (a popular Web browser core), Apache (Web server), PERL (Web scripting language) OpenOffice (a Sun Microsystems-originated set of office applications that support the Microsoft Office suite formats), and PNG (graphics file format) are all examples of very popular software that is based on open source. Advances in the applications available on the Internet, particularly many of the Web 2.0 applications that are making their way slowly into the corporate infrastructure, are open sourced. Corporations are learning to manage the open-source process by more clearly stating their requirements and interfacing with developers on what are typically their non-core systems.

Many good references are available for systems development, but further detail is beyond the scope of this text. The interested general manager is referred to a more detailed systems development text for a deeper understanding of this critical IS process.

MANAGING IT PROJECT RISK

IT projects are often distinguished from many non-IT projects on the basis of their high levels of risk. Although every manager has an innate understanding of what risk is, there is little consensus as to the definition of risk. Risk is perceived as the possibility of additional cost or loss due to the choice of alternative. Some alternatives have a lower associated risk than others. Risk can be quantified by assigning a probability of occurrence and a financial consequence to each alternative. We consider project risk to be a function of complexity, clarity, and size.²⁰

Complexity

The first determinant of risk on an IT project is the complexity level, or the extent of difficulty and interdependent components, of the project. Several factors contribute to greater complexity in IT projects. The first is the sheer pace of technological change. The increasing numbers of products and technologies affecting the marketplace cause rapidly changing views of any firm's future business situation. For example, introducing a new development approach such as open sourcing creates significantly different ideas in people's minds about the future direction of IT development in the firm. Such uncertainty can make it difficult for project team members to identify and agree on common goals. This fast rate of change also creates new vocabularies to learn as technologies are implemented, which can undermine effective communication.

The development of more complex technologies accelerates the trend toward increased specialization among members of a project team and multiplies the number of interdependencies that must be tracked in project management. Team members must be trained to work on the new technologies. More subprojects must be managed, which, in turn, means developing a corresponding number of interfaces to integrate the pieces (i.e., subprojects) back into a whole.

High complexity played a part in the 2008 failure at Heathrow's Terminal 5.²¹ The terminal project involved 180 IT suppliers and over 160 IT systems. There are more than 9,000 devices connected to it along with another 2,100 PCs. The system includes 175 lifts (elevators), 131 escalators, and 18 km of conveyor belts for baggage handling. According to the British Airports Authority (BAA), “It has taken 400,000 man-hours of software engineering just to develop the complex system, and coding is set to continue even after installation begins.” The British Airways CIO was quoted as saying that “even the construction of T5 involved creating a small town with a full telecommunications network for the construction workers, merely to enable the terminal to be built.”²² But the failure in 2008 resulted in cancelled flights, lost baggage, substantial delays and frustrated customers and employees. According to blogger Michael Krigsman, “the systems incorporated in T5 severely taxed BA's planning, testing and deployment capabilities.”²³

Complexity can be determined once the context of the project has been established. Consider the hypothetical case of a manager given six months and $500,000 to build a corporate Web site to sell products directly to customers. Questions that might be used to build context for this case include the following:

• How many products will this Web site sell?
• Will this site support global, national, regional, or local sales?
• How will this sales process interface with the existing customer fulfillment process?
• Does the company possess the technical expertise in-house to build the site?
• What other corporate systems and processes will this project affect?
• How and when will these other systems be coordinated?

Clarity

A project is more risky if it is hard to define. Clarity is concerned with the ability to define the requirements of the system. A project has low clarity if the users cannot easily state their needs or define what they want from the system. The project also has low clarity if user demands for the system or regulations that guide the structure of the system change considerably over the life of a project. A project with high clarity is one in which the systems requirements do not change and can be easily documented. Purchasing a scheduling software package that applies scheduling rules across a broad range of organizations would be an example of a high-clarity project for most firms.

Size

Size also plays a big role in project risk. All other things being equal, big projects are riskier than smaller ones. A project can be considered big if it has the following characteristics:

• Large budget relative to other budgets in the organization
• Large number of team members (and hence reflecting a large number of man-months)
• Large number of organizational units involved in the project
• Large number of programs/components
• Large number of function points
• Large number of source lines of code (i.e., the number of lines of code in the source file of the software product)

It is important to consider the relative size. At a small company with an average project budget of $30,000, $90,000 would be a large project. However, to a major corporation that just spent $2 million implementing an ERP, a $90,000 budget would be peanuts.

Managing Project Risk Level

The IS project management literature usually views risk management as a two-stage process: first the risk is assessed and then actions are taken to control it.²⁴ The project's complexity, clarity, and size determine its risk. Varying levels of these three determinants differentially affect the amount of project risk. At one extreme, large, highly complex projects that are low in clarity are extremely risky. In contrast, small projects that are low in complexity and high in clarity are low risk. Everything else is somewhere in between.

The level of risk determines how formal the project management system and detailed the planning should be. When it is difficult to estimate how long or how much a project will cost because it is so complex or what should be done because its clarity is so low, using formal management practices or planning is inappropriate. A high level of planning is not only almost impossible in these circumstances because of the uncertainty surrounding the project, but it also makes it difficult to adapt to external changes that are bound to occur. On the other hand, formal planning tools may be useful in low-risk projects because they can help structure the sequence of tasks as well as provide realistic cost and time targets.²⁵

Managing the Complexity Aspects of Project Risk

The more complex the project, the greater is the risk. The increasing dependence on IT in all aspects of business means that managing the risk level of an IT project is critical to a general manager's job. Organizations increasingly embed IT deeper into their business processes, raising efficiency but also increasing risk. Many companies now rely entirely on IT for their revenue-generating processes, whether the process uses the Internet or not. For example, airlines are dependent on IT for generating reservations and ultimately sales. If the reservation system goes down, that is, if it fails, agents simply cannot sell tickets. In addition, even though the airplanes technically can fly if the reservation system fails, the airline cannot manage seat assignments, baggage, or passenger loads without the reservation system. In short, the airline would have to stop doing business should its reservation system fail. That type of dependence on IT raises the risk levels associated with adding or changing the system. The manager may adopt several strategies in dealing with complexity, including leveraging the technical skills of the team, relying on consultants to help deal with project complexity, and other internal integration strategies.

Leveraging the Technical Skills of the Team

When a project is complex, it is helpful to have a project manager with experience in similar situations, or who can translate experiences in many different situations to this new complex one. For projects high in complexity, it also helps to have team members with significant work experience, especially if it is related.

Relying on Consultants and Vendors

Few organizations develop or maintain the in-house capabilities they need to complete complex IT projects. Risk-averse managers want people who possess crucial IT knowledge and skills. Often that skill set can be attained only from previous experience on similar IT projects. Such people are easier to find at consulting firms because consultants' work is primarily project based. Consulting firms rely on processes that develop the knowledge and experience of their professionals. Thus, managers often choose to “lease” effective IT team skills rather than try to build them within their own people. However, the project manager must balance the benefits achieved from bringing in outsiders with the costs of not developing that skill set in house. When the project is over and the consultants leave, will the organization be able to manage without them? Having too many outsiders on a team also makes alignment more difficult. Outsiders may have different objectives, such as selling more business, or learning new skills, which might conflict with the project manager's goal of completing the project.

Integrating Within the Organization

Highly complex projects require good communication among the team members, which helps them to operate as an integrated unit. Ways of increasing internal integration include holding frequent team meetings, documenting critical project decisions, and conducting regular technical status reviews.²⁶ These approaches ensure that all team members are “on the same page” and are aware of project requirements and milestones.

Managing Clarity Aspects of Project Risk

When a project has low clarity, project managers need to rely more heavily on the users to define system requirements. It means managing project stakeholders and sustaining commitment to projects.

Managing Project Stakeholders

A project's low clarity may be the result of its multiple stakeholders' conflicting needs and expectations for the system. The project manager must balance the goals of the various project stakeholders to achieve desired project outcomes. The project manager may also need to specifically manage stakeholders. It is not always a simple task to identify project stakeholders. They may be employees, managers, users, other departments, or even customers. However, failure to manage these stakeholders can lead to costly mistakes later in the project if a particular group is not supportive of the project.

Managing the expectations and needs of stakeholders often involves both the project manager and the general manager. Project sponsors are especially critical for IT projects with organizational change components. Sponsors use their power and influence to remove project barriers by gathering support from various social and political groups both inside and outside the organization. They often prove to be valuable when participating in communication efforts to build the visibility of the project.

Sustaining Commitment to Projects

An important way to increase the likelihood of project success is to gain commitment from stakeholders and to sustain that commitment throughout the life of the project. Research indicates four primary types of determinants of commitment to projects (see Figure 10.11).²⁹ They include project determinants, psychological determinants, social determinants, and organizational determinants. Project teams often focus on only the project factors, ignoring the other three types because of their complexity.

FIGURE 10.11 Determinants of commitment for IT projects.

Sources: Adapted from Mark Keil, “Pulling the Plug: Software Project Management and the Problem of Project Escalation,” MIS Quarterly (December 1995); and Michael Newman and Rajiv Sabherwal, “Determinants of Commitment to Information Systems Development: A Longitudinal Investigation,” MIS Quarterly (March 1996).

By identifying how these factors are manifested in an organizational project, managers can use tactics to ensure a sustained commitment. For example, to maintain commitment, a project team might continually remind stakeholders of the benefits to be gained from completion of this project. Likewise, assigning the right project champion the task of selling the project to all levels of the organization can maintain commitment. Other strategies to encourage stakeholder, especially user, buy-in so that they can help clarify project requirements are making a user or the project sponsor the project team leader; encouraging the project sponsor to provide public support for the project; placing key stakeholders on the project team; placing key stakeholders in charge of the change process, training, or installing the system; and formally involving stakeholders in the specification approval process. Being involved in the project makes stakeholders more aware of the trade-offs that inevitably occur during a system implementation. They may be more willing to accept the consequences of the trade-offs. In addition, being involved in the project allows users to better understand how the system works, and thus may make it easier for them to use the system.

Gauging Success

How does a manager know when a project has been a success? At the start of the project, the general manager who built the business case would have considered several aspects based on achieving the business goals. It is important that the goals be measurable so that they can be used throughout the project to provide the project manager with real-time feedback. The general manager probably also wants to know if the system meets the specifications and project requirements laid out in the project scope. But measuring this is complex. Metrics may be derived specifically from the requirements and business needs that generated the project to determine whether or not the system meets expectations. Such metrics need to be based on the specific system, such as automating the order entry process or building a knowledge management system for product design.

FIGURE 10.12 Success dimensions for various project types.

Source: Adapted from Aaron Shenhar, Dov Dvir, and Ofer Levy, “Project Success: A Multidimensional Strategic Approach,” Technology and Innovation Management Division (1998).

Four dimensions that are useful in determining if a project is successful or not are shown in Figure 10.12. The dimensions are defined as follows:

• Resource constraints: Does the project meet the established time and budget criteria? Was there schedule slip (i.e., the current scheduled time divided by the original scheduled time.) Most projects set some measure of success along this dimension, which is a short-term success metric that is easy to measure.
• Impact on customers: How much benefit does the customer receive from this project? Although some IT projects are transparent to the organization's end customer, every project can be measured on the benefit to the immediate customer of the IS. This dimension includes performance and technical specification measurements.
• Business success: How high are the profits and how long do they last? Did the project meet its return on investment goals? This dimension must be aligned with the business strategy of the organization.
• Prepare the future: Has the project altered the infrastructure of the organization so that in the future business success and customer impact are more likely? Today many companies are building Internet infrastructures in anticipation of future business and customer benefits. Overall success of this strategy will only be measurable in the future, although projects underway now can be evaluated on how well they prepare the business for future opportunities.

What other considerations should be made when defining success? Is it enough just to complete a project? Is it necessary to finish on time and on budget? What other dimensions are important? The type of project can greatly influence how critical each of these dimensions is in determining the overall success of the project. It is the responsibility of the general manager to coordinate the overall business strategy of the company with the project type and the project success measurements. In this way, the necessary organizational changes can be coordinated to support the new information system. After the project is completed, a post-project feedback (post-implementation audit) should be completed to ensure that the system met its requirements and the system development process was a good one.

SUMMARY

• A general manager fulfills an important role in project management. As a project sponsor, the general manager may be called on to select the project manager, to provide resources to the project manager, and to provide direction to and support for the project.
• The business case provides foundation for a well-managed project by specifying the objectives of the project, the required resources, the critical elements, and the stakeholders.
• Project management involves continual trade-offs. The project triangle highlights the need to delicately balance cost, time, and scope to achieve quality in a project.
• Four important project elements are project management, project team, project cycle plan, and common project vocabulary.
• Understanding the complexity of the project, the environment in which it is developed, and the dimensions used to measure project success allows the general manager to balance the trade-offs necessary for using resources effectively and to keep the project's direction aligned with the company's business strategy.
• Three popular information technology project development methodologies are the SDLC, agile programming and prototyping. Each of these methodologies offers both advantages and drawbacks. Other methodologies and approaches are emerging.
• In increasingly dynamic environments, it is important to manage project risk. Project risk is a function of project size, clarity, and level of complexity. For low-clarity projects, it is important to interface with users and gain their commitment in the project. Projects that are highly complex require leveraging the technical skills of the team members, bringing in consultants when necessary, and using other strategies to promote internal integration.
• The PMO, Project Management Office, brings focus and efficiency to project management activities. Often the PMO is a formal organization under the CIO.
• Projects are here to stay, and every general manager must be a project manager at some point in his or her career. As a project manager, the general manager is expected to lead the daily activities of the project. This chapter offers insight into the necessary skills, processes, and roles that project management requires.
• Mashups are new applications derived from combining existing applications on the Web.

KEY TERMS

agile development (p. 306)

direct cutover (p. 304)

joint applications development (JAD) (p. 309)

mashups (p. 311)

object (p. 309)

open source software (OSS) (p. 310)

open sourcing (p. 310)

parallel conversion (p. 304)

project (p. 290)

project management (p. 292)

project management office (PMO) (p. 294)

project manager (p. 295)

project stakeholders (p. 290)

prototyping (p. 307)

rapid applications development (RAD) (p. 308)

systems development life cycle (SDLC) (p. 303)

DISCUSSION QUESTIONS

1. What are the trade-offs between cost, quality, and time when designing a project plan? What criteria should managers use to manage this trade-off?
2. Why does it often take a long time before troubled projects are abandoned or brought under control?
3. What are the critical success factors for a project manager? What skills should managers look for when hiring someone who would be successful in this job?
4. What determines the level of technical risk associated with a project? What determines the level of organizational risk? How can a general manager assist in minimizing these risk components?
5. Lego's Mindstorms Robotics Invention System was designed for 12-year-olds. But after more than a decade of development at the MIT Media Lab using the latest advances in artificial intelligence, the toy created an enormous buzz among grown-up hackers. Despite its stiff $199 price tag, Mindstorms sold so quickly that store shelves were emptied two weeks before its first Christmas in 1998. In its first year, a staggering 100,000 kits were sold, far beyond the 12,000 units the company had projected. Seventy percent of Mindstorms' early customers were old enough to vote. These customers bought the software with the intention of hacking it. They wanted to make the software more flexible and powerful. They deciphered Mindstorms' proprietary code, posted it on the Internet, began writing new advanced software, and even wrote a new operating system for their robots. To date Lego has done nothing to stop this open source movement, even though thousands of Lego's customers now operate their robots with software the company didn't produce or endorse and can't support. The software may end up damaging the robot's expensive infrared sensors and motors.³⁰
   1. What are the advantages of Lego's approach to open sourcing?
   2. What are the disadvantages of Lego's approach to open sourcing?
   3. How should Lego manage the open source movement?

CASE STUDY 10-1
IMPLEMENTING ENTERPRISE CHANGE MANAGEMENT AT SOUTHERN COMPANY

Atlanta-based Southern Company, a leading utility provider in the southeast United States, is valued by its 4.4 electricity customers for its excellent service, and it ranks as Fortune magazine's “most admired” company in its industry. That means quality is important in everything the company does. When David Traynor, business excellence manager at the company, was charged with implementing a new enterprise change management (ECM) site, he knew its key users, employees in the IT department, would scrutinize the new system and be very critical if anything didn't work exactly as it should.

The projected investment for the ECM was in the seven figures range, but the business case was straightforward. The justification was based on the savings in time and costs from reduced meetings and the ability to devote more attention to risky projects. The IT department was handling over seven thousand change requests a year, each of which required a time-consuming approval process no matter how small or routine the change was. Each change request needed to be approved at one of the three hour-long review committee meetings that were held each week. Some frustrated employees were even starting to circumvent the approval process. Clearly something had to be done. But even though the ECM had clear benefits, the IT department was not eager to work on a system that didn't promise to be very exciting. Further, installing the ECM promised to markedly change the way the IT folks performed their work. “They had to log all their changes, gain approval, take all these steps that they weren't being tasked with before,” said Traynor.

The department selected BMC's Remedy software suite after spending six months designing the new process. Next came ten months to customize the systems and seven months to build them. The first ECM phase was rolled out in August 2010. Surprisingly, the new system produced even more change requests than before—almost 3,000 additional ones each year. Traynor reasoned that, before the ECM was switched on, a lot of changes must have been processed without any review. That was problematic given that about eight of ten requested projects have at least some level of risk and 100 percent require resources to complete. Now the change advisory board meets monthly (rather than three times weekly) and deals only with emergency changes and high-risk changes that could affect critical sites or many users. Routine change requests are pre-approved using standard formats.

Traynor hadn't spent much time getting buy-in from the IT department during the first phase of the ECM project. He now believes he should have started the ECM communication and training effort much sooner in the first phase. The second phase of the implementation, the incident and problem management system, was done differently. Traynor appointed “ambassadors” from each IT unit as before, but this time they participated from the very first day of the second phase of the project. Traynor encouraged them to talk with the IT employees in their unit, so they were not playing catch-up as they had been in the first phase. Rather, the ambassadors were actively involved in designing system changes. “They've put their fingerprints on it . . . We get a lot of mileage from [the ambassadors].” Traynor wants them to learn the ECM and play a major role in training and testing the system. He adds, “The hope is that [they]. . . become the go-to person after we go live.”

Discussion Questions

1. What type of development methodology appears to have been employed at Southern Company for the ECM project? Was this a good approach? Provide a rationale for your response.
2. Describe implementing the ECM? What would have been the advantages of applying Lewin's three-stage model?
3. Assess Southern's ECM system on the four dimensions of project success? How successful do you think this project is?

Sources: Southern Company Web site, www.southerncompany.com (accessed on April 18, 2012); and S. Overby, “How Southern Company Revamped IT Change Management,” CIO.com (October 18, 2010), http://www.cio.com/article/print/626323.

CASE STUDY 10-2
DEALING WITH TRAFFIC JAMS IN LONDON

As London entered the 21st century, it was confronted with a major issue that plagues many cities throughout the world—excessive automobile traffic. Many Londoners—and particularly the business community—rated traffic congestion as the city's most serious problem. At peak periods, the average speed was less than 10 miles per hour, a slower speed than the horse-drawn carriages of previous centuries. Drivers spent about half their time waiting in traffic. Not only was this congestion nightmare a major source of driver frustration, but it contributed to both environmental and economic problems as well. By one estimate, traffic-related problems cost London businesses roughly £2 million—more than $3 million—every week. Clearly, the city needed an aggressive policy to address this issue. The solution, proposed by a government study titled Road Charging Options for London (ROCOL), authorized by the 1999 Greater London Authority Act, and endorsed by incoming Mayor Ken Livingstone, was congestion charging. As the name suggests, the city would assess a fee, or charge, to every automobile that entered high-traffic sections of London during peak hours.

Rather than attempt a broad citywide implementation, the government focused specifically on the highly congested section of central London, where roughly 1 million people entered every day, about 150,000 of them by private automobile. Beginning in February 2003, drivers who entered this area between 7 AM and 6:30 PM had to pay a fee of £5 ($8) by midnight. (Certain types of vehicles, such as ambulances, buses, and taxis, were exempt.) Drivers have the option of paying the charge by mail (prepay), text messaging, telephone, or in person at various pay points. Failure to pay the fee results in a fine of £80 (roughly $130). Significantly, this solution makes extensive use of current technologies. The city installed almost 700 cameras at more than 200 sites in the designated high-traffic area. These cameras photograph the license plates of every vehicle that enters the area. They then transmit these photos to a data center that translates the photographic images into license plate numbers utilizing automatic number plate recognition technology. Drivers who fail to pay the fee receive a notice of the fine in the mail.

To create and implement the congestion charge plan, the government had to face a number of project risks:

• Tight Schedule: The project needed to be completed under tight deadlines in order to meet multiple statutory requirements and minimize disruptions to commuters.
• Technology: The cameras had to be strategically placed in order to accurately photograph tens of thousands of license plates every day.
• Lack of Pre-existing Models: There were no pre-existing models in the world to follow.
• Limited Experience and Expertise: Mayor Livingstone was newly elected, and the supervising governmental agency—Transport for London—had only recently been created. Thus, neither were experienced in building such a system.
• Political Fallout: The political risk of a system failure to the new mayor was so huge that it would be extremely damaging to his career.

Transport for London adopted a series of management strategies to navigate these waters and limit the risks resulting from their limited experience, IT ability, and management time. Perhaps the most significant decision was to outsource the basic management activities to firms that specialized in these areas. For example, to manage the competitive bidding process they contracted first with PricewaterhouseCoopers and then with Deloitte & Touche.

Early in the project, project managers identified the critical technical elements and divided the project into five “packages” that could, if required, be bought and managed separately. These included (1) the camera component; (2) the image store component that collected images, converted them into license numbers, and condensed the images (duplicates would occur when one vehicle was photographed by several cameras); (3) the telecommunications links between the cameras and the image store component; (4) the customer services infrastructure, including the ability to pay by phone, Web, and mail; and (5) an extensive network of retail outlet kiosks and gas stations where people could pay the toll.

The retail side was seen as a big enough risk that it was bought and managed separately. To further reduce the risks, it was decided to select the best available technologies for each of the five packages. Another risk-aversive move was to utilize only established technologies for the actual process of identifying the vehicles in the designated zone. For example, Transport for London rejected proposals to employ electronic tags because this technology had not been proved effective in scenarios such as this one. Finally, the city added roughly 200 buses to its fleet to accommodate increased ridership.

Transport for London requested bids on the project early in 2001. The estimated $116.2 million project was large enough to require listing in the European Union's public-sector register. Companies throughout Europe were allowed to bid on the project. Separate bids could be tendered for the camera and communications packages, whereas the remaining three could receive bids on a combined basis or individually. Deloitte & Touche reviewed more than 40 bids before deciding on a single contractor to manage the entire program. Their choice was The Capita Group, England's largest business process outsourcing firm. Significantly, before accepting Capita's bid, Deloitte required both that firm and the other final candidate to submit technical design studies. In addition, Capita's contract included penalties if the company failed to meet the established deadlines.

After awarding the contract to Capita, Deloitte closely monitored every step of the process, and it kept additions to the original plan to a minimum. As a result, scope creep—the process whereby a project increases in both size and costs as new features are added—was never a serious issue. One of the few changes added to the requirements was an option for motorists to pay fees through the popular SMS text messaging format.

Throughout the implementation of the new system, the city continually sought feedback from key stakeholders. In addition, it regularly updated the public concerning the project's status. Consequently, few drivers were caught unawares when the new policy went into effect on February 17, 2003. The mayor also wisely decided to begin operations during a school holiday period, when traffic volumes are significantly lower. Thus, by the time traffic returned to normal, drivers generally had adapted to the new procedures.

What were the results of these concerted efforts? Unlike so many systems projects, London's congestion charging plan was completed on time and within budget. Significantly, however, the demanding schedule did not compromise the quality of the work. Instead, the new program appears to have achieved its basic goals. A follow-up study indicated that traffic in central London had diminished by as much as 20%, and average driving speeds had improved. The fines and fees resulted in a project payback period of about one and a half years. It was estimated that total revenues would amount to $2.2 billion over a ten-year period. Moreover, vehicular emissions of toxic substances such as nitrogen dioxide were also reduced. One potential problem that did not emerge was “rat runs” in which traffic jams would appear in areas outside the zone as drivers altered their routes to avoid the charges. After reviewing the outcomes of the London program, many observers predicted that congestion charging would become a standard practice in cities throughout the world.

Discussion Questions

1. Assess the risks of this project. Given your assessment of the project complexity, clarity, and size, what management strategies would you recommend? What, if any, of these strategies were adopted in this project?
2. Describe the development methodology that was applied to this project. Was this the most appropriate approach? Provide a rationale for your response.
3. When a project is outsourced, who should manage the project—the internal group or the outsourcer? Why?

Sources: Ken Livingstone (Mayor of London), “The Challenge of Driving through Change: Introducing Congestion Charging in Central London” (December 2004), Planning Theory and Practice 5(4), 490–498, http://web.ebscohost.com.jerome.stjohns.edu:81/ehost/pdfviewer/pdfviewer?vid=23&hid=21&sid=9daf2014-9a51-45ea-8187-9f6bc0075556%40sessionmgr15; Bradford Wernie, “The World Watches As London Tries to End Congestion,” (January 27, 2003), Automotive News Europe 8(2), 3–4, http://web.ebscohost.com/ehost/detail?sid=dd39c013-cbdf-4628-a244-c556c0fad40e%40sessionmgr15&vid=22&hid=9&bdata=JnNpdGU9ZWhvc3QtbGl2ZQ%3d%3d#db=bsh&AN=9127667; and Malcolm Wheatley, “How IT Fixed London's Traffic Woes” (July 15, 2003), CIO 16(19), http://search.proquest.com.jerome.stjohns.edu:81/docview/205943050/fulltext/13626A661B39C302E/3?accountid=14068.