4 Project Management - Anvari.Net

4

Project Management

Overview

Chapter 4 provides a comprehensive introduction to the management of in-formation system development projects. The chapter’s intent is to survey the full range of activities performed by a project manager, and to introduce com-mon tools and techniques for project management. While it is not the intent to teach project management software for its own sake, the chapter demonstrates many activities in the context of Microsoft Project to reinforce the reality that project planning and control are largely performed using project management software.

Chapter to Course Sequencing

Most instructors will introduce this chapter immediately after Chapter 3. This makes sense because Chapter 3 can be viewed as “process management” to prepare the reader for Chapter 4, Project Management.

Since project management is a cross-cycle activity, it can be covered at any point in the semester. One Purdue instructor places it between data modeling and process modeling when he needs to spend extra time with class assign-ments. Alternatively, some adopters elect to cover this chapter near the end of an introductory systems analysis and design course. And still others elect not to cover the chapter. (Some schools offer a full course on the subject.)

What’s Different Here and Why?

The following changes have been made to the seventh edition of the informa-tion system development chapter:

1. As with all chapters, we have streamlined the SoundStage episode into a quick narrative introduction to the concepts presented the chapter. We believe this streamlined version will be more readable and thus more useful.

2. We have added a new key term for project manager.

3. We updated all technology references throughout the chapter.

4-2 Chapter Four

Copyright © 2007 by McGraw-Hill Companies, Inc.

Lesson Planning Notes for Slides

The following instructor notes, keyed to slide images from the PowerPoint repository, are intended to help instructors integrate the slides into their indi-vidual lesson plans for this chapter.

Slide 1

McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.

Chapter 4

Project Management

slide appearance after initial mouse click in slide show mode

This repository of slides is intended to sup-port the named chapter. The slide repository should be used as follows: Copy the file to a unique name for your course and unit. Edit the file by deleting those slides you don’t want to cover, editing other slides as appropriate to your course, and adding slides as desired. Print the slides to produce transparency masters or print directly to film or present the slides using a computer image projector. Most slides include instructor notes. In re-cent versions of PowerPoint, notes by default display in a window under the slide. The instructor notes are also reprinted below.

Slide 2 Objectives• Define the terms project and project management, and differentiate

between project and process management.• Describe causes of failed information systems and technology projects.• Describe basic competencies required of project managers.• Describe basic functions of project management.• Differentiate between PERT and Gantt as project management tools.• Describe role of project management software.• Describe eight activities in project management.• Define joint project planning and its role in project management.• Define scope and a write a statement of work to document scope.• Use a work breakdown structure to decompose a project into tasks.• Estimate tasks’ durations and specify intertask dependencies.• Assign resources and produce a project schedule with a Gantt chart.• Assign people to tasks and direct the team effort.• Use critical path analysis to adjust schedule and resource allocations in

response to schedule and budget deviations.• Manage user expectations of a project and adjust project scope.

No additional notes.

Project Management 4-3


Slide 3

4-3

Teaching Notes This slide shows the how this chapter's content fits with the building blocks framework used throughout the textbook. Since project manage-ment is an on-going activity, it deals with all phases. Project management is primarily a con-cern of systems analysts and the project man-ager.

Slide 4

4-4

Projects and Project Managers

Project – a [temporary] sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by specific time, within budget, and according to specification.

Project manager - the person responsible for supervising a systems project from initiation to conclusion


Slide 5

4-5

Project Management and Process ManagementProject management – the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.

Process management – the activity of documenting, managing, and continually improving the process of systems development.

Teaching Notes Key point to emphasize is that every IT project is unique, a factor that has made project manage-ment extremely challenging across the industry. Organizations today are placing considerably more importance on project management skills because of the impact information technology has on the business. Organizations can’t afford the project failures which were very much common-place in the past. Project management is a cross life cycle activity. It can be useful to characterize process man-agement as providing the “templates” (much as a word processor) for project management. But just as word processing templates must be managed and improved from time to time, so must process templates be improved and managed. Most organizations pursuing the CMM are target-ing Level 3, that is, consistently using a standard-ized process or methodology to develop all sys-tems. CMM Level 2 deals with project manage-ment. CMM Level 3 deals with what has come to be known as process management.

4-4 Chapter Four


Slide 6

4-6

Measures of Project Success

• The resulting information system is acceptable to the customer.

• The system was delivered “on time.”• The system was delivered “within

budget.”• The system development process had a

minimal impact on ongoing business operations.

Teaching Notes Emphasize that these measurements are from the perspective of the project manager. Failures and limited successes far outnumber successful information systems. Some studies show that 60-75% of all IT projects can be con-sidered failures.

