PSIS 4145-IS SP2013 Lecture 2 Project Initiation and Management 20130112

PSIS 4145-IS SP2013 Lecture 2 Project Initiation and Management - Stewart, McDonald.ppt 1
© 2005-2013 M.R. Stewart, E.G. Carayannis, K. Schwalbe Project Initiation and Management LECTURE 2 12-Jan-13 1
Project Initiation
and Management
McDonald R. Stewart
Assistant Professorial Lecturer
Spring 2013
PSIS 4145
Software Systems Development Processes

Project Management Overview
• PM involves complex systems of systems
– There is no one right answer or approach
– There are lots of possibly right answers and approaches
– There are infinitely many wrong answers and approaches
• Scale and Scope
– Impact the combinations and permutations of the solution set
• The cycle of problem avoidance
– Planning
– Measuring
– Evaluating
– Controlling
Plan the work and work the plan
-------------------------------
The plan is a living document that
will be revised as reality unfolds

A Menu of Challenges
• Identifying needs
• Defining requirements
• Forecasting costs
• Scheduling
• Allocating resources
• Navigating politics
– Who are the stakeholders, and what does each want?
• Can everyone always get exactly what they want or need?
– How and by whom are needs and wants “definitized”?
[Definitized is contract jargon meaning “worked out in detail and agreed upon”]
– How are trade-offs negotiated and prioritized?
– Just what is stakeholder mapping, and how does it work?
Opportunity Costs:
Everything involves a trade-off
-------------------------------
Not all cost/benefit decisions are
based on “the bottom line”

• Stakeholders are the people involved in or
affected by project activities
• Stakeholders include:
– The project sponsor
– The project manager
– The project team
– Support staff
– Customers
– Users
– Suppliers
– Opponents to the project
Project Stakeholders
©2009K.Schwalbe–Cengage,
InformationTechnologyProject
Management,6thEdition

Apparent Project
Customer
Organization
Mission
Goals
Objectives
Stake
Project
Sponsoring
Organization
Mission
Goals
Objectives
Stake
Project
Manager &
Team Members
Career Goals
Technical Ability
Personal Stake
Project
Functional
Department
Mission
Goals
Objectives
Stake
Technical Ability
Project Stakeholder / Customer Map
Project Goals, Objectives, Scope
& Technical Nature must be
consistent for all Project
Stakeholders if the project is to
be successful in meeting all of
their expectations and avoiding
scope creep.
Invisible Project
Customer
Organization
Mission
Goals
Objectives
Stake
©2005byE.G.Carayannis,Y.H.Kwak,&F.T.Anbari

Project Planning
• Planning can be a tortuous challenge
– An iterative process yielding better plans from not-so-good plans
– This improvement process can happen in fits and starts
– The planning process may be described formally,
but it does not necessarily occur formally
• Plans map "the path from idea to accomplishment”
– Must have sufficient detail to determine what must be done, step
by step
– But be simple enough that workers are not lost in a welter of
minutiae
Plans are only good intentions unless they immediately degenerate into hard work.
–Peter Drucker

Project Planning Approaches
• Top-Down
– Senior management models new project plans
• Based on high-level heuristics (rules of thumb)
• Often dictate the scope and specifications of technical approach
• Estimate the magnitude of time and cost requirements for categorical project
tasks
• Bottom-Up
– Analysts develop a thorough Work Breakdown Structure
• Apply detailed figures for cost (labor, materials & overhead)
• Forecast every identifiable task component
• Try to evaluate all possible technical configurations
• Middle-Out (or Middle-Up-Down)
– Mid-level managers temper the two with practical field experience
• Stakeholder mapping toward convergence of objectives
• Facilitate and expedite bottom-up analysis with experienced selectivity
• Thoroughly dissect the top-down dictates and respond with substantiated
options
• Forecast feasibility and cost-benefit of 3 to 5 significant alternatives
A badly planned project will take three times longer than expected—a well
planned project only twice as long as expected. –Project Management Proverb

