IS 425 Enterprise Information LECTURE 7 Winter 2006-2007.

IS 425

Enterprise Information LECTURE 7

Winter 2006-2007

2

Agenda IT Project Management The Flamholtz Leadership Effectiveness

Framework IT Project Risk Management Quiz for Week 9 Week 10: Guest Speaker and 1st Debate

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

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

Traditional IT Applications

“GL”Analysis

IS ApplicationsMgr

AnalystMgr

ProgrammingMgr

“PR”

Analysis

“GL”Programming

“PR” Programming

Department handlesApplication Development and Maintenance

The Payroll mgrhas a problem with theway the system is calculating Californiawithholding tax in the new system –Tell me how she would get this handled

6


“GL”Analysis

IS ApplicationsMgr

AnalystMgr

ProgrammingMgr

“PR”

Analysis

“GL”Programming



What are the goals of the Analyst Manager? What are the goals of the Programming Manager? The IS Applications Manager?

7


“GL”Analysis

IS ApplicationsMgr

AnalystMgr

ProgrammingMgr

“PR”

Analysis

“GL”Programming



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

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

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

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

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

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

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

Project Management vs Line Management

Project Line

Focus Pjt: single focus Org: multiple foci

Time Focus

Short term Short to Long

Attitude Focus on project Overall org perf

Personnel Close working relationship

Overall mgt

Budget Project Organization

Drivers Milestones General objectives

15

Project Environment/Infrastructure

Formalizes Project Recognition The process exists for Project:

Creation Oversight Management Termination Modification

16

Project Environment/Infrastructure

Project Tier Structure (5 tiers max)

Simple(Intra-departmental)

IOISInter-OrganizationalInformation Systems

Enterprise-wide

Process-wide

Inter-departmental

Transition Process Necessary – Between Tiers Changing Project Plans Adjusting Resources Reexamining Control Mechanisms

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

Project Manager

3 Management Responsibilities Resource Manager

manages & directs project resources to achieve project objectives

Planning/Control Managerdevelops project plan to ensure the work is completed on time / within budget / with acceptable quality

Coordinating Managerinterfaces with upper management regarding: project reviews approvals project issues

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

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

Team Characteristics

Work on shared tasks Some tasks require milestones Share common –

Methods Tasks Goals Results

Sink or Swim together

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 BehaviorWhat someone actually does to influence people to

carry out the organizational goals

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


25

The Leadership Styles and Categories

26

Factors Affecting Optimal Leadership Style

27


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

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

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

Exercise

Each team is given Leadership Effectivenesstasks

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

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

Typical IT Project Life Cycle

33

PLCPhases

SDLCPhases

The Project and System Development Life Cycles and Activities

34

35

36

Trade-Off Analysis Process

37

Project Risk ManagementDefinition

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

Purpose of Project Risk Management

Continuous &Iterative process

39

Tightly integrated with the Project management process

40

Propensity for Risk

41

Risk Impact

42

General Categories of Risks:

Economic Risks

Technical Risks

Organizational Risks

Legal Risks

Terrorist Risks

43


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


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


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


Legal Risksapplies 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


Terrorist Risks

applies to risks arising from intentional destruction or malevolent modification of the physical equipment data and information files communication links software

48

Sources of Project Risks

Project Work – quality and completeness of the work

Project Team and Leader – personality issuesallocation of resourcestrust issues

Management – poor or no decision makinglack of attention

Business Situation -- assumptions change-- conditions change

49


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


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

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

Keeping Track of Risks

Projects Economic Technical Organizational

Keep a count of the OPEN RISKS by type for each project –Update regularly

Keep track of your progress in mitigating / resolving risksREMEMBER – MANY RISKS WILL COME TOWARDS THE END OF THE PROJECT – SO THINK / PLAN AHEAD

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

Issues to be Addressed

Issues 23 and 27 must be addressed Issue 10 has time pressure so investigate

55

Time Marches on

Some issues go away Some issues emerge Some get more troublesome

56

Risk Issue Management Process

1. Create project risk issue database200+ 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

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 projectsCreate GANTT chart (major tasks / issues)-- follow-up on resolved issues (no reappearance)-- implement actions when known or appropriate

8. When resolved -- celebrate

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

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

NEXT WEEK

Quiz/Homework

IS 425 Enterprise Information LECTURE 7 Winter 2006-2007.

Documents

gl application

applications gl analysis

development slide

pr application

programming managers

track of gl

gl analysts

gl programmers