SoftwareProjectManagement New

DANANG UNIVERSITY OF TECHNOLOGY
FACULTY OF INFORMATION TECHNOLOGY
SOFTWARE PROJECT MANAGEMENT

VO TRUNG HUNG, Ph.D. Associate Professor Tel.: (84)511- 3841292, (84)511- 3847373, Fax.: (84)511- 3842771 E-mail: vthung@dut.udn.vn, hung.vo-trung@ud.edu.vn
Principles of Project Management
References
Rapid Development, Steve McConnell Information Technology Project Management, Kathy Schwalbe Quality Software Project Management, D. Shafer Software Project Survival Guide, Steve McConnell Peopleware, T. DeMarco and T. Lister

Session 1: Introduction, Fundamentals, Classic Mistakes
Basics
Essential elements of software project management Practical, rapid development focus Real-world case studies
And other examples like job interviews
Highly interactive
Job Fundamentals
Skills required PM Positions and roles The process
Project Management Skills

Leadership Communications Problem Solving Negotiating Influencing the Organization Mentoring Process and technical expertise
Project Manager Positions

Project Administrator / Coordinator Assistant Project Manager Project Manager / Program Manager Executive Program Manager V.P. Program Development
Software Project Management

Management Project Management
Software Project Management
Project Management
Whats a project? PMI definition
A project is a temporary endeavor undertaken to create a unique product or service
Progressively elaborated
With repetitive elements
A project manager
Analogy: conductor, coach, captain
Project vs. Program Management

Whats a program? Mostly differences of scale Often a number of related projects Longer than projects Definitions vary Ex: Program Manager for MS Word
10
Interactions / Stakeholders
As a PM, who do you interact with? Project Stakeholders
Project sponsor Executives Team Customers Contractors Functional managers
11
PM Tools: Software
Low-end
Basic features, tasks management, charting MS Excel, Milestones Simplicity
Mid-market
Handle larger projects, multiple projects, analysis tools MS Project (approx. 50% of market)
High-end
Very large projects, specialized needs, enterprise AMS Realtime Primavera Project Manager
12
Tools: Gantt Chart
13
Tools: Network Diagram
14
PMIs 9 Knowledge Areas

Project integration management
Scope Time Cost Quality Human resource Communications Risk Procurement
15
First Principles
One size does not fit all Patterns and Anti-Patterns Spectrums
Project types Sizes Formality and rigor
16
Why Rapid Development

Faster delivery Reduced risk Increased visibility to customer Dont forsake quality
17
Strategy
Classic Mistake Avoidance Development Fundamentals Risk Management Schedule-Oriented Practices
18
Four Project Dimensions

People Process Product Technology
19
Trade-off Triangle
Fast, cheap, good. Choose two.
20
Trade-off Triangle
Know which of these are fixed & variable for every project
21
People
Its always a people problem Gerald Weinberg, The
Secrets of Consulting
Developer productivity: 10-to-1 range Improvements:

Team selection Team organization Motivation
22
People 2
Other success factors
Matching people to tasks Career development Balance: individual and team Clear communication
23
Process
Is process stifling? 2 Types: Management & Technical Development fundamentals Quality assurance Risk management Lifecycle planning Avoid abuse by neglect
24
Process 2
Customer orientation Process maturity improvement Rework avoidance
25
Product
The tangible dimension Product size management Product characteristics and requirements Feature creep management
26
Technology
Often the least important dimension Language and tool selection Value and cost of reuse
27
Planning
Determine requirements Determine resources Select lifecycle model Determine product features strategy
28
Tracking
Cost, effort, schedule Planned vs. Actual How to handle when things go off plan?
29
Measurements
To date and projected
Cost Schedule Effort Product features
Alternatives
Earned value analysis Defect rates Productivity (ex: SLOC) Complexity (ex: function points)
30
10
Technical Fundamentals
Requirements Analysis Design Construction Quality Assurance Deployment
31
Project Phases
All projects are divided into phases All phases together are known as the Project Life Cycle Each phase is marked by completion of Deliverables Identify the primary software project phases
32
Lifecycle Relationships
33
11
Seven Core Project Phases
34
Project Phases A.K.A.
35
Phases Variation
Concept Exploration System Exploration
Requirements
Design
Implementation
Installation
Operations and Support
Maintenance
Retirement
36
12
36 Classic Mistakes
Types
People-Related Process-Related Product-Related Technology-Related
37
People-Related Mistakes Part 1

Undermined motivation Weak personnel
Weak vs. Junior
Uncontrolled problem employees Heroics Adding people to a late project
38

Noisy, crowded offices Customer-Developer friction Unrealistic expectations Politics over substance Wishful thinking
39
13

Lack of effective project sponsorship Lack of stakeholder buy-in Lack of user input
40
Process-Related Mistakes Part 1

Optimistic schedules Insufficient risk management Contractor failure Insufficient planning Abandonment of plan under pressure
41

Wasted time during fuzzy front end Shortchanged upstream activities Inadequate design Shortchanged quality assurance
42
14

Insufficient management controls Frequent convergence Omitting necessary tasks from estimates Planning to catch-up later Code-like-hell programming
43
Product-Related Mistakes
Requirements gold-plating
Gilding the lily
Feature creep Developer gold-plating

Beware the pet project
Push-me, pull-me negotiation Research-oriented development
44
Technology-Related Mistakes
Silver-bullet syndrome Overestimated savings from new tools and methods
Fad warning
Switching tools in mid-project Lack of automated source-code control
45
15

Session 2: Processes, Organization
46
Content
PMI Fundamentals Project Organization Project Selection Project Portfolio Management Procurement Management Statement of Work (SOW) Project Charter
47
Why Do Projects Succeed?

How to identify a projects success potential
What metrics could you look at?
Project size Project duration Project team size
48
16
Why Do Projects Succeed?

Executive support User involvement Experience project manager Clear business objectives Minimized scope Standard software infrastructure Firm basic requirements Formal methodology Reliable estimates
Standish Group CHAOS 2001: A Recipe for Success
49
Why Executive Support?

Top management can help to:
Secure adequate resources Get approval for unique project needs in a timely manner Receive cooperation from people throughout the organization Provide leadership guidance
50
15 PM Job Functions
Define scope of project Identify stakeholders, decision-makers, and escalation procedures Develop detailed task list (work breakdown structures) Estimate time requirements Develop initial project management flow chart Identify required resources and budget Evaluate project requirements Identify and evaluate risks Prepare contingency plan Identify interdependencies Identify and track critical milestones Participate in project phase review Secure needed resources Manage the change control process Report project status
*Northwest Center for Emerging Technologies, "Building a Foundation for Tomorrow: Skills Standards for Information Technology,"Belleview, WA, 1999
51
17
PMI Framework
Source: Project Management Institute
52
The 5 PMI Process Groups

1. Initiating 2. Planning 3. Executing 4. Controlling 5. Closing Note: these can be repeated for each phase
Each process is described by:

Inputs Tools & Techniques Outputs
53
PMI Process Groups
Source: Project Management Institute
54
18
PMI: Process Links
55
PMI Phase Interactions

Design Phase
Initiating Processes Planning Processes
Implementation Phase
Executing Processes Initiating Processes Planning Processes
Controlling Processes
Closing Processes
Controlling Processes
Executing Processes
Closing Processes
56
PMI: Initiating Process

Inputs
Product Description Strategic plan Project Selection Criteria Historical Information
Outputs
Project charter Project Manager assigned Constraints Assumptions
57
19
PMI: Planning Process

Devising and maintaining a workable scheme to accomplish the business need that the project was undertaken to address
Scope Planning Scope Definition Activity Definition Activity Sequencing Activity Duration Estimating Resource Planning Cost Estimating Cost Budgeting
Risk Planning Schedule Development Quality Planning Communications Planning Organization Planning Staff Acquisition Procurement Planning Project Plan Development
58
PMI: Executing Process

Coordinating people and other resources to carry out the plan
Project Plan Execution Scope Verification Quality Assurance Team Development
Information Distribution Solicitation Source Selection Contract Administration
59
PMI: Controlling Process

Ensuring that project objectives are met by monitoring and measuring progress and taking corrective measures when necessary
Overall Change Control Scope Change Control Schedule Control Cost Control Quality Control
Performance Reporting Risk Response Control
60
20
PMI: Closing Process

Formalizing acceptance of the project or phase and bringing it to an orderly end
Administrative Closure Contract Close-out
61
PMI Knowledge Areas
62
Importance of Phases
Define your management review points
Phase exits or kill points Ensure continued alignment with goals Form of Validation & Verification (V&V)
More later in term
63
21
Understanding Organizations
Structural frame: Focuses on roles and responsibilities, coordination and control. Organization charts help define this frame. Political frame: Assumes organizations are coalitions composed of varied individuals and interest groups. Conflict and power are key issues. Human resources frame: Focuses on providing harmony between needs of the organization and needs of people.
Symbolic frame: Focuses on symbols and meanings related to events. Culture is important.
64
Organizational Structures
Functional
Engineering, Marketing, Design, etc P&L from production
Project
Project A, Project B Income from projects PM has P&L responsibility
Matrix
Functional and Project based Program Mgmt. Model Shorter cycles, need for rapid development process
Principles of Project Management 65
Functional Organization
Pros
Clear definition of authority Eliminates duplication Encourages specialization Clear career paths
Cons
Walls: can lack customer orientation Silos create longer decisions cycles Conflicts across functional areas Project leaders have little power
66
22
Project Organization
Pros
Unity of command Effective inter-project communication
Cons
Duplication of facilities Career path
Examples: defense avionics, construction

Matrix Organization
Pros
Project integration across functional lines Efficient use of resources Retains functional teams
Cons
Two bosses for personnel Complexity Resource & priority conflicts
68
Matrix Forms
Weak, Strong, Balanced Degree of relative power Weak: functional-centric Strong: project-centric
69
23
IT Planning Process
70
Methods for Selecting Projects

There are usually (always?) more projects than available time and resources to implement them
Therefore: It is important to follow a logical process for selecting IT projects to work on
Methods include
Focusing on broad needs Categorizing projects Financial methods Weighted scoring models
(last 2 models covered later in term)
71
Broad Organizational Needs

It is often difficult to provide strong justification for many IT projects, but everyone agrees they have a high value
It is better to measure gold roughly than to count pennies precisely
Three important criteria for projects:

There is a need for the project There are funds available Theres a strong will to make the project succeed
72
24
Categorizing IT Projects
One categorization: whether project addresses a problem an opportunity a directive Another: how long it will take & when it is needed Another: overall priority of the project
73
Project Portfolio Management

Portfolio: a group of IT project under a coordinated management structure Different portfolio models are available:
Economic return model
NPV, IRR, ROI
Cost-benefit model
Can include less tangible factors
Market research model

For new products
Each considers relative value and resource/budget interactions More details in Session 4
Portfolio Management
A 5 level approach (from CIO magazine) 1. Create a Portfolio Database
Project names & descriptions Estimated costs, timeframes, staffing
Benefits
Spotting redundancies Communication across orgs & teams Holistic view
75
25
2. Prioritize Projects
Try quantifiable rankings
Risk and return
Still subjectivity and disagreements
3. Divide into budgets based on type

To align with business needs Ex: utilities (keeping the lights on), incremental upgrades, strategic investments
76
4. Automate the repository
Input of new data (new projects) Automated tracking (PM software integration)
5. Apply modern portfolio theory

Ex: www.modporttheory.com More advanced than most of us need
77
Procurement Management
Procurement means acquiring goods and/or services from an outside source
a.k.a. purchasing or outsourcing
Know how your ADIS project fits-into this model

Are you building in-house? for hire?
Thus are you the outside source?
As a startup? (thus in-house but as basis for the business itself)
78
26
Why Outsource?
To reduce both fixed and recurrent costs To allow the client organization to focus on its core business To access skills and technologies To provide flexibility To increase accountability
79
Procurement Management
Procurement planning: determining what to procure and when Solicitation planning: documenting product requirements and identifying potential sources Solicitation: obtaining quotations, bids, offers, or proposals as appropriate Source selection: choosing from among potential vendors Contract administration: managing the relationship with the vendor Contract close-out: completion and settlement of the contract
Project Procurement Management
81
27
Procurement Tools & Techniques

Make-or-buy analysis (build vs. buy)
Determining whether a particular product or service should be made or performed inside the organization or purchased from someone else. Often involves financial analysis
Experts
Both internal and external, can provide valuable inputs in procurement decisions
82
Types of Contracts
Fixed price or lump sum: involve a fixed total price for a well-defined product or service Cost reimbursable: involve payment to the seller for direct and indirect costs Time and material contracts: hybrid of both fixed price and cost reimbursable, often used by consultants Unit price contracts: require the buyer to pay the seller a predetermined amount per unit of service
83
Cost Reimbursable Contracts

