System Development Initiative Assessment Summary Stanford, ITSS August 12 th, 2003.

System Development Initiative Assessment Summary

Stanford, ITSSAugust 12th, 2003

© 2004 Stanford University & ThoughtWorks, Inc.®

Agenda

Approach

Preview of Assessment Results

Next Steps


Objectives & Scope

Objectives To improve the relationship between ITSS and its customers To increase the success of the ITSS' collaboration with outsourcing

vendors and other Stanford IT groups To improve the quality of analysis, requirement and specification

deliverables To establish consistent and effective quality assurance processes for

project delivery To reduce the duration and effort of chartering and delivering projects To increase visibility into and control over project scope changes To provide consistent metrics across projects To establish a consistent, transparent and manageable portfolio

management and project governance process Scope

In Scope:• Governance, Project and Portfolio Management, Delivery

Out of scope:• Hiring Practices, Operations, Major Technology Vendor choices


Approach Scope Definition

See diagram

Interviews Issues capture

Documentation Review Process verification

Root Cause analysis Categorize issues Trace issue cause

Metrics Gathering Financials Staffing Technology

Project Managemen

t

Project Managemen

t

IT Governance

IT Governance

Portfolio Managemen

t

Portfolio Managemen

t

Project DeliveryProject Delivery

Organizational Strategy: Alignment verification, funding & investments, long-term vision

Cross-Project Coordination: Project

prioritization, project Go/Hold/Kill decisions,

resource allocation

Delivery Facilitation: Clearing obstacles, tracking & baseline integrity, team enablement

Value Assurance:Collaboration with customers, assuring quality, delivering business value


Interview Process

60+ hours of interviews Management, Customers &

Delivery personnel

All biases treated equal

Anonymity guaranteed

200+ issues elicited (including duplicates)

Issues were collated, categorized and root cause analysis performed

Delivery30%

Project Management

16%Governance15%

Global/Misc15%

Portfolio Management

13%

People11%


Issues Capture


SCs lack deliveryrepresentation

lack of insightinto

delivery issues too many SCs

poor tech decisionsby SCs

inability togovern

polluted partnershipswith other departments

unclear sponsor-shiproles and responsibilities

poorsponsorship

lack ofsponsorship

unclearinfrastructure

customer

lack of business case

lack ofclear vision

IT Governance Flowscape

lack of quantitativegovernance

lack of consistency

lack of clarity

lack of clarity

lack of consistency


no data

no financials compliance driven

poor estimating / budgeting

orphan systems

late delivery

scope cuts

lack of visibility

complicatedenhancementgovernance

complicatedproject

approval

status report – a new bad format every week

focus onapproval

over tracking

lack of accountabilityslower time to market

no history

Portfolio Management Flowscape

no visibility

no control

lack of rigor inproject approval

lack of clarity

lack of consistency


reduced business value

lack of alignment

late delivery involvement

flawed baselines

role confusion

lack ofaccountability

inability to track

inability to plan

inability to pushbackschedule compression

pressure to cut cost

increased usageof “free”

resources

testing neglect

inconsistentPM practices

lack of clearprocesses / objectives

Project Management Flowscape

lack ofhistorical data

lack of clarity

lack of consistency

no visibility

no control


business sign-off on wrong

requirements

business has incorrect analysis session attendees

monolithic delivery model

Project Delivery Flowscape

poor estimating / budgeting

decisions made despite lack data

reduced business value of final

product

customers to their own system tests

> 50% of customers time spent on projects

lack of resourcescounter-

productive resource allocation

missing functionality

lack of clarity

lack of consistency

no visibility

no control

role confusion

lack of clearprocesses / objectives

pressure to shortcut testing

under-budgeting compensated for by

using "free" resources

inaccurate data rolled up to

management

business unprepared for analysis effort

required

analysis paralysis

lack of customer feedback


Root Cause Analysis

Too much Consensus, not enough

Understanding

Confused Decision Rights

Lack of Software Development Best Practices

Too much Money

Process Culture Mismatch

Process Strategy Mismatch


Root Cause Analysis

Too much Consensus, not enough Understanding Many meetings are held to discuss options and review

decisions, however, the basic concepts that these options and decisions are based on are not consensual…

For example, what are the answers to these questions:• What is the role of a sponsor?• What are the primary responsibilities of a project manager?• When is a project “active”?• Who’s job is it to provide estimates?• What is a project?• How much money does ITSS spend yearly on software

development? Package implementation? Support? Agreement is meaningless without a shared context


Root Cause Analysis

Confused Decision Rights The lack of clarity around roles and responsibilities has a

fundamental, testable effect – decisions rights mutate from project to project

This results in:• Frustration• Inability to govern consistently• Refusal to “own” or be held accountable

• why would you choose to be held responsible for something you have no control over?


Root Cause Analysis

Lack of Software Development Best Practices Partly a result of confusion inherited from Governance &

Portfolio and Project Management Partly a result of a consensus-driven organization that is not

bound by quantitative quality controls Resulting in poor quality, productivity and predictability …and poor morale – the effect of long-term “failure”


Root Cause Analysis

Too much Money Stanford is a wealthy organization, and as such pressure to

monitor spending and resource (personnel and other) usage has not been the primary driver of accountability.

Many software development best practices have emerged over the last decade, but the "entry points" of these best practices has most frequently been as driving toward financial accountability. Thus, Stanford needs to discover motivations toward accountability that gel with its existing culture.

It is notable that the only departments to provide metrics during the "Offshore Outsourcing Conference" were support departments. Why?

• Have they been squeezed harder than other areas?


Root Cause Analysis

Process Culture Mismatch On the one hand, ITSS has sought to work towards the

waterfall ideal of a process that allows one actor in the process can carry on the work begun by another with no other information than documentation handed over, or emailed – a "Hand-off" that is "Hands-Off".

On the other hand, Stanford is an inherently collaborative organization, with a drive to innovate, to excel.

These drives are inhibited by a plan-driven methodology. Innovation and exceeding expectations require flexibility,

adaptability and real-time, efficient collaboration. The process chosen must support these.


Root Cause Analysis

Process Strategy Mismatch On the one hand, ITSS has sought to work towards the waterfall

ideal of a process that allows one actor in the process can carry on the work begun by another with no other information than documentation handed over, or emailed – a "Hand-off" that is "Hands-Off".

On the other and, since many of the technologies being introduced during the last few years (Oracle, Peoplesoft, Web-based applications), many problems emerged that were unfamiliar to all parties, problems that could not be resolved by simply creating more comprehensive "hand-off" documents.

Put simply, the projects undertaken were of a unpredictability and unfamiliarity that they required more learning, and therefore more discussion, collaboration and communication for actors at all levels - from governance to delivery.

Tackling new technologies cannot be done without a process to support such unpredictability


Recommendations

Agile Development Pilot Verify what practices of Agile need to be tailored for ITSS Prove that Agile is a fit for ITSS/Stanford Produce demonstrable results and success stories

Governance Track Gradually introduce clarity and visibility in to ITSS processes

• From Project Management Portfolio Management Governance

Use this gradual process to develop a true consensus, build upon understanding (define terms, qualities, decision rights)

Administrative Application Pilot Further tailoring of baseline process for PeopleSoft (?) project Offshore vendor integration

Education Supplement the above with ongoing training, discussion, etc.

System Development Initiative Assessment Summary Stanford, ITSS August 12 th, 2003.

Documents

Transcript of System Development Initiative Assessment Summary Stanford, ITSS August 12 th, 2003.