Date post: | 19-Dec-2015 |
Category: |
Documents |
View: | 219 times |
Download: | 0 times |
Project ManagementIntroduction
Yuriy V. SilvestrovCiklum
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 Manage product
functionality Deals with projects
and features Program Manager
Coordinate interconnected projects
Deals with projects
Project Manager Makes a Project Plan Manage software
development Deals with resources
and achievements Team Leader
Creates the team 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 of one dimension could change up to 3 others
Tim e
Q uality
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
Hard to identify from the very beginning
Project parameters exceed the norm by 100%.
Risk of failure > 50%. Often, the best choice
is not to finish the project, but to escape “just in time”
Kamikaze MissionImpossible
Suicide Ugly
0%
Hap
pine
ss
1
00%
0% Chance of success 100%
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
WBS Task Start Finish Allocated
1. Specifications1.1 User specification1.1.1. User specification text 401.1.2. 201.2 Technical specification2. Design2.1. Database design 242.2. GUI design 162.3. Application design 403 Implementation3.1. Create database 123.2. Persistence layer 403.3. GUI coding3.3.1. Main form 203.3.2. Login form 83.3.3. Information forms 403.3.4. Reports 244. Testing4.1. Testing R1 244.2. Testing R2 244.3. Acceptance testing 165. Release procedure5.1. Release notes 8
Duration, m/h
User specification pics
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 List of the risks
List all the risks you could imagine
Make brainstorming Risks probability
Numerical or enumerate (like low-moderate-high-extreme)
Risk impact Numerical or enumerate
Risks categorization Multiply impact and
probability
# Description
1 1 3 3
2 2 1 2
3 2 2 4
4 3 2 6
5 1 1 1
Proba-bility1..3
Im-pact1..3
Score
1..9Lead Developer to leave the project.NET Remoting is not fast enoughGUI design is too complex for chosen FWInterconnection specs to be changed duringLogging library is not as flex-ible as needed
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