Project Selection and

Management
SYSTEMS ANALYSIS AND DESIGN, 6 TH EDITION
DENNIS, WIXOM, AND ROTH

1
Learning Objectives
❑ Explain how projects are selected in some organizations.
❑ Describe various approaches to the SDLC that can be used to structure a
development project.
❑ Explain how to select a project methodology based on project characteristics.
❑ Become familiar with project estimation.
❑ Be able to create a project work plan.
❑ Describe project staffing issues and concerns.
❑ Describe and apply techniques to coordinate and manage the project.
❑ Explain how to manage risk on the project.

2
Project Selection
HOW SPECIFIC PROJECTS ARE CHOSEN

3
Project Selection Issues
❑ Ways to Characterize Projects
o Size: What is the size? How many people are needed to work on the project?
o Cost: How much will the project cost the organization?
o Purpose: What is the purpose of the project? Is it meant to improve the technical
infrastructure? support a current business strategy? improve operations? demonstrate a new
innovation?
o Length: How long will the project take before completion? How much time will go by
before value is delivered to the business?
o Risk: How likely is it that the project will succeed or fail?
o Scope: How much of the organization is affected by the system? A department? a
division? the entire corporation?
o Economic Value: How much money does the organization expect to receive in return for
the amount the project costs?

4
Project Selection Issues
❑ The approval committee has the responsibility to evaluate
❑ not only the project’s costs and expected benefits,
❑ but also the technical and organizational risks associated with the project.
❑ Approval committee uses the system request and the feasibility study
❑ To examine the business need (found in the system request) and the project risks (described in the
feasibility analysis).
o Project portfolio perspective – how does the project fit within the entire portfolio of projects?
o A good project portfolio will have the most appropriate mix of projects for the organization’s needs
o e.g. For example, an organization may want to keep high-risk projects to a level less than 20% of its total project
portfolio.
o Trade-offs needed: select projects to form a balanced project portfolio.
o The approval committee must be selective about where to allocate resources, because the organization has limited
funds.
o E.g. If there are three potentially high-payoff projects, yet all have very high risk, then maybe only one of the projects
will be selected.
o Viable projects may be rejected or deferred due to project portfolio issues.
o There are times when a system at the project level makes good business sense, but it does not at the organization
level
o E.g. because there is no money in the budget for another system
o the organization is about to go through some kind of change (e.g., a merger, an implementation of a company-wide
system like an ERP)
5
Project Portfolio Management
❑ Project portfolio management (PPM) is the process of selecting, prioritizing, and monitoring project
results.
❑ Software for PPM, such as Hewlett Packard’s Project and Portfolio Management, Primavera Systems’
ProSight have become a valuable tool for IT organizations.
❑ PPM software collects and manages information about all projects – on-going and awaiting
approval.
❑ Portfolio management takes into consideration the different kinds of projects that exist in an
organization—large and small, high risk and low risk, strategic and tactical (refer slide 4).
❑ Benefits companies by staying upto date on projects and adapt to changing conditions.
❑ Features: project prioritization, employee allocation, real-time project monitoring, flagging cost and
time variances, monitoring economic feasibility.
❑ A good project portfolio will have the most appropriate mix of projects for the organization’s needs.

6
Creating the Project Plan
❑ Once a project is approved, the project manager
must:
o Select the best project methodology
o Develop a project work plan
o Establish a staffing plan
o Create ways to coordinate and control the project

7
Creating the Project
Plan
DEVELOPING A PLAN FOR A SUCCESSFUL RESULT

8
Selecting a Project Methodology
❑ Methodology: A formalized approach to implementing
the SDLC (i.e. a series of steps to perform and deliverables to
produce)
❑ Methodology Sources
o Internally developed by organizations, refined over the years
o Consulting firms
o Software vendors
o formal standards used by government agencies