Slide 7

4-7

Causes of Project Failure• Failure to establish upper-management

commitment to the project• Lack of organization’s commitment to the

methodology• Taking shortcuts through or around the

methodology• Poor expectations management

• Feature creep– uncontrolled addition of technical features to a system.

• Scope creep – unexpected and gradual growth of requirements during an information systems project.

Conversion Notes In the seventh edition the Causes of Project Fail-ure has been split between two slides, partially for readability and partially so that feature creep and scope creep can be included here in a more relevant point. Teaching Notes The major cause of project failure—most project managers were not educated or trained to be project managers! Just as good programmers don't always go on to become good systems analysts, good systems analysts don't automati-cally perform well as project managers. To be a good project manager, you should be educated and skilled in the “art of project management.”

Slide 8

4-8

Causes of Project Failure (cont.)• Premature commitment to a fixed budget

and schedule• Poor estimating techniques• Overoptimism• The mythical man-month (Brooks, 1975)• Inadequate people management skills• Failure to adapt to business change• Insufficient resources• Failure to “manage to the plan”




Slide 9

4-9

Project Manager Competencies• Business awareness• Business partner

orientation• Commitment to quality• Initiative• Information gathering• Analytical thinking• Conceptual thinking• Interpersonal awareness• Organizational

awareness

• Anticipation of impact• Resourceful use of

influence• Motivating others• Communication skills• Developing others• Monitoring and controlling• Self-confidence• Stress management• Concern for credibility• Flexibility

(Adapted from Wysocki, Beck, and Crane, Effective Project Management: How to Plan, Manage, and Deliver Projects on Time and within Budget.)

Teaching Notes There exists a core set of competencies that good project managers possess. Some of these competencies can be taught, both in courses, books, and professional workshops; however, you should immediately recognize that some of these competencies come only with professional experience in the field. First, you usually cannot manage a process you have never used. Second, you cannot manage a project without understand-ing the business and culture that provides a con-text for the project.

Slide 10

4-10

Project Management Functions• Scoping – setting the boundaries of the

project• Planning – identifying the tasks required to

complete the project• Estimating – identifying the resources

required to complete the project• Scheduling – developing the plan to

complete the project• Organizing – making sure members

understand their roles and responsibilities• Directing – coordinating the project• Controlling – monitoring progress• Closing – assessing success and failure

Teaching Notes The project management functions were derived from classic management functions. Project management functions are dependent upon interpersonal communications between the project manager, the team, and other managers.

Slide 11

4-11

Project Management Tools & Techniques

PERT chart – a graphical network model used to depict the interdependencies between a project’s tasks.

Gantt chart – a bar chart used to depict project tasks against a calendar.

Teaching Notes The Gantt chart, first conceived by Henry L. Gantt in 1917, is the most commonly used project scheduling and progress evaluation tool. PERT, which stands for Project Evaluation and Review Technique, was developed in the late 1950s to plan and control large weapons devel-opment projects for the U.S. Navy. The tools are not mutually exclusive (especially when PERT is based on “activity on the node” conventions). That is why (and how) most project management software tools maintain both views simultaneously.

4-6 Chapter Four


Slide 12

4-12

PERT Chart

Teaching Notes PERT was developed to make clear the interde-pendence between project tasks before those tasks are scheduled. The boxes represent project tasks (we used phases from Chapter 3). (The content of the boxes can be adjusted to show various project attributes such as schedule and actual start and finish times.) The arrows indicate that one task is dependent upon the start or com-pletion of another task. The “data” recorded in the nodes on a PERT chart vary with project management software tools. Microsoft Project supports different combi-nations of data in the nodes. See the comments at the beginning of the IG for an explanation of the “activity on the node: con-vention.

Slide 13

4-13

Gantt Chart

Teaching Notes Gantt charts offer the advantage of clearly show-ing overlapping tasks, that is, tasks that can be performed at the same time. The bars can be shaded to clearly indicate percentage completion and project progress. The figure demonstrates which phases are ahead and behind schedule at a glance. The popularity of Gantt charts stems from their simplicity—they are easy to learn, read, prepare, and use.

Slide 14

4-14

Microsoft Project Gantt Chart

Teaching Notes The previous slide’s Gantt chart was built using Microsoft Visio. This one was built with Microsoft Project. Emphasize that Gantt charts can also show mile-stones and intertask dependencies.



Slide 15

4-15

Microsoft Project PERT Chart