Middle-up-down Knowledge-creation Process
• The success of a project may owe a lot to the very wide gap
between the ideal and the actual
©1995byI.Nonaka&H.Takeuchi

Project Controlling
• Two fundamental objectives of control:
– Regulation of results
– Stewardship of organizational assets
(physical, human, financial)
• Monitoring: Collecting, recording, and
reporting project performance information
— distinct from evaluation or control
• Evaluation: Information collected about system performance is compared
with the desired (planned) level, and differences are identified and quantified
• Control: Action taken if actual and desired performance differ enough that
the manager wishes to decrease the difference
– Control is the act of reducing the difference between the plan and reality
• The costs of dealing with some non-problems are usually minor when
compared to the costs of dealing with real problems too late
Furious activity is no substitute for understanding.
–H.H. Williams

Project Management Fundamentals
Planning + Monitoring + Evaluation + Control » Management
• Metrics and measurement must be:
– Consistent
– Efficient
– In a clear, common language for all stakeholders
• Project Management is more an art than a science
– The Management of Ambiguity
– To the left side of the top equation, add:
Analysis + Reporting + Negotiation + Compromise + Accountability
– What other terms of Project Management art should be included?
• Targeting a relatively small “sweet-spot” in a multi-dimensional
space/time of constraints
– That satisfies the (often conflicting) agendas of many stakeholders
Not everything that counts can be counted, and not everything that can be counted counts.
–Albert Einstein

Inventory of PM Tools
• WBS – Work Breakdown Structure
• Gantt Charts (Bar Charts)
• CPM – Critical Path Method
• PERT – Program Evaluation
& Review Technique
• EVM – Earned Value Management

It doesn't matter how many resources you have; if you
don't know how to use them they will never be enough.
–Author and artist unknown

The Triple Constraint
• Cost
– How much is the predicted project cost? (budget)
– How much is the real cost? (expense)
– What is the acceptable difference? (change order)
– What is the unplanned difference? (overrun)
• Time
– What is the predicted timeline to completion? (schedule)
– What cushions are built in to and between tasks? (slack)
• Scope
– What are the technical deliverables? (specifications)
– How do the stakeholders interpret these? (expectations)

The Relationship of Cost, Time & Scope
• Cheap and fast
compromises technical
performance
• Challenging technical
scope on the cheap takes
forever
• Challenging technical
scope done fast costs a
fortune
A Three-Dimensional Challenge
• Financial performance
– Budgetary compliance
– Profitability
• Schedule performance
– Timeliness
• Technical performance
– Scope
– Specifications

Successful project
management means
meeting all three
goals (scope, time,
and cost) – and
satisfying the
project’s sponsor!
The Triple Constraint of
Project Management (Schwalbe, Fig. 1-1)

0
20
40
60
80
Cost
Weeks Months Years t =>
Trivial Scope
More Difficult
Most Challenging
The 3-D Relationship of Cost, Time & Scope
Uncontrolled projects will violate one or more
constraint — leading to partial or total failure.

Or is it a Quintuple Constraint?
• Cost, Time, Scope
• Quality
• Reliability
Short TermProject Mid Term Long Term
}The implications of Scope post-delivery
and the reality of life-cycle Cost
The bitterness of poor quality lasts long after the sweetness of making the due date is forgotten.
–Project Management Proverb

Project Slack
• “Extra Time” forecast for project tasks
– Within task estimates (in node)
– Between task schedulings (between node)
• Suboptimization of resource allocation
– Want as little as possible, but as much as needed
• Project forecasts are imperfect and contingent
– Tangibles vs. Intangibles
– Risk vs. Uncertainty
– Comparable Experience vs. Educated Guesswork
– Expectations vs. Reality
Work expands to fill the time available for its completion. –Parkinson's law