Cost plus incentive fee (CPIF)
Buyer pays seller for allowable performance costs plus a predetermined fee and an incentive bonus
Cost plus fixed fee (CPFF)

Buyer pays seller for allowable performance costs plus a fixed fee payment usually based on a percentage of estimated costs
Cost plus percentage of costs (CPPC)

Buyer pays seller for allowable performance costs plus a predetermined percentage based on total costs
84
28
Contract Types Versus Risk
85
Statement of Work (SOW)

A description of the work required for the project Sets the boundary conditions SOW vs. CSOW (Contract SOW)
Latter: uses legal language as part of a competitive bidding scenario
Can be used in the final contract be careful, be specific, be clear
86
SOW Continued
Typically done after approval (after Go) Can be multiple versions
1. List of deliverables for an RFP 2. More detailed within final RFP 3. Binding version from contract
87
29
SOW Template
I. II. III. Scope of Work: Describe the work to be done to detail. Specify the hardware and software involved and the exact nature of the work. Location of Work: Describe where the work must be performed. Specify the location of hardware and software and where the people must perform the work Period of Performance: Specify when the work is expected to start and end, working hours, number of hours that can be billed per week, where the work must be performed, and related schedule information. Optional Compensation section. Deliverables Schedule: List specific deliverables, describe them in detail, and specify when they are due. Applicable Standards: Specify any company or industry-specific standards that are relevant to performing the work. Often an Assumptions section as well. Acceptance Criteria: Describe how the buyer organization will determine if the work is acceptable. Special Requirements: Specify any special requirements such as hardware or software certifications, minimum degree or experience level of personnel, travel requirements, documentation, testing, support, and so on.
IV. V. VI. VII.
Project Charter
A high-level project description:
Business need, product, assumptions
Often precedes SOW Often 2-4 pages (can be longer)
89
Project Charter
Typical outline
Overview
Business need Objectives Method or approach
General scope of work Rough schedule & budget Roles & responsibilities Assumptions
90
30
Charter Examples
Assumptions
We will reuse the architecture from the previous ordering system The system will be built using an ASP model Customer will provide necessary business experts as needed during development System will run on existing networking and computer resources Customer will sign-off on interim deliverables within one week of each delivery All import data will be available in XML format This will be a web-based application Our in-house development team will do the work The rendering engine will be licensed from a third party We will partner with an overseas development firm to create the security systems
91
Charter Examples
Primary Stakeholders (following examples are not of one set)
Sponsor: VP of Marketing Sponsor: Five Star Brokerage Consortium Sponsor: Bill Smith, CEO Users: Call center operators Users: Our partner banks Customers: Attorneys from small-to-mid size law firms Customers: Males 30-45 earning $75K or more
92
Charter Examples
Deliverables
Retail Web Site
Full catalog Shopping-cart system Search engine User registration system
Trading System
Equities order entry system Portfolio management Order execution engine Integration with X legacy systems Security infrastructure
93
31
Charter Examples
Deliverables
Corporate Application
Network and hardware Web-based HR portal Connectivity for VPN Asset Management Viewport application Customized Reporting Engine
Allowing users to Perseus data mart Delivery into HTML and Excel
User manuals
94
Charter Examples
Out of Scope
News feeds Dynamic pricing Jazzy color picker Auction engine EDI support Legacy integration Help system
Schedule
We anticipate an overall 12-14 month development timeframe The project is expected to start in Q1 2003 and complete in Q3 2004 The initial release is expect within 10 months with the follow-on delivery within 4-6 months

Session 3: Planning
96
32
Project Phases
97
Time Allocation by Phase

Remember the 40-20-40 Rule
Specification-Implementation-Test
Planning Commercial DP Internet Systems Real-time Systems Defense Systems 25% 55% 35% 40% Code & Unit Test 40% 15% 25% 20% Integration & Test 35% 30% 40% 40%
Bennatan, E.M, On Time Within Budget
98
Time Allocation by Phase

Activity Analysis Design Code Unit Test Integration System test Small Project (2.5K LOC) 10% 20% 25% 20% 15% 10% Large Project (500K LOC) 30% 20% 10% 5% 20% 15%
McConnell, Steve, Rapid Development
99
33
Activities by % of Total Effort
NASAs Managers Handbook for Software Development
100
Potential Deliverables by Phase
101
Concept Exploration
The Why phase Not a mandatory formal phase
Sometimes called the pre-project phase
Collecting project ideas

Then the funneling process
Project Justification
ROI Cost-benefit analysis Project Portfolio Matrix
Initial planning and estimates
102
34
Concept Exploration
Possibly includes Procurement Management:
RFP Process Vendor selection Contract management
Gathering the initial team

Including PM if not already on-board
Identify the project sponsor

Primary contact for approval and decision making
Potential Phase Outputs:

Concept Document, Product Description, Proposal, SOW, Project Charter
103
Concept Exploration
Characteristics & Issues
Lack of full commitment and leadership Some frustrations:
Management only getting rough estimates from development Development not getting enough specifics from customer Finding a balanced team
Budget sign-off may be your 1st major task Achieved via:

Good concept document or equivalent Demonstration of clear need (justification) Initial estimates
104
Requirements
The What phase Inputs: SOW, Proposal Outputs:
Requirements Document (RD)
a.k.a.Requirements Specification Document (RSD) Software Requirements Specification (SRS)
1st Project Baseline Software Project Management Plan (SPMP) Requirements Approval & Sign-Off
Your most difficult task in this phase
105
35
Requirements
Perhaps most important & difficult phase Shortchanging it is a classic mistake Can begin with a Project Kickoff Meeting Can end with a Software Requirements Review (SRR)
For Sponsor and/or customer(s) approval
106
Why are Requirements so Important?
107
Requirements
Conflict of interest: developer vs. customer Potential tug-of-war:
Disagreement on Features & Estimates Especially in fixed-price contracts
Frequent requirements changes Achieving sign-off
Project planning occurs in parallel
108
36
Requirements
Requirements are capabilities and condition to which the system more broadly, the project must conform
109
2 Types of Requirements
Functional (behavioral)
Features and capabilities
Non-functional (a.k.a. technical) (everything else)

Usability Human factors, help, documentation Reliability Failure rates, recoverability, availability Performance Response times, throughput, resource usage Supportability Maintainability, internationalization Operations: systems management, installation Interface: integration with other systems Other: legal, packaging, hardware
Requirements
Other ways of categorizing
Go-Ahead vs. Catch-up
Relative to competition
Backward-looking vs. Forward-looking

Backward: address issues with previous version Forward: Anticipating future needs of customers
Must be prioritized
Must-have Should-have Could-have (Nice-to-have: NTH)
Must be approved
111
37
Early Phase Meetings

Project Kickoff Meeting Project Brainstorming Meeting
Clarify goals, scope, assumptions Refine estimates
WBS Meeting
112
Analysis & Design

The How Phases Inputs: Requirements Document Outputs:
Functional Specification Detailed Design Document User Interface Specification Data Model Prototype (can also be done with requirements) Updated Plan (improved estimates; new baseline)
113
Analysis & Design

a.k.a. Top-level design & detailed design Continues process from RD Ends with Critical Design Review (CDR)
Formal sign-off Can also include earlier Preliminary Design Review (PDR) for high level design
114
38
Analysis & Design

Enthusiasm via momentum Team structure and assignments finalized Delays due to requirements changes, new information or late ideas Issues around personnel responsibilities Unfeasible requirements (technical complexity) Resource Issues
Including inter-project contention
115
Development
The Do It phase Coding & Unit testing Often overlaps Design & Integration phases
To shorten the overall schedule PM needs to coordinate this
116
Development
Other concurrent activities
Design completion Integration begins Unit testing of individual components Test bed setup (environment and tools) Project plans updated Scope and Risk Management conducted
117
39
Development
Characteristics
Pressure increases Staffing at highest levels Often a heads-down operation
Issues
Last-minute changes Team coordination (esp. in large projects) Communication overhead Management of sub-contractors
118
Integration & Test

Evolves from Dev. Phase Often done as 2 parallel phases
Partial integration & initial test
Starts with integration of modules An initial, incomplete version constructed Progressively add more components
119
Integration & Test

Integration primarily a programmer task Test primarily a QA team task Integration:
Top-down: Core functionality first, empty shells for incomplete routines (stubs) Bottom up: gradually bind low-level modules Prefer top-down generally
120
40
Integration & Test

Tests
Integration testing Black & White-box testing Load & Stress testing Alpha & Beta testing Acceptance testing
Other activities
Final budgeting; risk mgmt.; training; installation preparation; team reduced
121
Integration & Test

Increased pressure Overtime Customer conflicts over features Frustration over last-minute failures Budget overruns Motivation problems (such as burnout) Difficulty in customer acceptance
Esp. true for fixed-price contracts
122
Deployment & Maintenance

Installation depends on system type
Web-based, CD-ROM, in-house, etc.
Migration strategy How to get customers up on the system

Parallel operation
Deployment typically in your project plan, maintenance not
123
41

Maintenance
Fix defects Add new features Improve performance
Configuration control is very important here Documents need to be maintained also Sometimes a single team maintains multiple products
124

Lack of enthusiasm Pressure for quick fixes Insufficient budget Too many patches Personnel turnover Regression testing is critical
Preferably through automated tools
125
Lifecycle Planning
a.k.a. Lifecycle Management or SDLC Greatly influences your chance of success Not choosing a lifecycle is a bad option Three primary lifecycle model components
Phases and their order Intermediate products of each phase Reviews used in each phase
126
42
Lifecycle Planning
Different projects require different approaches You do not need to know all models by name You should know how that if given a certain scenario what sort of SDLC would be appropriate There are more than covered here A lifecycle is not a design, modeling or diagramming technique
The same technique (UML, DFD, etc) can be used with multiple lifecycles
127
Pure Waterfall
The granddaddy of models Linear sequence of phases
Pure model: no phases overlap
Document driven All planning done up-front
128
Waterfall Risk
Why does the waterfall model invite risk? Integration and testing occur at the end
Often anyones 1st chance to see the program
129
43
Pure Waterfall
Works well for projects with
Stable product definition Well-understood technologies Quality constraints stronger than cost & schedule Technically weak staff
Provides structure Good for overseas projects
130
Pure Waterfall
Disadvantages
Not flexible
Rigid march from start->finish
Difficult to fully define requirements up front Can produce excessive documentation Few visible signs of progress until the end
131
Code-and-Fix
Code-like-Hell Specification (maybe), Code (yes), Release (maybe) Advantages
No overhead Requires little expertise
Disadvantages
No process, quality control, etc. Highly risky
Suitable for prototypes or throwaways
132
44
Spiral
133
Spiral
Emphasizes risk analysis & mgmt. in each phase A Series of Mini-projects Each addresses a set of risks
Start small, explore risks, prototype, plan, repeat
Early iterations are cheapest Number of spirals is variable

Last set of steps are waterfall-like
134
Spiral
Advantages
Can be combined with other models As costs increase, risks decrease Risk orientation provides early warning
Disadvantages
More complex Requires more management
135
45
Modified Waterfall Sashimi

Overlapping phases Advantages
Reduces overall schedule Reduces documentation Works well if personnel continuity
Disadvantages
Milestones more ambiguous Progress tracking more difficult Communication can be more difficult
136
Evolutionary Prototyping
Design most prominent parts first
Usually via a visual prototype
Good for situations with:

Rapidly changing requirements Non-committal customer Vague problem domain
Provides steady, visible progress Disadvantages

Time estimation is difficult Project completion date may be unknown An excuse to do code-and-fix
Staged Delivery
Waterfall steps through architectural design Then detailed design, code, test, deliver in stages Advantages
Customers get product much sooner Tangible signs of progress sooner Problems discovered earlier Increases flexibility Reduces: status reporting overhead & estimation error
Disadvantages
Requires more planning (for you the PM) More releases increase effort (and possible feature creep)
Hows this differ from Evolutionary Prototyping?

46
V Process Model
139
V Process Model
Designed for testability
Emphasizes Verification & Validation
Variation of waterfall Strengths