Teaching Notes Notice that summary tasks do not have depend-encies and are represented in black. The authors chose to use red to depict critical tasks (dis-cussed later in the chapter. Milestones are de-picted in teal.

Slide 16

4-16

Project Management Life Cycle

Teaching Notes This slide becomes the organizing model for the rest of the chapter.

Slide 17

4-17

Joint Project Planning Strategy

Joint project planning (JPP) – a strategy in which all stakeholders attend an intensive workshop aimed at reaching consensus on project decisions.


4-8 Chapter Four


Slide 18

4-18

Activity 1 – Negotiate ScopeScope – the boundaries of a project – the areas of a business that a project may (or may not) address. Includes answers to five basic questions:

• Product • Quality • Time • Cost • Resources

Statement of work – a narrative description of the work to be performed as part of a project. Common synonyms include scope statement, project definition, project overview, and document of understanding.

Teaching Notes In consulting engagements, the statement of work has become a commonly used contract between the consultant and client. But the ap-proach works equally well for internal system development projects to establish a contract be-tween business management and the project manager and team.

Slide 19

4-19

Statement of WorkI. PurposeII. Background

A. Problem, opportunity, or directive statementB. History leading to project requestC. Project goal and objectivesD. Product description

III. ScopeA. StakeholdersB. DataC. ProcessesD. Locations

IV. Project ApproachA. RouteB. Deliverables

V. Managerial ApproachA. Team building considerationsB. Manager and experienceC. Training requirements

(continued)

Notice the use of information system building blocks


Slide 20

4-20

Statement of Work (concluded)V. Managerial Approach (continued)

D. Meeting schedulesE. Reporting methods and frequencyF. Conflict managementG. Scope management

VI. ConstraintsA. Start dateB. DeadlinesC. BudgetD. Technology

VII. Ballpark EstimatesA. ScheduleB. Budget

VIII. Conditions of SatisfactionA. Success criteriaB. AssumptionsC. Risks

IX. Appendices




Slide 21

4-21

Activity 2 – Identify TasksWork breakdown structure (WBS) – a graphical tool used to depict the hierarchical decomposition of the project into phases, activities, and tasks.

Milestone – an event signifying the completion of a major project deliverable.

Conversion Notes For the seventh edition the figure definitions and the figure were combined on one slide. Teaching Notes A WBS may or may not specify milestones. Tasks must be broken down to a level at which they are manageable. Some experts suggest that a task must be accomplished within 40 work-ing hours or further subdivided into tasks until they can. Note the numbering scheme Phase 2, Activity 2.1 (activity 1 of phase 2), Task 2.2.3 (task 3 of activ-ity 2 of phase 2) An important thing to note is that WBSs represent a form of outlining and decomposition. As a rule of thumb, a task is broken down to two or more subtasks, but no task should have more than six subtasks.

Slide 22

4-22

Activity 3 – Estimate Task Durations• Elapsed time takes into consideration:

• Efficiency - no worker performs at 100% efficiency

• Coffee breaks, lunch, e-mail, etc.• Estimate of 75% is common

• Interruptions• Phone calls, visitors, etc.• 10-50%

Conversion Notes This is a new slide in the seventh edition.

Slide 23

4-23

Activity 3 – Estimate Task Durations1. Estimate the minimum amount of time it would take to

perform the task – the optimistic duration (OD). 2. Estimate the maximum amount of time it would take

to perform the task – the pessimistic duration (PD). 3. Estimate the expected duration (ED) that will be

needed to perform the task. 4. Calculate a weighted average of the most likely

duration (D) as follows:

D = (1 x OD) + (4 x ED) + (1 x PD)6

3.33 days = (1 x 2 days) + (4 x 3 days) + (1 x 6 days)6

PDEDOD

Teaching Notes Recognize that the chapter demonstrated only one approach to estimating. The terminology used is consistent with that of Microsoft Project. Project actually allows the project manager to modify this formula to reflect his or her personal experience.

4-10 Chapter Four


Slide 24

4-24

Activity 4 – Specify IntertaskDependencies• Finish-to-start (FS)—The finish of one

task triggers the start of another task. • Start-to-start (SS)—The start of one task

triggers the start of another task.• Finish-to-finish (FF)—Two tasks must

finish at the same time.• Start-to-finish (SF)—The start of one task

signifies the finish of another task.

Teaching Notes The default in most project management software packages is “finish-to-start.” The other options are provided to improve scheduling flexibility based on intertask dependency.

Slide 25

4-25

Entering Intertask Dependencies


Slide 26

4-26

Scheduling Strategies

Forward scheduling – a project scheduling approach that establishes a project start date and then schedules forward from that date.

Reverse scheduling – a project scheduling strategy that establishes a project deadline and then schedules backward from that date.

Teaching Notes In the event that the project manager is given a deadline to meet, reverse scheduling strategy is ideal.



Slide 27

4-27

A Project Schedule in Calendar View


Slide 28

4-28

Activity 5 – Assign Resources• People – includes all system owners, users,

analysts, designers, builders, external agents, and clerical help involved in the project in any way.

• Services – includes services such as a quality review that may be charged on a per use basis.

• Facilities and equipment – includes all rooms and technology that will be needed to complete the project.

• Supplies and materials – everything from pencils, paper, notebooks to toner cartridges, and so on.

• Money – includes a translation of all of the above into budgeted dollars!

Teaching Notes Before resources can be assigned to a pro-ject/task, the analyst must obtain the various stakeholders’ commitment of those resources.

Slide 29

4-29

Defining Project Resources


4-12 Chapter Four


Slide 30

4-30

Assigning Project Resources


Slide 31

4-31

Assigning People to Tasks

• Recruit talented, highly motivated people• Select the best task for each person• Promote team harmony• Plan for the future• Keep the team size small

Conversion Notes This is a new slide for the seventh edition.

Slide 32

4-32

Resource Leveling

Resource leveling – a strategy for correcting resource over-allocations.

Two techniques for resource leveling:• task delaying• task splitting

Teaching Notes It should be noted that resource leveling will be an ongoing activity since the schedule and re-source assignments are likely to change over the course of a project.



Slide 33

4-33

Task Splitting and Task Delaying• Critical path – the sequence of dependent

tasks that determines the earliest possible completion date of the project.

• Tasks on the critical path cannot be delayed without delaying the entire project. Critical tasks can only be split.

• Slack time – the amount of delay that can be tolerated between the starting time and completion time of a task without causing a delay in the completion date of the entire project.

• Tasks that have slack time can be delayed to achieve resource leveling

Teaching Notes You may want to refer to Figure 4-18 to illustrate the concepts of critical path and slack time. The reason the critical path sequence determines the earliest possible completion date is that those tasks have the largest sum of most likely dura-tions.

Slide 34

4-34

Activity 6 – Direct the Team Effort

• Supervision resources• The Deadline: A Novel

about Project Management

• The People Side of Systems

• The One Minute Manager• The One Minute Manager

Meets the Monkey

• Stages of Team Maturity(see figure to the right)


Slide 35

4-35

10 Hints for Project Leadership1. Be Consistent.2. Provide Support.3. Don’t Make Promises You Can’t Keep.4. Praise in Public; Criticize in Private.5. Be Aware of Morale Danger Points.6. Set Realistic Deadlines.7. Set Perceivable Targets.8. Explain and Show, Rather Than Do.9. Don’t Rely on Just Status Reports.10. Encourage a Good Team Spirit.


4-14 Chapter Four


Slide 36

4-36

Activity 7 – Monitor and Control Progress

• Progress reporting • Change management• Expectations management• Schedule adjustments—critical path

analysis (CPA)


Slide 37

4-37

Sample Outline for Progress ReportI. Cover Page

A. Project name or identificationB. Project managerC. Date or report

II. Summary of progressA. Schedule analysisB. Budget analysisC. Scope analysis(changes that may have an impact on future progress)D. Process analysis(problems encountered with strategy or methodology)E. Gantt progress chart(s)

III. Activity analysisA. Tasks completed since last reportB. Current tasks and deliverablesC. Short term future tasks and deliverables

(continued)

Teaching Notes Emphasize that this is merely a sample. Encour-age students to consider that many organizations have their own reporting standards to report pro-ject progress. In addition, many methodologies provide templates for various reporting needs.

Slide 38

4-38

Sample Outline for a Progress Report (concluded)

IV. Previous problems and issuesA. Action item and statusB. New or revised action items

1. Recommendation2. Assignment of responsibility3. Deadline

V. New problems and issuesA. Problems

(actual or anticipated)B. Issues

(actual or anticipated)C. Possible solutions

1. Recommendation2. Assignment of responsibility3. Deadline

VI. Attachments(include relevant printouts from project management software)




Slide 39

4-39

Progress Reporting on a Gantt Chart


Slide 40

4-40

Change ManagementChange management – a formal strategy in which a

process is established to facilitate changes that occur during a project.

Changes can be the result of various events and factors including:• An omission in defining initial scope• A misunderstanding of the initial scope• An external event such as government regulations that create

new requirements• Organizational changes• Availability of better technology• Shifts in planned technology that force changes to the business

organization, culture, and/or processes• Management’s desire to have the system do more• Reduced funding for project or imposition of an earlier deadline.


Slide 41

4-41

Expectations ManagementExpectations management matrix – a tool used to understand the dynamics and impact of changing the parameters of a project.

The most important The second most important

The least important

Can have only one X in each row and each

column

Teaching Notes We find this to be a useful teaching tool both with students and clients. One can have only one main goal. The second is accepted as a con-straint. Given the other two, the third just has to be accepted. To make one more important is to make another one less important.

4-16 Chapter Four


Slide 42

4-42

Lunar Project Expectations Management

Teaching Notes In the Apollo project, given that scope/quality was the number one goal and that schedule was the constraint, NASA and the U.S. government (the system owners) were prepared to accept what-ever cost was required.

Slide 43

4-43

Typical, Initial Expectations for a Project

Teaching Notes For many system development projects, scope/quality is the first concern and cost is the constraining factor. Users would then have to accept whatever schedule allowed that scope to be delivered within that cost.

Slide 44

4-44

Adjusting Expectations

Teaching Notes This diagram illustrates what happens when the scope increases. Generally if the new scope is the measure of success for the project, then ei-ther the deadline must be extended or more budget added to the project or both. Another possibility would be that other system require-ments can be put off until another version.



Slide 45

4-45

Changing Priorities

Teaching Notes This illustrates that only one factor can be the measure of success. If scope/quality is the measure then cost cannot be more than a con-straint and vice-versa.

Slide 46

4-46

Schedule Adjustments -Critical Path Analysis1. Using intertask dependencies, determine every

possible path through the project.2. For each path, sum the durations of all tasks in

the path.3. The path with the longest total duration is the

critical path.• The critical path is the sequence of tasks with the

largest sum of most likely durations. The critical path determines the earliest completion date of the project.

• The slack time for any non-critical task is the amount of delay that can be tolerated between starting and completion time of a task without causing a delay in the entire project.

Teaching Notes The explanation of identifying the critical path is a simplified description. Identifying the critical path for large complex projects with many paths can be quite challenging. There are other approaches that can be used to identify the critical path (see Wysocki et al.).

Slide 47

4-47

Critical Path Analysis

Teaching Notes The critical path is shown in red. It is critical be-cause it is the longest path from beginning to end. If any task along the critical path slips, the project slips.

4-18 Chapter Four


Slide 48

4-48

Activity 8 – Assess Project Results and Experiences

• Did the final product meet or exceed user expectations?• Why or why not?

• Did the project come in on schedule?• Why or why not?

• Did the project come in under budget? • Why or why not?




Answers to End of Chapter Questions and Exercises Review Questions 1. A project is a sequence of unique, complex, and connected activities that

have one goal or purpose (i.e. not a recurring process) and that must be completed by a specific time, within budget, and according to specification.

2. The major cause of project failure is that most project managers have not

been educated or trained to be project managers. Project managers are re-quired to have certain knowledge and skills in order to manage a project well.

3. Scope creep is the unexpected and gradual growth of requirements during

an information system project.

Feature creep is the uncontrolled addition of technical features to a system. 4. Business achievement competencies, problem-solving competencies, influ-

ence competencies, people management competencies, and self-management competencies

5. There are three major elements in business achievement competencies.

They are business awareness—tying every systems project to the mission, vision, and goals of the organization; business partner orientation—keeping managers and users involved throughout a system project; and commitment to quality—ensuring every systems project contributes to the quality expec-tation of the organization as a whole.

These three major elements are essential because the two most common mismanagement problems are the failure to establish upper-management commitment to the project and the lack of an organization’s commitment to the system development process.

The business achievement competencies will make sure project managers have enough business experience and knowledge of the organization to avoid project failures.

6. Scoping, planning, estimating, scheduling, organizing, directing, controlling,

and closing.

7. A PERT chart is a graphical network model used to depict the interdepend-encies between a project’s tasks. A Gantt chart is a bar chart used to depict project tasks against a calendar.

4-20 Chapter Four


The PERT chart should be used if you want to study the relationships be-tween different tasks because it shows you which task is dependent on which task.

A Gantt chart should be used if you are seeking to communicate sched-ule. It is because Gantt chart shows you the tasks against a calendar. It is very easy to tell if there are overlapping tasks and tasks that are ahead or behind schedule.

8. 1) Negotiate scope

