chap 02 project management.pptx

Chapter 2 Project Management

OBJECTIVES

• Understand how projects are selected in some organizations. • Understand various approaches to the SDLC that can be used to

structure a development project. • Understand how to select a project methodology based on

project characteristics. • Become familiar with project estimation. • Be able to create a project work plan. • Understand how to staff a project. • Understand techniques to coordinate and manage the project. • Understand how to manage risk on the project.

Lesson 1 of

Chapter 2

Introduction

Introduction

• This chapter discusses how organizations evaluate and select projects to undertake from the many available projects.

• Once a project has been selected, the project manager plans the project.

Introduction

• Project management involves:– selecting a project

methodology– creating the project

work plan– identifying project

staffing requirements, and

– preparing to manage and control the project.

• These steps produce important project management deliverables, including:– the work plan– staffing plan– standards list– project charter, and – risk assessment.

Introduction

• Most IT departments face a demand for IT projects that far exceeds the department’s ability to supply them.

• The corporate IT department needs to carefully prioritize, select, and manage its portfolio of development projects.

• Projects need to give value to the business.

Introduction

• Systems projects today are evaluated in the context of an entire portfolio of projects.

• Determination of a project’s contribution to an entire portfolio of a project reinforces the need for a feasibility study.

• Project portfolio management a process of selecting, prioritizing, and monitoring project results– has become a critical success factor for IT departments

facing too many potential projects with too few resources.

Project Selection

Project Selection• The project selection process takes into

account all of the projects in the organization, using portfolio management. • Portfolio management - takes into consideration

the different projects that exist in an organization.• If there are three potentially high-payoff projects,

and they all have the same risk, then maybe only one of the projects will be selected.

Project Selection• Once the feasibility analysis has been completed, it

is submitted back to the approval committee along with a revised system request. – The approval committee weighs many factors and makes

trade-offs before a project is selected.– An approval committee must be selective about where

to allocate resources as most organizations have limited funds.

– The committee then decides whether to approve the project, decline the project, or table it until additional information is available.

Introduction

• Once selected, a systems development project undergoes a thorough process of project management.• Project management is the process of planning and controlling the

project within a specified time frame, at minimum cost, with the desired outcomes.

• A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated.

• Project management has evolved into an actual profession with many training options and professional certification (e.g., Project Management Professional, or PMP) available through the Project Management Institute (www.pmi.org).

http://www.pmi.org/

Creating the Project Plan

Creating the Project Plan • Project methodology options• Selecting the appropriate methodology• Estimating the project time frame• Developing the work plan• Staffing the project• Coordinating project activities

Project methodology options

• A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and deliverables).

• The project methodology provides lists of tasks and deliverables for projects, which the project manager modifies, depending on the needs of the specific project.

• There are a number of different project methodologies that can be used to structure and guide systems development projects.

Project methodology options

• Several of the key methodologies are:– waterfall development and its variations: parallel

development and the V-model; – rapid application development, including iterative

development, system prototyping, and throwaway prototyping

– agile development, including extreme programming, Scrum, and others.

Selecting the appropriate methodology

• The project manager evaluates characteristics of the project to select the most appropriate methodology to use for the project. including factors such as:– clarity of user requirements– familiarity with technology– Complexity– Reliability– time frame– schedule visibility

Definition of terms Clarity of user requirement what the business side really

wants the system to do Familiarity with technology using technologies that analysts

and developers are familiar with Short time schedule how quickly the system can be

