This document discusses how lean principles can be applied to package implementation projects involving commercial off-the-shelf software. It recommends defining requirements using user stories and test cases instead of detailed specifications. It also advocates for implementing the package in iterations where each iteration is tested and deployed to production, rather than a "big bang" approach. Other lean aspects discussed include co-locating the project team, vendor, and client to improve communication, and including contractual incentives to encourage finishing early.

1. Lean Package Implementation
Lean/Agile Myth #12

2. Lean/Agile Myth #12
• Lean and Agile Methodologies are only applicable for
greenfield opportunities
- Not applicable for brownfield
- Not applicable for Package Integration
- Not applicable for Application Maintenance Services (Yesterday)

3. Agenda
• What are Package Implementation Projects ?
• How are Package Implementation Project typically
done?
• What aspects of Package Implementation projects could
be done in a Lean Manner?
• Questions

4. • What are Package Implementation Projects ?

5. Package Implementation Projects
• Package Implementation Projects are projects that
typically involves a Commercial Off The Shelf(COTS)
product that needs to be integrated into the client
environment.
• These products involve more or less configuration and
customization depending on the product and fit to the
client’s requirements.

6. Audience Participation
• Question #1 – Why do companies choose COTS
products?
- Time to Market?
- Cost?
- Transfer of Risk?
- Shared Cost of Ownership?
- Available resources/capacity?
- Product fit to Requirements?
- Others?

7. Reasons for choosing COTS products
• Surprisingly, the two main reasons for selecting COTS
products to address a business problem are:
- Transfer of Risk
- Shared Cost of Ownership
• The one reason which should have greater importance
but usually is not taken into consideration:
- Product Fit to Requirements (read Cost)
- Rule of thumb is that an 80-90% fit is required to make a COTS
implementation cost effective. Otherwise possibly more money
would be spent customizing a COTS package than building new.

8. • How are Package Implementation Project typically
done?

9. Application Maintenance Services
Components
Painful
Implementation
Painful Testing
Painful Specification
Painful Contracting

10. Contracting
• This is done is a very adversarial way to try and
anticipate all aspects of the relationship to ensure both
parties are covered.
• The contracts are very detailed and allow for very little
change and modification
• Most of the contract deals with how the companies will
interact and there is little to any mention of the business
problem being solved.

11. Specification
• Specification follows the contracting process and the
emphasis is to create extremely detailed specification
documents to define all the functionality required.
• Of course there are always items not thought of or not
detailed enough.
• Many time the product rationale is used to defend
functionality. (i.e. that is how the product works) This can
be initially accepted by the business but frequently
requires change later when reality hits.

12. Testing
• Testing of the COTS application is then problematic and
it builds upon the specification which was built upon the
contract.
• Testing then attempts to verify that the application works
as documented. Lost in this process is whether the
application is actually addressing the business problem.

13. Implementation
• Implementation is then built upon the testing which was
built upon the specification which was built upon the
contract and the question that is asked at
Implementation is not:
- Does this solve the business problem?
• Rather it is:
- Can you accept this solution and go live?

14. Where did it all go wrong?

15. Lean Principles Refresher
• Before we discuss how Package Implementation can be
done in a Lean manner, let’s do a Lean Principles
Refresher

16. Lean Software Development
• Lean Software development is a style of software
development that emphasizes customer satisfaction
through continuous delivery of functional software. In
contrast to traditional software development methods,
lean developers liaise continuously with business clients.
• Their objective is to deliver working software as
frequently as every two weeks during a project, and
welcome changes to the requirements in response to
evolving business needs.

17. Lean Software Development
• The most crucial aspect of Lean is the execution of the
project in iterations and quick feedback loops possible
because of these iterations. It is essential to note that
these iterations to not just apply to construction, they
also apply to the following tasks:
- Project Management and Planning
- Analysis
- Technical Design
- Testing
- Deployment

18. Lean Software Development
• Iteration planning is ‘the’ key planning initiative
- Iterations need to be planned in conjunction with the client to
accomplish the following:
• Deliver functionality to define the cadence and tempo of the project
• Deliver functionality to deliver real value to the client
• Deliver functionality to reduce and minimize risk for the entire project
• Lessons learned from one iteration must feed into subsequent iterations so
that we don’t execute the project in iterations with similar results, but that we
execute the project in iterations with better results.
- We execute better, smarter, and quicker