Encourages V&V at all phases
Weaknesses
Does not handle iterations Changes can be more difficult to handle
Good choice for systems that require high reliability such as patient control systems
140
RAD
Rapid Application Development Popular in the 80s
1. Joint Requirements Planning (JRP) 2. Joint Application Design (JAD) 3. Construction
Heavy use of tools: code generators Time-boxed; many prototypes
4. Cutover
Good for systems with extensive user input available
141
47
COTS
Commercial Off-The-Shelf software Build-vs.-buy decision Advantages
Available immediately Potentially lower cost
Disadvantages
Not as tailored to your requirements
Remember: custom software rarely meets its ideal (so compare that reality to COTS option)
142
IEEE 1074
A standard for developing software processes
Lifecycle model selection Project management process Predevelopment processes Development processes Post-development processes Integral process
143
Planning
Plans are nothing. But planning is everything. Gen. Dwight Eisenhower
144
48
Planning
Preliminary planning starts on day one Even in the pre-project phase Should not be conducted in secret Need buy-in and approval
Very important step Both from above and below
145
Your PM Process
Why
Deliverable: ROI
What
SOW, Requirements
How
Design Specification, SDP, Lifecycle
Futrell, Shafer, Shafer, Quality Software Project Management
Do
Execution
Done
PPR
Primary Planning Steps

Identify project scope and objectives Identify project organizational environment Analyze project characteristics Identify project products and activities Estimate effort for each activity Identify risk Allocate resources Review and communicate plan
49
Documents
Planning Product
148
Planning Documents
Software Development Plan (SDP) Software Quality Assurance Plan (SQAP) Software Configuration Management Plan (SCMP) Risk Management Plan Software Process Improvement Plan Communications Management Plan Migration Plan Operations Plan
149
Planning Documents
You (the PM) need to choose which documents are appropriate Docs do not have to be lengthy Small Set:
Software Development Plan Risk Management Plan Software Quality Assurance Plan Software Configuration Management Plan
150
50
Planning Documents
Project ROI Analysis Statement of Work (SOW) Project Charter Software Project Management Plan (SPMP) Budget Responsibility Assignment Matrix (RAM) Risk Management Plan
151
Product Documents
Statement of Need System Interface Specification Software Requirements Specification Software Design Specification Software Validation & Verification Plan User Documentation
Support Plan Maintenance Documentation
152
Software Project Survival Guide

Another McConnell book See construx.coms SPSG section
Good content online Documents Schedules Checklists Project web site template
153
51
Planning
How much will it cost? How long will it take? How many people will it take? What might go wrong?
154
Planning
Scoping Estimation Risk Schedule Control Strategy
155
Process Issues
You want a fairly sophisticated process without incurring much overhead Remember, projects are often larger than they first appear Easier to loosen too much process than add later
156
52
Plans Evolve Over Time
NASAs Managers Handbook for Software Development
157
Software Development Plan

Software Project Management Plan (SPMP) Some consider it the most important document in the project (along with SRS)
Can be seen as an aggregation of other core documents
Evolves over time as pieces come together
158
SDP / SPMP
Fundamental Sections
Project overview Deliverables Project organization Managerial processes Technical processes Budget Schedule
159
53
Communications Management Plan

Often a section of SPMP Describes information flow to all parties
Gathering and distributing information
Status meetings
Monthly, Weekly, Daily? Status reports are vital
160
Create a Project Intranet

A great communications tool Reference all project resources here
161

Session 4: WBS, Estimation & Scheduling
162
54
Real-world Case Study

Web-based customized reporting project How to Fail with the Rational Unified Process or 7 Steps to Pain and Suffering
163
Project Considerations
Is infrastructure setup part of your project? Assumptions
What are you counting on? These can be critical to identify Resources expected: equip/people, approvals Availability of partners, connections Delineate key limits:
System load: expect an maximum of 100 users
164
Estimation
Predictions are hard, especially about the future, Yogi Berra 2 Types: Lucky or Lousy?
165
55
Planning, Estimating, Scheduling

Whats the difference? Plan: Identify activities. No specific start and end dates. Estimating: Determining the size & duration of activities. Schedule: Adds specific start and end dates, relationships, and resources.
166
Project Planning: A 12 Step Program

1) 2) 3) 4) 5) 6)
Set goal and scope Select lifecycle Set org./team form Start team selection Determine risks Create WBS
7) 8) 9) 10)
11) 12)
Identify tasks Estimate size Estimate effort Identify task dependencies Assign resources Schedule work
167
How To Schedule
1. Identify what needs to be done
Work Breakdown Structure (WBS)
2. Identify how much (the size)

Size estimation techniques
3. Identify the dependency between tasks

Dependency graph, network diagram
4. Estimate total duration of the work to be done

The actual schedule
168
56
WBS & Estimation

How did you feel when I asked
How long will your project take?
Not an easy answer to give right? At least not if I were are real customer on a real project How can you manage that issue?
169
Partitioning Your Project

You need to decompose your project into manageable chunks ALL projects need this step Divide & Conquer Two main causes of project failure
Forgetting something critical Ballpark estimates become targets
How does partitioning help this?
170
Project Elements
A Project: functions, activities, tasks
171
57
Work Breakdown Structure: WBS

Hierarchical list of projects work activities 2 Formats
Outline (indented format) Graphical Tree (Organizational Chart)
Uses a decimal numbering system

Ex: 3.1.5 0 is typically top level
Includes
Development, Mgmt., and project support tasks
Shows is contained in relationships Does not show dependencies or durations

WBS
Contract WBS (CWBS)
First 2 or 3 levels High-level tracking
Project WBS (PWBS)

Defined by PM and team members Tasks tied to deliverables Lowest level tracking
173
A Full WBS Structure

Up to six levels (3-6 usually) such as
Upper 3 can be used by customer for reporting (if part of RFP/RFQ) Different level can be applied to different uses
Ex: Level 1: authorizations; 2: budgets; 3: schedules
174
58
WBS Chart Example
175
WBS Outline Example

0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production
WBS Types
Process WBS
a.k.a Activity-oriented Ex: Requirements, Analysis, Design, Testing Typically used by PM
Product WBS
a.k.a. Entity-oriented Ex: Financial engine, Interface system, DB Typically used by engineering manager
Hybrid WBS: both above

This is not unusual Ex: Lifecycle phases at high level with component or feature-specifics within phases Rationale: processes produce products
59
Product WBS
178
Process WBS
179
Outline WBS w/Gantt
180
60
WBS by PMI Process Groups
181
WBS Types
Less frequently used alternatives
Organizational WBS
Research, Product Design, Engineering, Operations Can be useful for highly cross-functional projects
Geographical WBS
Can be useful with distributed teams NYC team, San Jose team, Off-shore team
182
Work Packages
Generic term for discrete tasks with definable end results Typically the leaves on the tree The one-to-two rule
Often at: 1 or 2 persons for 1 or 2 weeks
Basis for monitoring and reporting progress

Can be tied to budget items (charge numbers) Resources (personnel) assigned
Ideally shorter rather than longer

Longer makes in-progress estimates needed These are more subjective than done 2-3 weeks maximum for software projects 1 day minimum (occasionally a half day) Not so small as to micro-manage
183
61
WBS
List of Activities, not Things List of items can come from many sources
SOW, Proposal, brainstorming, stakeholders, team
Describe activities using bullet language

Meaningful but terse labels
All WBS paths do not have to go to the same level Do not plan more detail than you can manage
184
WBS & Methodology

PM must map activities to chosen lifecycle Each lifecycle has different sets of activities Integral process activities occur for all
Planning, configuration, testing
Operations and maintenance phases are not normally in plan (considered post-project) Some models are straightened for WBS
Spiral and other iterative models Linear sequence several times
Deliverables of tasks vary by methodology
185
WBS Techniques
Top-Down Bottom-Up Analogy Rolling Wave
1st pass: go 1-3 levels deep Gather more requirements or data Add more detail later
Post-its on a wall
186
62
WBS Techniques
Top-down
Start at highest level Systematically develop increasing level of detail Best if
The problem is well understood Technology and methodology are not new This is similar to an earlier project or problem
But is also applied in majority of situations
187
WBS Techniques
Bottom-up
Start at lowest level tasks Aggregate into summaries and higher levels Cons
Time consuming Needs more requirements complete
Pros
Detailed
188
WBS Techniques
Analogy
Base WBS upon that of a similar project Use a template Analogy also can be estimation basis Pros
Based on past actual experience
Cons
Needs comparable project
189
63
WBS Techniques
Brainstorming
Generate all activities you can think of that need to be done Group them into categories
Both Top-down and Brainstorming can be used on the same WBS Remember to get the people who will be doing the work involved (buy-in matters!)
190
WBS Basis of Many Things

Network scheduling Costing Risk analysis Organizational structure Control Measurement
191
WBS Guidelines Part 1

Should be easy to understand Some companies have corporate standards for these schemes Some top-level items, like Project Mgmt. are in WBS for each project
Others vary by project
What often hurts most is whats missing Break down until you can generate accurate time & cost estimates Ensure each element corresponds to a deliverable
192
64
WBS Guidelines Part 2

How detailed should it be?
Not as detailed as the final MS-Project plan Each level should have no more than 7 items It can evolve over time
What tool should you use?

