managing it projects: an introduction · managing it projects: an introduction jean-louis binot 1...

Managing IT Projects: an introduction

Jean-Louis Binot

30/04/2014 Project Management 1

Agenda


Challenges of IT Projects 3

IT Project Life Cycle 4

IT Applications and IT Projects 2

Why Project Management ? 1

Role of the Project Manager 5

Agile Methodologies 6

Why Project Management ?

In a company, IT supports the business through IT applications and IT services

q  Implementation of a new IT application, or rolling out of IT services, is done through IT projects

q  IT projects are difficult to execute, and require a specific discipline to succeed: Project Management

q  Project management is a management activity, which can involve large teams and budget. The role of project manager may be a suitable career path for IT engineers


Agenda








An IT Application

q  Is a computer software designed to help the user to perform specific tasks (Wikipedia)

q  Automates business processes in order to produce business benefits, in four possible categories: n  Increase sales and hence revenues

n  Reduce costs and hence increase profits

n  Increase quality of product / service & customer satisfaction

n  Ensure compliance to regulations

q  Needs to store, retrieve, and process data in order to achieve that automation n  and thus typically involves some form of database


Example 1: a car configurator

30/04/2014 6 Project Management

Product DB Customer DB

Car configuration Quote

Test drive request

Test drive appointment

Benefits: increase sales

Main challenges of a web application ?

Challenges - Project size (>5M€; many concurrent users) - Data accuracy - Performance and availability - Graphical interface (3D, accuracy) -  Multi country / language (30 countries) -  Maintenance (25 people)

Example 2: technical document mgt


Engineering Data (3 languages)

European Data (>20 languages)

Technical doc

Local updates

