Lean beyond Software Development

Alina Hsualina.hsu@alum.mit.edu

2© Alina Hsu 2009

Why should we care about COTS software projects?

• Every organization uses COTS software

• High risk of very substantial cost/effort overruns

• High risk of suboptimal decisions

– incurring either additional cost/effort of rework, or

– pain of using suboptimal software for many years

• May yield some insight into improving the non-development aspects of Lean Software Development

3© Alina Hsu 2009

Caveat

• Material represents the “inspect and adapt” efforts of one firm

• Does not obviate the need for other organizations to inspect and adapt for themselves

4© Alina Hsu 2009

Meander-forward methodology

5© Alina Hsu 2009

… with roadblocks …

6© Alina Hsu 2009

… and dead ends.

7© Alina Hsu 2009

Overview: Business

• Professional services firm

– Clients

– Engagements

– Work

– Billing

• Medium size, 1000 employees

• 1 large office in US

• 3 small offices in Europe and Asia

© Alina Hsu 2009 8

Overview: Project

• HR system old, lacks many features

• Some HR areas not well-supported

• Lots of fussy detail, may be of little value

• >10 stakeholder groups

• Many processes still manual

• Project delays of 400% or more are “normal”, but new management would like to change this

© Alina Hsu 2009 9

What’s in a [project] name?

• HR system upgrade/conversion

– System-centric

– Narrow scope

• Improve support of HR function

– Business-centric

– May need multiple systems or components to do the job

• Nickname matters, too

© Alina Hsu 2009 10

Architectural context, or the importance of being indirect

© Alina Hsu 2009 11

HR + Benefits

Staffing

Contact Mgmt

Custom Reports

Time Entry

Billing

Professional Development

Recruiting

Payroll

BlackBerry Email Network Accounts

Accounting ODS

HR ODS

Accounting

Stakeholders

HR DirectorProf Dev Mgr

Benefits Manager

Recruiting Manager

CEO

Employees

Office Managers

Hiring Managers

HR Staff IT

Director

Architect

Temps

Project Team

12© Alina Hsu 2009

Project roadmap (planned)

Initiation: 2 weeks

Analysis: 2 months

*Decide on shortlist 2 weeks

Compare products: 2 months

*Select product: 1 month

Implement: 6 months

Total: 12 months

© Alina Hsu 2009 13

Classical Process

Initiate

Analyze

Select Shortlist

Compare, Evaluate

Select Software

Install, Configure

Train

Migrate Data

Go Live

14© Alina Hsu 2009

Project Timeline: actual

• Initiation – 2 months

– Kickoff meeting was cancelled and rescheduled

– Invitees often did not reply to email

© Alina Hsu 2009 15

Analysis 1

• Analysis 1: 5 months

– Documented all HR business processes down to the use case name

– Reviewed some available software

– Created shortlist

– Autopilot analysis, not prioritized or strategic

16© Alina Hsu 2009

Bad decision #1

• Decision: Product X is unsuitable. Patently false, but product owner doesn’t like Product X.

17© Alina Hsu 2009

Bad decision #2

• Decision: Exclude from scope detailed functionality for foreign offices– Foreign offices are happy

to continue using their own HR software in addition to Enterprise HR

– Product owner is “not willing to fight that battle”

18© Alina Hsu 2009

Intransigence

19© Alina Hsu 2009

Unsustainable “solutions”

20© Alina Hsu 2009

Disconnections

21© Alina Hsu 2009

What now?

• As it turns out, project team has no clear idea of how to structure product comparison

• It is clear, however, that the analysis done so far does not give them the information or structure they need

22© Alina Hsu 2009

Back to the drawing board

• Analysis 2: 3 months

– Get information needed for generating RFP

– Get signoff on revised requirements

– It is now 10 months into what was supposed to have been a 12-month project

23© Alina Hsu 2009

Hope is not a plan

• RFP design and creation takes longer than expected (2 months)

• When vendors receive RFP, they have modifications

• After receiving all responses, a supplement is sent to ensure consistency across vendors

24© Alina Hsu 2009

Another roadblock

25© Alina Hsu 2009

Déjà vu all over again

• Decisions made so far are challenged and reversed.

• More analysis is needed.

• Analysis 3: 3 months (trying to be more efficient now)

• The RFPs are now obsolete

26© Alina Hsu 2009

Summary

• Lots of activity, little progress

• Mindset not oriented toward delivering on time: delay is tolerated, even expected.– And if something takes twice as long, the effort also

expands and the time to value is extended

– If they knew how much it would really cost, it might not have been approved.

• Still have not identified or dealt with significant data issues, and broken processes, which result in …

27© Alina Hsu 2009

Misalignment

28© Alina Hsu 2009

Heroic measures

29© Alina Hsu 2009

Complexity

30© Alina Hsu 2009

Complexity adds risk

31© Alina Hsu 2009

Comments

• Quick wins (in this case some new reports for Recruiting) don’t fit into the project plan. They must wait for many months, until we get to a suitable phase of the “main” project

• We’ve lost sight of the goal of supporting the HR function for the organization: the “main” project has now become a system implementation.

32© Alina Hsu 2009

Common issues abstracted

• Work takes much longer than expected, and when it is “done,” it is not what was needed

• Even when the product owner gets what she specified, the software is unsatisfactory and does not meet business needs

• Software is chosen based on politics, biases, steep discounts available only until the end of the month, etc.

33© Alina Hsu 2009

Common issues abstracted

• Communication is serial and pairwise, with huge delays and distortion

• Failure to ensure that the outputs of step N are designed to meet the input needs of step N+1