Excel, Word, Project Org chart diagramming tool (Visio, etc) Specialized commercial apps
Re-use a template if you have one
193
Estimations
Very difficult to do, but needed often Created, used or refined during
Strategic planning Feasibility study and/or SOW Proposals Vendor and sub-contractor evaluation Project planning (iteratively)
Basic process
1) 2) 3)
Estimate the size of the product Estimate the effort (man-months) Estimate the schedule NOTE: Not all of these steps are always explicitly performed
194
Estimations
Remember, an exact estimate is an oxymoron Estimate how long will it take you to get home from class tonight
On what basis did you do that? Experience right? Likely as an average probability For most software projects there is no such average
Most software estimations are off by 25-100%
195
65
Estimation
Target vs. Committed Dates
Target: Proposed by business or marketing Do not commit to this too soon! Committed: Team agrees to this After youve developed a schedule
196
Cone of Uncertainty
197
Estimation
Size:
Small projects (10-99 FPs), variance of 7% from post-requirements estimates Medium (100-999 FPs), 22% variance Large (1000-9999 FPs) 38% variance Very large (> 10K FPs) 51% variance
198
66
Estimation Methodologies
Top-down Bottom-up Analogy Expert Judgment Priced to Win Parametric or Algorithmic Method
Using formulas and equations
199
Top-down Estimation
Based on overall characteristics of project
Some of the others can be types of top-down (Analogy, Expert Judgment, and Algorithmic methods)
Advantages
Easy to calculate Effective early on (like initial cost estimates)
Disadvantages
Some models are questionable or may not fit Less accurate because it doesnt look at details
200
Bottom-up Estimation
Create WBS Add from the bottom-up Advantages
Works well if activities well understood
Disadvantages
Specific activities not always known More time consuming
201
67
Expert Judgment
Use somebody who has recent experience on a similar project You get a guesstimate Accuracy depends on their real expertise Comparable application(s) must be accurately chosen
Systematic
Can use a weighted-average of opinions
202
Estimation by Analogy
Use past project
Must be sufficiently similar (technology, type, organization) Find comparable attributes (ex: # of inputs/outputs) Can create a function
Advantages
Based on actual historical data
Disadvantages
Difficulty matching project types Prior data may have been mis-measured How to measure differences no two exactly same
203
Priced to Win
Just follow other estimates Save on doing full estimate Needs information on other estimates (or prices) Purchaser must closely watch trade-offs Priced to lose?
204
68
Algorithmic Measures
Lines of Code (LOC) Function points Feature points or object points Other possible
Number of bubbles on a DFD Number of of ERD entities Number of processes on a structure chart
LOC and function points most common

(of the algorithmic approaches)
Majority of projects use none of the above
205
Code-based Estimates
LOC Advantages
Commonly understood metric Permits specific comparison Actuals easily measured
LOC Disadvantages
Difficult to estimate early in cycle Counts vary by language Many costs not considered (ex: requirements) Programmers may be rewarded based on this
Can use: # defects/# LOC
Code generators produce excess code
206
LOC Estimate Issues

How do you know how many in advance? What about different languages? What about programmer style? Stat: avg. programmer productivity: 3,000 LOC/yr Most algorithmic approaches are more effective after requirements (or have to be after)
207
69
Function Points
Software size s/b measured by number & complexity of functions it performs More methodical than LOC counts House analogy
Houses Square Feet ~= Software LOC # Bedrooms & Baths ~= Function points Former is size only, latter is size & function
Six basic steps
208
Function Point Process

1. Count # of biz functions per category
Categories: outputs, inputs, db inquiries, files or data structures, and interfaces
2. Establish Complexity Factor for each and apply

Simple, Average, Complex Set a weighting multiplier for each (0->15) This results in the unadjusted function-point total
3. Compute an influence multiplier and apply

It ranges from 0.65 to 1.35; is based on 14 factors
4. Results in function point total

This can be used in comparative estimates
209
Wideband Delphi
Group consensus approach Rand corp. used orig. Delphi approach to predict future technologies Present experts with a problem and response form Conduct group discussion, collect anonymous opinions, then feedback Conduct another discussion & iterate until consensus Advantages Easy, inexpensive, utilizes expertise of several people Does not require historical data Disadvantages Difficult to repeat May fail to reach consensus, reach wrong one, or all may have same bias
210
70
Parametric Method Issues

Remember: most projects youll run into dont use these Which is normal, so dont be surprised
Or come-in to new job and say Hey, lets use COCOMO
These are more effective on large projects

Where a past historical base exists
Primary issue for most projects are

Lack of similar projects
Thus lack of comparable data
Catch-22: how to get started
211
Code Reuse & Estimation

Does not come for free Code types: New, Modified, Reused If code is more than 50% modified, its new Reuse factors have wide range
Reused code takes 30% effort of new Modified is 60% of new
Integration effort with reused code almost as expensive as with new code
212
Effort Estimation
Now that you know the size, determine the effort needed to build it Various models: empirical, mathematical, subjective Expressed in units of duration
Man-months (or staff-months now)
213
71
Effort Estimation
McConnell shows schedule tables for conversion of size to effort As with parametric size estimation, these techniques perform better with historical data Again, not seen in average projects Often the size and effort estimation steps are combined (not that this is recommended, but is what often is done) Commitment-Based Scheduling is what is often done
Ask developer to commit to an estimate (his or her own)
214
COCOMO
COnstructive COst MOdel Allows for the type of application, size, and Cost Drivers Outputs in Person Months Cost drivers using High/Med/Low & include
Motivation Ability of team Application experience
Biggest weakness?
Requires input of a product size estimate in LOC
215
Estimation Issues
Quality estimations needed early but information is limited Precise estimation data available at end but not needed
Or is it? What about the next project?
Best estimates are based on past experience Politics of estimation:

You may anticipate a cut by upper management
For many software projects there is little or none

Technologies change Historical data unavailable Wide variance in project experiences/types Subjective nature of software estimation
216
72
Over and Under Estimation

Over estimation issues
The project will not be funded
Conservative estimates guaranteeing 100% success may mean funding probability of zero.
Parkinsons Law: Work expands to take the time allowed Danger of feature and scope creep Be aware of double-padding: team member + manager
Under estimation issues

Quality issues (short changing key phases like testing) Inability to meet deadlines Morale and other team motivation issues
217
Estimation Guidelines
Estimate iteratively!
Process of gradual refinement Make your best estimates at each planning stage Refine estimates and adjust plans iteratively Plans and decisions can be refined in response Balance: too many revisions vs. too few
218
Know Your Deadlines

Are they Real Deadlines?
Tied to an external event Have to be met for project to be a success Ex: end of financial year, contractual deadline, Y2K
Or Artificial Deadlines?
Set by arbitrary authority May have some flexibility (if pushed)
219
73
Estimation Presentation
How you present the estimation can have huge impact Techniques
Plus-or-minus qualifiers
6 months +/-1 month
Ranges
6-8 months
Risk Quantification
+/- with added information +1 month of new tools not working as expected -2 weeks for less delay in hiring new developers
Cases
Best / Planned / Current / Worst cases
Coarse Dates
Q3 02
Confidence Factors
April 1 10% probability, July 1 50%, etc.
Other Estimation Factors

Account for resource experience or skill
Up to a point Often needed more on the low end, such as for a new or junior person
Allow for non-project time & common tasks

Meetings, phone calls, web surfing, sick days
There are commercial estimation tools available

They typically require configuration based on past data
221
Other Estimation Notes

Remember: manage expectations Parkinsons Law
Work expands to fill the time available
The Student Syndrome

Procrastination until the last minute (cram)
222
74
Financial Analysis of Projects

Financial considerations are often an important consideration in selecting projects Three primary methods for determining the projected financial value of projects:
Net present value (NPV) analysis Return on investment (ROI) Payback analysis
223
Net Present Value Analysis: NPV

NPV: a method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time Projects with a positive NPV should be considered if financial value is a key criterion The higher the NPV, the better
224
NPV Example
225
75
Return on Investment (ROI)

ROI: income divided by investment
ROI = (total discounted benefits - total discounted costs) / discounted costs
The higher the ROI, the better Many organizations have a required rate of return or minimum acceptable rate of return on investment for projects
226

Session 5: Scheduling
227
WBS
Types: Process, product, hybrid Formats: Outline or graphical org chart High-level WBS does not show dependencies or durations What hurts most is whats missing Becomes input to many things, esp. schedule
228
76
Estimation
The single most important task of a project: setting realistic expectations. Unrealistic expectations based on inaccurate estimates are the single largest cause of software failure. Futrell, Shafer, Shafer, Quality Software Project Management
Session 4 cont.
229
Estimation
History is your best ally
Especially when using LOC, function points, etc.
Use multiple methods if possible

This reduces your risk If using experts, use two
Get buy-in Remember: its an iterative process! Know your presentation techniques
230
Estimation
Bottom-up
More work to create but more accurate Often with Expert Judgment at the task level
Top-down
Used in the earliest phases Usually with/as Analogy or Expert Judgment
Analogy
Comparison with previous project: formal or informal
Expert Judgment
Via staff members who will do the work Most common technique along w/analogy Best if multiple experts consulted
77
Estimation
Parametric Methods
Know the trade-offs of: LOC & Function Points
Function Points
Benefit: relatively independent of the technology used to develop the system We will re-visit this briefly later in semester (when discussing software metrics) Variants: WEBMO (no need to know this for exam)
Re-Use Estimation
See QSPM outline
U Calgary
232
Your Early Phase Processes

Initial Planning:
Why
SOW, Charter
What/How (partial/1st pass)

WBS Other planning documents Software Development Plan, Risk Mgmt., Cfg. Mgmt.
Estimating
Size (quantity/complexity) and Effort (duration) Iterates
Scheduling
Begins along with 1st estimates Iterates
Scheduling
Once tasks (from the WBS) and size/effort (from estimation) are known: then schedule Primary objectives
Best time Least cost Least risk
Secondary objectives
Evaluation of schedule alternatives Effective use of resources Communications
234
78
Terminology
Precedence:
A task that must occur before another is said to have precedence of the other
Concurrence:
Concurrent tasks are those that can occur at the same time (in parallel)
Leads & Lag Time

Delays between activities Time required before or after a given task
235
Terminology
Milestones
Have a duration of zero Identify critical points in your schedule Shown as inverted triangle or a diamond Often used at review or delivery times
Or at end or beginning of phases Ex: Software Requirements Review (SRR) Ex: User Sign-off
Can be tied to contract terms
236
Terminology
Example Milestones
237
79
Terminology
Slack & Float
Float & Slack: synonymous terms Free Slack
Slack an activity has before it delays next task
Total Slack
Slack an activity has before delaying whole project
Slack Time TS = TL TE
TE = earliest time an event can take place TL = latest date it can occur w/o extending projects completion date
238
Scheduling Techniques
Mathematical Analysis
Network Diagrams
PERT CPM GERT
Bar Charts
Milestone Chart Gantt Chart
239
Network Diagrams
Developed in the 1950s A graphical representation of the tasks necessary to complete a project Visualizes the flow of tasks & relationships
240
80
Mathematical Analysis
PERT
Program Evaluation and Review Technique
CPM
Critical Path Method
Sometimes treated synonymously All are models using network diagrams
241
MS-Project Example
242
Network Diagrams
Two classic formats
AOA: Activity on Arrow AON: Activity on Node
Each task labeled with

Identifier (usually a letter/code) Duration (in std. unit like days)
There are other variations of labeling There is 1 start & 1 end event Time goes from left to right
243
81
Node Formats
244
Network Diagrams
AOA consists of
Circles representing Events
Such as start or end of a given task
Lines representing Tasks

Thing being done Build UI
a.k.a. Arrow Diagramming Method (ADM)
AON
Tasks on Nodes
Nodes can be circles or rectangles (usually latter) Task information written on node
Arrows are dependencies between tasks a.k.a. Precedence Diagramming Method (PDM)
245
Critical Path
The specific set of sequential tasks upon which the project completion date depends
or the longest full path
All projects have a Critical Path Accelerating non-critical tasks do not directly shorten the schedule
246
82
Critical Path Example
247
CPM
Critical Path Method
The process for determining and optimizing the critical path
Non-CP tasks can start earlier or later w/o impacting completion date Note: Critical Path may change to another as you shorten the current Should be done in conjunction with the you & the functional manager
4 Task Dependency Types

Mandatory Dependencies
Hard logic dependencies Nature of the work dictates an ordering Ex: Coding has to precede testing Ex: UI design precedes UI implementation
Discretionary Dependencies
Soft logic dependencies Determined by the project management team Process-driven Ex: Discretionary order of creating certain modules
249
83
4 Task Dependency Types

External Dependencies
Outside of the project itself Ex: Release of 3rd party product; contract signoff Ex: stakeholders, suppliers, Y2K, year end
Resource Dependencies
Two task rely on the same resource Ex: You have only one DBA but multiple DB tasks
250
Task Dependency Relationships

Finish-to-Start (FS)
B cannot start till A finishes A: Construct fence; B: Paint Fence
Start-to-Start (SS)
B cannot start till A starts A: Pour foundation; B: Level concrete
Finish-to-Finish (FF)
B cannot finish till A finishes A: Add wiring; B: Inspect electrical
Start-to-Finish (SF)
B cannot finish till A starts (rare)
251
Example Step 1
252
84
Forward Pass
To determine early start (ES) and early finish (EF) times for each task Work from left to right Adding times in each path Rule: when several tasks converge, the ES for the next task is the largest of preceding EF times
253
Example Step 2
254
Backward Pass
To determine the last finish (LF) and last start (LS) times Start at the end node Compute the bottom pair of numbers Subtract duration from connecting nodes earliest start time
255
85
Example Step 3
256
Example Step 4
257
Slack & Reserve

How can slack be negative? What does that mean? How can you address that situation?
258
86
Slack & Reserve

Reserve Time Negative Slack
Forward Pass A B Backward Pass Start Date Project Due Date
259
Network Diagrams
Advantages
Show precedence well Reveal interdependencies not shown in other techniques Ability to calculate critical path Ability to perform what if exercises
Disadvantages
Default model assumes resources are unlimited
You need to incorporate this yourself (Resource Dependencies) when determining the real Critical Path
Difficult to follow on large projects
260
PERT
Program Evaluation and Review Technique Based on idea that estimates are uncertain
Therefore uses duration ranges And the probability of falling to a given range
Uses an expected value (or weighted average) to determine durations Use the following methods to calculate the expected durations, then use as input to your network diagram
261
87
PERT
Start with 3 estimates
Optimistic
Would likely occur 1 time in 20
Most likely
Modal value of the distribution
Pessimistic
Would be exceeded only one time in 20
262
PERT Formula
Combined to estimate a task duration
263
PERT Formula
Confidence Interval can be determined Based on a standard deviation of the expected time
Using a bell curve (normal distribution)
For the whole critical path use
264
88
PERT Example
Description m a b PERT time Std. Dev. Planner 1 10d 9d 12d 10.16d 0.5d Planner 2 10d 9d 20d 11.5d 1.8d
Confidence interval for P2 is 4 times wider than P1 for a given probability Ex: 68% probability of 9.7 to 11.7 days (P1) vs. 9.5-13.5 days (P2)
265
PERT
Advantages
Accounts for uncertainty
Disadvantages
Time and labor intensive Assumption of unlimited resources is big issue Lack of functional ownership of estimates Mostly only used on large, complex project
Get PERT software to calculate it for you

CPM vs. PERT

Both use Network Diagrams CPM: deterministic PERT: probabilistic CPM: one estimate, PERT, three estimates PERT is infrequently used
267
89
Milestone Chart
Sometimes called a bar charts Simple Gantt chart
Either showing just highest summary bars Or milestones only
268
Bar Chart
269
Gantt Chart
270
90
Gantt Chart
Disadvantages
Does not show interdependencies well Does not uncertainty of a given activity (as does PERT)
Advantages
Easily understood Easily created and maintained
Note: Software now shows dependencies among tasks in Gantt charts

In the old days Gantt charts did not show these dependencies, bar charts typically do not
271
Reducing Project Duration

How can you shorten the schedule? Via
Reducing scope (or quality) Adding resources Concurrency (perform tasks in parallel) Substitution of activities
272
Compression Techniques
Shorten the overall duration of the project Crashing
Looks at cost and schedule tradeoffs Gain greatest compression with least cost Add resources to critical path tasks Limit or reduce requirements (scope) Changing the sequence of tasks
Fast Tracking
Overlapping of phases, activities or tasks that would otherwise be sequential Involves some risk May cause rework
273
91
Mythical Man-Month
Book: The Mythical Man-Month
Author: Fred Brooks
The classic book on the human elements of software engineering First two chapters are full of terrific insight (and quotes)
274
Mythical Man-Month
Cost varies as product of men and months, progress does not. Hence the man-month as a unit for measuring the size of job is a dangerous and deceptive myth
275
Mythical Man-Month
Why is software project disaster so common?
1. Estimation techniques are poor & assume things will go well (an unvoiced assumption) 2. Estimation techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable 3. Because of estimation uncertainty, manager lack courteous stubbornness 4. Schedule progress is poorly monitored 5. When schedule slippage is recognized, the natural response is to add manpower. Which, is like dousing a fire with gasoline.
276
92
Mythical Man-Month
Optimism
All programmers are optimists 1st false assumption: all will go well or each task takes only as long as it ought to take The Fix: Consider the larger probabilities
Cost (overhead) of communication (and training)

His formula: n(n-1)/2
How long does a 12 month project take?

1 person: 1 month 2 persons = 7 months (2 man-months extra) 3 persons = 5 months (e man-months extra)
Fix: dont assume adding people will solve the problem

Mythical Man-Month
Sequential nature of the process
The bearing of a child takes nine months, no matter how many women are assigned
What is the most mis-scheduled part of process?

Testing (the most linear process)
Why is this particularly bad?

Occurs late in process and w/o warning Higher costs: primary and secondary
Fix: Allocate more test time

Understand task dependencies
278
Mythical Man-Month
Reliance on hunches and guesses
What is gutless estimating?
The myth of additional manpower

Brooks Law Adding manpower to a late project makes it later
279
93
Mythical Man-Month
Q: How does a project get to be a year late?
A: One day at a time
Studies
Each task: twice as long as estimated Only 50% of work week was programming
Fixes
No fuzzy milestones (get the true status) Reduce the role of conflict Identify the true status
280

Session 6: MS-Project Intro & Mid-term Exam
281
MS-Project
Mid-market leader Has approx. 50% overall market share 70-80% MS-Project users never used automated project tracking prior (a first tool) Not a mid/high-end tool for EPM (Enterprise Project Mgmt.)
282
94
Project Pros
Easy outlining of tasks Resource management Accuracy: baseline vs. actual; various calculations Easy charting and graphics Cost management Capture historical data
283
Project Cons
Illusion of control Workgroup features ok, still in-progress Scaling No estimation features Remember:
Being a MS-Project expert does not make you an expert project manager! No more so than knowing MS-Word makes you a good writer.
284
The MS-Project Process

Move WBS into a Project outline (in Task Sheet) Add resources (team members or roles) Add costs for resources Assign resources to tasks Establish dependencies Refine and optimize Create baseline Track progress (enter actuals, etc.)
285
95
Project Overview
This is a quickie overview We will return to all of these steps individually over the next few weeks Sample project from McConnell
286
Project UI
Views
Default is Gant Chart View
2 panes Task Sheet on left (a table) Gantt Chart on right
View Bar on far left
287
Project UI
(Un)Link Buttons Toolbars Outline Buttons Indicators Enter Tasks Here Timescale
Gantt Chart View Bar
Task Bars Task Sheet Milestone
Split Bar
288
96
Create Your Project

File/New Setup start date Setup calendar
Menu: Project/Project Information Often left with default settings Hours, holidays
289
Enter WBS
Outlining Sub-tasks and summary tasks Do not enter start/end dates for each Just start with Task Name and Duration for each Use Indent/Outdent buttons to define summary tasks and subtasks You can enter specific Start/End dates but dont most of the time
290
Establish Durations
Know the abbreviations
h/d/w/m D is default
Can use partial

.5d is a half-day task
Elapsed durations Estimated durations

Put a ? after duration
291
97
Add Resources
Work Resources
People
Material Resources
Things Can be used to track costs
Ex: amount of equipment purshased
Not used as often in typical software project
292
Resource Sheet
Can add new resources here
Or directly in the task entry sheet
Beware of mis-spellings (Project will create near-duplicates)
Setup costs
Such as annual salary (put yr after Std. Rate)
293
Effort-Driven Scheduling
MS-Project default Duration * Units = Work
Duration = Work / Units (D = W/U) Work = Duration * Units (W = D*U) Units = Work / Duration (U = W/D)
Adding more resources to a task shortens duration Can be changed on a per-task basis
In the advanced tab of Task Information dialog box Task Type setting
Beware the Mythical Man-month

Good for laying bricks, not always so for software development
98
Link Tasks
On toolbar: Link & Unlink buttons
Good for many at once
Or via Gantt chart

Drag from one task to another
295
Milestones
Zero duration tasks Insert task normally but put 0 in duration
296
Make Assignments
Approach 1. Using Task Sheet
Using Resource Names column You can create new ones by just typing-in here
2. Using Assign Resources dialog box

Good for multiple resources Highlight task, Tools/Resources or toolbar button
3. Using Task Information dialog

Resources tab
4. Task Entry view

View/More Views/Task Entry Or Task Entry view on Resource Mgmt. toolbar
297
99
Save Baseline
Saves all current information about your project
Dates, resource assignments, durations, costs
298
Fine Tune
Then is used later as basis for comparing against actuals Menu: Tools/Tracking/Save Baseline
299
Project 2002
3 Editions: Standard, Professional, Server MS Project Server 2002
Upgrade of old Project Central Includes Project Web Access, web-based UI (partial) Workgroup and resource notification features Requires SQL-Server and IIS Portfolio Analyzer
Drill-down into projects via pivot tables & charts
Portfolio Modeler
Create models and what-if scenarios
SharePoint Team Services integration
300
100
Project 2002
MS-Project Professional
Build Team feature
Skills-based resource matching
Resource Pools: with skill set tracking Resource Substitution Wizard
Project Guide feature

Customizable process component
301

Session 7: Risk and Change Management
302
Risk Management
Problems that havent happened yet Why is it hard? Some are wary of bearing bad news
No one wants to be the messenger Or seen as a worrier
You need to define a strategy early in your project
303
101
Risk Management
Identification, Analysis, Control Goal: avoid a crisis Thayer: Risk Mgmt. vs. Project Mgt.
For a specific vs. all projects Proactive vs. reactive
304
Project Risk
Characterized by:
Uncertainty (0 < probability < 1) An associated loss (money, life, reputation, etc) Manageable some action can control it
Risk Exposure
Product of probability and potential loss
Problem
A risk that has materialized
305
Types of Risks
Schedule Risks
Schedule compression (customer, marketing, etc.)
Cost Risks
Unreasonable budgets
Requirements Risks
Incorrect Incomplete Unclear or inconsistent Volatile
306
102
Types of Risks
Quality Risks Operational Risks Most of the Classic Mistakes
Classic mistakes are made more often
307
Risk Management Process

Risk Identification Risk Assesment
Risk Analysis Risk Prioritization
Risk Management Risk Management Planning Risk Control Risk Resolution
Risk Monitoring
Software Risk Management, Boehm, 1989
308
Risk Identification
Get your team involved in this process
Dont go it alone
Produces a list of risks with potential to disrupt your projects schedule Use a checklist or similar source to brainstorm possible risks
309
103
Risk Analysis
Determine impact of each risk Risk Exposure (RE)
a.k.a. Risk Impact RE = Probability of loss * size of loss Ex: risk is Facilities not ready on time
Probability is 25%, size is 4 weeks, RE is 1 week
Ex: risk is Inadequate design redesign required

Probability is 15%, size is 10 weeks, RE is 1.5 weeks
Statistically are expected values Sum all REs to get expected overrun
Which is pre risk management
310
Risk Analysis
Estimating size of loss
Loss is easier to see than probability
You can break this down into chunks (like WBS)
Estimating probability of loss

Use team member estimates and have a risk-estimate review Use Delphi or group-consensus techniques Use gambling analogy how much would you bet Use adjective calibration: highly likely, probably, improbable, unlikely, highly unlikely
311
Risk Prioritization
Remember the 80-20 rule Often want larger-loss risks higher
Or higher probability items
Possibly group related risks Helps identify which risks to ignore

Those at the bottom
312
104
Types of Unknowns
Known Unknowns
Information you know someone else has
Unknown Unknowns
Information that does not yet exist
313
Risk Control
Risk Management Plan
Can be 1 paragraph per risk McConnells example
314
Risk Resolution
Risk Avoidance
Dont do it Scrub from system Off-load to another party
McConnell: design issue: have client design
Risk Assumption
Dont do anything about it Accept that it might occur But still watch for it
315
105
Risk Resolution
Problem control
Develop contingency plans Allocate extra test resources See McConnell pg. 98-99
Risk Transfer
To another part of the project (or team) Move off the critical path at least
Knowledge Acquisition
Investigate
Ex: do a prototype
Buy information or expertise about it Do research
316
Risk Monitoring
Top 10 Risk List
Rank Previous Rank Weeks on List Risk Name Risk Resolution Status
A low-overhead best practice Interim project post-mortems

After various major milestones
McConnells example
Risk Communication
Dont be afraid to convey the risks Use your judgment to balance
Sky-is-falling whiner vs. information distribution
318
106
Miniature Milestones
A risk-reduction technique Use of small goals within project schedule
One of McConnells Best Practices (Ch. 27)
Fine-grained approach to plan & track Reduces risk of undetected project slippage Pros
Enhances status visibility Good for project recovery
Cons
Increase project tracking effort
319
Can be used throughout the development cycle Works with will hard-to-manage project activities or methods
Such as with evolutionary prototyping
Reduces unpleasant surprises Success factors

Overcoming resistance from those managed Staying true to miniature nature
Can improve motivation through achievements
320
Requires a detailed schedule Have early milestones McConnell says 1-2 days
Longer is still good (1-2 weeks)
Encourages iterative development Use binary milestones

Done or not done (100%)
321
107
Feature-Set Control
Class mistake avoidance Early Stages
1. Minimal Specification 2. Requirements Scrubbing 3. Versioned Development
Mid-Project
Effective change control
Late-Project
Feature cuts
322
Traditional Specs
Drive for traditional specs
Necessity Downstream cost avoidance Full control over all aspects
As McConnell notes:
But the goal is not to build exactly what you said you would at the beginning. It is to build the best possible software within the available time. Idealistic but worth remembering
323
Minimal Specification
This is not XP (extreme programming) Tradition spec. issues
Wasted effort
Too much detail
Obsolescence Lack of efficacy -- details do not guarantee success Overly constrained design User assumption that costs are equal (UI ex.)
324
108
Minimal Specification
Benefits
Improved morale and motivation Opportunistic efficiency Shorter requirements phase
Costs and Risks

Omission of key requirements Unclear or impossible goals Gold plating Used for the wrong reasons
Lazy substitute for doing good requirements
Success Factors
Used only when requirements are flexible Capture most important items; involve key users
Requirements Scrubbing
Removing a feature from the product
Eliminates all effort: spec., design, dev., test, doc. The earlier the better Typically done during or right after Requirements
Less risky than minimal specification Aims

Eliminate all but absolutely necessary requirements Simplify all complicated requirements Substitute cheaper items
326
Versioned Development
Eliminate them from the current version Lets put it in release 1.1
Youre still saying Yes, not No
By next rev. the list has changed anyway My favorite
327
109
Mid-Project Feature-Creep
Avg. project has 25% change in requirements during development Sources of change
Marketing: want to meet customers check-list Developers: want to perfect r1 deficiencies Users: want more functionality or now know what they want
They will all try to insert these during dev.
328
Mid-Project Feature-Creep
The devil is in the details McConnells example: trivial feature can have +/weeks of impact Developers can insert things when youre not looking No spec. can cover all details. You must. Programmer ideal: flip switch- Word -> Excel Up to 10-1 differences in prog. size w/same specs.
329
Change Control Board (CCB)

McConnell best practice Structure: representatives from each stakeholder party
Dev., QA, Marketing, Mgmt., Customer support
Perform change analysis

Importance, priority, cost, benefit
Triage
Allocating scare resources Some will not receive treatment Life-critical to the project
Will say No more than Yes Watch for bureaucracy
330
110
Change Control
Change Control System
CM System CM Tool
Quality Software Project Management, Futrell, Shafer, Shafer
331
Configuration Control
A management support function Includes
Program code changes Requirements and design changes Version release changes
Essential for developed items

Code, documentation, etc.
Example
The case of the code that used to work
But didnt in time for the demo
332
Configuration Control Terminology

Software Configuration Control Item (SCCI)
a.k.a. Source Item (SI) Anything suitable for configuration control Source code, documents, diagrams, etc.
Change Control: process of controlling changes

Proposal, evaluation, approval, scheduling, implementation, tracking
Version Control: controlling software version releases

Recording and saving releases Documenting release differences
Configuration Control: process of evaluating, approving and disapproving, and managing changes to SCCIs.
333
111
SCM
Software Configuration Management Formal engineering discipline Methods and tools to identify & manage software throughout its use
334
Configuration Control Needs

Establish clearly defined mgmt. Authority Setup control standards, procedures and guidelines
All team members must be aware of these
Requires appropriate tools and infrastructure Configuration Management Plan must be produced during planning phase
Often part of Software Development Plan
335
Maintenance
SCM is very important during all phases starting with Requirements Continues to be important during Maintenance
336
112
Session 8: Development Management
337
Feature Set Control

Minimal Specification Requirements Scrubbing Versioned Development Effective Change Control Feature Cuts
338
Change Control
Average project has 25% requirements change Sources of change Change control is a process Overly detailed specs. or prolonged requirements phase are not the answer Change Control Board (CCB)
Structure, process, triage
339
113
Items: code, documents Change & Version control SCM Configuration Management Plan Maintenance
340
Project Roles
Programmers (system engineers)
Technical lead, architect, programmer, Sr. programmer
Quality Assurance (QA) engineers (testers)

QA Manager, QA Lead, QA staff
DBAs
DB Administrator, DB Programmer, DB Modeler
CM engineers (build engineers) Network engineers, System Administrators Analysts (business analysts) UI Designers Information Architects Documentation writers (editors, documentation specialist) Project manager Other
Security specialist, consultants, trainer
Project Roles
You need to decide which of these are necessary for your class project Depends on what youre building
How big is it? Is it UI intensive? Data intensive? Are you installing/managing hardware? Do you need to run an operations center? Is it in-house, contract, COTS, etc?
Depends on your budget
342
114
Staffing Profile
Projects do not typically have a static team size Who and how many varies as needed
Copyright: Rational Software 2002
343
Roll-on & Roll-off

PM must have a plan as to how & when Roll-on
Hiring or reserving resources Ramp-up time
Learning project or company
Roll-off
Knowledge transfer Documentation Cleanup
344
Staffing Management Plan

Part of Software Development Plan Includes
What roles needed, how many, when, who Resource assignments Timing: Start/stop dates Cost/salary targets (if hiring)
Project Directory
Simply a list of those involved with contact info.
Team size: often dictated by budget as often as any other factor
345
115
Team Structure
1st: Whats the teams objective?
Problem resolution
Complex, poorly-defined problem Focuses on 1-3 specific issues Ex: fixing a showstopper defect Sense of urgency
Creativity
New product development
Tactical execution
Carrying-out well-defined plan Focused tasks and clear roles
346
Team Models
Two early philosophies
Decentralized/democratic Centralized/autocratic
Variation
Controlled Decentralized
347
Team Models
Business Team
Most common model Technical lead + team (rest team at equal status) Hierarchical with one principal contact Adaptable and general Variation: Democratic Team
All decisions made by whole team See Weinbergs egoless programming model
348
116
Team Models
Skunkworks Team
Put a bunch of talented, creative developers away from the mother ship
Off-site literally or figuratively
Pro: Creates high ownership & buy-in Con: Little visibility into team progress Applicable: exploratory projects needing creativity
Not on well-defined or narrow problem
349
Team Models
SWAT Team
Highly skilled team Skills tightly match goal Members often work together Ex: security swat team, Oracle performance team
350
Team Models
Large teams
Communication increases multiplicatively
Square of the number of people 50 programmers = 1200 possible paths Communication must be formalized
Always use a hierarchy Reduce units to optimal team sizes

Always less than 10
351
117
Team Size
What is the optimal team size?
4-6 developers
Tech lead + developers
Small projects inspire stronger identification Increases cohesiveness QA, ops, and design on top of this
352
Responsibility Assignment Matrix

A resource planning tool Who does What Can be for both planning and tracking Identify authority, accountability, responsibility Who: can be individual, team or department Can have totals/summary at end of row or column (ex: total Contributors on a task)
353
Simple RAM
354
118
Sample RAM With Stakeholders
355
Skills Matrix
Another resource planning tool Resources on one axis, skills on other Skills can high level or very specific Cells can be Xs or numeric (ex: level, # yrs.)
356
Capability Maturity Model: CMM

A software process framework Process determines capability 5 maturity levels
Evolutionary plateaus to a mature software process
Each level has its own goals Organizations can be certified

Later to be used as a marketing or validation tool
Links: SEI, Diagram, Levels, Drexel
357
119
CMM Levels
1. Initial
Ad hoc process, chaotic even Few defined processes Heroics often required here
2. Repeatable
Basic PM processes
For cost, schedule, functionality
Earlier successes can be repeated
3. Defined
Software & Mgmt. process documented All projects use a version of org. standard
358
CMM Levels
4. Managed
Detailed metrics of process & quality Quantitative control
5. Optimizing
Continuous process improvement Using quantitative feedback
359
Tools
Requirements Tools Design Tools Construction Tools Test Tools Maintenance Tools CM Tools
360
120
Tools
Tools could save 10-25% on some projects
But thats optimistic at best
Choose tools to meet your needs No can guarantee you anything

They *may* help Tools dont control people, especially customers
361
Programming Languages
Your projects: do you choose a language? Typically not the PMs choice, but does effect you
Staffing requirements Methodology Tools and infrastructure
362
Requirements
Requirements are capabilities and condition to which the system more broadly, the project must conform
363
121
Requirements
Perhaps most important & difficult phase Shortchanging it is a classic mistake Can begin with a Project Kickoff Meeting Can end with a Software Requirements Review (SRR)
For Sponsor and/or customer(s) approval
364
Why are Requirements so Important?
365
Requirements
Conflict of interest: developer vs. customer Potential tug-of-war:
Disagreement on Features & Estimates Especially in fixed-price contracts
Frequent requirements changes Achieving sign-off
Project planning occurs in parallel
366
122
2 Types of Requirements
Functional (behavioral)
Features and capabilities
Non-functional (a.k.a. technical) (everything else)

Usability Human factors, help, documentation Reliability Failure rates, recoverability, availability Performance Response times, throughput, resource usage Supportability Maintainability, internationalization Operations: systems management, installation Interface: integration with other systems Other: legal, packaging, hardware
Requirements
Must be prioritized
Must-have Should-have Could-have (Nice-to-have: NTH)
Must be approved
368
Requirements
Used by many people for many purposes Purposes
Management: Yes, thats what I funded Users: Yeah, thats what I need Developers: Yes, thats I will build
369
123
Requirements
The What phase Inputs: SOW, Proposal Outputs:
Requirements Document (RD)
a.k.a.Requirements Specification Document (RSD) Software Requirements Specification (SRS)
1st Project Baseline Software Project Management Plan (SPMP) Requirements Approval & Sign-Off
Your most difficult task in this phase
370
Requirements
Theres no sense being exact about something if you dont even know what youre talking about John von Neumann When the map and the territory dont agree, always believe the territory, taught to all Swedish army recruits
371
Requirements Gathering Techniques

Interviews Document Analysis Brainstorming Requirements Workshops Prototyping Use Cases Storyboards There are more
372
124
Interview Techniques
Best practice: use context free questions
A question that does not suggest a response High-level, early questions to obtain global properties of the problem and solution Applicable to any project/product Get the ball rolling
373
Context-free Questions
Process, product and meta questions Process
Who is the client for project X? What is a very successful solution really worth to the client? What is the reason for this project?
Product
What problems does this system solve? What problems could this system create?
Meta-questions
Are these questions relevant? Is there anyone else who can give useful answers? Is there anything you want to ask me?
374
Document Analysis
Review of existing documents
Business plans Market studies Contracts Requests for proposals (RFP) Statements of work (SOW) Existing guidelines Analyses of existing systems and procedures
375
125
Brainstorming
Idea generation & idea reduction Typically via group meetings Generation Best practices
Minimize criticism and debate
Editing occurs at end of meeting or later
Aim for quantity Mutate or combine ideas
Reduction best practices

Voting with a threshold (N votes/person) Blending ideas Applying criteria Scoring with a weighting formula
376
Requirements Workshops
Typically 1-5 days Who? Varies. Users & stakeholders Pros
Good for consensus building Builds participant commitment Can cost less than numerous interviews Provide structure to capture and analysis process Can involve users across organizational boundaries Can help identify priorities and contentious issues
JAD
A type of requirements workshop using a facilitator
377
Prototyping
Quick and rough implementation Good communications mechanism Can be combined with other techniques such as JAD Issues: creating the mis-appearance that development is more complete than it actually is
See joelonsoftwares The Iceberg Secret Revealed
378
126
Use Cases
Picture plus description Often misunderstood: the text is more important Diagrams Text structure
Use case name and number (ID) Goal Pre-conditions Primary & secondary actors Trigger Description Business rules Open issues
For good examples, see usecases.org
379
Storyboards
Set of drawings depicting user activities Paper prototyping Drawing screens or processes
380
Requirements: Who?
Customers and users (note: often not the same)
Customers can be users, but rarely opposite Sometimes user constituencies need to be found
Subject matter experts Other stakeholders

Marketing, sales Product managers
381
127
Other Requirements Tips

Meetings
Treat them like a tool: design them Boy scout motto: Be Prepared As small as possible but no smaller Make it safe not to attend
Publish an agenda before Publish a summary after
Generate a related issues list Can formal/informal, scheduled/ad-hoc
382
Other Requirements Tips

Manage expectations
Dont forget to ask people theirs Listen Make explicit otherwise implicit decisions
PDA: Possibility, Deferred, Absolutely impossible
Technical reviews
Requirements can be wrong by: inadequate or inaccurate
Quantity & quality
Reviews help with the latter
383
Requirements Tools
Starbase: CaliberRM Telelogic: DOORS Databases of requirements Displayable in various formats Optional requirements control metrics:
Requirements Stability Index
To help manage feature creep and vibration
384
128

385
Project Overview
386
Project UI
Views
387
129
Project UI
Split Bar
388
Create Your Project

389
Enter WBS
390
130
Establish Durations
Can use partial


391
Add Resources
Work Resources
People
Material Resources
392
Resource Sheet
Setup costs
393
131

Link Tasks
Or via Gantt chart

395
Milestones
396
132
Make Assignments


Resources tab
4. Task Entry view

397
Save Baseline
398
Fine Tune
399
133
Project 2002
Portfolio Modeler
400
Project 2002
Build Team feature

401
MS-Project Q&A
Your WBS in Project How did it go? Any questions?
402
134

Session 9: Project Control
403
Project Control
Ongoing effort to keep your project on track 4 primary activities:
1. Planning performance
A SDP, schedule, and a control process
2. Measuring status of work performed

Actuals
3. Comparing to baseline
Variances
4. Taking corrective action as needed

Response
Prerequisite to good control is a good plan

Project Control
Control
Power, authority, domination. No. Guiding a course of action to meet an objective. Yes.
Principles
Work is controlled, not workers
Control helps workers be more effective & efficient
Control based on work completed

Use concrete deliverables
Balance
Appropriate level between too much and too little Includes: Micro-managing vs. neglect Too much tracking detail vs. too little
405
135
Progress Monitoring
The 3 key Progress Monitoring Questions
What is the actual status? If theres a variance, what is cause? What to do about it?
Possible responses
1. Ignore 2. Take corrective action 3. Review the plan
406
Progress Monitoring
Monitoring rates
Daily, weekly, monthly If problems occur then adjust
You may have to monitor problem areas more closely For some period of time Almost always theres one or more areas under closer scrutiny
Status Reporting Part of the communications management plan

Which is usually just a section of SDP
407
Status Reports
From team to PM, from PM to stakeholders
Typical format for latter
Summary Accomplishments for this period (done)
Tasks, milestones, metrics
Plans for next period (to-do) Risk analysis and review Issues & Actions
Shoot for weekly updates

Email notes, then hold brief meeting More frequently during crises
408
136
Programming Status Reporting

A programmer reports that hes 90% done.
What does this mean?
A programmer reports completing 4,000 LOC on estimated 5,000 LOC effort.

Is this 80% complete? Quality? Ratio, estimated to completed?
Your estimates could have been wrong
If you cant measure scope or quality you dont know reality You really only know cost (hours spent) How can you improve this?
409
Binary Reporting
Work packages (tasks) can only be in one of 2 states: complete or incomplete
No partial credit
Preferred to anything subjective! 90% Complete Syndrome

Software is 90% complete 90% of the time
Use lower-level task decomposition Tangible exit criteria Plan for 4-80 staff hours of effort per task
410
Earned Value Analysis (EVA)

a.k.a. Earned Value Management (EVM) a.k.a. Variance Analysis Metric of project tracking What you got for what you paid
Physical progress
Pre-EVA traditional approach

1. Planned time and costs 2. Actual time and costs Progress: compare planned vs. actual
EVA adds third dimension: value

Planned, actual, earned
137
Earned Value Analysis

Forecasting
Old models include cost & expenditure EVA adds schedule estimation
Measured in dollars or hours

Often time used in software projects
Performance Measurement Baseline (PMB)

Time-phased budget plan against which contract performance is measured Cost & schedule variances go against this Best via a bottom-up plan
412

Different methods are available
Binary Reporting Others include
Based on % complete Weights applied to milestones
EVA can signal errors as early as 15% into project Alphabet Soup
413

3 major components
BCWS: Budgeted Cost of Work Scheduled
Now called Planned Value (PV) Yearned How much work should be done?
BCWP: Budgeted Cost of Work Performed

Now called earned value (EV) Earned How much work is done? BCWS * % complete
ACWP: Actual Cost of Work Performed

Now called Actual Cost (AC) Burned How much did the work done cost?
138
Derived EVA Variances

SV: Schedule Variance
BCWP BCWS Planned work vs. work completed
CV: Cost Variance

BCWP ACWP Budgeted costs vs. actual costs
Negatives are termed unfavorable Can be plotted on spending curves

Cumulative cost (Y axis) vs. Time (X axis) Typically in an S shape
What is the project status?

You can use variances to answer this
415
416
Derived EVA Ratios

SPI: Schedule Performance Index
BCWP / BCWS
CPI: Cost Performance Index

BCWP / ACWP
Problems in project if either of these less than 1 (or 100%)
417
139

Other Derived Values
BAC: Budget At Completion
Sum of all budges (BCWS). Your original budget.
EAC: Estimate At Completion

Forecast total cost at completion EAC = ((BAC BCWP)/CPI) + ACWP Unfinished work divided by CPI added to sunk cost If CPI < 1, EAC will be > BAC
CR: Critical Ratio

SPI x CPI 1: everything on track > .9 and < 1.2 ok Can be charted
418
EVA Example
As of 1-July where are we? BCWS BCWP ACWP
419
EVA Example
CV SV CPI SPI CR
420
140

BCWS
Use loaded labor rates if possible
Direct pay + overhead
Remember its an aggregate figure

May hide where the problem lies Beware of counterbalancing issues
Over in one area vs. under in another
421

Benefits
Consistent unit of measure for total progress Consistent methodology
Across cost and completed activity Apples and apples comparisons
Ability to forecast cost & schedule Can provide warnings early
Success factors
A full WBS is required (all scope) Beware of GIGO: Garbage-in, garbage-out
422

423
141
Project Overview
424
Project UI
Views
425
Project UI
Split Bar
426
142
Create Your Project

427
Enter WBS
428
Establish Durations
Can use partial


429
143
Add Resources
Work Resources
People
Material Resources
430
Resource Sheet
Setup costs
431

144
Link Tasks
Or via Gantt chart

433
Milestones
434
Make Assignments


Resources tab
4. Task Entry view

435
145
Save Baseline
436
Fine Tune
437
Project 2002
Portfolio Modeler
438
146
Project 2002
Build Team feature

439

Session 10: Integration & Testing
440
Deliverables by Phase
Possible Deliverables by Phase Concept Document Statement of W ork (SOW ) Project Charter RFP & Proposal Software Concept Requirements Document (Software Requirements Specification) Work Breakdown Structure (W BS) Requirements Functional Specification ( Top Level Design Specification) Entity Relationship Diagram Data Flow Diagram Analysis Project Development Plan (Software Development Plan ) Baseline Project Plan Quality Assurance Plan Configuration Management Plan Risk Management Plan Detailed Design Specification Object Diagrams Detailed Data Model Design Coding Standards Working Code Unit Tests Coding and Debugging Acceptance Test Procedures Tested Application Systems Testing Maintenance Specification Deployed Application Deployment & Maintenance
Integration Plan Detailed SQA Test Plan SQA Test Cases
User Documentation Training Plan
441
147
Development Costs
7% 29% 16%
Requirements Preliminary Design Detailed Design Code & Unit Test 24% Integration & System Test
24%
442
Integration & Testing

Development/Integration/Testing
Most common place for schedule & activity overlap
Sometimes Integration/Testing thought of as one phase Progressively aggregates functionality QA team works in parallel with dev. team
443
Integration Approaches
Top Down
Core or overarching system(s) implemented 1st Combined into minimal shell system Stubs are used to fill-out incomplete sections
Eventually replaced by actual modules
Bottom Up
Starts with individual modules and builds-up Individual units (after unit testing) are combined into sub-systems Sub-systems are combined into the whole
444
148
Integration
Who does integration testing?
Can be either development and/or QA team
Staffing and budget are at peak Crunch mode Issues

Pressure Delivery date nears Unexpected failures (bugs) Motivation issues User acceptance conflicts
445
Validation and Verification

V&V Validation
Are we building the right product?
Verification
Are we building the product right? Testing Inspection Static analysis
446
SQAP
Standard sections
Purpose Reference documents Management Documentation Standards, practices, conventions, metrics
Quality measures Testing practices
447
149
SQAP (Software Quality Assurance Plan)

Standard sections continued
Reviews and Audits
Process and specific reviews
Requirements Review (SRR) Test Plan Review Code reviews Post-mortem review
Risk Management
Tie-in QA to overall risk mgmt. Plan
Problem Reporting and Corrective Action Tools, Techniques, Methodologies Records Collection and Retention
448
Software Quality
Traceability
Ability to track relationship between work products Ex: how well do requirements/design/test cases match
Formal Reviews
Conducted at the end of each lifecycle phase SRR, CDR, etc.
449
Testing
Exercising computer program with predetermined inputs Comparing the actual results against the expected results Testing is a form of sampling Cannot absolutely prove absence of defects All software has bugs. Period. Testing is not debugging.
450
150
Test Cases
Key elements of a test plan May include scripts, data, checklists May map to a Requirements Coverage Matrix
A traceability tool
451
Rework
Software equivalent of scrap in manufacturing
30% 25% 20% 15% 10% 1% 5% 0% Requirements Detailed Design Integration & System Test 6% 12% 4% 16% 12% 10% 8% 12% 19% Rew ork Production
452
Sources of Defects
27%
Design Other Code
56% 7%
10%
Requirements
453
151
V Process Model
Project Requirements and Planning Non-functional Requirements Load & Performance Test Production, Operations, and Maintenance
Product Requirements and Specification Analysis
User Interface Design
Usability Test
System Testing and Acceptance Testing
High-Level Desig
Integration and Testing
Detailed Design
Unit Testing
Coding
454
Project Testing Flow

Unit Testing Integration Testing System Testing User Acceptance Testing
455
Black-Box Testing
Functional Testing Program is a black-box
Not concerned with how it works but what it does Focus on inputs & outputs
Test cases are based on SRS (specs)
456
152
White-Box Testing
Accounts for the structure of the program Coverage
Statements executed Paths followed through the code
457
Unit Testing
a.k.a. Module Testing Type of white-box testing
Sometimes treated black-box
Who does Unit Testing?

Developers Unit tests are written in code
Same language as the module a.k.a. Test drivers
When do Unit Testing?

Ongoing during development As individual modules are completed
458
Unit Testing
Individual tests can be grouped
Test Suites
JUnit
Part of the XP methodology Test-first programming
459
153
Integration Testing
Testing interfaces between components First step after Unit Testing Components may work alone but fail when put together Defect may exist in one module but manifest in another Black-box tests
460
System Testing
Testing the complete system A type of black-box testing
461
User Acceptance Testing

Last milestone in testing phase Ultimate customer test & sign-off Sometimes synonymous with beta tests Customer is satisfied software meets their requirements Based on Acceptance Criteria
Conditions the software must meet for customer to accept the system Ideally defined before contract is signed Use quantifiable, measurable conditions
462
154
Regression Testing
Re-running of tests after fixes or changes are made to software or the environment EX: QA finds defect, developer fixes, QA runs regression test to verify Automated tools very helpful for this
463
Compatibility Testing
Testing against other platforms
Ex: Testing against multiple browsers Does it work under Netscape/IE, Windows/Mac
464
External Testing Milestones

Alpha 1st, Beta 2nd Testing by users outside the organization
Typically done by users
Alpha release
Given to very limited user set Product is not feature-complete
During later portions of test phase Beta release

Customer testing and evaluation Most important feature Preferably after software stabilizes
465
155

Value of Beta Testing
Testing in the real world Getting a software assessment Marketing Augmenting you staff
Do not determine features based on it

Too late!
Beta testers must be recruited

From: Existing base, marketing, tech support, site
Requires the role of Beta Manager All this must be scheduled by PM


Release Candidate (RC)
To be sent to manufacturing if testing successful
Release to Manufacturing (RTM)

Production release formally sent to manufacturing
Aim for a stabilization period before each of these milestones

Team focus on quality, integration, stability
467
Test Scripts
Two meanings 1. Set of step-by-step instructions intended to lead test personnel through tests
List of all actions and expected responses
2. Automated test script (program)
468
156
Static Testing
Reviews
Most artifacts can be reviewed Proposal, contract, schedule, requirements, code, data model, test plans
Peer Reviews
Methodical examination of software work products by peers to identify defects and necessary changes Goal: remove defects early and efficiently Planned by PM, performed in meetings, documented CMM Level 3 activity
469
Automated Testing
Human testers = inefficient Pros
Lowers overall cost of testing Tools can run unattended Tools run through suites faster than people Great for regression and compatibility tests Tests create a body of knowledge Can reduce QA staff size
Cons
But not everything can be automated Learning curve or expertise in tools Cost of high-end tools $5-80K (low-end are still cheap)
Test Tools
Capture & Playback Coverage Analysis Performance Testing Test Case Management
471
157
Load & Stress Testing

Push system beyond capacity limits Often done via automated scripts
By the QA team Near end of functional tests
Can show
Hidden functional issues Maximum system capacity Unacceptable data or service loss Determine if Performance Requirements met
Remember, these are part of non-functional requirements
472
Load & Stress Testing

Metrics
Minimal acceptable response time Minimal acceptable number of concurrent users Minimal acceptable downtime
Vendors: High-End
Segue Mercury Empirix
473
Performance Metrics
Bad Good Must support 500 users Must support 500 simultaneous users 10 second response time [Average|Maximum|90th percentile] response time must be X seconds
Must handle 1M hits per Must handle peak load day of 28 page requests per second
Source: Athens Consulting Group
474
158
Other Testing
Installation Testing
Very important if not a Web-based system Can lead to high support costs and customer dissatisfaction
Usability Testing
Verification of user satisfaction
Navigability User-friendliness Ability to accomplish primary tasks
475

Session 11: Final Stages
476
Resource Leveling
Techniques
Activity shifting
Move start/end dates forward or backward
Activity splitting
Break an activity into two or more pieces
Activity stretching
Use less of a given resource continuously
Resource substitution
Assign a different resource
Allocating overtime
Work resources longer
477
159
Migration
Moving users from existing system to your new one
478
Migration Plan
Includes
Description of environment (computers, DBs, interfaces) Description of existing data needed Description of operational constraints (ex: when can we move to the new system? Weekends only? Last week of month only?) List of affected organizations and contacts Plan of steps to be taken
479
Migration Plan
Does it require a service interruption?
If so, when does this happen? A weekend?
Training? Is there a helpdesk?

If do, do they have scripts or new material?
480
160
Migration Strategies
Communication with customers is crucial
What is happening, when, and why Why should remind them of the benefits Not too much detail or too little Where do customers go for more information?
Minimize intrusiveness Find-out about customers key dates

When does the system absolutely need to be stable? Know about their important deadline dates They must buy-into the approach!
481
1. Flash-Cut
Straight-move from old system to new A) Immediate Replacement
Fastest approach Still want a back-out plan Requires strong planning and testing
B) Parallel Operation
Mitigates risk Parallel to either existing manual or system process Cut occurs once new system burned-in
2. Staged
Replace one part of existing system at a time
482
Considerations:
Level of business disruption Degree of latitude in production date How much internal opposition to system is there?
If higher, perhaps a longer adjustment period
Your comfort level of system quality

