A Portfolio Approach to Managing IT Projects

Chapter 10: A Portfolio Approach to Managing IT Projects

Despite 40 years of accumulated experience in managing IT projects, big disasters on major IT projects still occurs.
Research suggests 3 deficiencies involving general and IT management could be responsible:

• Failure to assess (or acknowledge) the implementation risks of a project at the time it is funded.
• Failure to consider the aggregate implementation risk of a portfolio of projects.
• Failure to recognize that different projects require different managerial approaches.

• Sources of Implementation Risk
• Risk is a necessary part of a project experience. Risk must be taken for a higher return.
• Project feasibility studies typically provide estimates of financial benefits, qualitative benefits, implementation costs, target milestone and completion dates, and staff levels. However, they rarely deal frankly with the risks of slippage in time, costs overruns, or outright failure.
• However, discernible characteristics of projects can be translated into indicators of project risks that are as tangible as project cost or duration.
• Three important project dimensions influence inherent implementation risk:
• Project size—the larger the project in terms of budget, staffing levels, duration, and number of departments affected, the greater the risk.
• Experience with the technology—Project risks increases when the project team and organization are unfamiliar with the hardware, software, or other project technologies.
• Requirements volatility—For some projects, the nature of the task fully and clearly defines project outputs., which remain fixed. Other projects do not have such convenient characteristics, and their requirements are volatile, difficult to determine, and evolve throughout the project.

 

B. Project Categories and Degree of Risk

• The three project dimensions described above influence project risk. For instance large project size, high technology, and high requirements volatility increases project risk. The more risk factors, the more faster risk increases. (Fig. 10.1)
• Figure 10.2 shows examples of projects that fit into high-risk categories because of high technology or high requirements volatility.

1. Assessing Risks for Individual Projects

• Many companies use questionnaires to assess project risk. The project manager must answer the questions before senior managers will approve the project.
• The questions highlight the sources of implementation risks and suggest alternative routes to conceiving the project and managing it to reduce risks. For instance, the project scope could be reduced, more familiar technology used, or the project could be broken into multiple phases.
• Questionnaires are often readministered several times during the project to reveal changes in risks. Ideally, risk assessment scores decline throughout implementation as the number and size of the remaining tasks dwindle and familiarity with the technology increases.

2. Managing the “Dip” during Project Implementation

• “Cutover,” when the new system goes live, is the most likely time for difficulties to materialize. Business users and their managers can quickly lose confidence in the system and the IT staff.
• Managing this “dip” in performance is an important part of managing project risk.
• Business users think about new systems in terms of the improvement they will provide. When the new system does not meet their expectations, they can feel betrayed and nostalgic for the old system, which they tend to idealize.
• IT managers should work to communicate the likelihood of a performance dip before it occurs.
• When cutover difficulties occur, project managers must find a way to focus, tackling problems one at a time, in order of importance.

3. Portfolio Risk

• A company should develop a profile of aggregate implementation risk for its portfolio of systems projects.
• Because projects are usually conceived and financially justified one at a time, not as a group, project portfolios often drift out of alignment with business strategy.
• Different portfolio risk profiles are appropriate to different companies and strategies:
• IT’s aggregate impact on corporate strategy is an important determinant of the appropriate amount of implementation risk to undertake.
• In an industry where IT is strategic (like retailing or catalog sales), managers should be concerned if there are no high-risk projects in the project portfolio. However, a portfolio filled with high-risk projects creates vulnerability to operational disruptions if projects are not completed as planned.

C. Project Management: A Contingency Approach
There is no single correct approach to all projects.
1. The 4 types of Management Tools (see examples of each in Table 10.1)

