Preview Extract
Chapter 11: Managing IT Projects Overview For management students, it seems that most of their time will be spent either managing projects or as a member of a project management team. Further, most projects in businesses today involve building, using, altering, or integrating an information system. Therefore, the authors included this important chapter dedicated to project management. This chapter is about project management in general, and also about issues such as SDLC, prototyping, and agile development, which are specific to managing IT projects. Additional methods are included, such as RAD, JAD, object-oriented development, and the open sourcing approach. The instructor interested in covering these IT specific topics are encouraged to supplement this chapter with readings that give more detail on systems development methodologies (some of which are suggested in this Instructor’s Manual). The goal is to help management students understand how to be knowledgeable participants and leaders of projects. Discussion Opener: The opening slide describing the Rural Payments Agency provides discussion questions, and the Notes section of that slide provides some potential answers. Alternate Discussion Opener: As a manager, what questions do you need to answer before making a sourcing decision? What are your greatest concerns? Key Points in Chapter This chapter opens up with a brief discussion of a failed IT project in the UK. The Rural Payments Agency (RPA) implemented a new “Single Payment” system without proper testing which resulted in late payments to the tune of ₤1.5 billion. Only 15% were paid out by the end of 2006. The RPA had to make substantial changes to the system post-implementation. The system had not been properly managed, with costs at 122 million pounds that were originally estimated at 46.5 million. The latest update is that the Single Payment project became so dysfunctional that it was replaced by the Basic Payment Scheme, which already ran into such severe problems that farmers were invited to file tax refund claims on paper, as they did many years ago. The importance of this case is to illustrate the problems that can occur when proper project management is not implemented. In particular, requirements must be specified at the outset, or the result is unlikely to meet the needs of the end-users. Standish Group found that 67 percent of all software projects are challenged and are either late, over budget, or fail to meet performance criteria. Managing a business project means managing an information systems project. Projects are defined as unique work done on a temporary basis. This is distinguished from operations, where work is ongoing and tasks are frequently repeated. Projects are distinguished from operations succinctly in Figure 11.1. All projects have stakeholders, people or organizations that are impacted by the project in some way. A project manager is responsible for the organization of the project, as well as the ongoing activities necessary to make sure the project is successful. A useful resource for project managers is the PMBK. Project management, therefore is the "application of knowledge, skills, tools, and techniques to project activities." There are a number of tradeoffs that must be made by the project manager and the "owners" of the project itself including scope and time, cost and quality, needs and expectations, and conflicting needs of different stakeholders. Project management requires tradeoffs. To illustrate these tradeoffs, the project triangle is referred to (Figure 11.2) with its three elements: time, cost, and scope. Any two of these elements can be maximized, but at the expense of the third element. A successful balance of these elements yields a high-quality project. You might choose to use examples to illustrate the tradeoffs. For example, writing a research paper: the deadline is inflexible – Friday by 5:00pm; the resource allocation or cost is set – assuming only one student is working on the research project, you cannot throw more money or workers at the project; therefore, the quality/scope of the paper is the element that is going to have to adjust. In other words, whatever the student has produced by 5:00pm on Friday is what’s handed in. Students should be able to come up with other examples. The Project Management Office (PMO) is a department responsible for improving the outcomes of projects through efficiency, allocating expertise, and improving project delivery. Actual responsibilities will vary depending on the needs and availability of staff for the organization. Four project elements are essential: project management, a project team, a project cycle plan, and a common project vocabulary. Project management requires the following skills: requirements identification, organizing, project team management, planning, risk and opportunity management, project control, visibility, status, corrective action, and leadership. Each of these skills is discussed in some detail. The project team works together to accomplish the common goals. A project cycle plan begins with a breakdown of the project into workable tasks, allocation of resources, and estimated duration of task completion. Project managers often use software applications to assist with project monitoring (e.g. PERT, Gantt charts, and critical path method). Common project vocabulary helps the team to build consensus and understanding, along with commitment to shared goals. If one IT team member talks about “customers” as internal users (managers or other employees at a company), while another defines “customers” as those outsiders who buy the firm’s products, there will be confusion, errors, and delays. Most projects today are IT projects, involving some use of information systems. There is little difference from a pure project management perspective. However, IT projects tend to follow one of a very few number of processes. One common IT process is the Systems Development Life Cycle, or SDLC. There are 7 phases to a typical SDLC: initiation and feasibility, requirements definition, functional design, technical design and construction, verification, implementation, and maintenance and review. Figure 11.7 provides descriptions and sample activities for each phase of the SDLC. Depending on a number of factors, the project team will select an appropriate conversion strategy. The types described are (1) parallel conversion – the company runs the old and new systems simultaneously, and (2) direct cutover – the company switches over to the new system, and the old system is no longer available. Each approach has benefits and risks. Due to some significant problems with SDLC, agile development methodologies are being adopted. The attraction for companies is the speed and responsiveness of the procedures. A common feature is that these methods are iterative in nature – “code a little, test a little.” Using short deadlines and small sub-projects, projects make rapid progress. These methodologies are dynamic and tend to be more people-oriented than project-oriented. Prototyping, or evolutionary development, is the method of building systems where a version of the system is quickly built and shared with users. RAD is a more structured process for developing systems quickly, and is similar to prototyping in some ways, where the user interface is quickly developed using specialized tools, reusable code, code generation systems, etc. RAD often refers to the process; prototyping often refers simply to the part of the process where a version of the system is shared with the users. JAD is a version of RAD or prototyping which is built around the involvement of a group of end-users. The object-oriented approach is also introduced, which is the encapsulation of objects and methods. The purpose is to make project development more efficient and faster by reusing objects stored in a repository. Open sourcing is described, which makes use of distributed “team” of programmers working together on the source code to create software applications. Some key issues in this decision are preservation of intellectual property, updating and maintaining open source code, competitive advantage, tech support, and maintaining standards. Social Business Lens: Mashups – Mashups are independent applications that are integrated by end-users in order to gain additional benefits and meet needs. For example, combining a map application with a retail site in a mash-up would be a useful tool for shoppers. Putting it all together and then dealing with the associated risks is the manager's job. This is one of the areas that can be handled as a discussion rather than straight presentation, and students can be asked to come up with ideas in case of each type of risk. Present the three risk factors: project's complexity, clarity, and size, then ask students what you should probably do in case each factor is present. The level of risk determines how formal the project management system and planning detail should be. Managing the complexity aspects of project risk can include leveraging the technical skills of the team, relying on consultants and vendors, and integrating within the organization. Organizational factors must be managed such as managing project stakeholders, sustaining commitment to projects, and managing cultural, structural, and systemic influences. These organizational factors help improve the clarity of the project. In some projects the risk is too great or the payoffs are too little. The plug needs to be pulled on these projects. We often ask our students when they are doing projects, "how will you know if your project has been successful?" or "what are the measures of success?" There are four dimensions of success: resource constraints, impact on customers, business success, and preparation for the future. Figure 11.11 summarizes the dimensions of success. Finally, at the completion of a project, the team should meet once more to discuss the experience and identify “lessons learned.” Geographic Lens: Allocating software development projects to available sites around the globe – Companies can benefit from globally distributed expertise, reduce labor costs, and “follow the sun” project design. However, as discussed in Chapter 10 on sourcing decisions, managers must weigh the factors before committing to global team solutions. There might be unexpected costs and risks that override the anticipated savings. Illustrative Answers to 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? Answer: The key point here is that cost, quality, and time are the key elements for a project. Often projects seek to be low cost, high quality, and completed in a short time frame. But while important to a client, these objectives are often in conflict with each other. It is often impossible to be successful in the project if all three of these elements are inappropriately specified. For example, given a restrictive, low-cost budget, a goal of high quality (things like zero defects, high level of functionality, etc.) and short timeframe, a project is most likely set up for failure. On the other hand, it is possible to design a project where cost, quality, and time objectives are all met. If they are all very generous, it may be possible to achieve all three. A manager must be clear as to which of these objectives is of greatest importance to the client/project owner. After identifying the most important objective (getting it done quickly, staying within a restrictive budget, or producing high quality), a manager must then negotiate a reasonable level for the other objectives. For example, if time is the most important factor, is there a new budget that makes the quality level achievable? Or is there a reduced scope/lower quality that is acceptable that makes the restrictive budget achievable? 2. Why does it often take a long time before troubled projects are abandoned or brought under control? Answer: This is a very open-ended question. I believe troubled projects are slowly abandoned or brought under control because of the human nature to try to fix problems before abandoning them. People often think that if they just do one more thing or one thing differently, they will get it right and make their objectives. There is a reluctance to abandon a project after time and resources have been committed and spent. Additionally, people are hesitant to admit failure, making it difficult to honestly address the failing project objectively. 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? Answer: Critical success factors for a project manager are somewhat subjective. This chapter does not specifically list CSFs. The chapter covers “10 elements” of project management, and many students will list these as the critical success factors (the 10 are: requirements definition, organizing, project team management, planning, risk and opportunity management, project control, visibility, status management, corrective action, and leadership). The more astute students will take some subset of these and give explanations as to why they are the most critical. Managers should look for skills such as ability to get along with people, organization, knowledge of managing projects, ability to negotiate through seemingly contradictory customer/owner demands, budgeting, schedule and risk management capabilities, agility and flexibility to change as necessary to meet dynamic project conditions, and ability to see the big picture. Critical success factors for a project manager include strong leadership and communication skills, effective stakeholder management, strategic thinking, and the ability to manage resources and budgets efficiently. Additionally, project managers should possess excellent organizational and time management skills, as well as the ability to prioritize tasks and adapt to changing circumstances. They must demonstrate resilience, problem-solving capabilities, and a results-oriented mindset to navigate challenges and deliver successful outcomes. When hiring project managers, managers should look for candidates with relevant experience in project management, ideally in similar industries or domains. Candidates should also exhibit a collaborative and team-oriented approach, with a track record of building and leading high-performing teams. Moreover, managers should assess candidates' ability to influence and motivate others, as well as their capacity for decision-making and risk management. Finally, candidates should demonstrate a commitment to continuous learning and professional development, as project management requires staying updated on industry trends, best practices, and emerging technologies. 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? Answer: Technical risk is determined by how new the technology is to the world (is it mature or likely to have significant bugs?), how new it is to the organization (is there substantial experience in the organization with it or not?), and complexity (is it a simple technology or a very complex system?). Organizational risk is determined by similar factors: how new is the idea to the organization (do they have to make a big change or a small change from the current organization)? How complex is the change the organization must make (is it very complex or simple? How widespread must the change be to take place? Will it affect a single individual or group, or will it take place across the wider organization)? How adaptable is the organization to change (do people make change often or not)? And how much time is there to make the change (must people change immediately or is there time for education and communication)? A general manager can assist in minimizing these components by careful planning, alternative scenario planning, careful monitoring the progress of the project, and by continually assessing metrics which reflect these risk factors. 5. Lego’s Mindstorms Robotics Invention System. (See the text for the full situation) a. What are the advantages of Lego’s approach to open sourcing? b. What are the disadvantages of Lego’s approach to open sourcing? c. How should Lego manage the open-source movement? Answer: a. Lego’s customers are clearly excited about generating code and this excitement is translating into increased sales. Further, the robots are being programmed to perform additional tasks, thanks to open sourcing. b. This question is designed to help students consider the downside of open sourcing for Lego. Some of these negative effects may result in damaged robots that don’t live up to Lego’s reputation, difficulty in maintaining the code, difficulty in producing advanced versions of the robots, physical harm to customers from the programmed robots, etc. c. Have the students focus on some of the issues discussed in the chapter. Some examples are: preservation of intellectual property, maintaining open source code, setting standards, and offering tech support. a. The advantages of Lego's approach to open sourcing include fostering innovation and collaboration within the robotics community, allowing users to customize and enhance their robotic creations, and expanding the functionality and capabilities of the Mindstorms system through community contributions. Additionally, open sourcing encourages user engagement and loyalty, as enthusiasts feel a sense of ownership and investment in the platform, leading to increased brand loyalty and market penetration. b. However, there are also disadvantages to Lego's approach to open sourcing, including the potential loss of control over the development process and intellectual property concerns, as competitors may leverage open-source contributions to develop similar products without licensing fees or restrictions. Moreover, maintaining compatibility and consistency across diverse user-generated content can be challenging, leading to fragmentation and compatibility issues within the Mindstorms ecosystem. c. To effectively manage the open-source movement, Lego should establish clear guidelines and governance mechanisms for community contributions, balancing openness with the protection of proprietary technology and brand integrity. This may involve implementing licensing agreements, contributor agreements, and quality control processes to ensure that user-generated content aligns with Lego's standards and values. Additionally, Lego should actively engage with the community, soliciting feedback, and fostering a sense of community ownership and responsibility for the continued success and evolution of the Mindstorms platform. Further Discussion Questions 1. What experiences have you had with system changes either in the university setting or work environment? Was your opinion collected before the implementation, such as during the requirements gathering phase? Was your feedback sought post-implementation? Would it have made a difference in your acceptance/adoption of the new system? Answer: However, I'm aware that feedback collection before and after system implementation is crucial for ensuring successful adoption and user satisfaction. In many cases, stakeholders' opinions are sought during the requirements gathering phase to identify needs, preferences, and potential challenges. Post-implementation feedback allows organizations to assess user experiences, address issues, and make iterative improvements to enhance system usability and functionality. Effective feedback mechanisms can significantly influence users' acceptance and adoption of new systems by addressing concerns, improving user experience, and demonstrating responsiveness to user needs and preferences. 2. Re-read the opening case. List and discuss all of the problems you can identify that led to the failure of the RPA project. What would you have done differently? Be specific. Answer: The problems contributing to the failure of the RPA project include inadequate stakeholder engagement, lack of clear project objectives, insufficient training for staff, poor change management, ineffective communication, and overreliance on technology without addressing organizational culture. Additionally, unrealistic timelines, improper assessment of RPA's fit for the organization's needs, and insufficient scalability planning were evident. To prevent such failures, I would have conducted thorough stakeholder analysis, clearly defined project goals, provided comprehensive training programs, implemented robust change management strategies, fostered open communication channels, and ensured a gradual approach to implementation. Moreover, realistic timelines, thorough assessment of technology fit, and proactive scalability planning would have been prioritized. 3. Explain, in your own words, why it might not be helpful to add more team members to a project that is already behind schedule. Have you ever experienced something similar? Discuss your personal experiences on group projects. How might problems have been handled better? Answer: Adding more team members to a project already behind schedule can exacerbate the problem due to the need for onboarding and integration, which consumes time and resources. In my experience, I've seen this lead to confusion, duplication of effort, and a lack of clear accountability. It's crucial to assess whether additional members will genuinely accelerate progress or simply add to the chaos. Often, better communication and coordination among existing team members, along with realistic reassessment of timelines and priorities, can be more effective solutions. Clear delegation of tasks, regular progress tracking, and fostering a collaborative environment are essential to navigating challenges in group projects efficiently. 4. Create a framework of questions/items that you would ideally cover in your post-project feedback debrief. Ensure that the items do not focus on allocating blame, but create positive recommendations for future projects. Answer: 1. Overall Satisfaction: How satisfied were you with the project outcome and its alignment with expectations? 2. Project Communication: How effective was communication throughout the project lifecycle, including updates, milestones, and potential issues? 3. Collaboration: How well did different teams and stakeholders collaborate during the project? Were there any communication or coordination challenges? 4. Timeliness: Were project timelines and deadlines met satisfactorily? If not, what factors contributed to delays, and how could they be addressed in future projects? 5. Resource Allocation: Were resources (financial, human, technological) allocated effectively to support project objectives? Were there any resource constraints or bottlenecks? 6. Risk Management: How were risks identified, assessed, and mitigated during the project? Were there any unforeseen risks that emerged, and how were they addressed? 7. Change Management: How was change managed throughout the project, including scope changes, requirements adjustments, and stakeholder expectations? 8. Lessons Learned: What were the key lessons learned from this project experience? What worked well and should be replicated in future projects? 9. Continuous Improvement: What recommendations do you have for improving project management processes, tools, or methodologies for future projects? 10. Future Opportunities: Are there any additional insights, opportunities, or areas for exploration identified during the project that could be leveraged in future initiatives? Cases Case Study 11-1: Implementing Enterprise Change Management at Southern Company 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. Answer: The original system was apparently designed using the traditional systems development and project management plan, although little effort was made to involve the end-users in the design stage. This led to significant resistance later on. This project covered a rather long period of time (6 months spent designing the new processes, 10 months to customize the software suite, and 7 months to build the system). That might seem excessive in today’s mindset. Perhaps an agile development approach could have moved the project along more rapidly, with greater involvement of the end-users. Also, prototypes might have eliminated some of the issues that emerged in the implementation stage. 2. Describe how Traynor could have applied Lewin’s three stage model of change in implementing ECM. What would have been the advantages of applying Lewin’s three-stage model? Answer: The IT staff wasn’t included in the planning phase, as part of the “unfreeze” stage. The way they accomplish their normal tasks was being radically changed, so this consideration should have been communicated to the individuals most impacted by the change. That would lead to a smoother transition in the actual “change” stage. The implementation should have only taken place after the requirements and design activities were completed. The “refreeze” stage would include an institutional acceptance and adoption of the new processes in compliance with the new system. If Traynor had employed Lewin’s three stage model of change, he would have anticipated the problems in advance. This would have given all of the project stakeholders an opportunity to communicate concerns and reservations long before the actual design was in production. The IT staff would have developed buy-in for the new system, since their perspectives would be part of the solution. 3. Assess Southern’s ECM system on the four dimensions of project success. How successful do you think this project is? Answer: 1) Resource constraints – The project seems to be successful as far as keeping to the schedule. The project had a long timeline, and there isn’t mention of significant or excessive schedule breach. 2) Impact on customers – In the first phase of the ECM project, the customers (IT department) were not included in the planning and design. This led to a negative impact, and the changes were unwelcomed by the stakeholders. The second phase seems to be greatly improved, creating IT ambassadors who will be intimately involved in the testing and training activities. 3) Business success – Initially, the response was to implement additional change requests, compared to the previous system. Traynor created processes to help focus on only emergency or high-risk changes. Routine changes could be approved through a standard format and an efficient pre-approval process. The change advisory board was able to decrease the necessity of holding 3 meetings per week down to once a month. That is a vast improvement on time and resources. 4) Prepare the future – This was successful as demonstrated by the acceptance and efficiency demonstrated after the early glitches were worked out. Going forward, it appears that the project stakeholders will be more satisfied with the new system, particularly since they are actively engaged in the design and development of the second stage. Students might have different views on this question. Encourage them to support their perspectives with information from the text. Case Study 11-2: Dealing with Traffic Jams in London 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? Answer: The transportation project was very complex. There were many technological factors that the system developers needed to decide: what type of camera technology to use, the image store component that collected images and converted them into license numbers, the telecommunication links between the cameras and the image store, the customer service infrastructure, where to situate the cameras, and identifying an extensive network of retail outlets, kiosks, and gas stations where people could pay the toll. They also had to deal with a tight implementation timetable--there was no preexisting model to follow--and they were under a new transit authority. Not typically considered an aspect of technology, but certainly important to the success of the project were the hundred year old, convoluted streets. To handle the complexity, the project was outsourced to a team with the expertise to handle the complexity. An elaborate approach was taken to determine the expertise of the consultants by having the two finalists draw up a technical design that could be compared to one another. Further, a second firm (first PricewaterhouseCoopers and then Deloitte & Touche) was hired to handle the critical project management elements. To reduce the technical risks associated with complexity, the technologies selected for the five packages were the best available. Luckily, the project was of high clarity. The project team knew what they wanted, and this scope did not change frequently throughout the project. According to the article, they vigorously guarded against scope creep by limiting changes to the requirements. Few other management strategies were needed to deal with clarity. This was definitely a large project. They were going to be placing 699 cameras at 203 sites in an 8 square mile target for traffic congestion control. The estimated cost was $11.6 billion. It was also estimated that this project would likely translate into total revenues of $2.2 billion dollars within 10 years. To handle the risks from size, the project was subdivided into five parts. All parts were subject to strict project management controls. There were clear milestones with penalties for Capita if they did not meet the deadlines. 2. Describe the development methodology that was applied to this project. Was this the most appropriate approach? Provide a rationale for your response. Answer: Not much information was given about the methodology, so it is important to explore the student responses. On one hand, the development methodology applied to this project seemed to have been the Systems Development Life Cycle. First, an initial Feasibility Analysis was done, in order to determine what kind of solution was possible to implement. The result was the idea for the toll system. Secondly, Project Requirements were established in order to decide on an appropriate course of action. After all these requirements were identified, bids were entertained. After discarding most of the bids, two companies were left. These two companies were provided with the Functional requirements for the project, and both of them presented their Technical Designs for the implementation. One of the companies was selected, and another contractor was hired to revise and supervise their work. When they were ready, they Implemented the system. After the system was in place, they monitored the system for any Maintenance and correction needed. Some students may say that a RAD approach was used because of the rapidity with which the system was developed. Point out that RAD usually is associated with prototyping, as opposed to the production system that was implemented. Further, RAD usually relies upon various development tools that were not mentioned in this case. The development methodology applied to this project was Agile, characterized by iterative development, frequent collaboration, and adaptive planning. This approach emphasized flexibility, responsiveness to changing requirements, and continuous delivery of value to stakeholders. The Agile methodology was deemed appropriate for this project due to its ability to accommodate evolving needs, promote stakeholder engagement, and mitigate risks through incremental development and feedback loops. By breaking down the project into manageable increments or sprints, Agile facilitated early delivery of tangible results and enabled stakeholders to provide timely feedback, ensuring alignment with expectations and fostering a sense of ownership and involvement. Additionally, the Agile approach promoted transparency, accountability, and shared responsibility among team members, enhancing collaboration and driving continuous improvement throughout the project lifecycle. Overall, the Agile methodology proved effective in enabling the project team to adapt to evolving priorities, address emerging challenges, and deliver high-quality solutions in a timely and efficient manner. 3. When a project is outsourced, who should manage the project --- the internal group or the outsourcer? Why? Answer: The internal group should not abrogate all responsibility for the project. However, for very complex projects they may not have the expertise to manage the project. In this case, Transport of London hired a consultant (first Price water house Cooper and then Deloitte & Touche) to manage the project for them. Supplemental Cases ERP Implementation Gone Terribly Wrong: The Case of Natural Springs (2011) V. Krotov, S. Boukhonine, and B. Ives; Communications of the AIS, Vol 28, Issue 1, Article 18. Available at no cost from http://aisel.aisnet.org/cais/vol28/iss1/18 Natural Springs is a company in Russia that experiences major difficulties matching the capabilities of an ERP to the needs of the firm. It is a good illustration of what happens when the vendor’s offerings do not conform to local requirements, and when organizational players do not cooperate. Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation by Aubert, B.A., Bourdeau, S., & Walker, B. International Journal of Case Studies in Management. 2012. (29 pages) Describes the successful ERP implementation at Bombardier Limited, a company in the transportation industry. Students will learn more details about ERP systems and the difficulties inherent in implementing a large, complex system. The case explains how job roles were changed and business processes modified to improve efficiency. Organizational transformation resulted in significant benefits. Pearson’s Successmaker: Putting the Customer First in Transforming Product Development Processes by Raghu, T.S., & Sellman, C. Richard Ivey School of Business. 2012. (13 pages) Describes the move from waterfall to agile development processes in the creation of new products for the higher education instructional market. Students will develop an understanding of the complexities of collaborative work in a business setting, and the necessity of using complimentary processes. Red Hat Global Support Services: The Move to Relationship-based Customer Servicing and Knowledge-centered Support by Kesner, R.M. Richard Ivey School of Business. 2011. (19 pages) This case identifies changes and innovations in the customer service delivery at Red Hat. As the market influence has increased, the company has adjusted to the changes and transitioned to a firm that is more responsive to customer needs. Keda’s SAP Implementation (Ivey case W11024) (from Harvard’s library) (2011) T. Fung, Y. Fang, H. Wang, and D. Neufeld. Keda, a manufacturer of ceramics machinery in China, experiences a successful ERP project using SAP, but there are still some unmet opportunities. The case describes their process and allows students to assess the project’s success as well as recommend what could have been done better. Students will learn more details about ERP systems and the difficulties inherent in implementing a large, complex system. Volkswagen of America: Managing IT Priorities by Robert D. Austin, Warren Ritchie & Greggory Garrett. Harvard Business School Publishing. 2005. (19 pages) Describes the efforts of Volkswagen of America, the U.S. subsidiary of Volkswagen AG, to arrive at a process for setting IT funding priorities so that they align with business priorities and the company's overall strategy. This case might be quite interesting for students given the difficulties faced by VW in 2015. Offshoring at EDC by HW Lane & DTA Wesley. Richard Ivey School of Business 2005 (19 pages) Education Development Center (EDC), a non-governmental organization, is an example of an offshoring best practice and will help identify factors for successful implementation of an outsourcing project. The PCNet Project: (A) Project Risk Management in an IT Integration Project, by Christoph Loch. INSEAD. 2005 (20 pages) The case illustrates competent project risk management, including risk identification, assessment, and management. Network Implementation Project in the State Sector in Scotland: The Influence of Social and Organizational Factors, Ann McCready and Andrew Doswell, Idea Publishing Group, 15 pages, IT5506, (setting: International - Scotland) This case study is about the introduction of networked PCs in a local government office in Perth, Scotland. The case focuses on the importance of organizational and social factors during the implementation process. The Application of IT for Competitive Advantage at Keane, Inc., Mark R. Andrews and Raymond Papp, Idea Publishing Group, 19 pages, IT5509, (setting: International - Scotland) This case focuses on Keane Company’s approach to Project Management and how they provide this service to their clients. Managing the NICS Project at the Royal Canadian University, Charalambos L. Iacovou, Idea Publishing Group, 12 pages, IT5550, (setting: International - Canada) This case describes the installation of an IBM mainframe computer at the Royal Canadian University. The goal of the described project was to establish a Numerically Intensive Computing Service (NICS) in order to provide “first-class” computing facilities to the researchers. Systems Requirements and Prototyping, Vincent Yen, Idea Publishing Group, 14 pages, IT5559, (setting: U.S.) This case study is based on a multi-year information systems plan for a marketing firm. The case describes the critical components of the enterprise system, including the software and hardware architectures. Recognizing Runaway IS Projects When They Occur: The Bank Consortium Case, J. C. Mann, Idea Group Publishing, 8 pages, IT 5616, (setting: U.S.) The case study describes a runaway project that occurred when several savings and loans formed a consortium to create a data center that would develop and operate basic transaction processing software for its members. The case highlights practical issues related to how runaways develop. The T1-Auto Inc. Production Part Testing Process: A Workflow Automation Success Story, Charles Cain, Thomas W. Lauer and Eileen Peacock, Idea Publishing Group, 14 pages, IT5658, (setting: Australia) This case describes the development, design, and implementation of a workflow automation system at a tier one automotive supplier, T-1 Auto. In 1994, Lotus Notes was installed as the corporate standard e-mail and workflow platform. The case goes on to describe the design and development of the Lotus Notes workflow management system. The case concludes with a discussion of project success factors and planned future enhancements. A Dream Project Turns into a Nightmare: How Flawless Software Never Got Implemented, V. Roy and B.A. Aubert, Idea Group Publishing, 8 pages, IT 5660, (setting: Canada) This case details the experience of Integra, a large Canadian life insurance institution, and its partner Intex Consulting, the Canadian subsidiary of a large international information system (IS) integration firm’s launch of its Banking and Loan Insurance Software System (BLISS) development project. After 1.3 million dollars of investment from each partner and twelve months of intensive efforts, the project came to an abrupt stop. Specifically, this case looks at the ramifications of introducing a new and unproven IS product and how to avoid and recover from and IS project failure. Large-Scale Sustainable Information Systems Development in a Developing country: The Making of an Islamic Banking Package, Adekunle Okunoye, Idea Publishing Group, 16 pages, IT5680, (setting: International) This case study explores the difficulties encountered in technology transfer to developing countries, specifically examining a company offering IT services to an Islamic bank. The case highlights the circumstances that led to the bank’s decision to develop the systems locally. The case looks at the outsourcing decisions, project management issues, and systems development problems as they relate to developing countries’ successful IS projects. Colorado Benefits Management System: Decision Time Donald J. McCubbrey and Cynthia V. Fukami, Communications of AIS, Volume 16 Article 34 (setting: public agency, US) In a sense, this is a failure story where a decision must be made about whether the project should be continued or abandoned. Such stories are hard to come by from private firms since the PR people and the management will always try to bury the failure. Thus, this case, like many failure cases, comes out of the public sector where transparency is higher. Supplemental Readings/Articles Cecez-Kecmanovic, Dubravka, Karlheinz Kautz, and Rebecca Abrahall. "Reframing success and failure of information systems: a performative perspective." Mis Quarterly 38.2 (2014): 561-588. Jiang, James J., and Gary Klein. "Special Section: IT Project Management." Journal of Management Information Systems 31.1 (2014): 13-16. (Introduces the special issue on Project Management, with several articles of interest) Alaranta, Maria, and Lars Mathiassen. "Managing Risks: Post-Merger Integration of Information Systems." IT Professional 16.1 (2014): 30-40. Nelson, Ryan, and Michael G. Morris. "IT Project Estimation: Contemporary Practices and Management Guidelines." MIS Quarterly Executive 13.1 (2014): 15-30. Mehta, Nikhil, Dianne Hall, and Terry Byrd. "Information technology and knowledge in software development teams: The role of project uncertainty." Information & Management 51.4 (2014): 417-429. Lee, Jong Seok, et al. "The role of a bad news reporter in information technology project escalation: a deaf effect perspective." ACM SIGMIS Database 45.3 (2014): 8-29. Fichman, R.G., Keil, Mark, Amrit,T. “Beyond Valuation: "Options Thinking" in IT Project Management.” California Management Review, 2005. Iacovou, C.L. & Dexter, A.S. “Turning Around Runaway Information Technology Projects.” California Management Review, 2004. Lam, W. and Alton Chua. “Knowledge Management Project Abandonment: An Exploratory Examination of Root Causes.” Communications of AIS, 16(35) 2005.
This article studies the abandonment of Knowledge Management systems in Singapore. Lam and Chua use root cause analysis to identify the causes of KM project abandonment in five well-documented cases of KM drawn from the literature. AlMarzouq, M., Li Zheng, Guang Rong, Varun Grover, “Open Source: Concepts, Benefits, and Challenges.” Communications of AIS, 16 (37) 2005.
This article represents a tutorial on free and open source software F/OSS that tries objectively to identify and present open source software’s concepts, benefits, and challenges. It also describes approaches to benefiting from F/OSS. King, J. “Post-Y2K: Project management.” Computerworld, (January 18, 1999) http://www.computerworld.com/cwi/story/0,1199,NAV47_STO33557,00.html Now that year 2000 work is winding down at Clark Refining & Marketing in St. Louis, CIO Jeff Chasney finally has the time and money to start in on the backlog of IT projects that earlier were forced to the back burner. Melymuka, K. “Born to Lead Projects.” Computerworld, (March 27, 2000) http://www.computerworld.com/cwi/story/0,1199,NAV47_STO44218,00.html You can train somebody to be a good project manager, but great project managers seem to be born, not made. Excellence depends on certain innate characteristics: some of us got 'em, and some of us don't. "Project management requires competencies in three subject areas: technology, business, and behavior," says Linda Pittinger, CEO of People3, a human resources consultancy in Somerset, N.J. Ideally, project managers should have all three, she says, but if you had to choose only one to focus on, it should be behavior. "People can go to school to learn the technical things, and they can learn the business over time," she says. "The behavioral competencies are the ones people are least able to learn. They're intuitive." Agarwal, R. J. Prasad, M. Tanniru & J. Lynch. “Risks of rapid application development.” Communications of the ACM 43(11). 2000. Millman, H. “Project Management On the Lite Side.” Computerworld, (June 26, 2000), http://www.computerworld.com/cwi/story/0,1199,NAV47_STO46311,00.html Article about an entirely Web-based, free and independently hosted, project management tool called eProject. Barki, H. S. Rivard & J. Talbot. “An Integrative Contingency Model of Software Project Risk Management.” Journal of Management Information Systems, 17(4) 1999. This article builds a model of software project risk management based on a profile deviation perspective of fit between the project’s risk and how the project is managed. The model is tested with longitudinal data obtained from leaders of 75 software projects. Schmidt, R., K. Lyytinen, M. Keil and P. Cule. “Identifying Software Project Risks: An International Delphi Study.” Journal of Management Information Systems, 17(4) 1999. International Delphi study to obtain listing of project risks. Books Galliers, Robert D., and Dorothy E. Leidner. Strategic information management: challenges and strategies in managing information systems. Routledge, 2014. Yourdon, E. Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible” Projects. Upper Saddle River, NJ: Prentice Hall, 1997. This book discusses “doomed to fail” projects that developers get trapped into performing. Yourdon walks the reader through the project life cycle and shares insights on how to survive failing projects. Wysocki, R.K. Effective Project Management: Traditional, Adaptive, & Extreme. NY: John Wiley and Sons, 2003. Forsberg, K., H. Cotterman, & H. Mooz. Visualizing Project Management: A Model for Business and Technical Success. NY: John Wiley & Sons, 2000.
Rather than offering a full inventory of management techniques, they decompose them into 10 essential elements to provide an innovative approach to project management using a universal project cycle. Excellent graphic charts and 3D models help readers understand the project cycle, enabling them to visualize how each element fits into the overall project picture. A Guide to the Project Management Body of Knowledge, 3rd edition. Newton Square, PA: Project Management Institute, 2004. Often referred to as the PMBOK, this book describes a generic project management model, suitable across many disciplines. It is written to be a standard. While it is authoritative and something you should definitely read, it is tough reading for beginners. The book does not proceed in the same sequence as project phases. Available at Amazon.com and other bookstores, and from the PMI, www.pmi.org. McConnell, S.C. Software Project Survival Guide. Redmond, WA: Micrsoft, 1997. Provides a short overview of a successful software project and details a plan for software development for medium-sized client/server projects using such modern development practices as object-oriented design and programming. (Can also be adapted for projects using traditional development practices and mainframe computers.) Designed for commercial applications and business systems. Fleming, Q.W. and Joel M. Koppelman. Earned Value Project Management. Upper Darby, Pa.: Project Management Institute, 2000. Most project managers with formal project management training know earned value is what you get for what you spend. It's a three-dimensional “early warning'' signal for management. Instead of the conventional actual cost vs. budget comparisons, it includes the dimension of relating the project's scope to the schedule and to the cost performance. It's the “budgeted cost of work performed,'' known affectionately as BCWP. Gilbert, S. 90 Days to Launch: Internet Projects on Time and on Budget. NY: John Wiley & Sons, 2000.
The first in its genre, 90 Days to Launch shows business managers and decision makers how to plan and deliver successful Internet projects, giving step-by-step instructions that will enable a company to efficiently launch a site. Ferry, D.D. & N.F. Ferry. 77 Sure-Fire Ways to Kill a Software Project: Destructive Tactics That Cause Budget Overruns, Late Deliveries, and Massive Personnel Turnover. iUniverse.com. 2000.
This book is a lighthearted, black sheep guide to managing software projects. Do you really believe that a spiffy SEI rating or the latest software engineering fad will save someone from working long nights, missing deadlines, or having a nervous breakdown? We've got news: the project didn't get that way by accident. It took a lot of careful planning, and this book will describe how things get out of hand for projects. A fun read. Websites www.pmi.org The website for the project management institute. This is a great resource for this topic. The website is for general projects, but they have the latest research, publications, communities of practice, etc. on project management. You can also get the Project Management Body of Knowledge book at this site, and it used to be a free .pdf file (or you can buy the book from them or Amazon.com). www.4pm.com/ A website for project managers, with a lot of good references for the general project manager and a whole sub-website on managing IT projects. www.ipma.ch/ A United Kingdom based project management website for international perspective on project management. Has some good information for "young project managers." http://www.gnu.org/philosophy/free-sw.html Free software definition News October 28, 2015: IEEE Spectrum has listed several failed project "gravestones" and describes each at http://spectrum.ieee.org/static/monuments-to-failure. Have students pull up that site and examine the very short description, then ask them to click on any two of the gravestones then their headlines, then ask them to determine the reason for the two failures on which they drilled down. Ask the following for an in-class discussion: (1) Does the author indicate that in 2015, things have changed from previous years? (2) What are the reasons for the failures offered by the author in the short introduction? (3) Do the reasons for the two projects you investigated further seem to agree with the reasons provided by the author? March 9, 2015: A blog about Microsoft's process for developing Windows 10 provides an interesting "ring" approach to testing. The inner ring gets daily builds. When a particular build passes the inner "Canary" ring's tests, it is then passed to the next ring, OSG. Then it moves on to the "Microsoft" ring. Once it passes that ring, it moves to the "fast" then the "slow" ring. Ask students to read http://blogs.windows.com/bloggingwindows/2015/03/09/frequency-and-predictability-of-builds-for-windows-insiders/ and answer the following: (1) What do you think of the "ring" structure? Why? (2) What is the role of expectations with regards to promised deadlines? What is the lesson about setting promised deadlines? (3) What are they intending to do about their pace in future builds? (4) What do you think of a potential "ludicrous" speed ring? March 11, 2015: Bart Perkins published an article in Computerworld about a huge project failure at the Department of Labor in the US Government. Have students read the article at http://www.computerworld.com/article/2895066/lessons-to-be-learned-from-a-project-nightmare.html and answer the following: (1) What are the five general lessons from the disaster? (2) Regarding low bids, what should a CIO do when faced with a very low bid? (3) What should a firm do to monitor progress of a project? (4) What is the amount of a likely new bid to be nearly 10 times the previous firm's bid? [This can help fuel a discussion of how an expanded scope can have serious consequences on costs]. Solution Manual for Managing and Using Information Systems: A Strategic Approach Keri E. Pearlson, Carol S. Saunders, Dennis F. Galletta 9781119244288, 9781118281734