2) Identify tasks 3) Estimate task durations 4) Specify inter-task dependencies 5) Assign resources 6) Direct the team effort 7) Monitor and control progress 8) Assess project results and experiences

9. Negotiating the scope of a project is to identify and set the boundaries of a

project—the parts of the business that are to be studied, analyzed, de-signed, constructed, implemented, and ultimately improved. It is of the ut-most importance to identify and set the scope before work begins because it defines the expectation of a project, and expectations ultimately determine satisfaction and the degrees of success. The decision-makers involved in the project must agree to the project scope before any attempt is made to identify and schedule tasks or assign resources to those tasks. Thus, nego-tiating the scope as the first activity is absolutely necessary prior to engag-ing in the other activities in the project management life cycle.

The deliverable is the statement of work. The statement of work is a nar-rative description of the work to be performed as part of a project. In a con-sulting engagement, it is also part of the contract between the consultant and client.

10. A work breakdown structure (WBS) is a commonly-used tool used to graphically depict the hierarchical decomposition of a project into phases, activities, and tasks.

11. The factors include the size of the project team, number of system users,

availability of the users, aptitudes of users, complexity of the business sys-tem, information technology architecture to be used, experience of team personnel, time committed to other projects, and experience with other pro-jects.

12. Forward scheduling is a project scheduling approach that establishes a