• External integration tools—organizational and other communication devices that link the project team’s work to system users, current and prospective, at both managerial levels.
• Internal integration tools—various personnel controls and communication devices that ensure that a project team operates as an integrated unit.
• Formal planning tools—help structure the sequence of project tasks in advance and estimate the time, money, and technical resources the team will need.
• Formal results controls—help managers evaluate progress and spot potential discrepancies so corrective action can be taken.
• Influences on Tool Selection
• Low Requirements Volatility/Low-Technology Projects
• The easiest, least risky, but least common type of project.
• Significant change management issues are not present.
• External integration practices such as assigning IT systems analysts to user departments, mandating heavy representation of users on the design team, and requiring formal user approval of design specifications are unnecessary.
• Training does remain important.
• Project can be staffed by people with average skills levels.
• Formal planning tools work well on this type of project, because they force the team to develop a through and detailed plan that exposes problem or unspecified areas.
• Low Requirements Volatility/High-Technology Projects
• Projects involving high technology call for significant elaboration on the practices outlined in most project management handbooks.
• Ex: converting a mainframe systems to run on client-server architecture.
• Interaction between the project team and business users is not crucial.
• However, interaction with users is important in two respects: 1) to ensure agreement on business procedure changes necessary for project success, and 2) to deal with adjustments made necessary by unexpected shortcomings in the project’s technology.
• For this kind of project, it is common to discover during implementation that the selected technology is inadequate for the task—forcing postponements.
• Because of the technical complexity of the project, a successful manager should have a strong background in high-tech projects and should be able to connect with the techies the project will require. He/she must establish and maintain teamwork, develop a record of all key design decisions, and call subproject meetings as needed.
• Formal planning methods that identify tasks and set completion dates have much less predictive value.
• Technical leadership and integration are key. External integration is much less important.
• High Requirements Volatility/Low-Technology Projects
• Low-risk when managed well, but often fail because of inadequate understanding of, and focus on, business requirements.
• Keys to success—involve users in design, development, and implementation; close, aggressive management of external integration, supplemented by formal planning and control tools.
• Such projects benefit from the following:
• A user as project leader or as the number two person on the team.
• A user steering committee to evaluate the design periodically.
• Breaking the project into a sequence of small, discrete subprojects.
• Distributing minutes of all key design meetings to the users.
• Adhering to all key subproject time schedules. Low turnover among users is important.
• Once the design is finalized, the importance of user leadership increases. However, unless changes are critical to the business, they should be addressed in a formal change-control process.
• Formal planning tools are very helpful in structuring tasks and removing uncertainties, and target completion dates should be attainable.
• Technology management is less difficult.
• High Requirements Volatility/High-Technology Projects
• Extremely difficult and should not be undertaken lightly.
• Outputs are not clearly defined at the project’s start.
• Technically complex. Should consider dividing the project into smaller parts or using less innovative technology.
• Managers need technical expertise and an ability to communicate with users about business needs.
• Intensive external integration is needed.
• Total user commitment to a particular set of design specifications is again critical.
• Strong technical leadership and internal project integration are vital.
• Highly experienced projects leaders who have strong support from users are needed.
• Formal planning and results-control tools are useful, but contribute little to reducing uncertainty or highlighting problems. New tasks crop up regularly, and unsuspected interdependencies between tasks often become apparent.
• Time, cost, and the resulting technical performance are almost impossible to predict simultaneously.
• Relative Contribution of Management Tools
• A single-minded, prescriptive approach to project management fails to deal with the realities of the tasks facing today’s managers. The right approach to project management flows from the specific characteristics of the project.
• The need to deal with the corporate culture within which the IT and the project team operate complicates the program management problem. Formal project planning and results-control tools are much more likely to produce successful results in highly formal environments than they are in companies where the prevailing culture is more informal.
• Emergence of Adaptive Project Management Tools
• Trends in the last decade:
• Projects with very volatile requirements that challenge traditional tools for project management and entail very high implementation risk.
• Business requirements for many enterprise systems are not well defined in advance and involve new technologies. 
• These projects require large investments, up-front, to achieve uncertain benefits.
• Results-control tools and traditional planning methodologies do not work well with so much outcome uncertainty.
• Emergency response to these trends: Adaptive methods
• Approaches to design, deployment, implementation, and investment that assume a need to gather information and to learn as one goes.
• These approaches require that project staff be able to experiment during a project without incurring prohibitively high costs.
• They are not yet universally applicable.
• Software Development Life Cycles: The Traditional Way to manage projects
• Analysis and Design—Begins with a comprehensive analysis of requirements, followed by documentation of the desired capabilities of the system in a form that can be used by system developers to code and implement the system. Users and IT professionals write a proposal with a formal statement of costs/benefits to initiate the process.
• Construction—Involves selecting appropriate computer equipment and then creating, buying, and adapting them to meet system requirements. Final step is testing the systems both in the lab and in the real-world user environment. Intense coordination and control are required to assure that the project remains on track, within budget, and focused on user requirements.
• Implementation—Joint effort. Extensive testing must be performed, training is required, and work procedures and communication patterns may be disrupted. Success of the new system depends on the users’ ability to use it to make better decisions and add value to the company.
• Operation and Maintenance—Operation and maintenance are planned in advance, during requirements definition. Maintenance is complex, particularly for older systems.
• Adaptive Methodologies
• Adaptive, prototyping-intensive methodologies call for quickly building a rough preliminary version of the systems with a lengthy or formal requirement definition or design phase.
• They iterate quickly through the traditional phases of design, construction, implementation, and operation, improving the performance of the product each time.
• These projects loop through each development phase every week or even every day.
• Ex: Cisco and Tektronix use adaptive methodologies.
• Adaptive projects share these characteristics:
• They are iterative, with design construction, and implementation occurring in small increments that result from each iteration so that outcomes and interactions can be tested as they appear.
• They rely on fast cycles and require frequent delivery of value so that incremental implementation does not slow down a project.
• They emphasize early delivery to end users of functionality, however limited, so that feedback can be incorporated into learning and improvement cycles.
• They require skilled project staff capable of learning and making midcourse adjustments in the middle of deployment.
• They often resist return on investment and other tools for investment decision making that implicitly assume predictability of outcomes. Instead, they emphasize buying of information about outcomes as a legitimate expenditure.
• Off the shelf, over the net, and open-source software like Linux and Apache Web server now facilitate adaptive development. They all emphasize low-cost experimentation and rapid delivery of prototypes.
• Formal results-oriented controls can lead to dysfunction and disaster with large, risky projects. With traditional development, in which tight schedules must be kept to, those in charge sometimes ignore problem issues or try to cover them up. In contrast, adaptive development views complications as learning inputs, whose adjustments can improve the end product.
• Adaptive Methods and Change Management
• Adaptive projects achieve change management by intensely involving users in evaluating the outcome of each development iteration and deciding on the next enhancement to be introduced.
• Sound change management requires strict control of the migration of system features from development, through testing, into production with a clear understanding of the benefits and the potential for unanticipated problems at each stage.

