1. IS 425 Enterprise Information LECTURE 7 Winter 2006-2007

2. 2 Agenda IT Project Management The Flamholtz Leadership Effectiveness Framework IT Project Risk Management Quiz for Week 9 Week 10: Guest Speaker and 1 st Debate

3. 3 Projects Definition: an organized method for reaching specific goals and planned benefits within a target schedule and defined budget. Project Management: The organized method Specific goals: These are the business, organizational, technological, physical, cultural, and political goals of the project. Planned benefits: Benefits can be financial, political, organizational, cultural, or any of many categories. Target schedule: One aim of the project management approach. Defined budget: Another aim of the project management approach.

4. 4 Organizations Traditional Functional IT Organization Line Perform jobs directly related to the core activities Operations oriented Stable for people in the organization Vertical communication channels already in place Existing budgeting and cost accounting mechanisms Better technical control -- rare resources can be shared Great at handling routine and recurring tasks Horizontal communication between managers Organized around resources Traditional IT development

5. 5 Traditional IT Applications “GL” Analysis IS Applications Mgr Analyst Mgr Programming Mgr “PR” Analysis “GL” Programming “PR” Programming Department handles Application Development and Maintenance The Payroll mgr has a problem with the way the system is calculating California withholding tax in the new system – Tell me how she would get this handled

6. 6 Traditional IT Applications “GL” Analysis IS Applications Mgr Analyst Mgr Programming Mgr “PR” Analysis “GL” Programming “PR” Programming Department handles Application Development and Maintenance What are the goals of the Analyst Manager? What are the goals of the Programming Manager? The IS Applications Manager?

7. 7 Traditional IT Applications “GL” Analysis IS Applications Mgr Analyst Mgr Programming Mgr “PR” Analysis “GL” Programming “PR” Programming Department handles Application Development and Maintenance Who is responsible for the GL application? Who is responsible for the PR application? Who is responsible for coordination between GL analysts and GL programmers?

8. 8 The Failure of Line Lack of Focus and Attention Who keeps track of “GL” and “PR” Normal Maintenance is usually 60% of budget Development projects not part of the department goals

9. 9 The Failure of Line Inability to Cope with Different Project Characteristics Often development projects using new platforms/technologies Projects “GL” and “PR” require constant attention Analyst and Programming Managers are mostly interested in meeting goals aimed at efficient use of resources

10. 10 The Failure of Line continued Feelings of Being Used and Exploited Often no new people are added for “GL” or “PR” Both “GL” and “PR” are “tack-on’s” Rewards are rarely tied to project’s success Lack of project experience Programming and Analyst manager are focused on deploying their resources efficiently Neither is focused on making sure project is done on time and within budget.

11. 11 Then Came Matrix Management A table of rows and columns The line departments are the rows The projects are the columns with one for the “bench” People are in a row and when assigned to project move to that column within the row Two bosses – line manager and project manager Government contractors and S/W developers often use matrix organization – projects are big part of business

12. 12 Matrix Management Advantages Good for projects oriented firms People on projects utilized Project mgt powerful at getting resources People develop skills while moving between projects Provides formal structure to projects Can track what people are working on in projects Disadvantages Good grabbed/others not Assigning control difficult Line mgrs tend to be weak Projects with long lives confused with line mgt Sharing resources difficult More difficult for skills to cross projects Project prospers and traditional org suffers More difficult to anticipate resource needs/staff requirements More difficult to address small projects

13. 13 Matrix Modification Use the Matrix with large projects Each project is an entity for duration with project manager Use the Functional for all small projects One functional manager with all reporting to same line manager

14. 14 Project Management vs Line Management ProjectLine FocusPjt: single focusOrg: multiple foci Time Focus Short termShort to Long AttitudeFocus on projectOverall org perf PersonnelClose working relationship Overall mgt BudgetProjectOrganization DriversMilestonesGeneral objectives

15. 15 Project Environment/Infrastructure Formalizes Project Recognition The process exists for Project: Creation Oversight Management Termination Modification

