Project Management Introduction Yuriy V. Silvestrov Ciklum The high-level introduction into a...

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