D. Process Consistency and Agility in Project Management

• Project management involves balancing tension between process consistency and process agility. Successful companies use process management tools that include the minimum formal specification critical to the success of a project:
•  Flow: People working on projects need to understand the relationships between their activities and those of others. Simple schedules and flowcharts will help
• Completeness: Checklists are needed to convey what needs to be done, when, by whom, and whether it is complete.
• Visibility: People need to be able to review processes while they are being executed to get status information. Computerized status reporting systems or even simple wall charts.

E. Conclusion: The Challenge of Managing in a Network Economy Revisited   (pp. 591-593)

• Key themes discussed in the text:
• The continuous pace of technology evolution requires that we confront new choices for designing and building industries markets, and organizations.
• The business models that dominated the Industrial Economy are evolving to take advantage of the new technologies and business practices of the Network Economy, giving rise to new sources of power and differentiation.
• The types of opportunities pursued and the technology employed strongly influence the approach to developing, operating, and managing IT.
• As IT infrastructure becomes more standardized, modular, and scalable, we are seeing a shift in TI investment priorities and decisions from a cost-avoidance, project-centered approach to an asset-based, strategic option approach.
• The time required for successful organization learning and assimilation of rapidly changing technologies limits the practical speed of chance.
• External industry, internal organizational, and technological changes are increasing the pressure on organizations to buy rather than make IT applications and services.
• The ability to exploit 21st century technology demands high levels of engagement and cooperation among 4 key constituencies: Business execs, IT execs, users, and technology providers/partners.
• The ability to ensure high levels of security, privacy, reliability, and availability is a core capability that determines an organization’s ultimate success and survival.
• Over the last decade there has been a fundamental shift in IT that has dramatically changed the way people access and use technology, the way organizations exploit it, and the way it is developed and managed.
• The new technologies have altered competitive positions and framed new strategic imperatives that require new capabilities. To succeed, companies must size the opportunities presented by new technologies.
• New networked infrastructures interweave complex business-technical issues that general managers dread but that ultimately make the difference between a rigid and constraining IT capability and a flexible and dynamic one.
• As technology-based projects grow larger and larger, decisions must be made ever more quickly, and execs express concern that the relentless pace of change is occurring too fast to enable them and their organizations to learn.

Questions for Discussion:

1. What three deficiencies related to general and IT management does research suggest are responsible for the high incidence of disaster on major IT projects?
2. What do project feasibility studies usually include? What do they often leave out?
3. What three important project dimensions influence implementation risk?
4. Discuss the role of questionnaires in risk assessment for individual projects.
5. Discuss portfolio risk and why it is important.
6. List and discuss the four types of management tools.
7. For each of the follow project scenarios, describe which management tools are appropriate, and how they are used:

• Low Requirements Volatility/Low-Technology projects
• Low Requirements Volatility/High-Technology projects
• High Requirements Volatility/Low-Technology projects
• High Requirements Volatility/High-Technology projects

8. Discuss IT project trends over the past decade.
9. Describe each of the steps in the traditional Software Development Life Cycle
10. Describe the major characteristics shared by all adaptive project methodologies.
11. According to the text, what are the three minimum formal specifications that are critical to the success of a project?
12. The Conclusion to the text lists a number of themes discussed in the text. Discuss the five themes that you found to be the most interesting and important. How do you think being aware of these themes will impact on your decision making in your present position/ future career?