• The divergent stakeholder groups, and members of the project team all have different ideas of what the project is about, and of the point of their work

34© Alina Hsu 2009

It’s hard to maintain focus

35© Alina Hsu 2009

Summary: Problems to be addressed

• Delay

• Unnecessary or wrong work

• Rework caused by

– Poor decision-making

– Delay in getting feedback, lack of error-proofing

– Insufficient focus on business value, goals

© Alina Hsu 2009 36

A Leaner Alternative

© Alina Hsu 2009 37

Lean Principles

• Optimize the whole

– Eliminate waste

– Single piece flow

– Just-in-Time processes

• Focus on value from the customer perspective

• Respect people

• Keep improving

© Alina Hsu 2009 38

Big Picture Up Front

• What is the point of this project, this deliverable, this step?

• Enterprise perspective – business value

• Fractal: applies at all levels of granularity

– Outline of document

– Row and column heads of decision matrix

– Approach to analysis

• Prioritize large chunks – analogous to epics

39© Alina Hsu 2009

Timebox everything

• Work expands to fill allotted time– Still worse, a long allotted time span encourages a

“plenty of time” mindset, rather than one of sustainable urgency

• Hard to estimate analysis effort (or anything) if time span larger than a few days

• Forces high-level analysis– Overview of solution options can usually be

completed within 2 days. Timebox prevents team member from doing work not needed right away.

40© Alina Hsu 2009

Just enough work, just in time

• Just enough for next deliverable

• Just enough for input to next step of process

• Documentation barely sufficient to meet needs (Ambler)

• Can include look-ahead tasks that require weeks of lead time

– Scheduling meetings

– Ordering hardware

41© Alina Hsu 2009

Short feedback cycles

• Error-proofing

• Synergy with with Big Picture Up Front, Timeboxing, and Just-Enough, Just-In-Time

• The four of these together can be applied recursively, at successive levels of detail

• Stop at the level where teams are able to self-organize (maximum 5 days of work)

42© Alina Hsu 2009

Standard work or patterns where needed

• Discovery

• Communication (collaborative workshops, information radiators, etc.)

• Decision-making

• Architecture

• Periodic standups (include big picture)

• Define work based on inputs needed for next step

• Rule of thumb for timebox: 4/3 x estimate, e.g.

43© Alina Hsu 2009

Standard Work: Discovery

• Universe of options

• Apply categories – partition

• Prioritize categories, eliminate where possible

• Analyze categories – coarse grain

– Technical, architecture, cost, maturity, etc.

• Select representative examples

44© Alina Hsu 2009

Standard Work: Decision-making

• Agree to use public, fact-based criteria

• Agree on an algorithm for comparison

• Agree that goal is not just to come to a decision, but a to come to a decision that is well-informed, sound and robust

• Include all stakeholder groups

• Reduce uncertainty via research or experimentation on a set of distinct options, subject to time and cost constraints.

45© Alina Hsu 2009

Patterns: Flexible Architecture

• Business architecture maps to data and system architecture

• Indirection, loose coupling

• Encapsulate business functionality

• Modular: simple iterative partitions (Sessions)

46© Alina Hsu 2009

Adaptive Architecture

47© Alina Hsu 2009

Modular Architecture

48© Alina Hsu 2009

Appropriate Interfaces

49© Alina Hsu 2009

Pattern: Consensus

Form

• “I can live with that.”

Meaning

• I will not go out in the hall and try to subvert it.

• I will not lose any sleep over it.

50© Alina Hsu 2009

Lean task management

• Big Picture Up Front: what is the point?

• Do one thing at a time, and complete it

• Get frequent feedback

• Satisfice: just enough detail

• Front-load risk

51© Alina Hsu 2009

COTS Project Initiation

• Discuss risk (time, solution quality, complexity, bad decisions) with Product Owner

• Develop agreement on tools, practices to mitigate these risks

• Agree to measure delivery based on overall business value using an appropriate metric

• Include lean project approach, and the specific tools and practices, in the kickoff

© Alina Hsu 2009 52

COTS Single-Piece Flow

• Identify the smallest possible chunks of business value (typically software modules, but may be smaller)

• Prioritize at this “chunk” level. If too many chunks, prioritize at one level up.

• Begin with “plain vanilla” installation– If customization is required, encapsulate it where

possible, for change tolerance

• Consider opportunities for parallel work

53© Alina Hsu 2009

COTS Single-Piece Flow

• Deliver top 60-80% of value of each of the most valuable chunks

• Deliver additional elaboration only if value high enough

• Otherwise, work on another project

• Vendors will grumble, but will mostly agree –they want your business

• Pressure to make modules smaller – buy a feature?

54© Alina Hsu 2009

Are we there yet?

55© Alina Hsu 2009

• This is just a beginning, but as people’s mindsets change – ultimately, as people think more and better about how they work – they will implement further improvements

• Improvements are corrective, and only apply when the underlying problems are similar. Later, the same team may need to correct in the opposite direction.

Conclusions

• Success of COTS projects is largely determined by a single very big decision

– Ensure that decision is sound and robust

• Explore wide range of options

• Use experiments to reduce uncertainty

• Include input from all stakeholder groups

– Work toward software architectures that permit multiple smaller, less risky decisions

© Alina Hsu 2009 56

Conclusions

• Big Picture Up Front, Detail Just In Time provides a general approach to managing any type of project

• Short feedback cycles reduce risk, delay caused by rework

• Since COTS projects involve a lot of IT support outside of the core project team, include broad training of IT staff in basic lean principles

© Alina Hsu 2009 57