Challenges - Project size (>10M€; huge # of users) - Interactive graphical diagrams - Automated search & link with repairer tools -  Automated translation in many languages -  Performance and availability -  Data accuracy

Technical data text & images

Automatic Translation

Any repairer in Europe

Benefits: increase quality & European compliance

Example 3: Vehicle order mgt (simplified)


Sales person

Benefits: reduce costs & increase customer satisfaction

Challenges -  Project size (300 M€, 30 countries) - Performance: < 2 secs in Europe -  Interface with ERP system -  Accurate ETA -  Complexity of algorithms -  Data accuracy, availability - Customisation

Customer

Factory

New built

From stock

Production planning

Factory Stocks

Car sale + ETA

Order

Customer Sales person Customer

Logistic routes

Hub Distributor Vendor

ERP system orders, car status over Europe, car allocation to order

route optimization, ETA calculation…

IT applications support the business

All important IT application issues will have business impacts

q  Application availability matters (must “keep the lights on”) n  Challenge both for application teams and for operational management

q  Application performance matters n  Delays have business impact

q  Respecting deadlines matters n  Many deadlines are “business critical”: they can’t be moved without impact

q  Data accuracy matters n  Impact of data errors goes from inconvenience to critical liability

q  Application reliability matters n  Bugs have business consequences


Agenda








Is there a missing level ?

IT added value in the enterprise : a maturity model


Transactional IT acts as “order taker” fulfilling requirements specified by business IT only focuses on technology and operational efficiency

Incompetent IT is not even able to execute on business requests

Partner IT interacts with business to understand and specify business requirements IT may recommend alternate solutions

Consultative IT understands both business and technology issues IT is proactive in recommending solutions for competitive advantage

Strategic leader IT is viewed as a strategic leader within the enterprise IT is a partner in the planning and execution of the business strategy

The added value of IT depends on its capacity to support the business

The difficulty of delivering IT projects


How many projects realy succeed ? The Standish group (IT project management research and consulting firm) delivers each year a “Chaos report” surveying project success rate The first report (1995) was a landmark:

q  16% success q  31% failure q  51% challenged

More recent Standish data (2012)


Slight improvement in project success rate, but still many failures

39%

18%

43%

0%

20%

40%

60%

2004 2006 2008 2010 2012

Project results

Successful Failed Challenged

Better results with agile methodologies for small projects

Why so many project failures ?

q  Technical / architectural mistakes

q  Requirement issues

q  Difficulty of integrating / managing all aspects

q  Lack of organization maturity or discipline

q  Difficulty of managing consensus between stakeholders

q  Competition for scarce budget and resources

q  Management pressures

q  Psychology and politics q …


Consequences on application life cycle

q  Because IT projects are difficult and costly, application renewal is slow. Applications tend to exist for a long time (e.g. 2 y project, 15/20 y maintenance !)

q  The highest cost comes from maintenance, hence the importance of quality

q  In most cases, after a few years, the original developers are no longer around


A typical application lifecycle, with defect rate evolution

Agenda








What is a project ?

q  A project is a temporary endeavor undertaken to create a unique product or service (PMI) n  Temporary: it has a definite start and a definitive end

n  Unique: it is not repetitive (not production nor maintenance)

q  A project has three main dimensions

n  Time (respect of deadline / schedule)

n  Cost (respect of budget, which can be “fixed price”)

n  Quality (of the delivered product / outcome)

q  A project involves many additional domains, such as n  Scope, human resources, communication, risks, procurement,

integration


The project life cycle (a typical view)


IDENTIFY

& QUALIFY

CONTRACT PROPOSE Go/No Go Go /No Go

N N

Y Y

PROJECT DEFINITION PHASE PROJECT DELIVERY CYCLE

Project selec?on -‐ which projects include in yearly plan (porKolio)? -‐ for IT provider: which bids to work on ?

q Opportunity profile

q Business case

q  Risk analysis

PROJECT EXECUTE

PROJECT CLOSE

Project defini?on

q Updated business case

q  Technical solu?on

q  High level plan

q  Project costs es?mate

q  Updated risk analysis

Selec?on of supplier & contrac?ng

q Milestones

q  Specific clauses

q  Subcontracts

q  Updated risks

q  Updated financials

q  Follow-‐up cycle

q  Schedule / plan

q  Es?mates

q  Quality

q  Staffing

q  Skills & coaching

q  Scope mgt

q  Customer mgt

q  Risks & counter

q  Financials

q  Closing internal, client, subs

q  Organiza?onal learning

PROJECT INITIATE

q  Project organiza?on

q  Project governance internal, client, subs

q  Handover from opportunity phase

q  Project Baselines scope, schedule, cost

q  Staffing

Project Definition Phase

q  Project Opportunity n  Is the project motivated by business needs / strategy ?

n  Are there enough business benefits generated by its outcome ?

q  Feasibility n  Have we identified the high level technical solution, schedule, costs,

and risks ?

n  Are these acceptable / manageable ?

q  ROI n  Is the Return On Investment acceptable given business needs?



Business Background

High Level System Changes

Benefits

Costs

Schedule

Business Process Improvement

A Project Justification Sheet (example)

The project life cycle (a typical view)


IDENTIFY

& QUALIFY

CONTRACT PROPOSE Go/No Go Go /No Go

N N

Y Y

PROJECT DEFINITION PHASE PROJECT DELIVERY CYCLE

Project selec?on -‐ which projects include in yearly plan (porKolio)? -‐ for IT provider: which bids to work on ?

q Opportunity profile

q Business case

q  Risk analysis

PROJECT EXECUTE

PROJECT CLOSE

Project defini?on

q Updated business case

q  Technical solu?on

q  High level plan

q  Project costs es?mate

q  Updated risk analysis

Selec?on of supplier & contrac?ng

q Milestones

q  Specific clauses

q  Subcontracts

q  Updated risks

q  Updated financials

q  Follow-‐up cycle

q  Schedule / plan

q  Es?mates

q  Quality

q  Staffing

q  Skills & coaching

q  Scope mgt

q  Customer mgt

q  Risks & counter

q  Financials

q  Closing internal, client, subs

q  Organiza?onal learning

PROJECT INITIATE

q  Project organiza?on

q  Project governance internal, client, subs

q  Handover from opportunity phase

q  Project Baselines scope, schedule, cost

q  Staffing


Project Delivery Cycle

Project proposal

Project initialization

Project execution

Delivery control

Project closing

Project office

OrganizationalLearning cycle

Project review cycle

Start in orderly fashion - Avoid cost leakage - Avoid costly mistakes Approval based on

accurate estimates

Improve efficiency (estimates, reuse, KPIs…)

Consistent approach to reduce mistakes and increase efficiency (standards, templates, coaching)

Deliver on time, on budget, with quality

How to structure an IT project ?

Several types of IT projects q  Application development q  Application Rollout / Service rollout q  ERP (Enterprise Resource Planning) q  Consulting q …

For application development, at least two approaches q  Classical approach (planning & control) q  Agile methodologies

Let us start with the classical approach …


How to structure an IT project ? ./.


Which % of project efforts is typically used by coding ?

Requirements Functional analysis Architecture

Development Unit testing (coding)

Functional, integration, performance, stress, regression testing

Customer Acceptance

Warranty

Internal gateway

Internal gateway

Customer gateway

20% 35% 25/30% 5/10% 10%

To be added: Project mgt 15%; contingency >= 10% linked to risks; quality 2-3 %

Init meeting

Case of an IT application development project

Efforts

q  Coding is only 1/3 of a project activity q  There are challenges at every stage q  A good project has gateways (go / no go points)

IT project structure: requirement and analysis phase Old joke, still true q  Customer may have only a high level view of

his needs and be unclear q  He is often not IT/process literate q  But he has to accept system and pay bill

Challenges for IT project q  Elucidate requirements (first in NL) q  Detect incompleteness, inconsistency, risks q  Formalize functional requirements and data q  Obtain sign-off in reasonable time frame


Examples of Requirement failures

Too little requirement formalization n  Customer wanted to migrate automatically a web system and database to new

technology; was sure to have required it n  Service provider was convinced automatic migration was unfeasible; was sure to have

agreed manual solution n  Documents existed but no clear evidence of agreement n  Customer refused to accept systems; several months delay and

1 M€ over-costs needed to agree and implement compromise

Too much requirement formalization n  Major global credit card company wanted to implement global settlement system

including functions of its European partner n  30 European people sent to USA to work 2 years on requirements n  Business lost faith after 2 years of “paper”and cancelled project at huge cost


IT project structure: coding phase

q  Competing constraints n  Highest cost comes from maintenance, and applications are long-lived;

typically original developers are no longer around => need for software quality

n  To be competitive, the project must meet deadline and cost targets => need for speed and efficiency

q  Typical industry requirements for the coding activity n  Reuse (libraries of routines, frameworks)

Coding must be teamwork n  Quality (correctness if possible, but also testing) n  Standards (documentation, naming conventions…) allowing maintenance


IT project structure: testing phase

q  Testing should be documented (test plans, test results) q  Unit tests are typically a developer’s responsibility q  Other tests are ideally done by other people q  Acceptance test criteria should be agreed before you start coding


The classical “V” of testing


Agenda







Role of the Project Manager

q  Project : The mission of Project Manager is to deliver the result of the project n  On time n  Within budget n  With quality

q  Manager: The Project Manager is not a content expert nor an administrator. His job is to manage the project n  Planning n  Assigning tasks, delegating n  Monitoring and controlling n  Assessing risks, making decisions, anticipating n  Leading and motivating a team n  Communicating and negotiating


Project Management standards

q  Standards provide methods, templates… to assist the project manager in properly managing a project

q  Several important international standards exist, a.w. n  PMI: Project Management Institute

(publishes the PMBOK: Project Management Book of Knowledge)

n  Prince 2 (PRojects IN Controlled Environments) initially developed for the British government, now recognized as an international standard

q  They also provide certification of project managers



Main project management deliverables in the delivery cycle

Project proposal


Project execution

Delivery control

Project closing

Project office




accurate estimates




Typical PM activities & deliverables

Activities q  Clarify and manage project objectives (scope, deadline, budget, assumptions, etc.)

q  Define project organization

q  Break down the project into tasks, assign them, monitor performance, detect deviations and take counter-measures

q  Manage project costs against budget, make forecast of cost evolution, detect deviations and take counter-measures

Deliverables q  Project charter / statement

q  Project organization

q  Project plan (initial plan = baseline)

q  Project costs (initial plan = baseline)


Project charter – typical agenda

The project charter summarizes initial mission of the Project Manager and is his first important deliverable

q  Objectives of the project

q  Targeted benefits

q  Stakeholders (key people having stake in / decision on the results)

q  Scope assumptions: in scope, out of scope

q  Main deliverables with their milestones

q  Communication plan (including reviews, steering committee)

q  Project budget

q  High level risk management plan (risks & counter-actions)


Project Organisation – typical roles


Project Manager

Business Modeling

Team Lead

Business Analysts

Architect Lead

Architects

Functional Team Lead / Testing lead

Functional Analysts / Testers

Development Team Lead

Developers

Deployment Manager

Project Officer Quality Manager

Project planning : key points

q  You can’t plan precisely without requirements n  Your plan needs to be refined after requirements phase.

q  Planning requires to estimate efforts (cfr “Estimating” later)

q  Selection of the planning tool is usually not the key point n  Your plan should tell a) where you had planned to be, b) where you are, c) what is the deviation (to

take counter-action)