9
Selecting a Project Methodology -
Issues
❑ These factors influence the best choice:
o Clarity of User Requirements
o Familiarity with Technology
o System Complexity
o System Reliability
o Time Frame
o Schedule Visibility

10
Structured Systems Development
❑ Based upon SDLC
❑ Assumes a project phase is complete before moving to
the next phase
o Waterfall Development
o Parallel Development
o V-model
❑ Goal – doing each phase thoroughly before moving
forward ensures correct and high-quality outcomes
11
Waterfall
Development
Methodology
o analysts and users proceed
sequentially from one phase to the
next

o Emphasis on deliverables from one

phase flowing into the next phase

o The key deliverables for each phase

are presented to the approval
committee and project sponsor for
approval as the project moves from
phase to phase

12
 Waterfall Methodology Assessment
STRENGTHS
 System requirements identified long before
programming begins
 Requirements are “frozen” as project proceeds
WEAKNESSES
 Must wait a long time before there is “visible” evidence
of the new system
 a long time elapses between the completion of the
system proposal in the analysis phase and the delivery
of system
 testing is treated almost as an afterthought in the
implementation phase
 If the project team misses an important requirement,
expensive post-implementation programming may be
needed

In today’s dynamic business environment, a system that met the existing environmental conditions during the analysis
phase may need considerable rework to match the environment when it is implemented. This rework requires going
back to the initial phase and making needed changes through each of the subsequent phases in turn.

13
Parallel
Development
Methodology
o Evolved to address the lengthy time
frame of waterfall development

o Subdivide the project into

subprojects that can be worked on
at the same time.

o Once all subprojects are complete,

there is a final integration of the
separate pieces, and the system is
delivered

o Reduce the overall project length

14
Parallel Methodology Assessment
STRENGTHS WEAKNESSES

 Reduces overall project time (compared to
Waterfall)
 Reduces the need for rework; with shorter
time frame, less chance of requirements
changing
 Creating subprojects requires careful design
decisions
 Integrating subprojects at the end can be
complex and difficult

15
V-Model
Development
Methodology
o another variation of waterfall
development that pays more explicit
attention to testing
o the development process proceeds
down the left-hand slope of the V,
defining requirements and designing
system components.
o At the base of the V, the code is
written.
o On the upward-sloping right side of
the model, testing of components,
integration testing, and, finally,
acceptance testing are performed.
o A key concept of this model is that
as requirements are specified and
components designed, testing for
those elements is also defined.
o 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 and
maximize test effectiveness.
16
V-Model Methodology Assessment
STRENGTHS WEAKNESSES

 Simple and straightforward  suffers from the rigidity of the waterfall

development process,
 Quality improves through the emphasis on
testing  Difficult to use in a dynamic business
environment
 Including Quality Assurance expertise early
in the project strengthens system quality

17
Rapid Application Development
❑ It is a collection of methodologies that emerged in response to the weaknesses of waterfall
development and its variations.
❑ Incorporate special techniques and 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. e.g.
o CASE (computer-aided software engineering) tools
o JAD (joint application development) sessions
o Visual programming languages
o Code generators

While RAD can improve the speed and quality of systems development, it may also introduce a problem in managing user
expectations.
As systems are developed more quickly and users gain a better understanding of information technology, user expectations
may dramatically increase and
system requirements may expand during the project (sometimes known as scope creep or feature creep).

❑ Goal – get some portion of system developed quickly and in the users’ hands

18
Three RAD Approaches
❑ Iterative development
o breaks the overall project into a series of versions that are
developed sequentially
o The most important and fundamental requirements are bundled
into the first version of the system.
o 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.

19
Iterative
Development
Methodology
o RAD approach

o Develop system in series of

versions

20
Iterative Development Methodology
Assessment
STRENGTHS WEAKNESSES

 Users get a system to use quickly
 Users identify additional needs for later
versions based on real experiences with
current version
 Users faced with using an incomplete
system for a time
 Users must accept that only the most critical