Productivity vs. Slack
• Productivity (a measure of value)
– Efficiency
• Output
Input
– Effectiveness
• Performance to standards
(The quintuple constraint)
• On time
• Under budget
• To specification
• With quality
• And reliability
• Productivity is the yield from
resources input to the system
– Drivers of Productivity
• Competitiveness
• Human Capital
• Financial Capital
• Social Capital
• Intellectual Capital
• Management
• Technology
• Slack is like system entropy
• Like the energy that’s lost when
converting coal to electricity
• Productivity is the traction
• Slack is the slippage

The Irony of Progress
• Systems development is a discipline of deploying
information and communications technologies
(ICT) to bring mechanical structure and order to
messy human business processes
– Sometimes people and organizational cultures resist this
discipline
• To work with and around human resistance, the
systems developer (or IS manager) must revise the
imposition of order into an insinuation of order
– As systems intelligence (“user friendliness”) evolves, the
machine-based structure and order becomes more
organic
• User-friendliness is a coevolutionary strategy to
insinuate human messiness into mechanistic structure
and order!

An Ideological Proposition
• As systems intelligence (“user friendliness”)
evolves, technology options become more fluid,
dynamic, and interchangeable
– But the only guarantee that technology can always
make is this:
• At some point it will fail
• Cultural influences are pervasive and least
responsive to change
– At all levels, from national, societal and regulatory,
down to office politics and policies
• People are therefore the pivotal determinant of
system success or failure
– Whatever the proposition or venue:
• Systems development, IS management, or IT project
management
– Professionalism is a set of behaviors that have
evolved to compensate for the inevitability of
human failures.
CP
T
The “Mickey Mouse” Venn diagram
of People, Culture and Technology
© 2001-2011, E.G. Carayannis
Unaffiliated with actual Mickey
Mouse, © Walt Disney Corporation

Technophobia
Dystechnia
Some People Perspectives
• Never underestimate the human element
– Technology embodies the cumulative sum of human learning
– But without the human context technology is merely an artifact
• People who purchase technology often discount this simple
principle
– Or flatly deny it
– Or simply don’t know what’s really available
– Or don’t know what they want or really need
• Systems analysts and designers don’t always interpret the
buyers’ or users’ requirements correctly or effectively, either
• People are optimistic and imaginative, and like to be served
– Which is why science fiction is so popular, especially where
machines make life easier
• Technology acquisitions too frequently suffer under a
delusion of panacea
– Which accordingly too often becomes Pandora’s box

More People Perspectives
• What users want to buy can not always
be supported by the state of existing
technology
– “Phantasmagoria”
• Likewise, what vendors want to sell can
not always be supported by the state of
existing technology
– “Vaporware”
• Science fiction or technology fact?
– What ever became of
• Artificial Intelligence?
• The “paperless” office?
• Picturephones?
• Bubble memory?
• Teracubes?
• Technological realities often do not dovetail
with people’s expectations

People on the Outside
• Stakeholders are always people!
– Even stakeholders that are organizations are populated by individual people
• Managing systems development projects demands much patience and
education
– The developer must be educated and patient enough:
• To learn what the users’ real requirements are
• To conceptualize and propose a feasible solution
• To educate the sponsor and buyer (not just the users, but the decision makers)
– After the decision makers are educated enough to commit to the project, then all of
the users must also be educated in how to use the technology
• Post-implementation customer service will always be a requirement
– Whether customers are internal or external
• And always demands a continuing customer education or re-training component
– “Customer support hot line”
• Managing systems development projects demands prudence and savvy
– To manage expectations
– And to balance expectations against reality
• Managing systems development projects demands ongoing developer
education and training
– To stay abreast of technological and environmental developments
• The Manager must stay on top of tools, resources, technology change
• And evolving Stakeholder interests, needs, and capabilities

Outside People Drive Life-Cycle Costs
• All of those outside people
– Along with their various agendas
– And the constraints and impediments that also come with
• Very much influence the life-cycle cost of systems
development
– And aggravate risk and uncertainty
– As suggested under the concept of quintuple constraint
Short TermProject Mid Term Long Term