project start date and then schedules forward from that date.



Reverse scheduling is a project scheduling strategy that establishes a pro-ject deadline and then schedules backward from that date.

13. People, services, facilities and equipment, supplies and materials, and

money 14. Change management is a formal strategy wherein a process is established

to facilitate changes that occur during a project. Project managers should establish a change management system that defines the procedures for documenting a change request and the steps necessary to consider the change. Project managers also need to ensure a feasibility impact analysis is performed to assess the importance of the change to the business, on the project schedule, and on the project budget.

15. It is important because when it comes to the project schedule, some tasks

are more sensitive to schedule delays than others. Thus, project manager must become aware of the critical path and slack times for a project. Criti-cal path is the sequence of dependent tasks that determines the earliest completion date for a project, whereas slack time is the amount of delay that can be tolerated without causing delay in the completion date. It is essential to understand that resources, if necessary, might be temporarily diverted from tasks with slack time to help get the critical tasks back on schedule, because those tasks are critical to the completion of the project.

Problem and Exercises 1. From the viewpoint of project manager, four critical success factors must be

met for a project to be considered a complete success: • The project must be completed on time • The project must be delivered within budget • The project must not have had an unanticipated impact on business op-

erations. • The project must be acceptable and meet expectations of the customer.

Unless all four critical success factors are fully met, the project can not be considered a complete success. A project that does not fully meet what is arguably the most important success factor – satisfying customer expecta-tions – can only be considered a limited success.

