Project Management

Introduction

Yuriy V. Silvestrov
Ciklum

The high-level introduction into a

Project Management world
 Introduction

 Describe the subject to be treated

 Define the learning objective
 Determine what previous experience the
participants have
 Take their experience into account when
teaching
 Agenda

 Project, Program, Product

 Software Development Processes
 Starting the project
 Finishing/Escaping the project
 Project Management in practice
 Recommended reading
 Overview

 Give an overview of the contents to be covered

 Mention the connections between the various
topics and their importance
 Establish a practical context for the audience
 Program, Project and Product

 Program includes a lot of inter-connected

Projects
 Product includes a lot of contiguous Projects
 Managing of Program, Product and Project
involves different skills and techniques
 Manager Positions

 Product Manager  Project Manager

 Manage product  Makes a Project Plan
functionality  Manage software
 Deals with projects development
and features  Deals with resources
 Program Manager and achievements
 Coordinate  Team Leader
interconnected projects  Creates the team
 Deals with projects  Lead the team to
success
 Deals with people
 Program

 Input:
 Management vision
 Strategic plan
 Business policy
 Output
 Benefits
 Duration
 Ongoing
 Product

 Input
 Marketing Vision
 Output
 Market Share
 Duration
 Life cycle
 Project

 A project is a finite endeavor - having specific

start and completion dates - undertaken to
create a unique product or service which brings
about beneficial change or added value.
 Input
 Specification - more or less formal
 Output
 Delivery
 Duration
 Definite
 Project Characteristics

 4 Main Characteristics
 Scope
 Time
 Cost
 Quality
 5th Additional
 Risk
 “3 of 4” Rule. Project Triangle

 In ideal situation, you

could choose not
more then 3 of 4
characteristics
 In practice, changing Q u a lit y

of one dimension T im e

could change up to 3
others
Software Development Processes

 Waterfall
 Iterative
 "Google" way
 Open-Source
 Waterfall

 The oldest and the most well-defined process

kind.
 Pros
 Could be planned with very high details
 Contras
 Hard to implement the plans
 Market needs could change faster then the project
itself
 Variations
 Time
 Cost
 Iterative

 Concrete processes:
 Agile
 XP
 Pros
 Fast reaction to changes
 Contras
 Less formal and documented
 Stakeholders could feel themselves “unsafe”
 Variations
 Scope
 “Google” way

 Permanent beta
 Variations
 Quality
 Open Source

 Kind of “Bazaar” structure

 Except from biggest projects getting donations,
programmers implements the features they'd
like to, not the features are needed
 Starting the Project

 Identify Goals
 Project Documentation
 Depends on methodology chosen
Before Start – Goals Identification

 Having a tool to measure progress

 Clean and positive vision
 Having a "compass"
 Tool for finding right direction
 Accessibility
 Ecological compatibility
 PM
 Team
 Company
 Stakeholders
Starting a Project - Documentation

 Depends on process kind chosen

 Most common documentation includes
 Specification of different kinds
 Internal documentation (analysis/design etc.)
 QA documentation
 Test plan
 Test result
 Release documentation
 Release notes
 User documentation
 User guide
 Help
 Finishing the Project

 Delivery
 Planned
 Running application
 Documentation
 User documentation
 Process documentation
 Testing documentation
 After delivery activities
 Project finishing analysis
 Positives and negatives
 Project planning errors
 Achievements and reusable components
 Escaping the Project

 “Mission Impossible”
projects Kamikaze Mission

 100%
 Hard to identify from Impossible

0%  Happiness
the very beginning
Suicide Ugly
 Project parameters
exceed the norm by
100%.
0% Chance of success  100%
 Risk of failure > 50%.
 Often, the best choice
is not to finish the
project, but to escape
“just in time”
 How to deal with “MI” project

 Key players: stakeholders, shareholders, loser

users
 Cutting off the project functionality or splitting
the project up
 Finding a compromise between stakeholders
 Commitment level – chicken or pigs
 Project Management

 Time Management
 Risk Management
 Quality Management
 Resource Management
 Team Management
 ...
 Time Management

 Project Plan
 Project stages
 Milestones
 Work Breakdown Structure (WBS)
 Gantt chart
 Resources leveling
 Critical path
 Project Stages

 Project should be divided to several stages

 Common stages:
 Initiation
 Planning and design
 Executing
 Monitoring and Controlling
 Closing
 Milestones

 Internal
 Track and measure project progress
 External
 Track external events that are vital for project
 Specification releases
 3rd party libraries release
 Integration of all kinds
 Deadline
 Time limit the project to be finished before
 Should not exists in ideal world
 But really is one of the project characterics
 WBS

 Work-breakdown structure
 Breaks a project into smaller, more manageable