• The IS Manager has the most control over people involved
on his/her own project
– Develop a human resource plan:
• Identify and document project roles, responsibilities, and reporting
relationships
– Acquire the project team:
• Get the needed personnel
• Embrace diversity
• Be excruciatingly selective
– The worst mistake is a hiring error!
– Develop team capacity and capabilities:
• Build individual and group skills to enhance project performance
– Manage the project by managing the team:
• Track team member performance, motivate team members,
provide timely feedback, resolve issues and conflicts, and
coordinate changes to enhance project performance
People on the Inside

Sample Org Chart for Large IS Project

Work Definition and Assignment Process

A Schematic WBS for an IS Project
PROGRAM
XYZ
1.0
SYSTEM
DESIGN REVIEW
1.2.1
SYSTEM
REQ. REVIEW
1.1.1
PRELIMINARY
DESIGN
1.3.1
DETAILED
DESIGN
1.3.2
SOFTWARE
INTEGRATION
1.3.4
CODING
1.3.3
DESIGN
1.3.1.1
DESIGN
REVIEW
1.3.1.2
CODING
MILESTONES
1.3.3.1
CODING
ROUTINES
1.3.3.2
DEVELOP
TEST
1.3.4.1
VALIDATION
TEST
1.3.4.2
CODING
1.3.3.2.1
IN-HOUSE
TEST
1.3.4.2.1
CUSTOMER
TEST
1.3.4.2.2
SYSTEM
DEVELOPMENT
1.3
Level 1
Level 2
Level 3
Level 4
DESIGN
1.3.2.1
DESIGN
REVIEW
1.3.2.2
Level 0
SYSTEM
CONCEPT
1.1
SYSTEM
DEFINITION
1.2

A Tabular WBS (for same IS Project)
1.0 Program XYZ Level 0
1.1 System Concept Level 1
1.1.1 System Requirements Review Level 2
1.2 System Definition Level 1
1.2.1 System Design Review Level 2
1.3 System Development Level 1
1.3.1 Preliminary Design Level 2
1.3.1.1 Design Level 3
1.3.1.2 Design Review Level 3
1.3.2 Detailed Design Level 2
1.3.2.1 Design Level 3
1.3.2.2 Design Review Level 3
1.3.3 Coding Level 2
1.3.3.1 Coding Milestones Level 3
1.3.3.2 Coding Routines Level 3
1.3.3.2.1 Coding Level 4
1.3.4 Software Integration Level 2
1.3.4.1 Develop Test Level 3
1.3.4.2 Validation Test Level 3
1.3.4.2.1 In-House Test Level 4
1.3.4.2.2 Customer Test Level 4

Work Package Example

Building Upward from the WBS
• WBS serves as the basis for managerial and
technical planning, including assigning
responsibilities
– From the WBS, the PM can construct:
• Linear Responsibility Chart or a Responsibility Assignment
Matrix
• Master Production Schedule (MPS)
• WBS defines the molecular building blocks of the
entire project
– These components are assembled, integrated, and monitored
using estimating and scheduling tools
• MRP – Materials Requirements Planning
• Gantt Charts (Bar Charts)
• CPM – Critical Path Method
• PERT – Program Evaluation & Review Technique

Using the WBS to Forecast Costs
Labor = (Hours + Slack)*Wage Rates
+ Benefits, Taxes, Insurances
Burdened Labor Cost
+ Other Direct Costs (ODCs = Equipment + Supplies)
Total Direct Costs
+ General & Administrative Expenses (G&A)
Total Project Costs
+ Profit or Fee
TOTAL PRICE
Refer also to
accompanying
Excel file

Gantt Charts
• Developed around 1917 by Henry L. Gantt, a
pioneer in scientific management
– Depicts planned and actual progress of a project
• Any number of tasks
• Horizontal time scale
– Easy to read method
• Comparing current against predicted
• Keeping track of what’s done
– Helpful in expediting, sequencing, reallocating resources
• Symbolically highlights items of special concern
NOTE: PMBOK and now many PM software
products refer to Gantt Charts as simply
“Bar Charts”. This is their weakness, and
not a weakness of the method.

