1. © 2004-05, David Gadish, Ph.D.1 Project Management CIS 486 Fall 2005 Week 2 Lecture Dr. David Gadish

2. © 2004-05, David Gadish, Ph.D.2 Week 1 Review  My background  Course outline  Teaching philosophy, expectations  Course structure  Student survey  Student introduction

3. © 2004-05, David Gadish, Ph.D.3 Week 1 Review  Information Technology in the Digital Economy (Ch-1)  The Harvard Case Studies –Team selection and assignment of cases

4. © 2004-05, David Gadish, Ph.D.4 Week 2 Overview  Student Introductions  The Project Management and Information Technology Context (Ch-2)  The Project Management Process Groups (Ch-3)

5. © 2004-05, David Gadish, Ph.D.5 Student Introductions  Your name  What you do?  How do you currently use technology?  What do you want to do?  Technology impacts on your future plans?

6. 6 The Project Management and Information Technology Context Chapter 2

7. © 2004-05, David Gadish, Ph.D.7 Learning Objectives  Understand the systems view of project management and how it applies to information technology projects  Analyze a formal organization using the structural, human resources, political, and symbolic organizational frames  Explain the differences among functional, matrix, and project organizational structures  Explain why stakeholder management and top management commitment are critical for a project’s success

8. © 2004-05, David Gadish, Ph.D.8 Learning Objectives  Understand the concept, development, implementation, and close-out phases of the project life cycle  Distinguish between project development and product development  Discuss the unique attributes and diverse nature of information technology projects  List the skills and attributes of a good project manager in general and in the information technology field

9. © 2004-05, David Gadish, Ph.D.9 Projects Cannot Be Run in Isolation  Projects must operate in a broad organizational environment  Project managers need to take a holistic or systems view of a project and understand how it is situated within the larger organization

10. © 2004-05, David Gadish, Ph.D.10 A Systems View of Project Management  A systems approach emerged in the 1950s to describe a more analytical approach to management and problem solving  Three parts include: –Systems philosophy: View things as systems, interacting components working within an environment to fulfill some purpose –Systems analysis: problem-solving approach –Systems management: Address business, technological, and organizational issues before making changes to systems

11. © 2004-05, David Gadish, Ph.D.11 Three Sphere Model for Systems Management

12. © 2004-05, David Gadish, Ph.D.12 Understanding Organizations Structural frame: Focuses on roles and responsibilities, coordination and control. Organizational charts help define this frame. Human resources frame: Focuses on providing harmony between needs of the organization and needs of people. Political frame: Assumes organizations are coalitions composed of varied individuals and interest groups. Conflict and power are key issues. Symbolic frame: Focuses on symbols and meanings related to events. Culture is important.

13. © 2004-05, David Gadish, Ph.D.13 What Went Wrong?  Many enterprise resource planning (ERP) projects fail due to organizational issues.  For example, Sobey’s Canadian grocery store chain abandoned its two-year, $90 million ERP system due to organizational problems.  Sobey’s ERP system shut down for five days and employees were scrambling to stock potentially empty shelves in several stores for weeks.  The system failure cost Sobey’s more than $90 million and caused shareholders to take an 82-cent after-tax hit per share.*

14. © 2004-05, David Gadish, Ph.D.14 Many Organizations Focus on the Structural Frame  Most people understand what organizational charts are  Many new managers try to change organizational structure when other changes are needed  3 basic organizational structures –functional –project –matrix

15. © 2004-05, David Gadish, Ph.D.15 Basic Organizational Structures

16. © 2004-05, David Gadish, Ph.D.16 Organizational Structure Influences on Projects The organizational structure influences the project manager’s authority.

17. © 2004-05, David Gadish, Ph.D.17 Recognize the Importance of Project Stakeholders  Project stakeholders are the people involved in or affected by project activities  Project managers must take time to: –Identify –Understand –Manage relationships with all project stakeholders  Using the four frames of organizations can help meet stakeholder needs and expectations  Senior executives are very important stakeholders

18. © 2004-05, David Gadish, Ph.D.18 What Helps Projects Succeed?  The following items help IT projects succeed, in order of importance: –Executive support –User involvement –Experienced project manager –Clear business objectives –Minimized scope –Standard software infrastructure –Firm basic requirements –Formal methodology –Reliable estimates

19. © 2004-05, David Gadish, Ph.D.19 Need for Top Management Commitment  Top management can help project managers: –Secure adequate resources –Get approval for unique project needs in a timely manner –Receive cooperation from people throughout the organization –Learn how to be better leaders

20. © 2004-05, David Gadish, Ph.D.20 Need for Organizational Commitment to Information Technology (IT)  If the organization has a negative attitude toward IT, it will be difficult for an IT project to succeed  Having a Chief Information Officer (CIO) at a high level in the organization helps IT projects  Assigning non-IT people to IT projects also encourages more commitment

