Project Management

1
Project Management
2
Project Management
Contents

• ANF DATA introduction
• Project Management Definition Context
• Project Management Activities
• Effort Estimation
• Planning, Scheduling Controlling
• Managing People
• Risk Management
• Some Special Project Types
• Distributed Projects
• Death March Projects

3
Introduction
My Introduction

• Ivan Bradác, ANF DATA KB
• In ANF DATA since 2002
• Most of the time as Project Manager
• Involved also in
• Architecture
• Implementation (Java)
• Requirements Specifications
• Before ANF DATA employed in Sun Microsystems, AIS
  Software
• Masaryk University, Faculty of Science
  (Mathematical Analysis)
• Ivan.Bradac_at_siemens.com

4
PM Definition Context
What is Project Management

• What is a Project?
• A project is a temporary endeavor to create a
  unique product, service, or result.
• Project vs. Operational Work Operations are
  ongoing and repetitive
• What is Project Management?
• Application of knowledge, skills, tools and
  techniques to project activities to meet project
  requirements
• What is special on software Project Management?
• Intangible product
• Processes not standardised
• Uniqueness of software projects

5
PM Definition Context
Project Players (Stakeholders)

• Project Manager Project Team
• Performing Organization
• Owner (Sponsor) person/organization who accepts
  and pays for the project result.
• Customer (User) person(s)/organization who will
  use the project result.
• Other stakeholders (Influencers)
• Individuals and organizations involved in the
  project or affected by the projects outcome
• Stakeholders can have positive or negative
  influence on the project
• Dont forget to identify the players, dont
  forget about the political influences!

6
PM Definition Context
Organizational Influences

• Organizational systems can be project-based or
  non-project based
• Organizational structures
• Functional No Project Managers
• Projectized Project manager Functional
  Manager
• Matrix Project are performed throughout the
  functional lines.
• The organizational structure has an influence on
  the Projects Manager authority

7
PM Definition Context
Functional Organization (Gray boxes represent
staff engaged in project activities.)
8
PM Definition Context
Projectized Organization (Gray boxes represent
staff engaged in project activities.)
9
PM Definition Context
Matrix Organization (Gray boxes represent staff
engaged in project activities)
10
PM Definition Context
Project Lifecycle

• In general, the following phases are always
  present
• Initial Phase
• Intermediate Phase
• Final Phase
• According to SEM

11
PM Definition Context
Project Lifecycle Staffing

12
PM Definition Context
Project Management Activities

• Scope Management (Requirements engineering)
• Time Management (Planning, scheduling,
  controlling)
• Cost Management (Effort estimation, controlling)
• Quality Management
• Human Resource Management
• Risk Management
• Integration Management (communication, putting
  everything together)

13
Integration Management
Integration Management

• Coordination and integration of all project
  management activities and processes in accordance
  with the proper development method (e.g. stdSEM)
• Includes e.g. the following activities
• Scheduling meetings with customers and other
  stakeholders
• Making choices where to concentrate resources in
  the moment
• Anticipating potential issues
• Making trade-offs among competing objectives
• The central project document Project Plan

14
Integration Management
Project Plan

• Project Plan is the fundamental project document
  dedicated to team members and the management.
• It sets out the available resources, work
  breakdown and schedule
• It may reference more detailed documents
  pertaining to specific parts, e.g. Test Plan
• Project Plan consists at least of
• Key project data
• Project organization
• Deliverables (software, documentation, everything
  to be delivered)
• Project volume planning (efforts and costs)
• Work breakdown and schedule
• Risk Analysis
• Monitoring and reporting

15
Integration Management
Project Plan - Continued

• The following parts are either included in the
  Project Plan directly or in a separate document