From WBS to Master Schedule
• First steps were:
– Work Breakdown Structure (hierarchical lists)
– Linear responsibility charts
– Work package identification
• Now build a table for the Project Master Schedule
– Down the left side:
• WBS subprojects
• Major tasks
• Responsibilities assignments
– Across the top:
• Linear calendar grid
– Resolution of each should be fairly coarse for the Master Schedule
• The Gantt Chart is for the finer detail

Master Schedule – Shell
Subproject Task
Responsible
Depts.
Dependent
Depts. J F M A M J J A S O N D
Determine
specifications
A
1
Widget Industrial
Engineering
A
2
Gizmo Project
Engineering
Industrial
Engineering
Solicit quotations
and source
vendors
B
1
Issue RFPs P.E.,
Contract Mgt.
Finance, I.E.,
Purchasing
B
2
Evaluate bids I.E., Purchasing Contract Mgt.,
P.E., P.M.
Installation and
startup
C
1
Screen & hire
staff
H.R. P.M.
C
2
Award sub-
contracts
Purchasing,
Contract Mgt.
P.M.
C
3
Equipment
installation
P.E., Program Plant
C
4
Training H.R., P.E., P.M. Plant, Q.C.

Legend of Symbols
[ Scheduled Start
] Scheduled Finish
 Actual Progress
 Unavailable
 Current Date
 Milestone Scheduled
 Milestone Achieved
 Miller Time
Customization
is limited only
by the P.M.’s
creativity and
imagination
(or software)

Master Schedule – Example
Subproject Task
Responsible
Depts.
Dependent
Depts. J F M A M J J A S O N D
Determine
specifications
A
1
Widget Industrial
Engineering
A
2
Gizmo Project
Engineering
Industrial
Engineering
Solicit quotations
and select
vendors
B
1
Issue RFPs P.E.,
Contract Mgt.
Finance, I.E.,
Purchasing
B
2
Evaluate bids I.E., Purchasing Contract Mgt.,
P.E., P.M.
Installation and
startup
C
1
Screen & hire
staff
H.R. P.M.
C
2
Award sub-
contracts
Purchasing,
Contract Mgt.
P.M.
C
3
Equipment
installation
P.E., Program Plant
C
4
Training H.R., P.E., P.M. Plant, Q.C.

Master Schedule to Gantt Chart
• The Gantt Chart magnifies the Master Schedule
detail
– Rows are inserted to subdivide tasks into activities and work
packages
– Columns are inserted to subdivide months into weeks and
days
– Columns can also be inserted to enlarge the detail in the left
end task/activity descriptors
• Start Date, End Date, and Duration
• Dependency path linkages (predecessor relationships)
• All of the foregoing can be done manually
– And has been, for nearly a century

Gantt Chart – Example
Task Code Duration Start Date Predecessors M T W T F S S M T W T F S S M
D1 D1.1.a 2 days 05/01/06 C2
D1.1.b 3 days 05/03/06 D1.1.a
D1.1.c 0 days 05/03/06 D1.1.b
D1.2.a 4 days 5/08/06 D1.1.c
D1.2.b 0 days 05/12/06 D1.2.a
D2 D2.1 3 days 05/08/06 D1.1.c
D2.2.a 1 day 05/11/06 D2.1
D2.2.b 5 days 05/12/06 D2.2.a
D2.3 8 days 05/11/06 D2.1
Apr 30, 2006 May 7, 2006 14…

Intro to PDM/CPM and ADM/PERT
• Both techniques developed in the 1950s
– CPM created by M.R. Walker of DuPont Inc.
in 1957 for construction of chemical plants
– PERT created by Booz-Allen Hamilton and Lockheed
Corp. in 1958 to guide development of the Polaris
submarine-launched ballistic missile
• Key concept for both techniques is precedence
– Denotes which activities must be completed (predecessors) before
another task can be completed
– Note that in some cases, the later task can be initiated before the
predecessors are complete
• Both techniques renamed in 2005
– CPM → Precedence Diagram Method (PDM)
– PERT → Arrow Diagram Method (ADM)