2. Taking shortcuts through or around the system development methodology is

a possible cause of the user dissatisfaction, since the most common short-cut is to rush the requirements analysis process and begin system design prematurely.

4-22 Chapter Four


Poor expectations management, such as scope creep or feature creep, is a possible candidate, although it usually leads to projects being behind schedule and/or over budget, which this project wasn’t.

Failure to adapt to business change is a more likely candidate, especially since this was a large project that spanned several years. During this time, it is highly probable that significant business change occurred. If project management did not include a periodic assessment of the impact of these business changes upon the project in progress, then this may very well be the cause of user dissatisfaction.

3. There are two underlying “truths” regarding project management competen-

cies. One, you can’t manage a process you have never used yourself, and you must understand the business and culture that drives the project. These premises are reflected in the PMBOK Project Competencies table, which lists 20 competencies. 12 of the competencies can be obtained only through business experience. Five of the competencies can be obtained through a combination of education or training and business experience. Two can be obtained from just training or education only, and only one re-quires project experience. None of the competencies requires IT experience. By far, the most important prerequisite is successful business experience at the professional level.

Assuming all other factors regarding the candidates’ qualifications and personal fitness are equal, you would probably eliminate both the IT man-ager and the recent graduate as candidates because neither has the neces-sary business experience.

Thus, your recommendation may be to hire the candidate with extensive successful business experience, provided that this candidate be given train-ing in project management and the opportunity to lead several smaller pro-jects first, in order to become familiar with the specialized techniques and language of project management, before tackling the mission-critical project.

Otherwise, your recommendation to the CEO may be to continue recruit-ing, and seek a candidate with both business and project management ex-perience!

4. Your first activity should be to negotiate the scope of the project. Defining

the scope is at the very beginning of the project is absolutely critical to its ultimate success, since the scope identifies the boundaries and the expecta-tions of the project. Typically, the project manager and the system owner(s) work together to answer five essential questions: what is the product to be delivered, what are the expectations regarding quality, by when must it be completed, how much can it or will it cost, and what resources are avail-able?

The outcome or deliverable is the statement of work, also known as the scope statement or project definition. The statement of work is in essence a contract that states the work to be performed, who makes the project deci-sions, who is in charge of the funding, and who are the stakeholders, i.e., it



defines the business relationship between the project manager and both the business customer and project team.

5. The Gantt chart should look similar to the one below. Starting and ending dates should be the same, but task durations and dependencies can vary.