• QM Plan
• CM Plan
• Test Plan
• Effort Estimation and scheduling are typically
  done outside of the Project Plan (but the PP must
  reference them.
• Keep the Project Plan up to date
• Each team member must know where is the valid
  Project Plan

16
Integration Management
Project Roles

• The typical project roles include
• Project Manager
• Technical Leader/ Architect
• Quality Assurance Manager
• Test Leader
• Testers
• Developers
• Further project roles Requirements Manager,
  Subproject manager, Team Leader, Documentation
  Writer, Configuration Engineer/Manager, ...
• The project organization chart is a hierarchical
  diagram depicting the roles.

17
Effort Estimation
Effort Estimation Dominant part of Cost
Management

• Cost management Planning, estimating,
  budgeting, and controlling costs
• Goal Project should be completed within the
  approved budget
• Project Costs consist of
• Hardware and SW costs
• Travel and training costs
• Effort costs (paying of the SW engineers)
• Cost Estimation ? Effort Estimation
• As effort cost is dominant in SW projects, effort
  estimation is the dominant part of cost
  estimation

18
Effort Estimation
Effort Estimation Known Issues

• Effort Estimation is a black art!
• Industry surveys from organizations such as the
  Standish Group, as well as statistical data ...
  suggest that the average software project is
  likely to be 6-12 months behind schedule and
  50-100 percent over budget.Yourdon, E., Death
  March, Second Edition, Prentice-Hall, 2004.
• What is special about SW effort estimation?
• Intangible product
• Rapidly emerging new technologies
• Insufficient statistical data

19
Effort Estimation
Effort Estimation - Interpretation

• The effort estimation is often disinterpreted as
  the minimum possible time to complete the project
  (see next slide for explanation)

20
Effort Estimation
Effort Estimation - Interpretation

• Explanation of the picture before
• The x-axis is the time (person-hours) necessary
  to complete the project.
• The curve is a probability distribution
• Start (theoretically) the same project P many
  times independently.
• For distinct points xi on the x-axis, set the
  y-value to be the nr. of projects, whose real
  duration was closest to xi
• Create the curve by interpolating ? you get a
  skewed Gaussian curve
• (For math freaks, integral of the curve over R
  equals 1 integral from a to b is the probability
  that the project will take more person-hours than
  a but less person-hours than b)

21
Effort Estimation
Effort Estimation Interpretation

• The result of an effort estimation is a figure,
  which predicts the project duration/necessary
  completion time with some probability
• The best effort estimation is in the middle of
  the skewed Gaussian curve
• The probability that the project will be
  completed earlier is 50
• The probability that the project will be
  completed later is 50
• As there is some minimal time necessary, the
  Gaussian curve does not start at 0.
• As there is no certainty that the project wil be
  finished in a finite time, the Gaussian curve is
  not limited

22
Effort Estimation
Effort Estimation Techniques Overview

• Standard techniques
• Expert judgement
• Algorithmic
• Analogy
• Bottom-up approach
• Some other techniques
• Parkinsons law (Work expands to fill the time
  available)
• Price to win (Estimate to whatever the customer
  has available)

23
Effort Estimation
Effort Estimation Expert Judgement

• Experts on the domain or/and used technology are
  consulted and they provide an estimate based on
  their experience.
• Theory The experts estimates are compared the
  estimation process iterates untill an agreed
  estimation is reached
• Practice the project manager alone makes the
  effort estimation and is responsible for it. At
  least, a review is critically needed!
• Another practice As there is no time for
  iterations of estimation, an average is taken
  from the available estimations.

24
Effort Estimation
Effort Estimation - Algorithmic cost modelling

• Uses a mathematical mode to compute the effort
• Input parameters Unique Project characteristics
  like
• Project size
• Project complexity
• Result is computed.
• Most general form Effort A SizeB M
• A ... Constant for organizational influences
• B ... Magic constant , 1 lt B lt 1.5
• M ... Combines process, product, development
  attributes
• Example COCOMO model
• Problems How to define the Size?
• Lines of codes
• Function points

25
Effort Estimation
Linear X Exponential dependence Size/Effort

26
Effort Estimation
Perfectly Partitionable Task (50 person-months)

27
Effort Estimation
Unpartitionable Task

28
Effort Estimation
Message from previous slides

• The dependence between size and effort is an
  exponential one
• For small projects and partitionable tasks, the
  dependence of effort/size is close to a linear
  one (exponent 1)
• For bigger projects, complex (less partitionable)
  task, the dependence is a exponential one
  (exponent 1.5)
• Persons and months are not interchangable To
  accelerate the work in a factor of two,
  duplicating the number of persons is not
  sufficient.

29
Effort Estimation
Effort Estimation by Analogy

• Compare the system to be developed to completed
  projects, system or components
• Analyse similarities and differences
• Derive the estimate based on the known
  price/effort of the systems used for the
  comparison
• Recommendations
• Combine with other techniques
• Use more on lower level, not suitable for whole
  projects
• Provide an order-of-magnitude assessment

30
Effort Estimation
Effort Estimation Bottom-up Approach

• The not scientific approach but most widely
  used
• Typical steps
• Decompose the work to subpackages
• Assess the subpackages
• Add contingency allowance for subpackages
• Sum the results
• Add contingency allowance for the whole result
• For a set of similar tasks, a base task can be
  identified and thoroughly estimated the other
  tasks are compared to the base task.

31
Effort Estimation
Effort Estimation Bottom-up Approach - Traps

• Bottom-up approach has got its pitfalls
• Dividing the whole work into work packages might
  be more difficult than estimating the single
  packages
• Some tasks are easily forgotten
• Development tools installation, support,
  training
• Code not directly attributable to as
  functionality like logging, system start-up/shut
  down, backup, archiving
• Performance and stress testing
• Meetings, communication
• Technical documentation
• ... And many others

32
Effort Estimation
Effort Estimation Function Point Analysis -
Overview

• Function Point Analysis is a widely adopted and
  used estimation method
• Divide the software into modules from the user
  point of view
• For each module,
• Compute the Unadjusted Function Points
• According to complexity factors, compute the
  Adjusted Function Points
• Summarize the Function Points of the modules
• Transform the Function Points count to the
  expected effort.

33
Effort Estimation
Effort Estimation Function Point Analysis
Unadjusted Function Points

• The number of Unadjusted Function Points of a
  module is derived from
• External Inputs File types, data elements that
  are input as parameters to the module
• External Outputs output parameters of the
  module (as above)
• External Enquiries Nr. of transactions withim
  the module where an input causes an immediate
  output
• Internal Logical Files Records and their
  elements internal within the module
• External Interface Files Records and their
  elements to be used by other modules
• Each factor is assigned a value according to a
  table results are summed.

34
Effort Estimation
Effort Estimation Function Point Analysis
Adjusted Function Points

• Once the Unadjusted Function Points are computed,
  complexity factors are taken into account
• Data Communication
• Distributed data processing
• Performance
• Heavily used configuration
• Transaction rate
• Online data entry
• End user efficiency
• Online update
• Complex processing
• Reusability
• Installation ease
• Operational ease
• Multiple sites
• Facilitate change
• Result ? Adjusted Function Points

35
Effort Estimation
Effort Estimation Tips Tricks

• Well known rule of thumb Estimate the effort
  to the best of your abilities and multiply it by
  two (and add something...)
• Avoid political estimation (political price is
  however acceptable)
• Always introduce a contingency factor
• Contingency of standalone tasks
• Contingency for the whole project
• Acceleration penalty if the project is to be
  accelerated by some factor, the size of the team
  must be increased at least by a square of the
  factor (acc. 2 ?increase team by 4!) but the
  reasonable team size is limited
• The length of the project in months should not
  exceed the average number of the team
• Example 180 months project ? at most 13 people
  working for 14 months

36
Effort Estimation
Effort Estimation Tips Tricks II

• Overestimation is not the solution why?
• Effort is overestimated ? Price is too high ?
  project does not start or the competing company
  starts it
• Bindingly Obvious Rule of Estimation There is
  no method that works
• Paul Coombs, IT Project Estimation a
  Practical Guide to the Costing of Software,
  Cambridge University Press
• ? Combine the techniques

37
Planning, Scheduling Controlling
Overview

• Project planning is an iterative process
• The following activities are done at the
  beginning
• Establish project constraints
• Define milestones and deliverables
• Schedule the work packages
• The following activities are iterated (untill
  project is completed or cancelled)
• Review project progress
• Revise estimates of project parameters
• Assess and renegotiate (if possible) project
  constraints
• Reschedule the project
• Continue with updated schedule

38
Planning, Scheduling Controlling
Scheduling

• Divide the work into subpackages
• (Estimate needed effort)
• Identify activity dependencies
• Allocate people to work packages
• Schedule the work packages
• Identify the critical path the longest sequence
  of dependent tasks
• Identify the critical chain the longest
  sequence of tasks taking the resource
  dependencies into acount
• Introduce project-wide contingency. Two options
• Mutliply each taks by some factor
• Add buffers into the plan
• Typically, bar charts and activity networks are
  used for the scheduling
• Note The following pictures depict just an
  abtract example, the real meaning of tasks is not
  significant.

39
Planning, Scheduling Controlling
Divide the work to subpackages (Identify Tasks)

40
Planning, Scheduling Controlling
Identify Activity Dependencies

41
Planning, Scheduling Controlling
Find the critical path

42
Planning, Scheduling Controlling
Identify Resource Conflicts

43
Planning, Scheduling Controlling
Resolve Resource Conflicts

44
Planning, Scheduling Controlling
Identify Critical Chain

45
Planning, Scheduling Controlling
Planning Controlling Tools

• There is a vast number of PM Tools, but the tools
  of the Microsoft world prevail ...
• Excel (or the like) in pratice, the most used
  tool
• MS Project (2003)
• Desktop application, part of MS Office suite
• Mostly used features include Gantt charts,
  resource sheets, network activity diagrams
• MS Project Server (also reffered to as EPM
  Enterprise Project Management)
• Web solution
• The plan can be accessed from MS Project 2003
  (advanced work, mostly for the PM) or via web
  (simpler interface, for team members)
• Can be customized and extended for the companys
  needs

46
Managing People
Managing People General

• People working in a software organization are its
  greatest assets!
• Treat all people in a project in a comparable way
• Take in account different technical and
  communication skills and experience
• Let all people contribute and listen to them
• Inform honestly about project status
• Communication Support proper communication
  channels
• Most important activities include
• Selecting the staff
• Team building and development
• Motivating people

47
Managing People
Selecting the Staff

• Information about people to be appointed to the
  project comes mostly from the following sources
• Information provided by the candidates (CVs)
  provides the first hints whether a candidate is
  likely to be suitable (Education, practise,
  certificates, ...)
• Interviews provides more information about the
  communication and social skills - but avoid rapid
  subjective judgements
• Recommendations for people who have worked with
  the people very effective if you know and trust
  the people making the recommendations
• Beware Social communication skills are as
  important as the technical ones - a conflicting
  person can destroy the project regardless of
  their technical skills!

48
Managing People
Selecting the Staff - Limitations

• In an ideal world, the project manager has the
  option to select the complete staff for the
  project in the real world, this is mostly not
  the case
• The best experts are typically not available as
  they work on other projects or they are too
  expensive
• Pressures to employ less experienced, less
  talented or even problematic people in the
  project may appear
• ? You cant mostly involve exactly the people you
  want but insist on rejecting unacceptable persons

49
Managing People
Team Building

• Stages of team development include
• Forming Team members define goals, roles, and
  direction of the team. Kick-off meeting!
• Storming The team sets rules and
  decision-making processes, often renegotiates
  (argues) over team roles and responsibilities
• Norming Procedures, standards, and criteria are
  agreed on
• Performing The team begins to function as a
  system
• Adjourning Termination of tasks, disengagement
  of relationships

50
Managing People
Motivating people Hierarchy of Needs

• Maslows human needs hierarchy

51
Managing People
Motivating People Hertzbergs two Factor Theory

• The motivation factors can be divided into two
  groups
• Hygiene Factors must be present so that people
  wont become dissatisfied
• Salary, regular bonuses
• Working conditions, working hours
• Inter-personal relationships, style of leadership
• Motivating Factors Encourage people to do their
  best
• Achievement
• Responsibility
• Recognition
• Challenge

52
Managing People
Motivating People Some Hints

• Money is a great motivator but keep in mind that
• It is just a hygienic factor (and dont forget
  about the taxes)
• Size of a bonus does not have a linear
  relationship with the productivity of people if
  the people e.g. already work big overtimes, the
  laws of physics prevent further increasing the
  work hours
• Typically, programmers love their work and dont
  need Draconian measures to keep them working
• The necessity to keep team members informed
  cannot be overemphasized
• Non-financial rewards are possible including
  common beer evening, extended vacation, cups with
  the projects logo, etc ...

53
Risk Management
Risk Management Overview

• Risk Management is a part of Project Planning
• Risk Management is the process of measuring, or
  assessing risk and then developing strategies to
  manage the risk
• Risk Management process consists of the following
  steps
• Identification
• Evaluation
• Priorization
• Undertaking preventive and remedial measures
• Following up the impact of measures
• Risk Analysis is to be done periodically
  throughout the whole project lifetime

54
Risk Management
Risk Management - Identification

• Risk types
• Technology risks unknown new technologie used,
  obsolete technologies used, ...
• People risks people leaving the team, conflicts
  within the team, not enough trained people, ...
• Organizational risks movements, politics in the
  organization
• Tools risks people not trained or willing to
  use some tools, buggy tools, not performant
  tools, ...
• Requirements risks Requirements unclear,
  requirements ever changing, ...
• Estimation risks typically understimation
• To ease the risks identification, checklists are
  available in SEM

55
Risk Management
Risk Management - Evaluation

• For each risk
• Create a short description
• List all possible consequences for the project
• Estimate the probability of its occurrence
• Estimate effort (cost) that would be necessary to
  eliminate the consequences
• Calculate the risk potential
• Risk probability x effort (cost) for counter
  measure
• In pratice, it is difficult to set probabilities
  for occurence and effort for elimination of
  consequences however, one always has at least
  some sense of magnitude of these variables

56
Risk Management
Risk Management Priorization, Measures Follow
up

• Based on the risk evaluation, divide the risks in
  classes or simply sort the risks according to the
  risk potential
• Select approximatelly 10 risks to be followed up
• For each of the selected risks
• Determine preventive and remedial measures
• For each measure
• Create a short description
• Assign responsible person
• Estimate effort and set a deadline
• For each risk that came true and pertinent
  measures have been applied
• Sum up the effects of each measure
• Evaluate the effort spent so far
• Assess the effects
• Re-evaluate the corresponding risks

57
Risk Management
Risk Management Summary

• Risks live increase, decrease, spring into
  existence, die, rise again
• Only a small set of risks can be processed, but
  this must be done in a methodological way
• If probability is very high (gt 85) ? no more
  risk, a normal project event
• Process not only negative risks but also the
  positive ones ? so called Risk-Chance
  Management
• Remember Risk Management is Project Management
  for Adults (Tom DeMarco)

58
Distributed Projects
Distributed Projects at a Glance (distribution of
a real SIEMENS PSE project)

59
Distributed Projects
Distributed Projects Overview

• Projects, which span multiple organizations
  and/or multiple physical locations
• Distribute project types range from
• Strictly separated components being integrated on
  a central site to
• Almost integral team just geographically divided
• Why are distributed projects done?
• Shortage of engineering skills
• Intense competition on the market ? Using
  low-cost countries
• Example - Siemens PSE
• about 6,200 employees(incl. foreign
  subsidiaries)
• 20 locationsin 7 European countries, Turkey,
  China and USA

60
Distributed Projects
Distributed Project Come at a Cost

• Communication issues
• Lack of unplanned contact
• Knowing who to contact about what
• Difficulty of initiating contact
• Ability to communicate effectivelly
• Lack of trust, or willingness to communicate
  openly
• Leadership struggles
• Competition between sites
• Cultural incompatibility
• Technical issues (common storage space,
  configuration management)
• Time zone differences
• Travelling costs

61
Distributed Projects
Distributed Projects Best Pratices
Recommendations

• The PM
• Must be equally respected on all sites
• Must not prefer one location to another
• Must have good (English) language skills being
  able to speak to team members in their native
  language is of a big advantage.
• Shoud travel to all locations regularly know
  each team member personally
• State of the art in software development
  (processes, CM and bug tracking tools, automated
  nightly build, ..) is a must dont even try
  without it!
• Regular teleconferences of steering comitee

62
Distributed Projects
Distributed Projects Best Pratices
Recommendations - Continued

• Technical teleconferences on demand
• Use NetMeeting or similar tool to share
  documents, pictures, whiteboard, source code
• Each location must have a perfomant development
  infrastrucure
• Kick-off and experience workshops at important
  milestones ? The whole team should meet time to
  time

63
Death March Projects
Death March Projects Overview

• Project, whose parameters exceed the norm by at
  least 50
• The schedule has been compressed to less than
  half the amount estimated
• The staff has been reduced to less than half the
  number that would normaly be assigned
• The budget and resources have been cut in half
• Another way to characterize A project whose risk
  assessment determines that the likelihood of
  failure is greater than 50

64
Death March Projects
Death March Projects are the Norm

• Remember?
• Industry surveys from organizations such as
  the Standish Group, as well as statistical data
  ... suggest that the average software project
  is likely to be 6-12 months behind schedule and
  50-100 percent over budget.Yourdon, E., Death
  March, Second Edition, Prentice-Hall, 2004.
• Death March Projects are the norm ?
• This is the project you will be working on!

65
Death March Projects
Why do Death March Projects Happen

• Politics
• Management struggles, getting an important
  contract
• Intense competition on the market
• Sheer underestimation
• Naive optimism
• We can do it over the night!
• Real programmers dont need sleep
• Unexpected crisis
• People unexpectedly leaving the team,
  hardware/software vendor just went bankrupt, ...
  Reasons that might not have be taken into account
  in the Risk Analysis

66
Death March Projects
Death March Projects How to Survive

• Keep your mental health. Dont get involved too
  deep. After all, its you and your family which
  is really important.
• Understand who are the stakeholders
• Concentrate on negotiations (see next slide)
• Priorizatition (Triage)
• Among the basic project dimensions
  (functionality, deadline, quality, budget), it
  is mostly the functionality which can be
  renegotiated ? be prepared to cut the
  functionality to be delivered

67
Death March Projects
Death March Projects Negotiation Games

• Doubling and add some use whatever estimation
  technique, double the result and add something
• Reverse doubling Reaction on the strategy above
  manager will automatically divide the
  estimation by 2.
• Spanish inquisition You are asked unaware for
  an instance estimate on a high management
  meeting
• Gotcha Reveal the real state of project right
  before the deadline
• Chinese Water Torture Bring the bad news in
  small pieces
• Hidden variables of quality Any project can be
  delivered in a zero time unless it does not have
  to work and be maintainable.

68
Project Management
Links Literature

• Project Management Institute
• Software Engineering Institute
• SW Project Management Resources - Columbia
  University
• COCOMO Cost Model
• A Guide to the Project Management Body of
  Knowledge, Project Management Institute
• Software Engineering, Ian Sommerville
• Agile Software Development, Alistair Cockburn
• IT Project Estimation, Paul Coombs
• The Mythical Man-Month, Frederick P. Brooks, Jr.
• Death March, Second Edition, Edward Yourdon

69
Project Management

• Thank you 4 your attention