1 / 48 ©jozef de man 2008-2009 managing a small software project a quick guide ed 2 managing a...

Managing a small Software ProjectA quick Guide ed 2

1 / 48©Jozef De Man 2008-2009

Managing a small Software ProjectA quick Guide

Prof. Dr. ir J. De Man


2 / 48©Jozef De Man 2008-2009

Introduction

This is a quick guide to project management for small sofware projects.It is a light-weight interpretation of general project management practices tailored to the specific needs of software projects.This is an adaptation of the Capability Maturity Model Integration (CMMI) for Development edition 1.2.http://www.sei.cmu.edu/cmmi/

Software development is not only a technical activity requiring technical skills but also a business activity requiring (project) management skills


3 / 48©Jozef De Man 2008-2009

Content

A few words about: Process Model – CMMI Development Model – Agile

What is a project?

Process Areas Measurements Requirements Management Project Planning / Monitoring and Control Quality Assurance Configuration Management Risk Management Process Improvement


4 / 48©Jozef De Man 2008-2009

CMMI Staged Representation5 Maturity Levels

22Managed

Projects haveDisciplined

Process

33Defined

OrganizationalStandardProcess

44QuantitativelyManaged

Measured,Predictable

Process

55Optimizing

ContinuouslyImprovingProcess

A Maturity Level is assigned toan organization and is anevolutionary plateau in process maturity

Practices at a lower level must beestablished to enable practices at

a higher level to be efficient and effectivehttp://www.sei.cmu.edu/cmmi

11Initial

Ad hocChaotic


5 / 48©Jozef De Man 2008-2009

CMMIProcess Areas by Maturity Level (Staged)

Requirements Management*Project Planning*Project Monitoring and Control*Supplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality Assurance*Configuration Management*

2 Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process Focus*Organizational Process Definition + IPPDOrganizational TrainingIntegrated Project Management + IPPDRisk Management*Decision Analysis and Resolution

3

Organizational Process PerformanceQuantitative Project Management

4 Organizational Innovation and DeploymentCausal Analysis and Resolution

5

Process Areas at lower levelmust be addressed beforeProcess Areas at higher levels

IPPD = Integrated Product and Process Development

*Process Areas addressed in this guide


6 / 48©Jozef De Man 2008-2009

CMMIGeneric Goals and Practices

Generic Practices to be applied to EACH process area GP2.1 Establish an organizational policy GP2.2 Plan the process GP2.3 Provide resources GP2.4 Assign Responsibility GP2.5 Train people GP2.6 Manage Configurations GP2.7 Identify and involve relevant stakeholders GP2.8 Monitor and control the process GP2.9 Objectively evaluate adherence GP2.10 Review status with higher level management

Stakeholder = individual or group affected by or accountable for the outcome of an activity

Policy = guiding principle, typically established by higher management


7 / 48©Jozef De Man 2008-2009

http://agilemanifesto.org/

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent BeckMike Beedle

Arie van BennekumAlistair Cockburn

Ward CunninghamMartin Fowler

James GrenningJim HighsmithAndrew HuntRon Jeffries

Jon KernBrian Marick

Robert C. MartinSteve Mellor

Ken SchwaberJeff SutherlandDave Thomas

We still value the items on the right


8 / 48©Jozef De Man 2008-2009

What is a Project?

Delivers one or more products/services to a customer

Has a definite beginning and end

Involves interacting resources (people, tools, material)

Typically operates according to a plan, specifying The product(s) to be delivered The work to be done The required resources and funds The schedule for doing the work


9 / 48©Jozef De Man 2008-2009

ProjectBasic Decision Gates

StartGate

CommitGate

EndGate

Planning Execution

Develop Business CaseVision Statement

Define RequirementsManage Risks

Develop initial planCommit Adequate Resources

Is there a business case with acceptable risk to

continue with the project?

Is the product ready for delivery to the customer?

Initiation Closure


10 / 48©Jozef De Man 2008-2009

Four essentialDimensions

Scope

Cost

Schedule

Quality

FunctionalRequirements

Non-FunctionalRequirements • What is the order of priority?

• What are the targets?• Which dimensions are fixed?• Which dimensions can be renegotiated

during the project?


11 / 48©Jozef De Man 2008-2009

Measurement and AnalysisGlobal Performance

Priorities along schedule, cost, scope and quality are based on business objectives defined by higher management

Metrics must be defined to quantitatively express performance along these four dimensions (key performance indicators), e.g.