Use of Networks in Diagramming
• A project diagram is constructed as a network where activities
are connected based on their dependencies
– Objective is to provide a temporal diagram to denote the exact
order of activities
• Diagram can use activity-on-node (AON) or activity-on-arrow
(AOA) format
– PDM/CPM uses AON—node denotes activity and completion, while
arrow denotes order of events
– ADM/PERT uses AOA—arrow denotes the activity itself, while node
denotes completion of the activity
– Difference is mostly stylistic

Sample Project: Gantt View

PDM/CPM Network Diagram
in PM Software
• Sample report output from MS Project software (MSP)

Critical Path Method (CPM)
• CPM focuses on scheduling
– First used to plan maintenance shutdown
of a plant—reduced downtime from
125 hours to 93 hours
– Primarily used today in the
construction industry
• Addresses issue of determining
which tasks/activities are
critical versus ancillary
• Based on a single time
estimate for each activity

Why PDM/CPM?
• Two key objectives of CPM usage
– Determine the minimum time required to complete a
project
– Determine what activities are the primary source of
delays, so that resource allocation can be prioritized
• CPM helps us to focus on those tasks which are of
utmost importance to project completion
– Superior to Gantt charts by reducing complexity
– Tracks relationships among activities in both time and
cost

Time Estimates in PDM/CPM
• Analyze each activity in isolation
– Identify “start” activities (those with no predecessors)
– Calculate minimum time to complete
• Determine required order of activities
– Determine earliest start (ES) based on which predecessors
must be completed before start
– ES + completion time = Earliest finish (EF)
• Critical path is the sequence of activities with the latest EFs
which lead to the activity that ends the project
– The longest timeline through the task network

Slack or Float in CPM
• Slack (aka float) in an activity is the
amount of time that the activity can be delayed without
delaying project completion
• Slack is determined by estimating the difference between
ES and “latest start” (LS)
– LS can be found by identifying the latest finish (LF) date for the
activity which does not affect the critical path, and subtracting
the time-to-completion
– Note: CP activities by definition have zero slack
• Slack provides an estimate of the “safety cushion” in
completing a given task, which assists in resource allocation

Program Evaluation &
Review Technique (PERT)
• ADM/PERT differs from CPM
by introducing probability
into time estimates
• PERT was developed for projects
with a high degree of uncertainty
and complexity, to assist in budgeting and
scheduling
• Commonly used today in research & development
projects and similar high-risk areas

Why ADM/PERT?
• Use of probabilistic estimates instead of
deterministic estimates is more realistic
• ADM/PERT provides a bounded range for
project costs and scheduling, rather than a
single number
• PERT gives a better view of resources that can
be diverted from one activity to the critical path
without affecting the completion date

In-Class Exercise
• Prepare a PERT chart for the following worksheet:
• Determine:
• The successors
• The Expected Completion Time
• The Latest Expected Completion Time
• The Slack Time
• Whether the Task is on the Critical Path
• Draw the PERT Chart
• Distinguish the Critical Path on your PERT Chart
Task Pred Succ TE TL TE Slack C-Path
1 Requirements Collection 2,3 5 5 5
2 Screen Design 1 4 11 11 6
3 Report Design 1 4 11 11 6
4 Database Design 2,3 5,6 13 13 2
5 User Documentation 4 8 18.5 21 5.5
6 Programming 4 7 18 18 5
7 Testing 6 8 21 21 3
8 Installation 5,7 22 22 1

PSIS 4145-IS SP2013 Lecture 2 Project Initiation and Management 20130112

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to PSIS 4145-IS SP2013 Lecture 2 Project Initiation and Management 20130112

Similar to PSIS 4145-IS SP2013 Lecture 2 Project Initiation and Management 20130112 (20)

PSIS 4145-IS SP2013 Lecture 2 Project Initiation and Management 20130112