If questionable, may want to mitigate risk
483
161
Cutover
Criteria: What conditions must be met prior? Responsibility: Who decides? Operations: Who owns it once its live? Rehearsals: Sometimes used.
484
Flash-Cut
Immediate Replacement
Ex: new corporate-wide calendaring system
Requires very careful planning & testing Still try to get some users to try it first if possible Develop a back-out plan
485
Back-Out Plan
Especially important for conversions
Customers already have expectations and needs as defined by their existing system Must be able to restore customers service ASAP
May mean running both simultaneously just in case Leave it in place for awhile (more than a day!) When to fall-back?
Mgmt: sooner, Tech: one-more-fix Set a time limit (ex: 3 hours of start)
486
162
Data Conversion
Quote:
If you add a cup of champagne to a barrel of sewage, youll have a barrel of sewage If you add a cup of sewage to a barrel of champagne, youll have a barrel of sewage
Most systems need this step Most PMs forget this Impacts both completely new and replacement systems The data often more valuable than the system
487
Data Conversion Areas

Data Sources:
Where does it come from? Do you need to modify data on the way in? Is it accurate?
Process Controls:
Does it happen all at once? How do you guarantee its been done correctly?
Completion:
How do you handle any exceptions? Do you make backups? Can you restart?
488
Parallel Operation
Multiple variations of this method An adoption period
See telephone industry w/new area codes Both work for a period of time
Strategies
Avoid flash-cuts if possible
Start with test subjects
489
163
Rollout
Create a Release Checklist
Avoid activities falling through the cracks Example Activities by Group:
Engineering, QA, Documentation, Operations
Possibly sign-off signatures
Roll-out: Must have a plan for the process