6. This is a classic case of feature creep. Programmers, particularly the most talented and creative ones, frequently like to “tweak” systems with added features. Although the added features frequently improve system function-ality, the benefits are generally outweighed by the disadvantages. The added features may cause conflicts with other parts of the system, particu-larly in large projects where there are many programmers, each working on a small part of the system. Even if there is not a conflict with other parts of the system, additional time must be spent downstream to test and docu-ment the added features, as well as to train users. Since this additional time was not built into the schedule or budget, this may cause the project to fall behind schedule or to exceed its budget. The project manager should nurture creativity, but insist upon disciplined adherence to methodology; new features that a stakeholder wants to add should always go through a formal change management process for approval first, regardless of whether the stakeholder is a system owner, user, design or builder.

7. Changes may be needed for a variety of reasons, such as an incomplete ini-tial scope, new legal requirements, organizational changes, etc. In this case, the reason given could be a desire to have the system do more than was in the original scope agreement. Your justification should include an analysis of the impact upon the organization and the project: will developing the new features adversely impact the project budget, schedule, or quality? What is the impact upon customer expectations? Will it increase ongoing operational costs?

8. The management expectations matrix and priorities should look like the fol-lowing diagram:

4-24 Chapter Four


Max or Min

Constrain Accept

Cost

X

Schedule

X

Scope or Qual-ity

X

Based upon the expectations set by the CEO, the absolute top priority is de-livering the new system to customers before a certain date. Scope and qual-ity are the second priority because while they have certain minimum expec-tations, there is some flexibility as to the features to be included. Budget, while extremely important, is the third priority because the CEO has indi-cated adjustments can be made if absolutely necessary.

9. What you should not do is to change the priorities yourself. The CEO, as

the system owner in this case, is the only one who can initiate priority changes. Your role is to make the system owner aware of the conflict and to discuss possible courses of action. These courses of action might include not making any changes, maintaining the schedule as the highest priority, but allocating additional budget to cover both the deficit and the cost of hir-ing more staff to work on the additional features, or changing the priorities.

10. If expanding scope is now the highest priority, the expectations matrix

must be modified per step 1 below to reflect this change. But this means that since there can be only one “X” per column, schedule must become the constrained priority, as shown in Step 2 below. Expectations have now been adjusted; the CEO has accepted that slippage of schedule may occur in order that the system being developed include the new features.

Max or Min

Constrain Accept

Cost

X

Schedule

X

Step 2 X

Scope or Qual-ity

Step 1 X

X



11. The first step is to calculate optimistic duration (OD), i.e., the absolute

minimum amount of time needed for the task if the worker efficiency rate was 100 percent and there were no interruptions whatsoever. Using the formula OD = (75% efficiency) X (1.00 – 0.15 interruptions) X (ED of 24 hours), the optimistic duration equals about 15.3 hours. The next step is to calculate the most likely duration (D) using the following classic formula based upon a weighted average:

D = (1 X OD) + (4 X ED) + (1 X PD)

6 Plugging in the values, this becomes:

D = (1 X 15.3) + (4 X 24) + (1 X 80) 6

Based on this formula, the most likely duration for the task = 31.9 hours.

12. This technique is called “decomposition.” This is a basic technique which involves decomposing a project and/or task into smaller pieces where their duration can be estimated based upon historical experience and/or data from previous projects.

Other techniques you could have used include:

COCOMO, which is a model-based method that estimates duration of a project and/or task using parameters that are based upon a fairly complex and involved set of industry standards.

Function points, which is another model-based technique. Estimated du-rations using function points are calculated based upon the volume and complexity of inputs, outputs, processes and data stores, which in turn is compared to projects with similar function points.

There are also an increasing number of project management tools, which contain expert system modules that will estimate duration based responses to questions concerning the nature of the project, resource knowledge and skills, technical environment, etc.

13. Resource leveling is a technique that is commonly used to adjust tasks

when a resource is over-allocated. Resource leveling accomplishes this by delaying and/or splitting tasks. Delaying tasks is an approach based upon the premise that tasks not on the critical path, i.e., with slack time, can be delayed up to the amount of slack time available without affecting

4-26 Chapter Four


the scheduled completion date of the project. Of course, this assumes that your over-allocated resource has been assigned enough tasks not on the critical path to sufficiently reduce the over-allocation; otherwise, your only option other than delaying the project may be to split tasks. Splitting tasks, as the name implies, is an approach that is based upon dividing a task into smaller tasks in order to assign additional resources who are not over-allocated.

14. Path 1: A -> G -> I 15 days