components, organized in a tree-like structure
 WBS design principles
 The 100% Rule
 Planned outcomes, not planned actions
 Mutually exclusive elements
 OK level of details
 8/80 Rule
 Terminal elements should be not less then 8 hrs and not more then
80 hrs
 Depend on project needs this could be changed
 WBS Example

W BS Task Duration, Start Finish Allocated

m/h
1. Specifications
1.1 User specification
1.1.1. User specification text 40
1.1.2. User specification pics 20
1.2 Technical specification
2. Design
2.1. Database design 24
2.2. GUI design 16
2.3. Application design 40
3 Implementation
3.1. Create database 12
3.2. Persistence layer 40
3.3. GUI coding
3.3.1. Main form 20
3.3.2. Login form 8
3.3.3. Information forms 40
3.3.4. Reports 24
4. Testing
4.1. Testing R1 24
4.2. Testing R2 24
4.3. Acceptance testing 16
5. Release procedure
5.1. Release notes 8
 Gantt chart

 Popular type of bar chart that illustrates a

project schedule
 Gantt chart elements are WBS terminal
elements, thus Gantt chart should be created
after WBS
 Then Gantt chart could be used for resource
leveling and project tracking
Gantt example
 Resource leveling

 Procedure to manage conflicts when resources

are overloading
 Use automatic resource leveling, if available
 Otherwise level resources by starting date
 Do not use linking tasks for resource leveling
 Critical path

 Is the sequence of project network activities

which add up to the longest overall duration.
 Determines the shortest time possible to complete the
project.
 Any delay of an activity on the critical path directly
impacts the planned project completion date (i.e.
there is no float on the critical path).
 Remove all risky tasks from CP
 Risk Management

 Risks Identification
 Managing identified risks
 Project plan to include risks
Risk Management - Identification

 Risk Matrix # Description Proba- Im- Scor

bility pact e
1..3 1..3 1..9
 List of the risks 1 Lead Developer to leave the 1 3 3
project
 List all the risks you 2 .NET Remoting is not fast 2 1 2
could imagine enough
3 GUI design is too complex 2 2 4
 Make brainstorming for chosen FW
4 Interconnection specs to be 3 2 6
 Risks probability changed during
5 Logging library is not as flex- 1 1 1
 Numerical or enumerate ible as needed
(like low-moderate-high-
extreme)
 Risk impact
 Numerical or enumerate
 Risks categorization
 Multiply impact and
probability
 Risk Management – taking care

 Risk prevention (avoidance)

 To modify project plan in such a way that risk is
eliminated
 Risk reduction (reduce the risk impact)
 To plan activities to be taken if risk is materialized
 Risk retention (accepting the loss when occurs)
 Kind of self-insurance
 for risks with low probability and low impact
 Cancellation of the project
 for risks with low probability and high impact
 Risk transfer (another party to accept the risk)
 Insurance
 Outsourcing
Risk Management in Project Plan

 The main idea is to modify Project Plan to

include identified risks
 Risks probability and impact differs between project
stages
 Ideal task/project finish date
 is the date to finish task or project if no risks are
materialized. The probability of this situation is 0%.
 Risks are moving finish date up in time
 The move could be statistically calculated
 Average/worst finish date
 Quality Management

 Quality Improvement
 Quality Control
 Quality Assurance
 Quality Standards
 Coding Standards
 Issue tracking
 Resource Management

 Human Resources
 Team Management

 Roles
 Management and Leadership
 Organization structure
 Creating successful team
 Team Management - Roles

 Differ by the methodology chosen

 Most common roles are
 Project Manager
 Developer
 Business Analyst
 Quality Assurance
 Technical Writer
 Management and Leadership

 Manager and leader could be different persons

 Example with fire:
 Manager to manage chain of people transmitting
water
 Leader to take a water bucket crying “Follow me”
 Formal and informal leader
 Do not try to overrule informal leaders. Better to
collaborate with.
 Organization Structure

 Centralization
 Centralized
 Decentralized
 Flatness
 Flat
 Hierarchical
 Orientation
 Vertical
 Horizontal
 Matrix structure - group by
 function
 project
 Successful Teams

 Successful Projects are made by Successful

Teams.
 Find the right people and put them to the right
places
 You can't create the team, but you could
eliminate obstacles and hope the team to be
successful
 Summary

 Summarize the material covered

 Refer to the practical context again
 Clarify any remaining questions
 Ask for audience feedback about the training
seminar
 Further reading

 Classical
 Фредерик П.Брукс. Мифический человеко-месяц
или как создаются программные системы
 Том ДеМарко и Тимоти Листер. Человеческий
фактор: успешные проекты и команды
 Том ДеМарко. Вальсируя с Медведями.
Управление рисками в проектах по разработке
программного обеспечения
 Project Management
 Project Management Step by Step: How to Plan and
Manage a Highly Successful Project by Richard
Newton