Software Project Management

1
Software Project Management

• Todd Kustra
• Tuesday, June 30, 2009

2
Software Project Experience

• UCAV Control Station - Medium
• project manager. Investigative tool to
  experiment with different control strategies for
  UCAVs
• CAMS - Huge
• designer for new interface. Research
  implementation of new interface style using Image
  Theory
• LOCIS - Large
• module designer. Predicting goal status at end of
  time period using modeling and simulation
• MEOCS Job Order Process- Small
• system designer / project manager

3
Overview

• Introduce software project management
• Managerial Roles and Basic Tenets
• Supplier/Acquirer software development
• Lessons learned

4
Software Project Management

• Ensuring that software is delivered on time and
  on schedule and in accordance with the
  requirements of the organization
• Development is always subject to budget,
  performance, and schedule constraints

5
Software Management Distinctions

• Product is intangible
• user, manager, etc. may not be able to see
  progress
• customer management is more difficult
• Product is uniquely flexible
• watch out for mission creep
• more than one correct answer / solution
• Software development is not standardized
• freedom to change as necessary
• user wants you to program code Now!

6
Managerial Activities

• Proposal writing
• Advertisements in Commerce Business Daily
  299.00
• Personnel selection and evaluation
• Project planning and scheduling
• What are the subgoals and how will you meet them
• Project costing
• How much will it cost in advance
• Project monitoring
• Report writing and presentations

7
Where to Find Projects
8
(No Transcript)
9
Proposals

• Be familiar with what your company has to offer.
• What can you leverage from past projects
• What are your core competencies
• What is in your companys code library
• Apply your strengths to the problem to propose a
  solution

10
Managing your Project

• Staffing
• Planning
• Scheduling
• Costing
• Risk Management

11
Project Staffing

• May not be possible to appoint the ideal people
  to work on a project
• Budget may not allow the use of highly-paid staff
• Staff with appropriate experience may not be
  available
• An organization may wish to develop employee
  skills on a software project
• Shortage of IT workers
• Does your project need Human Factors Engineers?
• If special considerations, use a pro!

12
Choosing Your Staff

• Technically competent
• Knows where to go for help
• Politically sensitive
• Cooperation between departments essential
• Strong problem orientation
• Want to solve any problem, not just their area
• Strong goal orientation
• Focus on results not in 9-5 attitude
• High self-esteem
• Able to acknowledge errors and point out problems

13
Project Planning

• Probably most time consuming managerial activity
• Continuous activity from initial concept through
  to system delivery. Plans must be regulary
  revised as new info becomes available.
• Various different types of plans may be developed
  to support the main software project plan that is
  concerned with schedule and budget.
• Quality plan, validation plan, configuration mgt
  plan, maintenance plan, staff development plan,
  etc.

14
(No Transcript)
15
(No Transcript)
16
Project Plan Structure

• Introduction
• Project organization
• Risk analysis
• Hardware and software resource requirements
• Work breakdown Structure
• Project schedule
• Monitoring and reporting mechanisms

17
Guidelines for Successful Acquisition and
Management of Software-Intensive SystemsVolume
1 -- Version 3.0 May 2000
18
Organize the Activities

• Activities in a project should be organized to
  produce TANGIBLE outputs for management to judge
  progress
• Milestones are the end-point of a process
  activity
• Deliverables are project results delivered to
  customers (mns, ord, etc.)

19
Guidelines for Successful Acquisition and
Management of Software-Intensive SystemsVolume
1 -- Version 3.0 May 2000
20
Project Scheduling

• Split project into tasks and estimate time and
  resources required to complete each task
• Organize tasks concurrently to make optimal use
  of workforce
• Minimize task dependencies to avoid delays caused
  by one task waiting for another to complete
• Dependent on project managers intuition and
  experience

21
Scheduling Problems

• Estimating the difficulty of problems and hence
  the cost of developing a solution is hard
• Productivity is not proportional to the number of
  people working on a task
• Adding people to a late project makes it later
  because of communication overheads
• The unexpected always happens. Always allow for
  contingency in planning

22
Project Costing

• Analogy
• Completed similar projects
• Easier to find analogous efforts at subsystem
  level
