Post on 28-Dec-2015
© 2004 Stanford University & ThoughtWorks, Inc.®
Agenda
Approach
Preview of Assessment Results
Next Steps
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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%
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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?
© 2004 Stanford University & ThoughtWorks, Inc.®
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”
© 2004 Stanford University & ThoughtWorks, Inc.®
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?
© 2004 Stanford University & ThoughtWorks, Inc.®
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.
© 2004 Stanford University & ThoughtWorks, Inc.®
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
© 2004 Stanford University & ThoughtWorks, Inc.®
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.