21. © 2004-05, David Gadish, Ph.D.21 Need for Organizational Standards  Standards and guidelines help project managers be more effective  Senior management can encourage –the use of standard forms and software for project management –the development and use of guidelines for writing project plans or providing status information –the creation of a project management office or center of excellence

22. © 2004-05, David Gadish, Ph.D.22 Project Phases and the Project Life Cycle  A project life cycle is a collection of project phases  Project phases vary by project or industry, but some general phases include –concept –development –implementation –support

23. © 2004-05, David Gadish, Ph.D.23 Phases of the Project Life Cycle

24. © 2004-05, David Gadish, Ph.D.24 Product Life Cycles  Products also have life cycles  The Systems Development Life Cycle (SDLC) is a framework for describing the phases involved in developing and maintaining information systems  Systems development projects can follow –predictive models: the scope of the project can be clearly articulated and the schedule and cost can be predicted –adaptive models: projects are mission driven and component based, using time-based cycles to meet target dates

25. © 2004-05, David Gadish, Ph.D.25 Predictive Life Cycle Models  The waterfall model has well-defined, linear stages of systems development and support  The spiral model shows that software is developed using an iterative or spiral approach rather than a linear approach  The incremental release model provides for progressive development of operational software  The prototyping model is used for developing prototypes to clarify user requirements  The RAD model is used to produce systems quickly without sacrificing quality

26. © 2004-05, David Gadish, Ph.D.26 Adaptive Life Cycle Models  Extreme Programming (XP): Developers program in pairs and must write the tests for their own code. XP teams include developers, managers, and users  Scrum: Repetitions of iterative development are referred to as sprints, which normally last thirty days. Teams often meet every day for a short meeting, called a scrum, to decide what to accomplish that day. Works best for object- oriented technology projects and requires strong leadership to coordinate the work

27. © 2004-05, David Gadish, Ph.D.27 Distinguishing Project Life Cycles and Product Life Cycles  The project life cycle applies to all projects, regardless of the products being produced  Product life cycle models vary considerably based on the nature of the product  Most large IT systems are developed as a series of projects  Project management is done in all of the product life cycle phases

28. © 2004-05, David Gadish, Ph.D.28 Why Have Project Phases and Management Reviews?  A project should successfully pass through each of the project phases in order to continue on to the next  Management reviews (also called phase exits or kill points) should occur after each phase to evaluate the project’s progress, likely success, and continued compatibility with organizational goals

29. © 2004-05, David Gadish, Ph.D.29 The Context of IT Projects  IT projects can be very diverse in terms of size, complexity, products produced, application area, and resource requirements  IT project team members often have diverse backgrounds and skill sets  IT projects use diverse technologies that change rapidly. –Even within one technology area, people must be highly specialized

30. © 2004-05, David Gadish, Ph.D.30  Define scope of project  Identify stakeholders, decision-makers, and escalation procedures  Develop detailed task list (work breakdown structures)  Estimate time requirements  Develop initial project management flow chart  Identify required resources and budget  Evaluate project requirements  Identify and evaluate risks  Prepare contingency plan  Identify interdependencies  Identify and track critical milestones  Participate in project phase review  Secure needed resources  Manage the change control process  Report project status Fifteen Project Management Job Functions

31. © 2004-05, David Gadish, Ph.D.31 Suggested Skills for Project Managers  Project managers need a wide variety of skills  Comfortable with change  Understand the organizations they work in and with  Be able to lead teams to accomplish project goals

32. © 2004-05, David Gadish, Ph.D.32 Suggested Skills for Project Managers  Project managers need both “hard” and “soft” skills.  Hard skills include product knowledge and knowing how to use various project management tools and techniques  Soft skills include being able to work with various types of people

33. © 2004-05, David Gadish, Ph.D.33 Suggested Skills for a Project Manager  Communication skills: listening, persuading  Organizational skills: planning, goal- setting, analyzing  Team Building skills: empathy, motivation

34. © 2004-05, David Gadish, Ph.D.34 Suggested Skills for a Project Manager  Leadership skills: set examples, be energetic, have vision (big picture), delegate, be positive  Coping skills: flexibility, creativity, patience, persistence  Technological skills: experience, project knowledge

35. © 2004-05, David Gadish, Ph.D.35 Most Significant Characteristics of Effective and Ineffective Project Managers  Lead by example  Are visionaries  Are technically competent  Are decisive  Are good communicators  Are good motivators  Stand up to upper management when necessary  Support team members  Encourage new ideas  Set bad examples  Are not self-assured  Lack technical expertise  Are poor communicators  Are poor motivators Effective Project Managers Ineffective Project Managers

36. 36 The Project Management Process Groups: A Case Study Chapter 3