developed and implemented System reliability how accurate the system must be (such as

medical equipment or for games. System complexity how intricate and difficult the system

must be Schedule visibility knowing whether a project is on schedule.

Waterfall Development

PowerPoint Presentation for Dennis, Wixom &

Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All

rights reserved..

2 - 20

• With waterfall development, analysts and users proceed sequentially from one phase to the next.

• The key deliverables for each phase are typically voluminous (often, hundreds of pages) and are presented to the approval committee and project sponsor for approval as the project moves from phase to phase.

• Once the work produced in one phase is approved, the phase ends and the next phase begins/

• As the project progresses from phase to phase, it moves forward in the same manner as a waterfall.

• While it is possible to go backward

Historic standard, but is used less today because it takes the longest to complete all the SDLC steps


• Most appropriate if you have a system project with: – clear requirements; – very familiar technologies; – not all that complex; – reasonably reliable; – a very long time schedule and the schedule

visibility is not important

Parallel Development



rights reserved..

2 - 22

There are two important variants of waterfall development. • The parallel development

methodologies evolved to address the lengthy time frame of waterfall development.

• As shown in Figure 2-3, instead of doing the design and implementation in sequence, a general design for the whole system is performed..

• Then the project is divided into a series of subprojects that can be designed and implemented in parallel. Once all subprojects are complete, there is a final integration of the separate pieces, and the system is delivered.


• Most appropriate if you have a system project with: – clear requirements; – very familiar technologies; – not all that complex; – reasonably reliable; – a very long time schedule and

the schedule visibility is not important

Parallel Development• Most appropriate if you

have a system project with: – clear requirements; – very familiar technologies; – not all that complex; – reasonably reliable; – a short time schedule and the

schedule visibility is not important

V-model



rights reserved..

2 - 24

• The V-model is another variation of waterfall development that pays more explicit attention to testing.

• As shown in Figure 2-4, the development process proceeds down the left-hand slope of the V, defining requirements and designing system components.

• At the base of the V. the code is written.

• On the upward-sloping right side of the model, testing of components, integration testing, and, finally, acceptance testing are performed.

• A key concept of this model is that as requirements are specified and components designed, testing for those elements is also defined. In this manner, each level of testing is clearly linked to a part of the analysis or design phase, helping to ensure high quality and relevant testing.

Parallel Development• Most appropriate if you

have a system project with: – clear requirements; – very familiar technologies; – not all that complex; – reasonably reliable; – a short time schedule and the

schedule visibility is not important

V-Model• Most appropriate if you

have a system project with: – clear requirements; – very familiar technologies; – not all that complex; – must be reliable; – a somewhat longer schedule

and the schedule visibility is not important

Rapid Application Development (RAD)

• Rapid application development is a collection of methodologies that emerged in response to the weaknesses of waterfall development and its variations.

• RAD incorporates special techniques and computer tools to speed up the analysis, design, and implementation phases– in order to get some portion of the system developed

quickly and into the hands of the users for evaluation and feedback.

Rapid Application Development (RAD)

As systems are developed more quickly and users gain a better understanding of IT, user expectations may dramatically increase and system requirements may expand during the project (sometimes known as scope creep or feature creep).

a. Throwaway Prototypingb. Iterative developmentc. System Prototyping

RAD: Iterative Development(series of versions or various releases)

• RAD may be conducted in a variety of ways.

• Iterative development • breaks the overall project into a

series of versions that are developed sequentially.

• This version is developed quickly by a mini-waterfall process, and once implemented, the users can provide valuable feedback to be incorporated into the next version of the system.

• The most important and fundamental requirements are bundled into the first version of the system.

RAD: System Prototyping



rights reserved..

2 - 29

• System prototyping performs the analysis, design, and implementation phases concurrently in order to quickly develop a simplified version of the proposed system and give it to the users for evaluation and feedback.

• The system prototype is a “quick and dirty” version of the system and provides minimal features.

The approach is very useful when users have difficulty expressing requirements for the system.- the lack of careful, methodical analysis - fundamental design limitations

RAD: Throwaway Prototyping



rights reserved..

2 - 30

Throwaway prototyping includes the development of prototypes, but uses the prototypes primarily to explore, design alternatives rather than as the actual new system (as in system prototyping). - used to gather requirements

and to develop ideas for the system concept.

- A design prototype is not intended to be a working system.

- It contains only enough detail to enable users to understand the issues under consideration.

Iterative Development• Most appropriate if you

have a system project with: – somewhat unclear

requirements; – somewhat unfamiliar

technologies; – that is complex; – reasonably reliable; – a short time schedule and

high schedule visibility

Throwaway Prototyping• Most appropriate if you have

a system project with: – unclear user requirements– unfamiliar technologies– somewhat complex or very

complex– needs to be reliable or must

be reliable– time is not an issue or a short

to medium time schedule and the schedule visibility is somewhat important

Agile Development

• A group of programming-centric methodologies that focus on streamlining the SDLC.

• Includes face-to-face communication – means much of the modeling and documentation overhead is eliminated.

• There are several popular approaches to agile development, including extreme programming (XP), Scrum, and dynamic systems development method (DSDM).



rights reserved..

2 - 32

Streamline To improve the efficiency of a process, business or organization by simplifying or eliminating unnecessary steps, using modernizing techniques, or taking other approaches.

Extreme Programming



rights reserved..

2 - 33

Extreme programming – emphasizes customer satisfaction and teamwork.- recommended only for small groups

of developers (not more than 10)- Project teams are kept small.- not advisable for mission-critical

applications- only code documentation, thus

maintenance of large systems developed using XP may be impossible.

- For small projects with highly motivated, cohesive, stable, and experienced teams

Extreme Programming• Communication, simplicity, feedback, and courage are core

values. – Communication Developers communicate with customers and fellow

programmers. – Simplicity Designs are kept simple and clean. – Feedback Early and frequent testing provides feedback– Courage developers are able to courageously respond to changing

requirements and technology

• Most appropriate if you have a system project with: – unclear requirements– very familiar technologies– not all that complex– reasonably reliable– a short time schedule and the schedule visibility is somewhat important

Important Factors to Consider

• The project manager evaluates characteristics of the project, to select the most appropriate methodology to use for the project, including factors such as:– Clarity of User Requirements– Familiarity with Technology– System Complexity– System Reliability– Short Time Schedules– Schedule Visibility



rights reserved..

2 - 35

Selecting the Appropriate Development Methodology

Selecting the Appropriate Development Methodology



rights reserved..

2 - 36

Criteria for Selecting a Methodology

Quiz 2

Lesson 2of

Chapter 2

Creating the Project Plan

• Project Methodology Options• Selecting the Appropriate Methodology• Estimating the Project Time Frame• Developing the Work Plan• Staffing the Project• Coordinating Project Activities

Estimating the Project Time Frame

• Estimation – is the process of assigning projected values for time and effort.

• Who will estimate the time frame for the project?– The project manager

• Ways or approach or techniques used to estimate:– Past experience– industry standards– function-point analysis – a more precise approach to

estimation, more complex, and more reliable.

Estimating Project Time Using Industry Standards

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved..

2 - 42

Developing the Work Plan

• Work Plan – is a dynamic schedule that records and keeps track of all of the tasks that need to be accomplished over the course of the project.– Is the mechanism used to manage the tasks that are

listed in the work breakdown structure.– Is a table that lists all of the tasks in the work

breakdown structure, along with important task information such as the people who are assigned to perform the tasks, the actual hours that the tasks took, and the variances between estimated and actual completion times.

Developing the Work Plan

• The project manager: – Identifies the tasks that need to be completed

• refines the tasks into a work breakdown structure

– Estimates the time that will be needed on tasks– Creates a dependency chart

• Task dependencies, which occur when one task cannot be performed until another task is completed

– Identifies the key milestones or important dates to track• Presentations to the approval committee• The start of end-user training• A company retreat• The due date of the system prototype

Staffing the Project

• Staffing involves:– determining how many people should be assigned to the

project or determining the number of people that might be needed

– Selecting people with good interpersonal skills to help with political considerations

– matching people’s skills with the needs of the project• Determining the technical skills needed on the project

– motivating the team to meet the project’s objectives– minimizing conflict among team members– assigning project roles to team members– developing a reporting structure for the team


• Matching people’s skills with the needs of the project ---technical skills and interpersonal skills• Technical skills – are useful for working with technical tasks (e.g.,

programming in JAVA) and in trying to understand the various roles that technology plays in the particular project (e.g., how a Web server should be configured on the basis of a projected number of hits from customers).

• Interpersonal skills – include interpersonal and communication abilities that are used when dealing with business users, senior management executives, and other members of the project team.– for a project manager might be important when working with a highly

controversial project that may have political implications


• If the skill not match with the project, the possible solutions are:– Use a consultant– Use a contract employee– Train the project team (or some of the team) on

the skills needed– Mentor a team member (like sending a person to

work on a similar project to acquire the necessary skills)


• Deliverables are:– Staffing plan – describes the number and kinds of

people who will work on the project.• Lists the roles that are required for the project

– Overall reporting structure– Project charter – describes the project’s objectives

and rules or lists the project’s norms and ground rules.

Increasing Complexity with Larger Teams

2 - 49

• Staffing levels will change over a project’s lifetime• Adding staff may add more overhead than additional labor• Using teams of 8-10 reporting in a hierarchical structure can reduce

complexity

A four-person team will have six lines of communication.

A two-person team has single line of communication.

Why is it generally a problem to add more people to a late project?

• With more people, the communication complexity grows.

• Also, with adding people to a late project, you will have to bring them up-to-speed on the project (and that may even delay you more as they have no idea of what has (and has not) been accomplished so far).

• Where you had a project that had a structure, now you are making it unstructured and harder to manage and keep on task and on time!!!

fig_02_15

fig_02_15Possible Reporting Structure

A functional lead manages a group of analystsA technical lead oversees progress of programmers and technical staff members

Staffing the project

• Both motivation and cohesiveness have been found to greatly influence performance of team members in project situations.

• Motivation – has been found to be the number-one influence on people’s performance.

Motivation

• Use monetary rewards cautiously• Use nonmonetary or intrinsic rewards

– Recognition• Recognize and reward good efforts

– Achievement• Reward those with outstanding quality and effort

– The work itself– Having a good working environment– Setting realistic deadlines

– Responsibility– Advancement– Chance to learn new skillsPowerPoint Presentation

for Dennis, Wixom & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved..

2 - 53

Cohesiveness

• Group cohesiveness – the attraction that members feel to the group and to other members.• Contributes more to productivity than do project

members’ individual capabilities or experiences.

Handling Conflict

• Conflict can be minimized by:– clearly defining the roles on a project– holding team members accountable for their tasks– Clearly defining project plans– Develop a project charter listing norms and ground rules– Look at other projects and priorities and see how that might

impact the project– Communicate the business value to the team – Recognize project importance to organization– Develop schedule commitments ahead of time– Forecast other priorities and their possible impact on the

project

Coordinating Project Activities• Three techniques are available to help coordinate

activities on a project:– Computer-Aided Software Engineering (CASE) CASE is a

category of software that automates all or part of the development process.

– Standards standards are formal rules or guidelines that project teams must follow during the project

– Documentation includes detailed information about the tasks of the SDLC. • Often, documentation is stored in project binder(s) that contain all the

deliverables and all the internal communication that takes place—the history of the project.

CASE Tools

2 - 57

Planning Analysis Design Implementation

Upper CASE Lower CASE

Integrated CASE (I-CASE)

Upper CASE - Used during the analysis phase to create integrated diagrams of the system and to store information regarding the system components.Lower CASE – design-phase tools that create the diagrams and then generate code for database tables and system functionality.I-CASE – contains functionality found in both upper CASE and lower CASE tools that it supports tasks that happen throughout the SDLC.

CASE Tools

• Computer-aided software engineering (CASE) is a category of software that automates all or part of the development process. – Upper CASE Some CASE software packages are

primarily used during the analysis phase to create integrated diagrams of the system and to store information regarding the system components (often called upper CASE), whereas

– Lower CASE others are design-phase tools that create the diagrams and then generate code for database tables and system functionality (often called lower CASE)

CASE Tools

• Integrated CASE or I-CASE, contains functionality found in both upperCASE and lower-CASE tools in that it supports tasks that happen throughout the SDLC CASE comes in a wide assortment of flavors in terms of complexity and functionality:

• Examples are the Visible Analyst Workbench Oracle Designer Rational Rose, and the Logic Works suite

CASE Tools

The benefits:tasks are much faster to complete and alter, development information is centralized, and information is illustrated through diagrams, which

typically are easier to understand can reduce maintenance costs,improve software quality, and enforce discipline, and some project teams even use CASE to assess the

magnitude of changes to the project.

CASE Tools The advanced CASE tools

are complex applications that require significant training and experience to achieve real benefits.

CASE should not be considered a silver bullet for project development. serves only as a glorified diagramming tool that supports the

practices described in Chapter 5 (process modeling) and Chapter 6 (data modeling).

a helpful way to support the communication and sharing of project diagrams and technical specifications—as long as it is used by trained developers who have applied CASE on past projects.

CASE Components

2 - 62

Procedural MetadataLogic

Diagrams ScreenDesigns

CASE RepositoryThe central component of any CASE tool.(otherwise known as data dictionary or information repository)

CASE repository – stores the diagrams and other project information, such as screen and report designs, and it keeps track how the diagrams fit together.

Metadata is data that describes other data.

Metadata summarizes basic information about data, which can make finding and working with particular instances of data easier. For example, author, date created and date modified and file size are examples of very basic document metadata.

Standards

• Standards are created to ensure that team members are performing tasks in the same way and following the same procedures.

• Examples– Formal rules for naming files– Forms indicating goals reached– Programming guidelines

fig_02_18

fig_02_18

Documentation

• Documentation – includes detailed information about the tasks of the SDLC.– Stored in project binder.

• Project binder – contain all the deliverables and all the internal communication that takes place---the history of the project.

– Table of contents– Continual updating

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th EditionCopyright 2009 © John Wiley & Sons, Inc. All rights reserved..

2 - 65

Lesson 3of

Chapter 2

Managing and Controlling the Project

• Refining estimates• Managing scope• Timeboxing• Managing risk• Gantt Chart


• The science (or art) of project management is in making trade-offs among three important concepts: – the size of the system (in terms of what it does), – the time to complete the project (when the

project will be finished), and – the cost of the project.


• As inevitable project changes arise, however, project managers try to balance the project size (number of features), time frame, and cost.

Refining Estimates

• Refining estimates - needs to estimate each of these levers, then assess how the project meet the needs.

• Estimates may have to be revised as more is learned about the system.

• Graphical tools such as Gantt and PERT charts help depict progress on tasks and clarify critical task dependencies.

Avoiding Classic Planning Mistakes (Practical Tip 2-1)

1) Overly optimistic schedule – don’t inflate time estimates