Schedule overrun = actual duration – planned duration

Margins must be defined within which the project must be managed, e.g.

Schedule adherence < 1 week

Estimates of the key performance indicators (KPIs) are maintained during the project and higher management must be asked to intervene if the project is estimated to go beyond one of the margins


12 / 48©Jozef De Man 2008-2009

MeasurementsQuality

Also non-functional requirements of the product must be documented and expressed quantitatively

Examples: Coverage of test cases in terms of features and code Number of test case executed and passed Number of known, unresolved defects in the product

Performance against quality targets is an aspects determining readiness for delivery of the product to the customer


13 / 48©Jozef De Man 2008-2009

MeasurementsKPI Examples

Schedule Overrun Actual duration – Planned duration

Budget Overrun Actual effort spent – Original budgeted effort

Feature Churn # features added/deleted during execution

Quality # test cases passed successfully / # test cases planned


14 / 48©Jozef De Man 2008-2009

MeasurementPractical Guide

Derive metrics from goals Identify goals of the project Identify simple metrics to quantify the goals Define mechanisms to collect/report measurements Do it

Remember Metrics must be useful Keep it simple


15 / 48©Jozef De Man 2008-2009

RequirementsTypes

Functional requirements Describe the functionality of the system Typically expressed in terms of nouns and verbs

Non-functional requirements Describe properties of the system and its actions Typically expressed in terms of adjectives Include the “-ilities” of the system

Constraints Are externally imposed and cannot be negotiated, e.g. legal

obligations


16 / 48©Jozef De Man 2008-2009

RequirementsActivities

Elicitation - identify sources of requirements and obtain requirements

Documentation - write down the requirements in a way that is understandable for all stakeholders

Negotiation - reconcile conflicting interests of stakeholders

Classification - identify (hierarchical) relationships, taxonomy, traceability, priority,…

Analysis - understand the requirements, identify possible conflicts, overlaps, ambiguities

Allocation - to components of the product/solution

Modeling - abstract representation supporting formal analysis


17 / 48©Jozef De Man 2008-2009

Requirements DocumentationHierarchy/Granularity

Vision - One page general description of the objectives and scope to provide a common direction to the entire team

Feature/Requirements List - Index with one sentence for each requirement to serve as a basis for classification

Requirements Specification - detailed specification of each requirement (e.g. detailed specification of protocols)


18 / 48©Jozef De Man 2008-2009

Requirements DocumentationFeatures

The definition of the product must be broken down in “features”

Features are more or less independent characteristics of the product

It must be possible to implement features incrementally To develop value as quickly as possible To enable tracking of progress To enable renegotiation of scope during project


19 / 48©Jozef De Man 2008-2009

Requirements DocumentationFeature List

Features are documented in a Feature List which is maintained during the course of the project

The initial Feature List documents the “target” for scope

A Feature List involves for each feature Name Description Cost Estimate (rough estimate - high,medium,low) Customer Value Estimate (need-to-have, nice-to-have) Risk level (level of uncertainty of feasibility/cost) Dependencies on other features Project increment/iteration


20 / 48©Jozef De Man 2008-2009

Requirements ManagementTraceability

Establish a simple mechanism to maintain traceability from requirement to implementation

Examples Features > Code Modules Features > Test Cases Bug reports > affected items

The goal is to answer questions like What is the test coverage of a feature? Is a feature completely implemented? Have all corrections associated with a bug report been

implemented?


21 / 48©Jozef De Man 2008-2009

Project PlanningAssign Responsibility

Project Manager

But also Requirements/Feature Manager Development Manager, Test Manager Build / Configuration Manager Quality Manager Process Improvement Manager Risk Manager Measurements Manager

NotesSeveral roles can be performed by one personRoles must be assigned early in the planning phase


22 / 48©Jozef De Man 2008-2009

Project PlanningIterations

The execution of a project happens in iterations/increments

Essential characteristics of each iteration Period (duration) Available Resources Features to be implemented

StartGate

CommitGate

EndGate

Planning Execution

Iteration1

Iteration3

Iteration2

……….


23 / 48©Jozef De Man 2008-2009

Project PlanningIdentify Activities / Work Products

Consider mainstream Requirements, feature lists, design artefacts, code modules,

test cases, …

But also supporting functions Build / Configuration Management of code and documents Risk Management Planning and Monitoring Requirements Management Measurement and Analysis Quality Assurance of Product and Process Process Improvement / Definition Training


24 / 48©Jozef De Man 2008-2009