• Quality equal to credibility of data
• Expert Opinion
• Cost/Schedule estimated by experts
• Use estimate from multiple sources
• Parametric
• repeatable, facilitating sensitivity and domain
  analysis
• models generate estimates through statistical
  formulas that relate a dependent variable (e.g.,
  cost, schedule, resources) to one or more
  independent variables
• Use multiple models for accuracy

23
(No Transcript)
24
(No Transcript)
25
Risk Management

• Risk management is concerned with identifying
  risks and drawing up plans to minimize their
  effect on the project.
• A risk is a probability that some adverse
  circumstance will occur.
• Project risk affect schedule or resources
• Product risk affect the quality or performance
  of the software being developed
• Business risk affect the org. developing the
  software

26
(No Transcript)
27
Software Risks

• Risk
• Staff Turnover
• Mgt Change
• Requirements Change
• Specification Delays
• Size Underestimate
• Technology Change
• Product Competition

• Description
• Exp. staff leaves the project unfinished
• New management has different priorities
• There will be a larger number of changes to the
  requirements than anticipated
• Specifications of essential interfaces are not
  available on schedule
• Size of the system has been underestimated
• Underlying technology on which the system is
  based is superseded by new technology
• Competitive product is marketed before your
  system is completed.

28
Risk Management Process
29
Risk Management

• Risk Identification
• Identify project, product, and business risks
• Risk Analysis/ Quantification
• Assess the likelihood and consequences of these
  risks
• Risk Planning/ Response Development
• Draw up plans to avoid or minimize effects
• Risk Monitoring/ Response Control
• Monitor the risks throughout the project

30
Guidelines for Successful Acquisition and
Management of Software-Intensive SystemsVolume
1 -- Version 3.0 May 2000
31
Risk Identification/Quantification

• Technology
• People
• Organizational
• Requirements
• Estimation

• Legal
• Regulatory
• Market
• Social

Risk Exposure Prob (risk event) Consequence
of Loss used to prioritize risks
32
Risk Planning

• Consider each risk and develop a strategy to
  manage that risk
• Avoidance strategies
• The probability that the risk will arise is
  reduced
• Minimization strategies
• The impact of the risk on the project or product
  will be reduced
• Contingency plans
• If the risk arises, contingency plans are plans
  to deal with that risk

33
Risk Monitoring

• Assess each identified risk regularly to decide
  whether or not it is becoming less or more
  probable
• Also assess whether the effects of the risk have
  changed
• Each key risk should be discussed at management
  progress meetings

34
Potential Indicators of Problems

• Late delivery of hardware or support software,
  many reported technology problems
• Poor staff morale, poor relationships amongst
  team members, job availability
• Organizational gossip, lack of action by senior
  management
• Many requirements change requests, customer
  complaints
• Failure to meet agreed schedule, failure to clear
  reported defects

35
Laws of Project Management

• No major project is ever installed on time,
  within budget, with the same staff that started
  it. Yours will not be the first.
• Projects progress quickly until they become 90
  complete, then they remain at 90 complete
  forever.
• If project content is allowed to change freely,
  the rate of change will exceed the rate of
  progress.
• A carelessly planned project will take three
  times longer to complete than expected, a planned
  project will take only twice as long.

36
Lessons Learned

• Take action early, dont accept excuses
• Your people are actively trying to hide problems
  and your success depends on finding those
  problems and solving early
• Use the tools at your disposal
• Documentation will save you
• The people who introduce mission (feature) creap
  usually out-rank you
• The user will turn on you - expect it!
• Incorporate visual simulations of unseen processes

37
(No Transcript)
38
(No Transcript)
39
(No Transcript)
40
Software Acquisition Food Chain

• Ultimately the project must satisfy this group
• They set funding priorities
• Writes proposal (Req / Tech pull/ push)
• Personal stake in outcome
• Counselors Finance, Contracting,
• ACQ, Tech Exp, User
• You are here
• Probably one of many projects they manage
• Multidisciplinary team
• May work on more than one project

Government Management ()
Government Project Manager
Contracted Project Manager
Contracted Project Team