agenda - rhodes-consulting.com

1

AgendaAgenda

Application of Project Management Processes• What the Executive Sponsor Needs from the Project Manager

• Description of the Portfolio of Project Management Processes

• What Processes should be focused on– Per research

– From our experience

– How to detect Processes needing more focus

• Information available, links

Copyright © 2004 by Rhodes Consulting Services, Inc.

2

IntroductionsIntroductionsCharley Reed

• DSHS, 1966-2000

• Deputy Secretary, DSHS, 1996-2000

• Rhodes Consulting Services, 2002-present

Mark Tovey PMP

• Project and Program Management, Boeing, VLC

• 10 Yrs PM experience

• Rhodes Consulting Services, 2003-present, Project Management Consulting, FircrestDownsizing, DDD Support

Rhodes Consulting Services, Inc.

• Project Management, Project Planning

• Formed 12 years ago, in WA for 9+ years

• Multiple State, County, and Municipal Projects incl ACES, ERP (Cook County),Welfare Reform, WorkFirst (WA), TIERS (TX), etc. (approx 40 project, 10 states)


3

What the Executive Sponsor NeedsWhat the Executive Sponsor Needs

10 Things1. A Clear way to get from points “A” to “Z”2. Some way to identify all the steps necessary.3. Some way to determine how all the steps interrelate.4. Some way to determine who is responsible for what5. A time table for getting each step done on time.6. A way to “force” discipline on responsible workers that may be good

subject experts but know little about project management.7. Loyalty, complete honesty.8. A very clear “heads up” on what is really going on in the project

(Good/Bad)9. Not to read about the project in the paper until it is successfully completed.10. The completion of a successful project on time..


4

The Executive Sponsor in the Public SectorThe Executive Sponsor in the Public Sector

The Goldfish Bowl Effect

• Nothing in the Public Sector is Private.

• The Media is usually more interested in problems thansuccesses

• Public disclosure usually means everything must bedisclosed.

• Good project management provides comfort and assurancenot only to the Executive Sponsor, but also to all those whoprovide oversight.


5

What I What I ““HearHear”” the Executive Needs the Executive Needs

What Executive Sponsor Says1. A Clear way to get from points “A” to “Z”2. Identifying all the steps necessary.3. Determining how all the steps interrelate.4. Determining who is responsible for what5. A time table for getting each step done on

time.6. “Forcing” discipline on responsible

workers that may be good subject expertsbut know little about project management.

7. Loyalty, complete honesty.8. A very clear “heads up” on what is really

going on in the project.9. Not to read about the project in the paper

until it is successfully completed.10. The completion of a successful project on

time..

What I “Hear”A. Requirements (1)B. Clear Roadmap (Plan) (1,6)C. Detailed Plan (2) incl QA stepsD. Integrated Plan w/ Dependencies (3)E. Plan w/ clear ownership (4)F. Plan w/ Scheduled Tasks (5)G. Tracking (6)H. SDLC (6)I. QA (6)J. Good News/Bad News (7,8)K. Early Warning System (8)

• Data Driven, Not Optimism Driven• Issue Mgmt/Risk Mgmt

L. External QA – (8,10)M. Whatever Processes are Required (10)N. Extreme sensitivity to

• Success• Good controls feeding good

communications


6

Project Management ProcessProject Management ProcessSelectionSelection

•Introduction - Portfolio

•Success and Failure Factors

•PM Processes

•Planning for Success

•Selecting the right PM Processes for a Project


7

Portfolio of PM ProcessesPortfolio of PM Processes

•PMBOK•39 PM Processes according to the PMBOK

•Activity Sequencing

•Scope Planning and Definition

•Integrated Change Control

•CMMILevel 2 – Repeatable

Software configuration managementSoftware quality assurance

Software subcontract managementSoftware project tracking and

oversightSoftware project planning

Requirements management


8

What Processes to Focus On - fromWhat Processes to Focus On - fromResearchResearch

Sources•Capers Jones – analyzed 6,700 projects

•Etc.


9