2) Failing to monitor the schedule – require report progress

3) Failing to update the schedule - revise the schedule4) Adding people to a late project – revise the

schedule, use timeboxing, throw away bug-filled code, and add people only to work on an isolated part of the project.

Managing scope

• The most common reason for schedule and cost overruns, occurs after ---the project is underway— is the scope creep.

• Scope creep happens when new requirements are added to the project after the original project scope was defined and “frozen.”

• Project managers should try to avoid introducing scope creep or feature creep into the schedule.

What can you do to manage scope creep?

• Make it clear to users and managers that adding requirements is very difficult and make sure that requirements are all specified in advance.

• Work hard to keep the project tight and focused• Understand that there are some things that are truly required

in the current project – but limit those and put other wants / needs / requirements off to the next project / next release

• Attempt to keep the schedule accurate – communicate the time line and the business need / business value – and that completing the project on time is also significant to the business.

Timeboxing

• Another approach to scope management is a technique called timeboxing.

• Timeboxing can be used to deal with shortened time frames. – This technique sets a fixed deadline for a project

and delivers the system by that deadline no matter what, even if functionality needs to be reduced.

Timeboxing

1) Realistic due date2) Build the core of the system, create a sense of urgency, focus on

the most important features3) Quality cannot be compromised.

Managing risk