16. 16 Project Environment/Infrastructure Project Tier Structure (5 tiers max) Simple (Intra-departmental) IOIS Inter-Organizational Information Systems Enterprise-wide Process-wide Inter-departmental Transition Process Necessary – Between Tiers Changing Project Plans Adjusting Resources Reexamining Control Mechanisms

17. 17 Projects – Scarce Resources Types: Human Hardware/Software Capital Information Resource Portfolio Management Line managers m/assign resources to projects No resources permanently assigned (specifying time frame)

18. 18 Project Manager 3 Management Responsibilities Resource Manager manages & directs project resources to achieve project objectives Planning/Control Manager develops project plan to ensure the work is completed on time / within budget / with acceptable quality Coordinating Manager interfaces with upper management regarding: project reviews approvals project issues

19. 19 Project Manager Directs activities and resources Motivates team Plans activities Supervises team’s work Administers tasks Interfaces and Coordinates through meetings Does some tasks Trains members Counsels management on technical issues Delegates work Resolves conflicts over resources and schedules

20. 20 Power Sources for Project Managers Formal Authority -- weakest form of power – can only be used effectively Rewards/Penalties -- few tangible rewards and penalties Technical Authority -- somewhat rare, too many technical areas Respect / Trust -- leads to leadership -- best and most lasting form of power

21. 21 Team Characteristics Work on shared tasks Some tasks require milestones Share common – Methods Tasks Goals Results Sink or Swim together

22. 22 Leadership Definition: process of influencing members of an organization to achieve established long term and short term goals on a day-to-day basis. Leadership Behavior What someone actually does to influence people to carry out the organizational goals

23. 23 Flamholtz Leadership Effectiveness F/W The situation in which the leader is operating The work that the group is doing The nature of the people doing the work The leader performs tasks relating to the Goals Work tasks Team interactions Feedback Member career development The style in which work is done

24. 24 Flamholtz Leadership Effectiveness F/W

25. 25 The Leadership Styles and Categories

26. 26 Factors Affecting Optimal Leadership Style

27. 27 Flamholtz Leadership Effectiveness F/W To use the framework Look at the situation Is the work creative and unpredictable –or – Is it repetitive and best practices are easily documented? Are the people highly trained and experienced – or – are the people inexperienced and untrained? Determine the appropriate style Perform the task in that style

28. 28 Project Manager Types Administrator – people skills poor -- written skills good Doer – no delegation Upward-Oriented – delegates but does not monitor Task Master – monitors excessively Leader -- the BEST!!! – monitors – delegates -- people skills good

29. 29 Some Concluding Thoughts When researchers went out to look at effective leaders — There are NO common traits Charisma is the least effective form of governance – why? Trust is the most important – easiest to loose -- hardest to rebuild Why?

30. 30 Exercise Each team is given Leadership Effectiveness tasks For each task: Give one example of the wording of the task in: Directive Style and who is the appropriate audience Interactive Style and who is the appropriate audience Nondirective Style and who is the appropriate audience

31. 31 IT Project Management Need to consider both the project life cycle (PLC) and the systems development life cycle (SDLC) PLC: activities of the project SDLC: activities to accomplish the product/system requirements

32. 32 Typical IT Project Life Cycle

33. 33 PLC Phases SDLC Phases The Project and System Development Life Cycles and Activities

34. 34

35. 35

36. 36 Trade-Off Analysis Process

37. 37 Project Risk Management Definition The process in which potential risks to a business are identified, analyzed and mitigated, along with the process of balancing the cost of protecting the company against a risk vs. the cost of exposure to that risk. Or, "What imperils getting benefits from effort?"

38. 38 Purpose of Project Risk Management Continuous & Iterative process

39. 39 Tightly integrated with the Project management process

40. 40 Propensity for Risk

41. 41 Risk Impact

42. 42 General Categories of Risks: Economic Risks Technical Risks Organizational Risks Legal Risks Terrorist Risks