n  You can plan in PowerPoint, Excel, with a scheduling tool…

q  To measure deviations, two views need to be maintained n  The initial plan or baseline, which cannot be changed by the project manager himself. Often

limited to high level milestones

n  The actual status with as much details of tasks as appropriate

q  No plan, no resources



Assessment (10 interview sessions @ 0.5 mds; assessment 5 mds) 10 mds

Action plan (3 mds draft, 1md review, 1md finalization) 5 mds

Total 15 mds

21/02 20/03 31/03

Kick-off Assessment review Action plan review with Executive Committee

Planning

Efforts (consultant)

Assessment Action plan definition Implementation

13/03 assessment

draft

27/03 action plan

draft

Activities and deliverables 1.  Assessment of existing status Deliverable: status report (Powerpoint)

2.  Definition of improvement plan Deliverable: action plan (Powerpoint)

A simple plan (consulting project)

Example of a more complex schedule


Estimating: key points

q  You can’t estimate precisely without requirements q  Your estimates need to be refined after requirements phase.

q  You need to break down project into tasks, and count efforts n  Size (granularity) of the tasks must be small enough for accurate planning, but not too

small (e.g. a few man-days)

q  Estimating helps you to define the initial size of the project

q  Estimating will also help to track progress AND cost n  Cost tracking should tell a) how much budget you have, b) how much you will spend, c) what is the