• The project manager also keeps a close watch on the project risk.

• Risk Management is the process of assessing and addressing the risks that are associated with developing a project.

Managing risk

• Many things can cause risks: – weak personnel– scope creep– poor design– overly optimistic estimates.

Managing Risk

• Risk Assessment - is a document that tracks potential risks along with an evaluation of the likelihood of the risk and its potential impact on the project (Figure 2-22). – should be created and updated to evaluate the

likelihood of various risks and their potential impact on the project.

Managing and Controlling the Project: Managing risk

Kendall & Kendall 3-80

Project Scheduling

• Project managers utilize several tools to help manage projects.

• Gantt Charts– Simple and easy to use– Lends itself to worthwhile communication with end users– The bars representing activities or tasks are Drawn to

scale or indicates the relative length of time• PERT diagrams

– Useful when activities can be done in parallel rather than in sequence

Gantt Chart

• A Gantt chart is a horizontal bar chart that shows the same task information as the project work plan, but in a graphical way. – Sometimes a picture really is worth a thousand words,

and the Gantt chart can communicate the high-level status of a project much faster and easier than the work plan.

• Creating a Gantt chart is simple and can be done with a spreadsheet package, graphics software (e.g., Microsoft VISIO), or a project management package.

Gantt Chart• First, tasks are listed as rows in the chart, and time is listed across the