43. 43 General Categories of Risks: Economic Risks applies to risks that can potentially impact the business. These risks could result to failure or loss of business. business environment changes vendor survival

44. 44 General Categories of Risks: Technical Risks applies to the risks that can impact the development, implementation, and the operation of a system. Sources of these risks can come from the project team’s degree of familiarity with the technology, familiarity with the application, security and project size. integrating technology with existing portfolio poor training poor monitor/control

45. 45 General Categories of Risks: Organizational Risks applies to the risks that could potentially impact the acceptance of the project. Problems arise when there is potential reduction of manpower, changing the way business process is performed, and when there is increase of workload. Consequences to these risks are defined below: resistance to the system low morale of personnel lack of political support possible rejection of the system poor procedures lack of trained support lack of trainers ineffective use by users poor help desk

46. 46 General Categories of Risks: Legal Risks applies to risks arising from potential lawsuits and liabilities associated with the implementation of a project. fiduciary responsibility of managers laws and regulations inappropriately administered personal financial and criminal liability (from shareholder lawsuits and FCPA)

47. 47 General Categories of Risks: Terrorist Risks applies to risks arising from intentional destruction or malevolent modification of the physical equipment data and information files communication links software

48. 48 Sources of Project Risks Project Work – quality and completeness of the work Project Team and Leader – personality issues allocation of resources trust issues Management – poor or no decision making lack of attention Business Situation -- assumptions change -- conditions change

49. 49 Sources of Project Risks Other Projects -- Changes in priorities External Factors -- regulatory changes, -- union pressures, -- consumer groups -- various special interest groups Technology -- changes that can make project irrelevant

50. 50 Sources of Project Risks Vendors and Contractors -- reliability -- quality -- sustainability Business Processes -- reengineering changes power bases Business Units -- management changes -- organization changes -- staffing changing Customers and Suppliers -- changes in mix

51. 51 Risk Management Process & Purposes 1. Risk management planning 2. Risk identification 3. Qualitative risk analysis 4. Quantitative risk analysis 5. Risk response planning 6. Risk monitoring and control

52. 52 Keeping Track of Risks ProjectsEconomicTechnicalOrganizational Keep a count of the OPEN RISKS by type for each project – Update regularly Keep track of your progress in mitigating / resolving risks REMEMBER – MANY RISKS WILL COME TOWARDS THE END OF THE PROJECT – SO THINK / PLAN AHEAD

53. 53 Preferred Project Risk Strategy Method Group issues by Impact if not solved Time pressure to do something Use your judgment and experience on positioning issues

54. 54 Issues to be Addressed Issues 23 and 27 must be addressed Issue 10 has time pressure so investigate

55. 55 Time Marches on Some issues go away Some issues emerge Some get more troublesome

56. 56 Risk Issue Management Process 1. Create project risk issue database 200+ commonly known problems 2. Identify 20-30 most likely based on experience 3. Present potential issues to management with project proposal 4. In estimating project tasks – more issues may emerge 5. All issues relate to tasks – if not find the missing tasks

57. 57 Risk Issue Management Process 6. Phase beginning -- team meetings on near term issues -- discuss impact of issues -- track the issues -- develop issues resolution table -- use 1-page project summary to Mgt. 7. Create table of issues versus projects Create GANTT chart (major tasks / issues) -- follow-up on resolved issues (no reappearance) -- implement actions when known or appropriate 8. When resolved -- celebrate

58. 58 Management Communications Focus on informal communications with management on risk issues Focus on getting management slowly on board with knowledge of problem growing Then on presenting alternatives Then on getting approval for actions

59. 59 Project Risk Portfolio Approach Same issues database for all major projects Common issues reporting method Periodically prepare new table of issues versus projects Support / facilitate Meetings Analysis on issues When issue resolved -- take the decisions, then -- identify action items for each impacted project -- follow up on action items across project -- report to management

60. 60 NEXT WEEK Quiz/Homework