Project PlanningIdentify attributes of activities / work productsA few examples:

Reviews Duration Number of participants Frequency “Size” – number of slides in presentation

SW Build Effort Duration Frequency Required resources


25 / 48©Jozef De Man 2008-2009

Project PlanningEstimate attribute values and cost

For example for reviews Duration 1 hour Number of participants 5 Frequency monthly Number of slides in presentation 20

Derive estimated of required effort Effort spent in meeting + preparation

Notes: Estimates tend to be more accurate if “objective” attributes

are identified first and required effort is derived based on attribute values

Accuracy of initial estimates may be low


26 / 48©Jozef De Man 2008-2009

Project PlanningScheduling

Consider for the first increment Available effort budget Estimated period Effort for supporting functions

And determine the features to be implemented in the first iteration based on

Customer value, estimated cost, risk

Negotiate and obtain commitment on resources based on Project Requirements Available skills Personal interest


27 / 48©Jozef De Man 2008-2009

Project Monitoring and ControlMonitoring

Monitoring the project involves Keeping people aware of their commitments Verifying actual performance against plan Adapting the plan as required Improving the way of working based on experience gained in

the project (and previous projects)

To enable this, it is essential that mechanism are established to monitor actual performance versus the original plan


28 / 48©Jozef De Man 2008-2009

Project Monitoring and ControlCorrective Actions

Monitor performance at the level of the attribute values

E.g. for project reviews Actual duration, frequency, number of participants, size

If actual performance deviates from the plan it is now possible to take corrective action at the process level and adjust either the plan or actual performance at the attribute level

You can propose changes in the attribute values and get accurate estimates for the impact on performance assuming the other values will not change, e.g.

Change frequency, content, duration, # of participants


29 / 48©Jozef De Man 2008-2009

Project Monitoring and ControlProject Review/Meetings Types

Decision Reviews at Decision Gates to decide Go / No Go for project at Commit Gate Delivery of product at End Gate

Iteration Reviews between iterations to accept end of previous iteration and decide to start the next iteration

Kick-off meetings with the entire team at the beginning of the project or an iteration

Periodic Meetings Team meetings Progress reviews at project level Reviews with higher Management / External Stakeholders


30 / 48©Jozef De Man 2008-2009

Project Monitoring and Control – Decision GatesCommit Gate Checklist - sample

Feature List available? Risk repository available, risks analyzed and risk handling

actions planned? Targets established for features, quality, schedule and

budget? Are the “boundary conditions” for the project team

established? Initial Plan available

Responsibilities Activities / Work Products, their attributes and estimates Schedule Allocation of resources to activities / work products committed

Are the risks acceptable to proceed?


31 / 48©Jozef De Man 2008-2009

Project Monitoring and Control - Decision GatesEnd Gate Checklist - sample

Are all committed features implemented? Does the product meet its quality targets? Is the business case still valid? Are all legal and regulatory issues resolved? Are plans and resources in place to support the product? Are the risks acceptable to deliver the product to the

customer?


32 / 48©Jozef De Man 2008-2009

Project Monitoring and ControlIteration Reviews

Goals Verification committed targets have been met Risk (re-)assessment Lessons-learned: what did we do well?

What can be improved? Keep focus

At iteration reviews Process changes can be introduced The Feature List can be updated The project plan is revised


33 / 48©Jozef De Man 2008-2009

Project Monitoring and ControlProject/Iteration Kick-Off

Goals Re-enforce a common vision Higher management to demonstrate its commitment to the

project

Entire project team and higher management are invited

Project Management presents Vision Features Quality targets Schedule The process to be followed


34 / 48©Jozef De Man 2008-2009

Project Monitoring and ControlProject/Team Meetings

Goals Review progress Identify issues and take action to resolve them Decide on escalation of issues if required

Format Weekly meetings with project team to review overall

progress Daily Team meetings (Scrum meetings) for fast direct

communication and avoid delays associated with email


35 / 48©Jozef De Man 2008-2009

Project Monitoring and ControlManagement Reviews

Goal Provide higher management visibility on project progress Obtain commitment for actions that are beyond the

responsibility of the project team

Typical content Key features Latest estimate of project in terms of schedule, cost, scope

and quality Main achievements Issues that require higher management attention Next steps


36 / 48©Jozef De Man 2008-2009

Project Monitoring and ControlData Management - Establish a Project Portal

It is important that all members of the project have instant access to the latest edition of data relevant to the project

Feature List Risk List Action Points Planning / tracking Meeting minutes …