Often on a given day (ex: a Sat.) Must be a very detailed plan
490
Training
Often more than just end-users
Users Sales & Marketing staff System operators Maintenance engineers (possibly) Sales engineers (possibly)
491
Documentation
Must be ready by ship-date Final user documentation Updates to other
Operations documentation Development documentation Sales and marketing material Wed site Test reports
492
164
Shipping Details
Packaging (if commercial product) Marketing collateral Security mechanisms (if commercial product) Licensing
Plan Mechanism
493
Installation
Scripts Uninstall (if not Web-based) If you need to install your software (as on PCs):
Dont underestimate:
Time this takes to develop Importance of a first impression
Or, if custom software youre reselling

Installation at site is often a mini-project
494
Project Recovery
How to save a drowning project 3 Approaches
1. Cut the size of the software 2. Increase process productivity 3. Slip the schedule, proceed with damage control
Opportunity for decisive leadership action Not a time to just cut corners
Be realistic (not foolish)
Timing: politically important

Not too early, not too late
495
165
Project Recovery
Steps
Assess situation
Is there a hard deadline, whats negotiable, etc.
Dont do whats been done already Ask team what needs to be done
People Steps
Restore morale
Sacrifice a sacred cow Dress code, off-site, catered meals, etc Cleanup personnel problems
Focus peoples time