Path 2: A -> D -> F -> H -> I 18 Path 3: B -> E -> G -> I 20 Path 4: C -> F -> H -> I 13

The critical path of the project is Path 3: B-> E -> G -> I -> Finish.

Critical path analysis is not just theoretical knowledge that can be forgot-ten right after it learned. To be a successful project manager, you must understand critical path analysis and be able to apply it in the business world to ensure that people resources are being effectively managed used where they are most needed in a project.

15. You should keep in mind the principle of the mythical man-month: there is

no linear relationship between the amount of time a project will take and the number of resources assigned. Every person you assign to a team in-creases the number of communication paths, which create project over-head. A five-person team has 10 communications paths, an eight-person team has 28, and a 10-team has 45 communication paths! Staff your pro-ject team appropriately, but don’t overstaff – it generally won’t get you any-thing additional other than headaches.

Project and Research 1. Responses can be open-ended, but should reflect an understanding of the

cost and consequences associated with project failure, and that the over-whelming majority of project failures are avoidable. “Lessons learned” (Question 1g) should show thought and personal reflection on how to avoid a similar occurrence in one’s career.

2. Responses are open-ended, but should indicate originality and depth of

thought regarding the issue of professional certification for project manag-ers.



3. a. Expectations regarding the product or service to be delivered, quality, timeframes for delivery, cost, and resources available for the project need to be negotiated in order to arrive at agreement over the project scope.

b. The Statement of Work represents a contract between the client or man-agement, and the consulting firm or internal project management team. Normally, it should be no more than several pages.

c. Response can be open-ended, but it should address each of the outline items in succinctly but in sufficient detail to avoid any ambiguity or misunderstanding regarding deliverables and responsibilities, just as if it were an actual contract

4. Responses Questions 4a – 4c can be open-ended regarding reasons and

opinions, but typically will indicate that most project managers are now us-ing project management software, usually Microsoft Project. The web search should find at least several dozen project management software pro-grams, of which perhaps a handful are widely known and used. Microsoft Project is certainly the most widely used program, but not necessarily the most popular.

5. Response should follow the Figure 4-11 outline, and should identify any

problems or concerns in a frank and accurate manner without glossing over them. The project manager should never yield to the temptation, par-ticularly on lengthy or challenged projects, of writing the status report in a rote or repetitive manner.

6. Open-ended, but responses should cite a number of articles, and recognize

the value on future projects of learning not only what went well, but per-haps more importantly, what did not go well on the project.

Minicases 1. The basic tenet of project management is that the factors of: time, deliver-

ables, quality, and cost are in opposition. As a result, the increase of one will directly, and *must* directly affect at least one of the others. It is the adage of: you can’t get something for nothing. What should you do when a client demands extras, and doesn’t want to allow variability in time, cost, or quality? You will have to be firm and clear with Debbie as to the project management constraints. Practice within the class what to say to this cli-ent, and how to handle the situation.

2. The most likely duration is 3 months. However, 1) things generally take

longer than we’d like, and 2) clients are generally unhappy with deadline

4-28 Chapter Four


slippage, yet I have never known one to be upset with an early delivery. Plan accordingly, and give yourself more time than you think you need.

3. Note to Professor: The timeline for tasks will almost always be different by starting at the due date, and working forward than it will starting at the project beginning and working to the end. This is because people naturally give themselves ample time for tasks at the start of the planning process. By backward scheduling, they are naturally front-loading the project since the start of the planning process is actually the end of the project! This simple act tends to help students meet their deadlines.

4. Note to Professor: Life happens – most large projects are affected by non-work related issues. Project managers need expect the unexpected, and to have a contingency plan to ensure project success.

Team and Individual Exercises 1. For the Professor to direct: Create teams of four and assign them a chal-

lenging task with a short deadline. It should be doable for the class, but certainly not easy. Midway through the project, exchange one member per team so that each team has lost one member and gained one new member. Do not allow the team to converse with the member that was “hired away.”

Have the project manager document how they handled the situation, what problems arose, and how they would handle a team differently in the future (knowing that they could lose a teammate at any time and without any notice).

2. Note to Professor: this can get out of hand – make sure the students re-

main somewhat realistic. E.g. nobody is going to suddenly get recruited by NASA to go to the moon, so we really don’t have to make a contingency plan for that one…

3. Note to Professor: Does this seem just too feel-good and “warm-and-fuzzy?”

Don’t get nauseous. People (in this case, students) that can create an emo-tional bond (positive) to a team are more “embedded” in that team and will be less likely to quit on that team. I.e. when the going gets really difficult, they will be more likely to tough it out.

4 Project Management - Anvari.Net

Documents

Transcript of 4 Project Management - Anvari.Net