Success and Failure FactorsSuccess and Failure FactorsUnsuccessful Project Technologies Successful Project TechnologiesNo historical S/W measurement data Accurate S/W measurement (Tracking)Failure to use automated estimating tools Early use of estimating tools (Planning)Failure to use automated planning tools Continuous use of planning tools (Planning)*Failure to monitor progress or milestones *Formal progress reporting (Tracking)Failure to use effective architecture Formal architecture planning (Planning)*Failure to use effective development methods *Formal development methods (SDLC)*Failure to use design reviews *Formal design reviews (QA)*Failure to use code inspections *Formal code inspections (QA)*Failure to include formal risk management *Formal risk management (Risk Mgmt)Informal, inadequate testing Formal testing methods (QA)Manual design and specifications Automated design and specifications (SDLC)Failure to use formal configuration control Automated configuration control (incl CC)More than 30% creep in user requirements Less than 10% creep in requirements (Change)Inappropriate use of 4GL’s Use of suitable languages (Planning)Excessive and unmeasured complexity Controlled and measured complexity (Change)Little or no reuse of certified materials Significant reuse of certified materials (SDLC)Failure to define database elements Formal database planning (Planning)

** From Capers Jones “Software Systems Failure and Success 1995” , p. 6


10

Success and Failure FactorsSuccess and Failure Factors

S/W Project Management Performance on Successful and UnsuccessfulProjects

Activity Successful Projects Unsuccessful Projects

Sizing Good Poor

Planning Very Good Fair

Estimating Very Good Very Poor

Tracking Good Poor

Measurement Good Very Poor

Quality Control Excellent Poor

Risk Analysis Good Very Poor

Overall Performance Very Good Poor

** From Capers Jones “Software Systems Failure and Success 1995”, p. 152


11

Success and Failure FactorsSuccess and Failure Factors

The overall ranking of US software expenseand schedule elements is of interest, sincecoding is only in fourth place

Defect removal operations

Paperwork in all forms

Meetings and communications

Code developmentFrom Capers Jones “Applied Software Measurement 1991”, p. 230


12

Success and Failure TrendsSuccess and Failure Trends

$59.5 Billion Wasted! The U.S. gross domesticproduct loses 0.6% a year because of softwaredefects. Currently, over half of all errors arenot found until “downstream” […] or duringpost-sale use. This occurs even though vendorsalready spend 80% of development costs ondefect removal.

From Mark Windholtz, “Lean Software Development”


13

Product Development LifecycleProduct Development Lifecycle