requirements of the system will be available
in the early versions
 Users must be patient and wait for fully-
functional system

21
Three RAD Approaches (cont’d)
❑ System Prototyping
o 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.
o The system prototype is a “quick and dirty” version of the system and provides
minimal features.
o Create prototype (model) of system and “grow” it into the final system
o By following reaction and comments from the users, the developers reanalyze, redesign, and
reimplement a second prototype that corrects deficiencies and adds more features
o The approach is very useful when users have difficulty expressing
requirements for the system.
o A disadvantage is the lack of careful, methodical analysis prior to making design
and implementation decisions.

22
System
Prototyping
Development
Methodology
o RAD approach

o Create a rough version of system

quickly and “grow” it into final
system with repetitive refinement

23
System Prototyping Methodology
Assessment
STRENGTHS
 Users get to work with prototype very
quickly
 Feedback cycles let users identify changes
and refine real requirements
WEAKNESSES
 Superficial analysis may cause problems
 Initial design decisions may be poor
 Overlooked features may be hard to add
later
24
Three RAD Approaches (cont’d)
❑ Throw-away prototyping
o Prototype alternative designs in an experimental way
o 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)
o A design prototype is not intended to be a working system.
o Build system following prototype design but discard the actual prototype
o requires several design prototypes during the analysis and design phases.
o Each of the prototypes is used to minimize the risk associated with the system
by confirming that important issues are understood before the real system is built.
o Once the issues are resolved, the project moves into design and implementation.
o At this point, the design prototypes are thrown away

25
Throwaway
Prototyping
Development
Methodology
o RAD approach

o Adds emphasis on experimenting

with design options before design
is finalized

o Design options are thrown-away,

but learning from them is factored
into final design

26
Throwaway Prototyping Methodology
Assessment
STRENGTHS WEAKNESSES

 Uncertainty is minimized  May take longer (compared to system

prototyping)
 Important issues are understood before
building the final system

27
Agile
Development
Methodologies
o is a group of programming-centric
methodologies that focus on
streamlining the SDLC
o Much of the modeling and
documentation overhead is
eliminated; instead, face-to-face
communication is preferred
o popular approaches to agile
development include Extreme
Programming (XP), Scrum, and
dynamic systems development
method (DSDM)
o Focus on short cycles (one to four
weeks) that produce a complete emphasizes simple, iterative application development in which every iteration is a
software product
o Highly adaptable in dynamic
complete software project, including planning, requirements analysis,
environments design, coding, testing, and documentation.

28
Agile Methodologies Assessment
STRENGTHS WEAKNESSES

 Fast delivery of results  Requires discipline

 Works well in projects with undefined or  Significant user involvement is essential
changing requirements
 Initial high learning curve
 Works best in smaller projects

29
Selection Summary
Waterfall Parallel V-Model Iterative System Throwaway Agile
Ability to develop Proto- Prototyping Develop-
systems typing ment

With unclear user Poor Poor Poor Good Excellent Excellent Excellent
requirements

With unfamiliar Poor Poor Poor Good Poor Excellent Poor

technology

That are complex Good Good Good Good Poor Excellent Poor

That are reliable Good Good Excellent Good Poor Excellent Good

With a short time Poor Good Poor Excellent Excellent Good Excellent
schedule

With schedule Poor Poor Poor Excellent Excellent Good Good

visibility

30
Project Management
Tasks
PREPARING TO LAUNCH THE PROJECT

31
Project Manager’s Balancing Act
Project Management
involves making trade- Project Size
offs…

Modifying one element

requires adjusting the others

32
Project Estimation
❑ The process of assigning projected values for time and effort
❑ Estimation can be performed manually or with the help of an estimation
software package like Construx Estimate,TM Costar,TM or
KnowledgePLAN, to name a few.
❑ Sources of estimates
o Methodology in use
o taken from projects with similar tasks and technologies
o Experienced developers
❑ Estimates begin as a range and become more specific as the project
progresses
o Industry standards
o Function point estimation (discussed in Chapter 4)