Remove non-essential work
496
Project Recovery
Process Steps
Fix classic mistakes
Inadequate design, shortchanged activities, etc?
Create Miniature Milestones

Small (in day(s)), binary, exhaustive Boosts morale: getting things done!
Track progress meticulously Recalibrate after a short time Manage risk painstakingly
497
Project Recovery
Product Steps
Stabilize the requirements Raise the bar on change requests Trim the feature set
Determine priorities, cut the low ones
Take out the garbage

Find error-prone modules; re-design
Get to a known, stable state & build from there
498
166

Session 12: Project Success
499
Concluding Software Projects

Seems simple, often isnt Potential Issues
Last-minute change requests
One more feature
Disputes of fulfillment of all requirements

Often interpretation issues
Keeping the team motivated Difficult transition to maintenance
500
Maintenance Phase
The No respect phase Less glamorous
Lack of enthusiasm
Pressure to make fixes quickly

For production problems
Software can become hacked patchwork over time Finding a support & test platform can be difficult
Often the forgotten child until fixes are needed
501
167
Maintenance Phase
Compare to hardware maintenance
Not to keep state same; but changes to state Fixes and enhancements
Configuration control is very important

Fixing the right version; tracking branches
Project management not always carried over Smaller team

Often not a dedicated team Drawn from developer with other main tasks
502
Maintenance Phase
Contracts, remember those?
Always consider the maintenance phase here Often via a labor hours contract
Time & materials in a direct scenario
Otherwise via maintenance contract

