project management. outline defining the project manager role planning projects managing risks
TRANSCRIPT
PROJECT MANAGEMENT
Outline
• Defining the Project Manager Role• Planning Projects• Managing Risks
Development process- when to do what phase- document: SPMP
Management structure- hierarchical, peer,...
Risk identification & retirement
Plan project
Integrate & test system
Analyze requirements
Design
Maintain
Test unitsImplement
Software Engineering
Roadmap:
Corporate practices
Development phases
Schedule
Cost estimate
SPMP
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Learning Goals
• Understand the term “project management”
• Learn different ways to organize teams
• Identify and manage risks
• Create high level project schedules
• Estimate costs very early in the life cycle
• Create Software Project Management Plan
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
UPEDU PM Foci
• The UPEDU development process has three mechanisms for tacking the central issues of PM:– Adapting plans to changing project constraints– Managing risk through iterative development– Ensuring progress through use of adequate
measurement of: time, cost, capability, and quality
Introduction to Project management
PM WANTED - Requirements:•Technical
•Organizational•People Management Skills
Management 101
The four fundamental activities of management:
• Planning• Organizing• Controlling• Leading (influencing)
http://smallbusiness.chron.com/four-basic-functions-make-up-management-process-23852.html
Variables for Project Management
cost
capability duration
defectdensity(quality)
Target :$70K
Target : 30 wks
Target : 4 defects/Kloc
Target:100%
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Can somewhat vary each of these factors
Bullseye Figure for Project Variables
cost
capability duration
defectdensity
Target :$70K
Actual: 100%
Target : 30 wksTarget :
4 defects/Kloc
thisproject
Actual:1 defect/Kloc
Actual:20 wks
Actual:$90K
Target:100%
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
RoadMap for Project Management
1. Understand project content, scope, & time frame
2. Identify development process (methods, tools, languages, documentation and support) -- section 4 of chapter 1
3. Determine organizational structure (organizational elements involved) -- see section 3
4. Identify managerial process (responsibilities of the participants) -- see section 3 of case study 1 at end of chapter
6. Develop staffing plan -- see section 3.5 of case study 1
5. Develop schedule (times at which the work portions are to be performed) -- see section 6
7. Begin risk management -- see section 4
8. Identify documents to be produced -- see SQAP 4.2
9. Begin process itself -- described in chapters 3-10
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Managing people
“the principal ingredient is people”
Project Management Perspectives
• Enterprise (Business) Perspective– Effecting the “bottom line”
• Management Perspective– “there are no technical failures only management failures”– Get the job done PM Keep staff happy
• User / Joe Employee Perspective– “we just want management to make our jobs better”
• Engineers’ Perspectives– Architecural and design level, implementation level– High quality workmanship, pride
Managing Expectations
• Managers must have a strong concern for the people they work for and with
• They must help people work together• Must be familiar with team building concepts
(covered next week)• Must fit personal aspirations to team goals• Communicate expectations affectively • Measurement of project variables is key• Note deviation from plan, take action
3. Options for organizing personnel
Optimal Size for Interaction (Approximate)
Number of people with whom developer must frequently interact
Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help.
Key: = engineer
3
Effectiveness per developer
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
What is the best range of peopleIn a workgroup?
Optimal Size for Interaction (Approximate)
Number of people with whom developer must frequently interact
Developer communicates regularly with eleven people. Communication time outweighs benefits of interaction
Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help.
Key: = engineer
Approximateoptimal range
3 7
Effectiveness per developer
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
L yle HerbertM arke ting
E ric A dam sS oftw are engineer
F ran S arr isS oftw are engineer
Ha l K e l lyS oftw are engineer
F red M orde l lD eve lopm ent
V ern K ruppT echnica l spec ia l is t
Q uinn ParkerQ A
A pri l S m ithM anager
Hierarchical Project Management Organizations
Larger Projects:Smaller Projects:
No separate Marketing dept?No separate QA group?
Subdivide QA into testing, …?Subdivide Engineering into
system engineering, …?Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Networked Project Management Organizations
Gil WarnerTeam leader
Ian CorlissTeam member
Nel TremontTeam member
Fran SmithTeam member
Team facilitator?
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
(A more Organic/Democratic Structure)
Peer Organizations for Larger Projects
Team of leaders
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Roles versus People
Project Manager
Technical Architect
Programmer
Jim Nasium 50% 25%
Bart Simpson 100%
Judy Jedi 75% 25%
Organize a Team
1. Select team leader: responsibilities: – ensure all project aspects active– fill all gaps
3. Designate leader roles & document responsibilities team leader: proposes and maintains… SPMP configuration management leader: ... SCMP quality assurance leader: ... SQAP, STP requirements management leader: ... SRS design leader: ... SDD implementation leader: ... code base
2. Leaders’ responsibilities:– propose a strawman artifact (e.g. SRS, design)– seek team enhancement & acceptance– ensure designated artifact maintained & observed– maintain corresponding metrics if applicable
4. Designate a backup for each leader as per
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Identifying and managing risks
What is a Risk?
• What is risk?• Do all projects have risks?• What about software projects?
Risk Sources Ordered by Importance (Keil, Cule, Lyytinen, Schmidt)
1. Lack of top management commitment
2. Failure to gain user commitment
3. Misunderstanding of requirements
4. Inadequate user involvement
5. Failure to manage end-user expectations
6. Changing scope and/or objectives
7. Lack of sufficient knowledge/skills
What is a Risk?
• Two types of project risks– Direct Risk - Can be avoided / controlled
• eg. Project member likely to move• Retirement via elimination
– eg. job shadowing, replace when necessary
– Indirect Risk - Cannot be avoided• eg. Comm. time between NS and BC• Retirement via mitigation (decrease risk as
much as possible)– eg. Use client/server arch. to provide some
local functionality
The Four Risk Activities
1. Identification – a continual activity
2. Analysis and Prioritization (see spreadsheet)
– RBC = Probability * Impact; RAC = RBC * Cost
3. Planning – create action plan
- to retire or mitigate
4. Retirement or mitigation – includes tracking
and control
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Projectfinish
The Risk Management Mindset
Projectstart
Identification Retirement
2. “Java skills not high enough.”
1. “May not be possible to superimpose images adequately.”
1. Retirement by conquest:
Demonstrate image super- imposition
Risk 1
Risk 2
Risk 1
Projectfinish
Risk 2
2. Retirement by avoidance:
Use C++
Projectstart
Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
*:in advance of first meeting M: at meeting **: between meetings
Identify and Retire Risks
1.* Each team member spends 10 mins. exploring his or her greatest fears for the project’s success
2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader
3.* Team leader integrates and prioritizes results 4.M Group spends 10 mins. seeking additional risks 5.M Team spends 10 mins. finalizing the risk table
– Designates responsible risk retirement engineers
6.** Responsible engineers do risk retirement work7.M Team reviews risks for 10 mins. at weekly meetings
– responsible engineers report progress– team discusses newly perceived risks and adds them
In-Class Exercise
• Each group member takes 5 minutes to identify risks to project success – fill in probability, impact, retirememt method and costs
on spreadsheet provided
• One group member leads all to integrate and rationalize, and add any additional risks
• Calculate priority (RBC, RAC) of risks• Rank priorities, determine most important• Suggest methods of retirement or mitigation and
assign person responsible for follow-up
Creating schedules: High level planning
Create an Initial Schedule
1. Indicate the deliveables you must meet– usually includes delivery date
2. Introduce the milestones you should meet– e.g., begin system testing well before delivery
3. Designate a time at which all requirements frozen The remaining steps depend on the process used. Assume an iterative process.
4. Show first iteration: establishes minimal capability– usually: keep it very modest, even trivial, in capability– benefit: exercises the development process itself
5. Show task of identifying & retiring risks– starting from project inception
6. Show unassigned time (e.g., week) near middle,
consider liberal estimates, add admin tasks/time
7. Complete the schedule
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
High Level Task Chart with Fixed Delivery Date:Order of Completion
Month 1
1 2 3 4
Month 2
1 2 3 4
Month 3
1 2 3 4
Month 4
1 2 3 4
Month 5
1 2 3 4
Milestones (1) Delivery
Begin system testing
Iteration 1
Iteration 2(6)
(4)
(3) Freeze requirements
Risk identification & retirement
(5)
* Indicated the order in which the parts of this table were built
SCMP complete
SQAP complete
SPMP rel. 1 complete
(2)
Prep. for maintenance
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Level Labor Allocation for Fixed Labor Total
Month 1
1 2 3 4
Month 2
1 2 3 4
Month 3
1 2 3 4
Month 4
1 2 3 4
Month 5
1 2 3 4
MilestonesRelease to production
Complete testing
Iteration 1
Iteration 2
Freeze requirements
Risk ID & retire
2 2 2 3 2 2 3
2 2 2 1 1 1
4 4 4 3 3 4
4 4 4 4 4 3 3 4 4 4 4 3 3 4 4 4 4 4
4 4 4 4 4
4 4
4
Given team size:
To be assigned4
Halvacation
Karenvacation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Software Project Management Plan => UPEDU Software Development Plan
IEEE 1058.1-1987 SPMP Table of Contents
1. Introduction 1.1 Project overview 1.2 Project deliverables 1.3 Evolution of the SPMP 1.4 Reference materials 1.5 Definitions and acronyms 2. Project organization 2.1 Process model 2.2 Organizational structure 2.3 Organizational boundaries and interfaces 2.4 Project responsibilities 3. Managerial process 3.1 Managerial objectives & priorities
3.2 Assumptions, dependencies & constraints 3.3 Risk management 3.4 Monitoring & controlling mechanisms (QA approach) 3.5 Staffing plan4. Technical process 4.1 Methods, tools & techniques 4.2 Software documentation 4.3 Project support functions 5. Work packages, schedule & budget 5.1 Work packages 5.2 Dependencies 5.3 Resource requirements 5.4 Budget & resource allocation 5.5 Schedule (phases,milestones)
UPEDU Software Development Plan
BONUS MATERIAL
FOR
PROJECT MEETINGS
1.* Distribute start time, end time, and agenda with approximate times (important items first)
2.*Ensure “strawman” items prepared3. Start on time4. Have someone record action items‡
5. Have someone track time & prompt members6. Get agreement on the agenda and timing7. Watch timing throughout, and end on time
– allow exceptions for important discussion– stop excessive discussion; take off line
8. Keep discussion on the subject 9.** E-mail action items & decision summary.
* in advance of meeting ‡ actions members must perform ** after meeting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Plan and Execute Meetings
Specify Agendas
1. Get agreement on agenda & time allocation
2. Get volunteers to … :… record decisions taken and action items
… watch time and prompt members (see figure tbd)
3. Report progress on project schedule -- 10 mins
4. Discuss strawman artifact(s) -- x mins
5. Discuss risk retirement -- 10 mins
<MORE ITEMS>metrics and process improvement?
n. Review action items -- 5 mins
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.