33
 Project Estimates Using Industry
Standard Percentages
INDUSTRY STANDARD PERCENTAGES EXAMPLE
IF 4 months are required for Planning, then

15% X = 4, where X = overall length of project

X = 4 / 15%

X = 26.66 months for entire project

Therefore:
◦ Planning (15%): 4 months
◦ Analysis (20%): 5.33 months
◦ Design (35%): 9.33 months
◦ Implementation (30%): 8 months

◦ Total Project Length: 26.66 months

The obvious limitation of this approach is that it can be difficult to take into account the specifics of your individual
project, which may be simpler or more difficult than the “typical” project.
34
Devoloping the Work Plan
❑ Once a project manager has a general idea of the size and
approximate schedule for the project, he or she creates a work
plan
❑ It 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
❑ To create a work plan, the project manager identifies the tasks
that need to be accomplished and determines how long each one
will take

35
Identifying Tasks
The overall objectives for the system were recorded on the system
request, and the project manager’s job is to identify all the tasks
that will be needed to accomplish those objectives.

❑ Use established guidelines – existing methodologies

❑ Use analogies – model previous projects’ task lists
❑ Top-down approach – break high level tasks into smaller, detailed
subtasks
❑ A list of tasks hierarchically numbered in this way is called a work
breakdown structure

36
Typical
Workplan Entry

It shows the type of task information needed, including when it needs to be

completed, the person assigned to do the work, and any deliverables that will
result.

37
Project Work Plan

38
Project Work Plan

39
 Staffing Considerations
❑ Match skills to project needs whenever possible
❑ Consider technical skills and interpersonal skills
o All IS work is done in teams
o Technical skills are not sufficient – need to be able to
work with others
o Use training and outside sources (consultants, vendor
support) when skills are not readily available
❑ Staffing levels will change over a project’s lifetime
❑ Adding staff adds overhead; not always productive

40
Motivation
❑ Use monetary rewards cautiously
❑ Use intrinsic rewards
o Recognition
o Achievement
o The work itself
o Responsibility
o Advancement
o Chance to learn new skills

© 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 41

Motivation
❑ Consider the “de-motivators” … DO NOT
o Assign unrealistic deadlines
o Ignore good efforts
o Accept a low-quality product
o Give everyone on the project the same raise
o Make an important decision without the team’s input
o Maintain poor working conditions

© 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 42

Assuring Group Performance
❑ Make sure team understands the project and its goals
❑ Establish operating procedures (Project Charter)
o Availability
o Status reporting
o Meetings
❑ Ensure that team members get to know each other
❑ Establish methods for dealing with problems

© 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 43

Project Estimates Require Refinement
oEven projects with high-quality
estimates will need refinement
oProject managers must adjust
estimated time throughout the
project

© 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 44

Managing Scope
❑ Beware of scope creep
❑ Use JAD and prototyping to minimize scope creep pressure
❑ Implement formal change approval process
❑ Defer additional requirements as future system enhancements

© 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 45

Timeboxing
❑ Time estimating techniques may reveal that the project requires
more time than we have available
❑ Timeboxing helps in these situations
o Set a tight but realistic deadline. Identify core, essential functional
requirements
o Team limits its focus just to essential functions
o High quality is stressed
o Other functions will be added later
o Repeat to add refinements and enhancements

© 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 46

When a Target Date is Missed…
❑ Don’t assume you can catch up
❑ The ONLY situation in which you can make up time is when:
o The remainder of the project is simpler than the part you fell behind on, and
o The remainder of the project is simpler than you expected when the original
estimates were made.
❑ Evaluate the complexity of the remainder of the project to
determine the correct schedule adjustment.
❑ Adding people is not always the right way to handle schedule
slippages.

© 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 47