A “Project Portal” must therefore be established to manage project data and support efficient communication

The portal must also refer to the Process Assets Library of the project


37 / 48©Jozef De Man 2008-2009

Quality AssuranceProduct and Process

Product Quality Assurance Actions to ensure and verify that the quality requirements of

the product are satisfied These actions are typically performed as part of the

“mainstream” project: document reviews, testing activities at various levels.

Process Quality Assurance Actions to ensure and verify objectively that actions for

product quality assurance are executed as planned and effective

These actions are typically performed by a separate Quality function to ensure objectivity


38 / 48©Jozef De Man 2008-2009

Quality AssuranceQuality Manager Role

Ensure that the Project Manager not only considers schedule and content but also quality

Monitors whether the process (agreements made in the project) is followed and analyzes deviations

Coaches project members in the process

Considers adjustments of the process if required

Report quality issues to senior management


39 / 48©Jozef De Man 2008-2009

Configuration ManagementOverview

Configuration Management involves Identification of items to be placed under CM Establishing a repository for items (code, test cases,

requirements, technical and project documents,..) Ensuring the most current version of each item is available Managing changes to items in an efficient and controlled

fashion Audit integrity of the configurations, e.g. have all approved

changes been implemented?


40 / 48©Jozef De Man 2008-2009

Risk ManagementUncertainty

A project faces many uncertainties Feasibility of implementation Volatility of the requirements Accuracy of effort estimates Availability of resources Dependencies on external partners ….

A risk is a potential problem that has not yet turned into an actual problem

Risk Management deals with risks and not with problems


41 / 48©Jozef De Man 2008-2009

Risk ManagementPurpose

Before Commit Gate Identify risks Plan risk handling actions Plan for risk reduction during the execution of the project

E.g. implement high-risk features first Establish adequate visibility on risk as input for decision

During Execution Monitor risks and re-assess periodically Monitor and replan mitigation actions as required Take corrective actions if risks materialize as problems


42 / 48©Jozef De Man 2008-2009

Risk ManagementRisk Register

Risks and related attributes are maintained in a risk register

Risk Attributes Likelihood of occurrence Number of occurrences (optional) Impact/cost of occurrence Cost/Impact of actions

Risk ranking is used to select type of action


43 / 48©Jozef De Man 2008-2009

Risk ManagementRisk Statement

A well-written risk statement facilitates risk management

It typically contains two components: A condition An undesirable effect cause by that condition

To be a risk, the condition must not yet be satisfied, otherwise it is a problem


44 / 48©Jozef De Man 2008-2009

Risk ManagementActions

Avoidance Take action to reduce the likelihood that the risk materializes

Mitigation Take action to reduce the negative impact of a risk in case it

materializes

Nothing Accept the risk


45 / 48©Jozef De Man 2008-2009

Process DefinitionEstablish a “Process Assets Library”

A “Process Assets Library” is the all information that enable project members to perform their tasks more efficiently and effectively

In includes Templates for documents (e.g. the risk list) Templates for meeting presentations, reports Standards (e.g. rules for configuration management, naming

conventions, coding rules,…) Procedures (e.g. how build the product) User guides for tools Recommended attributes of activities (frequency of reviews,

duration of reviews,…) …


46 / 48©Jozef De Man 2008-2009

Process Improvement

You must continuously improve your way of working

This must happen in a controlled fashion Project members must follow agreed rules Everybody can submit proposals for improvements Proposals are evaluated, approved and implemented quickly New rules must only be followed after agreement

Recommendations Take time to discuss and agree improvements at project

meetings Communicate changes (e.g. via kick-off meetings) Document changes in the Process Assets Library Share improvements with fellow project


47 / 48©Jozef De Man 2008-2009

Process ImprovementTwo Levels

Organization Lessons-learned in projects, appraisals of the process and

other inputs are used to document improvements for use by later projects (organizational learning)

Project If a project is executed in iterations, lessons learned in an

iteration can be used for improvements in the next iteration Iteration Reviews must be used to evaluate possible

improvements and decide whether they can be applied immediately

Process Improvements must be clearly communicated to all members


48 / 48©Jozef De Man 2008-2009

SummaryKey Points

Perform Software development as a PROJECT

Deliver a functioning product early and frequently

Keep focus on the customer

Ensure efficient and effective communication between all stakeholders

Stick to a common way of working and continuously improve it

1 / 48 ©jozef de man 2008-2009 managing a small software project a quick guide ed 2 managing a...

Documents