top in increments based on the needs of the projects.– A short project may be divided into hours or days, whereas a medium-sized

project may be represented in weeks or months. • Horizontal bars are drawn to represent the duration of each task; the

bar’s beginning and end mark exactly when the task will begin and end. • As people work on tasks, the appropriate bars are filled in

proportionately to how much of the task is finished. • Limit tasks to 20 to 30 Too many tasks on a Gantt chart can become

confusing, so it’s best to limit, the number of tasks to around 20 to 30. • Create Subtasks If there are more tasks, break them down into

subtasks and create Gantt charts for each level of detail.

Gantt Chart

• There are many things a project manager can see by looking quickly at a Gantt chart. – see how long tasks are and how far along they are– tell which tasks are sequential– Tell which tasks occur at the same time– Tell which tasks overlap in some way. – a quick view of tasks that are ahead of schedule and behind

schedule• by drawing a vertical line on today’s date. • If a bar is not filled in and appears to the left of the line, that task is

behind schedule.


Figure 3.8 Using a two-dimensional Gantt chart for planning activities that can be accomplished in parallel

Time is indicated on the horizontal dimension.

A description of the activities make up the vertical dimension.

PERT Chart

• PERT chart - a second graphical way to look at the project work plan information.– displays the project tasks in a flowchart. – means Program Evaluation and Review Technique– is a network analysis technique that can be used