difference (to take counter-action)

q  To answer that question the Pr Manager needs two views n  The initial budget or baseline, which cannot be changed by the project manager himself.

n  The actual Estimate (of cost) At Completion (EAC): that is the current estimate of what the total cost will be


Example of estimating method (partial)

Actor Type Description Quantity Weight Factor Subtotal Simple Defined API 3 1 3 Average Interactive or protocol-driven interface 2 2 4 Complex Graphical user interface 1 3 3 Total Actor Points 10


q  Use Case Points (Schneider & Winters, 2001) n  Based on Universal Modeling (UML) approach;

distinguishes actors, use cases

n  Use Case Points = Total * corrective factors (technology, experience) n  Efforts= Use Case Points * Effort Rate (e.g. 20 mh / point)

Use Case Type Description Quantity Weight Factor Subtotal Simple Up to 3 transactions 3 5 15 Average 4 to 7 transactions 2 10 20 Complex More than 7 transactions 1 15 15 Total Use Cases 50


Main project management deliverables in the delivery cycle

Project proposal


Project execution

Delivery control

Project closing

Project office




accurate estimates




At each cycle (at least monthly):

review status and risks

Reassess planning and estimates

Typical PM activities and deliverables


Activities q  Assign tasks, monitor project plan and performances, detect deviations and take counter-measures

q  Manage project costs against budget, make forecast of cost evolution, detect deviations and take counter-measures

q  Periodically report on project status (in project review)

q  Identify risks and issues and take counter-measures

q  Implement and follow-up needed actions

Deliverables q  Project plan (actual status)

q  Project costs (actual status)

q  Project status report

q  Risks & issues status register

q  Tracking of decisions and actions (action list, minutes of meetings …)

Cost Control and Financial indicators


BAC

Budget

Initial Budget

CR

Actuals

ACWP (recognized

revenue)

ETC

EAC

ACWP/EAC = %

completion Earned

Value = BAC *

% completion

Budget

Variance

Cost

Variance

Billing

Billed

WIP

At each review, the Pr Mgr needs to re-evaluate the Estimate to Complete (ETC) based on plan and status. This is not simply budget minus costs.

Main Financial Indicators

q  BAC Budget At Completion

q  BCWS Budgeted Cost of Work Scheduled

q  ACWP Actual Cost of Work Performed

q  ETC Estimate To Complete

q  EAC Estimate At Completion

q  BCWP Budgeted Cost of Work Performed - Earned Value

q  BV Budget Variance

q  SV Schedule Variance

q  CV Cost Variance


Reviewing estimates – basic example

BAC (budget)

Actuals (22/3)

ETC (Estimate to complete)

EAC (Estimate at completion)

BV (budget variance)

Assessment 10 13 5 18 8

Action Plan 5 0 6 6 1

Total 15 13 11 24 9 (60%)


21/02 20/03 31/03

Planning Baseline and status Assessment Action plan definition Implementation

13/03 assessment

draft

27/03 action plan

draft

Budget baseline and status

Schedule variance: 7 days (assessment completion estimate: 22/03 + 5 = 27/03) Budget variance: 9 person-days Earned value (pd rate 1000 euro): (13/18)*15= 722 euro

Actual status 22/3

What does it take to be a good project manager ?

According to survey by ESI International of project managers following their training q  Inspires a Shared Vision q  Good Communicator q  Integrity q  Enthusiasm q  Empathy q  Competence q  Ability to Delegate Tasks q  Cool Under Pressure q  Team-Building Skills q  Problem Solving Skills


I would add:

-  Anticipation

-  Strength of character


Agenda


IT Project Management 4





Agile Methodologies

q  Manifesto for Agile Software Development in 2001: promote n  Individuals and interactions over processes and tools

n  Working software over comprehensive documentation

n  Customer collaboration over contract negotiation

n  Responding to change over following a plan


Agile Development


•  Many small iterations

• Time-boxed approach

•  Each iteration delivers a working product

•  Each iteration involves a team working intensively through full cycle

•  Team composition is cross-functional and self-organising

•  Face to face communication and user involvement privileged

Agile versus classical

Adaptative q  Adjust quickly to changing realities q  Difficulty to describe future tasks q  Difficulty to describe content of future release q  Involve users and decide scope changes as they go

Predictive q  Difficulty to change direction. May requires project redefinition q  Structured plan q  Agreed scope q  May require a change control board


Choice of method must be influence by culture of the enterprise

Conclusion

q  Project Management is a management role n  not a leading content / expert one

n  not an administrative one

q  As such it is well suited for IT engineers


THANK YOU
