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.

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 departments 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 projects 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.

 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.

 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).

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

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

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
PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

2 - 20

Waterfall Development
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
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.
2 - 22

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

Waterfall Development 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

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.

V-model

2 - 24

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

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 Prototyping b. Iterative development c. 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

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

2 - 29

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

RAD: Throwaway Prototyping

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.

2 - 30

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

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).

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

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

Extreme Programming

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
PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

2 - 33

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
2 - 35
PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

Selecting the Appropriate Development Methodology

2 - 36

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John

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 Edition Copyright 2009 John Wiley & Sons,

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 peoples skills with the needs of the project
Determining the technical skills needed on the project

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

Staffing the Project

Matching peoples 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

Staffing the Project

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)

Staffing the Project

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 projects objectives and rules or lists the projects norms and ground rules.

Increasing Complexity with Larger Teams

A two-person team has single line of communication.

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

Staffing levels will change over a projects lifetime Adding staff may add more overhead than additional labor Using teams of 8-10 reporting in a hierarchical structure can reduce complexity 2 - 49

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

A functional lead manages a group of analysts A 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 peoples 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 skills

PowerPoint Presentation for Dennis, Wixom & Roth Systems Analysis and Design, 4th Edition Copyright 2009 John 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 placethe history of the project.

CASE Tools
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 2 - 57 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 specificationsas long as it is used by trained developers who have applied CASE on past projects.

CASE Components
Diagrams Screen Designs

CASE Repository
The central component of any CASE tool. (otherwise known as data dictionary or information repository)
Procedural Logic
CASE repository stores the diagrams and other project information, such as screen and report designs, and it keeps track how the diagrams fit 2 - 62 together.

Metadata
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

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 Edition Copyright 2009 John

2 - 65

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 dont inflate time estimates 2) Failing to monitor the schedule require report progress 3) Failing to update the schedule - revise the schedule 4) 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 date 2) Build the core of the system, create a sense of urgency, focus on the most important features 3) 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 risk

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
Kendall & Kendall 3-80

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 mediumsized project may be represented in weeks or months.

Horizontal bars are drawn to represent the duration of each task; the bars 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 its 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 todays 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
A description of the activities make up the vertical dimension.

Time is indicated on the horizontal dimension. Kendall & Kendall 3-84

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 days delay is encountered.
Kendall & Kendall 3-86

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 1s duration plus task 3s duration) Path 2 duration: 11 days (Task 2s plus Task 3 durations) Path 3 duration: 10 days (Task 4s 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.

Task A, 4 days

Start
Task A, 4 days

Task A, 4 days

Task A, 4 days

dummy

Task A, 4 days

Start
Task A, 4 days

Task A, 4 days

Task A, 4 days

Kendall & Kendall

3-92