when the individual task time estimates are fairly uncertain


Figure 3.12 A completed PERT (Program Evaluation and Review Technique) diagram for

the analysis phase of a systems project

• The length of the arrows has no direct relationship with the activity duration.• Circles are called events and can be identified by numbers, letters, or any other arbitrary form of designation.• The longest path is referred to as the critical path. Although the critical path is determined by calculating the

longest path, it is defined as the path that will cause the whole project to fall behind if even one day’s delay is encountered.

Definition of Terms • The critical path refers to the way the diagram shows those

activities that must be completed, and complete in a specific order, so that the project can be completed successfully and on time. – A series of lines and circles visually depict the critical path.

• Each circle represents an activity that needs to be completed and • each line shows the relationship between two activities.

• The critical path will be the longest path through the diagram, and will show how long a project is expected to take if the scope does not change and everything goes according to plan.

• Slack time In project scheduling, the free time for an activity, or the amount of time an activity can be delayed without delaying the entire project.

• A PERT chart will show which steps in an IT project cannot be delayed without delaying the entire project.

The most useful part of a PERT chart is that you can identify the critical path. To find the critical path, first identify how many paths you can take from the start to the finish. Then, for each path, add up the duration of the steps. If there are 4 paths, you may end up with durations of, for example:Path 1 duration: 12 days (Task 1’s duration plus task 3’s duration)Path 2 duration: 11 days (Task 2’s plus Task 3’ durations)Path 3 duration: 10 days (Task 4’s duration)In this case, path 1 is the critical path because if there is any delay at all in path 1, the entire project will be delayed. The other paths contain slack time so they can experience delays if necessary.

Start

Task A,

4 days

Task A,

4 days

Task A,

4 days

Task A,

4 days

Start

Task A,

4 days

Task A,

4 days

Task A,

4 days

Task A,

4 days

dummy

chap 02 project management.pptx

Documents

project manager

project methodologycreating

monitoring project

project selectiononce

project characteristics

project estimation

project portfolio management

project management chapter