37. © 2004-05, David Gadish, Ph.D.37 Learning Objectives  Describe the five project management process groups, the typical level of activity for each, and the interactions among them  Understand how the project management process groups relate to the project management knowledge areas  Discuss how organizations develop project management methodologies to meet their needs

38. © 2004-05, David Gadish, Ph.D.38 Learning Objectives  Review a case study of an organization applying the project management process groups to manage an information technology project  Understand the contribution that effective project initiation, project planning, project execution, project control, and project closing makes to project success

39. © 2004-05, David Gadish, Ph.D.39 Project Management Process Groups  Project management can be viewed as a number of interlinked processes  The project management process groups include –initiating processes –planning processes –executing processes –controlling processes –closing processes

40. © 2004-05, David Gadish, Ph.D.40 Overlap of Process Groups in a Phase

41. © 2004-05, David Gadish, Ph.D.41 Relationships Among Process Groups and Knowledge Areas

42. © 2004-05, David Gadish, Ph.D.42 Relationships Among Process Groups and Knowledge Areas

43. © 2004-05, David Gadish, Ph.D.43 Developing an IT Project Management Methodology  Just as projects are unique, so are approaches to project management  Many organizations develop their own project management methodologies, especially for IT projects  Blue Cross Blue Shield of Michigan used the PMBOK as a guide in developing their IT project management methodology

44. © 2004-05, David Gadish, Ph.D.44 ITPM Methodology (Fig 3.2)

45. © 2004-05, David Gadish, Ph.D.45 Case Study: JWD Consulting’s Project Management Intranet Site  This case study provides an example of what’s involved in initiating, planning, executing, controlling, and closing an IT project  You can download templates for creating your own project management documents from the companion Web site for the book  Note: This case study provides a big picture view of managing a project. Later chapters provide detailed information on each knowledge area.

46. © 2004-05, David Gadish, Ph.D.46 Project Initiation  Initiating a project includes recognizing and starting a new project or project phase  Some organizations use a pre-initiation phase, while others include items like developing a business case as part of initiation  The main goal is to formally select and start off projects  Key outputs include: –Assigning the project manager –Identifying key stakeholders –Completing a business case –Completing a project charter and getting signatures on it

47. © 2004-05, David Gadish, Ph.D.47 Project Initiation Documents  Business case: See pages 74-76  Charter: See pages 77-78, also shown on next two slides  Note: Every organization has its own variations of what documents are required for project initiation.

48. © 2004-05, David Gadish, Ph.D.48 Project Initiation Documents  It’s important to identify: –The need for projects –Who the stakeholders are –What the main goals are for the project

49. © 2004-05, David Gadish, Ph.D.49 JWD’s Project Charter

50. © 2004-05, David Gadish, Ph.D.50 JWD’s Project Charter

51. © 2004-05, David Gadish, Ph.D.51 Project Planning  The main purpose of project planning is to guide execution  Every knowledge area includes planning information (see Table 3-5 on pages 79-80)

52. © 2004-05, David Gadish, Ph.D.52 Project Planning  Key outputs include: –A team contract –A scope statement –A work breakdown structure (WBS) –A project schedule, in the form of a Gantt chart with all dependencies and resources entered –A list of prioritized risks  See sample documents on pages 83-90, and refer to them later in the course

53. © 2004-05, David Gadish, Ph.D.53 JWD’s Project Gantt Chart

54. © 2004-05, David Gadish, Ph.D.54 JWD’s List of Prioritized Risks

55. © 2004-05, David Gadish, Ph.D.55 Project Executing  It usually takes the most time and resources to perform project execution since the products of the project are produced here  The most important output of execution is work results  Project managers must use their leadership skills to handle the many challenges that occur during project execution

56. © 2004-05, David Gadish, Ph.D.56 Project Controlling  Controlling involves measuring progress toward project objectives, monitoring deviation from the plan, and taking corrective actions  Controlling affects all other process groups and occurs during all phases of the project life cycle  Status and progress reports are important outputs of controlling

57. © 2004-05, David Gadish, Ph.D.57 Project Closing  The closing process involves gaining stakeholder and customer acceptance of the final product and bringing the project, or project phase, to an orderly end  Even if projects are not completed, they should be closed out to learn from the past  Project archives and lessons learned are important outputs. Most projects include a final report and presentations

58. © 2004-05, David Gadish, Ph.D.58 Post-Project Follow-up  Many organizations have realized that it’s important to review the results of projects a year or so after they have been completed  Many projects promise potential savings, so it’s important to review the financial estimates and help learn from the past in preparing new estimates

59. © 2004-05, David Gadish, Ph.D.59 Questions?

60. © 2004-05, David Gadish, Ph.D.60 Next Week’s Agenda  Project Integration Management (Ch 4)  Project Scope Management (Ch 5)