Percentage of software license fee Ex: 20% of original cost per year
Corp. budget if internal/IS projects

Often annual/monthly maintenance allocations
503
Success Metrics
1. On schedule
Requires good: plan; estimation; control
2. Within budget
Again: planning, estimation & control
3. According to requirements
Importance of good requirements Perception & negotiation critical
504
168
You are not Santa Claus

Learn to say No
Be polite but firm
The Value of Versions

We will put that in phase 2
An Ounce of Prevention
505
Think Small
Keep requirements tight & focused One milestone at a time Smaller, incremental chunks As simple as possible but no simpler
506
Process Spectrum
Too much medicine can kill the patient
Process Spectrum
Chaos
Bureauracracy
Balance is crucial
169
Paralysis
Analysis Paralysis
Over-process Nothing gets finished 65% of software professionals have experienced this
Paralysis Paranoia
Fear of over-process = process avoidance
508
Miscellaneous
MBWA
Management by Walk About
Shows your actually involved day-to-day Recognizes individuals may say more 1-on-1 Allows spontaneity Finds personnel problems sooner
509
Delegate
Dont be a Control Freak You need to be the hub but not everything
510
170
Success Rates
By Industry
Best: Retail
Tight cost controls in general
Worst: Government
Least cost controls
By Size
Smaller is better: cost, duration, team
Stats
511
Project Home Page

Give your project an intranet page Central repository for project status, documents and other resources McConnells example
512
Continuous Process Improvement
Herbsleb, 1994, Benefits of CMM-Based Software Process Improvement
513
171
Risk Management
Risk Management
Types of risk: schedule, cost, requirements
Risk Identification
Involve the team
Risk Analysis
Risk Exposure (RE = Prob. * Size)
Probability is 15%, size is 10 weeks

.15 * 10w = 1.5w
Risk Prioritization
80-20 rule; large size or prob. 1st; grouping; ignoring
514
Risk Management
Risk Control
Plan
Risk Resolution (5 Types)

Avoidance (ex: scrub) Assumption (just monitor) Control (contingency) Knowledge Acquisition (learn/buy/prototype) Transfer (off project, team, critical path)
Risk Monitoring
Top 10 Risk List (McConnells example)
515
Requirements
Functional vs. Non-functional (technical)
Functional
Features
Non-functional
Reliability Usability Performance Operations: systems management, installation Other: legal, packaging, hardware
516
172
Requirements
Requirements gathering techniques
Interviews Document Analysis Brainstorming Requirements Workshops Prototyping Use Cases Storyboards
517
Teams
Start with objective
Problem resolution, creativity, tactical execution
Decentralized vs. Centralized Large teams

Decompose via hierarchy, into optimal sizes
Optimal size?
4-6 developers
Hiring
Hire for trait train for skill
518
Team Models
Business team
Technical lead + team; most common Can be strong or loose hierarchy
Chief-programmer team
Surgical team; star at top; ego issues
Skunkworks team
Off-site; pro: buy-in; con: minimal visibility
Feature team
Interdisciplinary; balanced
SWAT team
Highly skilled/specialized; Ex: security team
519
173
Resource Allocation
Responsibility Assignment Matrix
Who does What
Skills Matrix
Who has what skills
Hiring Guidelines
Hire for trait, train for skill Smart, gets things done
Balance
520
Feature Set Control

Minimal Specification Requirements Scrubbing Versioned Development Effective Change Control Feature Cuts
521
Change Control
Average project has 25% requirements change Sources of change Change control is a process Overly detailed specs. or prolonged requirements phase are not the answer Change Control Board (CCB)
Structure, process, triage
522
174
Items: code, documents Change & Version control SCM Configuration Management Plan Maintenance
523
Exam Review
Project Roles Project Control
Planning Measuring Evaluating Acting
Binary Reporting
524

BCWS BCWP
Earned value
ACWP Variances
CV (BCWP BCWS), SV (BCWP ACWP)
Ratios
SPI (BCWP / BCWS), CPI (BCWP / ACWP) CR (SPI x CPI)
Benefits
Consistency, forecasting, early warning
525
175
CMM
Capability Maturity Model Five levels
Initial Repeatable Defined Managed Optimizing
Links: Diagram, Levels

Tools & Languages

Impact of platform and language choice
Staffing requirements Methodology
Cobol != Java
Tools and infrastructure

Software, hardware
Classic Mistake: silver bullet syndrome

Over-reliance/expectation on tool benefits
527
QA & Testing
Testing Phases
Unit Integration System User Acceptance Testing
Testing Types
Black-box White-box
528
176
QA & Testing
Static vs. Dynamic Testing Automated Testing
Pros and cons
Defect tracking Integration: 2 types

Top down Bottom up
529
Defect Metrics
Open Bugs (outstanding defects)
Ranked by severity
Open Rates
How many new bugs over a period of time
Close Rates
How many closed over that same period Ex: 10 bugs/day
Change Rate
Number of times the same issue updated
Fix Failed Counts

Fixes that didnt really fix (still open) One measure of vibration in project
530
Migration and Rollout

1. Flash Cut
A. Immediate Replacement B. Parallel Operation
2. Staged
One part at a time
531
177
Exam Review MS-Project

Effort-driven scheduling
532
Resource Leveling
5 Leveling techniques
Activity shifting Activity splitting Activity stretching Resource substitution Allocating overtime
533
Migration
Migration Plan Importance of 2-way communication
Find-out customers key dates
Minimize intrusiveness Back-out Plan Data Conversion
534
178
Migration
Flash-Cut Migration
Immediate Replacement Parallel Operation
Staged Migration
535
Other Final Steps

Roll-Out
Release Check-List
Training
More than just end-users
Users, systems ops, maintenance developers, sales
Documentation
Many types: End-user, sales & marketing, operations, design
536
Project Recovery
3 Approaches
1. Cut the size of the software 2. Increase process productivity 3. Slip the schedule, proceed with damage control
People Steps
Morale; focus; re-assign
Process Steps
Fix classic mistakes; mini-milestones
Product Steps
Stabilize; trim features; take out the garbage
537
179
Post Project Reviews

Focused on process not people Steps
Prepare survey form Email team with survey and schedule meeting
Gather data
Conduct meeting Prepare PPR report
538
180

SoftwareProjectManagement New

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SoftwareProjectManagement New

Enviado por

Direitos autorais:

Formatos disponíveis

DANANG UNIVERSITY OF TECHNOLOGY

FACULTY OF INFORMATION TECHNOLOGY

SOFTWARE PROJECT MANAGEMENT

Principles of Project Management

Principles of Project Management

SOFTWARE PROJECT MANAGEMENT

Principles of Project Management

Principles of Project Management

Principles of Project Management

Project Management Skills

Principles of Project Management

Project Manager Positions

Principles of Project Management

Software Project Management

Software Project Management

Principles of Project Management

Principles of Project Management

Project vs. Program Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Tools: Gantt Chart

Principles of Project Management

Tools: Network Diagram

Principles of Project Management

PMIs 9 Knowledge Areas

Principles of Project Management

Principles of Project Management

Why Rapid Development

Principles of Project Management

Principles of Project Management

Four Project Dimensions

Principles of Project Management

Principles of Project Management

Principles of Project Management

Developer productivity: 10-to-1 range Improvements:

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Principles of Project Management

Seven Core Project Phases

Principles of Project Management

Project Phases A.K.A.

Principles of Project Management

Operations and Support

Principles of Project Management

Principles of Project Management

People-Related Mistakes Part 1

Uncontrolled problem employees Heroics Adding people to a late project

Principles of Project Management

People-Related Mistakes Part 2

Principles of Project Management

People-Related Mistakes Part 3

Principles of Project Management

Process-Related Mistakes Part 1

Principles of Project Management