•Software Development Lifecycle (SDLC)•6 Stages (Defined by “Rapid Development, 1996”

•Software Concept

•Requirements Development

•Architectural Design

•Detailed Design

•Coding and Debugging

•System Testing

•Reviews before completion of each stage and moving to the next

•Consistent repeatable process

•Proven development steps


14

Product Development LifecycleProduct Development Lifecycle

QA


15

Initiating ProcessesInitiating Processes

For Initiating all Projects

•Determine Scope•Determine the size of the project

•Determine the complexity of the project

•Scope allows you to know when you are done

•Determine Major Risks•Identify major risk items

•Develop contingency and abatement plans

•Select Biggest Impact Processes•What areas are the biggest risk factors?

•How much time do you have for implementing the processes?


16

Selecting the Right PM ProcessesSelecting the Right PM Processes

How do you know which processes are best•39 Processes from PMBOK

•17 KPAs from CMMI

•SDLC

•Many others

•Automated Tools

In many cases, it’s not – What processes to implementbut – How formal or rigorous should the process be.


17

What Processes to Focus OnWhat Processes to Focus On

••from personal experiencefrom personal experience

••for supporting Exec Sponsorfor supporting Exec Sponsor

Examples

•ACES

•Welfare Reform•Saskatchewan Gaming Machines


18

Example - ACESExample - ACES

What events caused processes tobe added or modified?

CommunicationsMgmt Decision

External QANeed for strong stakeholder/fieldsupport, additional overview ofdevelopment

Project Planning•Inability to know “true” schedule ofrecovery and required resources•Inability to know resources required

.

Automatic Client Eligibility System (ACES)•State Government•Traditional Waterfall Development•Prior failures (Cosmos, bad –restart)•Approx 125 staff (state, mostly contractors, IBM)•Lots of media attention

Processes Used from the Beginning

•Practically everything

Processes made more robust

•External QA

•Internal, External Communications

•Project Planning

•1100->6200 tasks, CPM, extensive resourcemgmt analysis, larger scope (external interfaces)

•Internal QA – structured, scheduled review ofartifacts

•Issue Management


19

ACES Project EnvironmentACES Project Environment

Exec SponsorExecSponsor-C. Reed


20

How Processes Helped ACESHow Processes Helped ACESand Exec Sponsorand Exec Sponsor

Exec Sponsor Needs from Project-Well Informed

-Loyalty-Complete honesty.

Project Needs from Exec Sponsor•Conversion O/T

•System Performance Support

Project Planning andTracking Process

Updated Weekly

ExecSponsor-C. Reed

ACES ManagementTeam

ExternalQA

•Portion of Exec Report•Plan 7000+ tasks

ID Task Name Slack,6/26

27 MAJOR DELIVERABLES28 Ready for System Test29 Intake document complete 30 Appl. & Case Change complete31 Phase 1

32 Phase 2 3.15d 33 English Notices Ready for System Test 0d 34 Notices document Complete -0.11d 35 Monthly and Quarterly Reporting (Eligibility) document complete36 Phase 1 FS Elig37 Phase 2 Cash Ready for System Test38 Phase 2 w/ CRs 127,132,134,135,136,138 & Medical1.38d 40 Phase 3 -1d 41 Tracking (Alerts, ACM) document complete

1/16

3/11

7/31 8/3

6/28 7/13

7/26 8/14

5/9

6/19

7/18 7/19

7/21 7/24

6/17

Q4 Q1 Q2 Q3 Q4 Q1 Q21994 1995 1996


21

Example Example –– Welfare Reform Welfare Reform

What events caused processes to beadded or modified?

Issue Mgmt•When task completions were beingcollected, tasks were not beingcompleted on schedule, issues wereholding tasks up (policies, waiting onexternal department response, etc. )

sDLC•Review of progress indicated that anintegrated design was not complete,construction was proceeding. Progresshalted – process implemented forIntegrated Design.

More Robust QA•Design document included significantQA Process (public reviews).

Welfare Reform (WorkFirst) (non-I/T)•State Government

•Biggest Change in Welfare in 60 Years

•Approx 100 state staff, 1 contractor (SMEs, notexperienced in PM)

•Multiple teams (programs, policy, multipledepartments) DSHS, ESD, Governor’s office

Beginning Processes

•Project planning–Scope definitions

–Requirements/deliverables defined

–Forced discipline on SMEs, getting from A to B

•Project Tracking and Oversight

Processes Added/Modified

•Issue Management (incl escalation)

•Awareness of sDLC

•Communications (Field, stakeholders, publicReviews)


22

Example Example –– non I/T non I/T

Why discuss non I/T

•Many Public Sector projects do not contain a large portion of I/T

•I/T project often contain a large portion of the business side of the organization (nonI/T)

Project management challenges with non-I/T teams are often different

•Team may not have been on a significant project before (example, Welfare Reform vsACES)

•Teams may consist of SMEs, social workers, not technical staff that go from projectto project

• Participants may say “I’ve never had to think this way before (sequentialdevelopment)

•Will need a defined plan to

•Get items out of DRAFT (consensus may not be possible

•Flag issues, escalate


23

Example - Saskatchewan GamingMachines

What events caused processes tobe added or modified?

Requirements Management•No original baseline requirements wereagreed upon

Change Management•Customer requests for changes and/oradditions were creeping the scope of theproject

Province of Saskatchewan Gaming Machines

•State Government

Processes Used from the Beginning

•Communications Planning

•Requirements Definition

Processes made more robust

•Requirements Management•Detailed Customer Requirements were createdand reviewed at every stage of the SDLC

•Change Management

•Changing Customer Requirements were addedwithout changing the schedule, but increased therevenue


24

How to ApplyHow to ApplyInitiation• Start with Basic Processes from experience• Consider circumstances of public sector

– Fishbowl– On some projects, many project staff may be new to “projects”

Knowledge• Be knowledgeable of portfolio of formal, strong processes

Add or Modify Processes• Primarily for Corrective Actions• Will require “decoding”

– Detect weak areas– Categorize (problem is symptomatic of problems in which process area)– Define new or modified process


25

Links for InformationLinks for Information

•This Presentation

www.rhodes-consulting.com

•PMBOK

http://www.focusproject.pl/content/download/pmbok2000.pdf

•CMM/CMMI

http://www.sei.cmu.edu/cmm/


agenda - rhodes-consulting.com

Documents