19. Lean Software Development Principles
• Eliminate Waste
- The three biggest wastes in software development are:
- Extra Features
- Churn
- Crossing Boundaries
• Build Quality In
- If you routinely find defects in your verification process, your process is defective.
- Mistake-Proof Code with Test-Driven Development
- Stop Building Legacy Code
- The Big Bang is Obsolete

20. Lean Software Development Principles
• Create Knowledge
- Planning is useful. Learning is essential.
- Use the Scientific Method
- Standards Exist to be Challenged and Improved
- Predictable Performance is Driven by Feedback
• Defer Commitment
- Abolish the idea that it is a good idea to start development with a complete
specification.
- Break Dependencies
- Maintain Options
- Schedule Irreversible Decisions at the Last Responsible Moment

21. Lean Software Development Principles
• Deliver Fast
- Lists and queues are buffers between organizations that simply slow things
down.
- Rapid Delivery, High Quality, and Low Cost are Fully Compatible
- Queuing Theory Applies to Development, not Just Servers
- Limit Work to Capacity
• Respect People
- Engaged, thinking people provide the most sustainable competitive advantage.
- Teams Thrive on Pride, Commitment, Trust, and Applause
- Provide Effective Leadership
- Respect Partners
• Optimize the Whole
- Brilliant products emerge from a unique combination of opportunity and
technology.
- Focus on the Entire Value Stream
- Deliver a Complete Product
- Measure UP

22. • What aspects of Package Implementation projects could
be done in a Lean Manner?

23. Audience Participation
• Question #2 – How could we implement an COTS
application in a Lean Manner?
- Visual Project Management?
• i.e. dashboards/Ticket Boards
- Iterations?
- Requirement Management?
- Implementation?
- Logistics?
- Lean Project Management?
• i.e. Daily Stand ups

24. Requirements Management
• Requirements Management is key to any successful
project. For Package Implementation projects it becomes
even more important to ensure everyone understands
the requirements.
• Frequently Use Cases are the traditional way of
documenting requirements.
• A much better way of defining requirements are:
- User Stories
- Test Cases

25. User Stories
• A user story of one or more sentences in the everyday
or business language of the user that captures what the
user wants to achieve.
• They are typically in the following format:
- "As a <role>, I want <goal/desire> so that <benefit>"
• User Stories are much more concise that Use Cases and
provide this extra communication and detail required
when dealing with an external and somewhat unknown
COTS product.
• These User Stories can then be collected together to
define features of the system.

26. User Stories
• One challenge with User Stories is the ability to
document batch on non end user processes
• Honestly we need to address this on all Lean project

27. Test Cases
• Traditionally Test Cases are not used for Requirements
Management but rather for the testing process itself.
• Ultimately, there are no better requirements than to list
the test cases that will confirm the requirement has been
met or not met.
• These Test Cases should be defined at the start of the
project and with User Stories will define the system
requirements.

28. Iterations
• Traditionally, Package Implementations follow a Big
Bang approach. All the functionality is analyzed,
designed, coded, tested, and implemented at once.
• This does not take advantage of one of the main tenets
of Lean to execute better as we progress through the
project.
• It is highly recommended that Package Implementations
also be implemented in iterations. These iterations
should go right through to production.

29. Iterations
• It is important to remember that these iterations are not
just for development and testing, but for all phases of the
project including testing and implementation.
• Sometimes critical items are left out of iterations like
Reporting and Data Conversion. This is not
recommended. An iteration must be able to stand on it’s
own.

30. Iteration Schedule
• Agreement on scope and schedule
• Execution of required scope
• Demonstration of iteration scope
- This is more than a simple project led demonstration
- The business execute all of the User Stories and Test cases to
ensure the expected outcome occur
• Feedback is then solicited for new User Stories or test
cases that should be added to future iterations
• Clients are then asked to sign off that iteration

31. Implementation
• For some unknown reason the bulk of Package
Implementations still implement using the Big Bang
approach
• Very rarely are they implemented using the parallel or
pilot approach
• This adds a great amount of risk to the projects.

32. Contractual
• Include Contractual incentives
- profit sharing for finishing early
- Cost sharing for finishing late
- Ability and incentive to add additional business value
• Concept of trading User Stories

33. Logistics
• Lean Software Development recommends having the
project team and business co-located.
• For Package Implementations, I would also recommend
that the vendor should also be co-located.

34. Conclusion
• The principles of Lean Software Development are
applicable to all types of projects
• They are some areas of Package Implementation
projects that can benefit greatly. These are:
- Requirements Management
- Iterations
- Implementation
- Contractual
- Logistics

35. Questions?