1. The objectives are to share packaged software implementation strategies and challenge key players. 2. Key factors that impacted past results include using the wrong methodology, late validation of requirements, and focusing on software rather than business results. 3. A radical change is needed, not just incremental changes, to improve success rates for packaged software implementations.

1. My objectives for this presentation are
1. Share implementation strategies for maximizing the packaged software investment
2. Challenge key players for packaged software implementations
1

2. 2

3. 3

4. 4

5. 5

6. • This slide provides a list of the key potential advantages for packaged software.
• Important to note that these advantages are not guaranteed.
6

7. 7

8. • Majority of packaged software industry is ERP.
• Last bullet point is a quote by M.H. Martin, “An ERP Strategy”, Fortune, February 1998,
pp. 95-97.
Transition: So now let’s discuss some of the key factors that brought about these results.
8

9. •Quick Fix – when ERP arrived there was no methodology. The industry used what was
readily available (Waterfall).
• Late validation – problem with Waterfall methodology.
• Packaged software makes for a very expensive custom solution. Rapid delivery of
functionality and ROI depends upon upgrades.
• Software supports business results – it does not generate business results.
9

10. 10

11. Given the success rate we need a radical change – not an incremental change – to
improve success rates quickly.
Transition: So how do we change the game?
11

12. •People and Business Processes are more important than technology.
• One methodology (discipline) can not effectively address all the components of a
business solution. Example: Look at the rise in adoption regarding Organizational
Change Management and Business Process Management.
• We need to have an implementation approach that takes into consideration the key
reasons why we selected packaged software in the first place.
Transition: Let’s now speak to the key strategies that we can employ to change the
game!
12

13. Now lets briefly discuss the 10 principles or strategies for packaged software
implementations.
13

14. 14

15. 15

16. • Too often we fixate on software features and not the end result. Ex. Running a report
is not a business result.
• People have the greatest impact on business results.
• Challenge to Project Managers – how can you lead a business solution implementation
if you do not understand the business.
• Odds are that the customer’s existing business model is not 100% lean (efficient) and
100% effective (quality). Therefore, it’s fair to say that you will find requirements that
support non-value-add business activities and business results. The strategy here is to
focus on the “critical path” requirements that support value-add business results and
not waste time/effort on capturing all requirements then filter during fit/gap. The later
approach is reactive and is time consuming.
• Must be solution-focused, not software-focused
16

17. • The more your partner understands your business model and environment the more
relevant advice they can provide.
• Best practice is to ask the customer to conduct formal training session for your
implementation partners. One time – every one in the room. Customer leads.
• Knowledge Transfer -> In a general, a person has to hear something 3 times before
understanding is created.
17

18. • Educate: Help people to see the big picture and the impact they will have. Every one
likes to matter.
• Enable: Provide the training and the mentorship needed.
• Empower: Foster ownership and trust
• Celebrate: Success.
18

19. • Directing – telling others what to do
• Coaching – instruction others
• Facilitating – coordinating input from others
• Supporting – providing assistance where needed
19

20. • Use prototyping for gathering requirements – especially when the requirements are
evolving, modeling for validating requirements.
• Requirements management: Requirements gathering and Requirements validations.
• Iterative approach: Best practice is 3 iterations. (Standard, Variation, Gap).
• Hands-on experience build confidence.
20

21. • Use prototyping for gathering requirements – especially when the requirements are
evolving. Use modeling for validating requirements.
• As you move from prototyping to modeling activities the implementation should
refine focus from multiple options to a single option.
• Project team focus (i.e. what software features will be implemented) is what
accelerates a packaged software implementation.
21

22. Business solution modeling consists of the following activities:
• Plan – defining what business scenarios need to be modeled/validated
• Prepare – setting up the modeling instance to support modeling of the business
scenario(s) in the packaged software
• Model – executing the business scenario(s) in the packaged software
• Analyze – compare against expected results
• Decision – determine if you need to perform additional iterations or move forward
with Fit/Gap
22

23. • Methodologies are not the issue – it’s how they are applied that are the issue.
• Quality Management and Business Process Management are typically considered a
Phase N initiative. Need to address support strategy during the implementation
because a viable solution is a manageable solution.
• The secret is to integrate the disciplines in such a way as to leverage their strengths.
23

24. Key factors to consider when selecting and applying a methodology.
• Project size: project $ and organizational impact
• Personnel capabilities – are project team members experienced and knowledgeable.
• Risk: Both Business and Pure Risk. Is the customer risk adverse?
• Business/IT relationship: Partnership, Do the parties trust one another? If trust is not
present then a heavy-weight methodology may be the best fit.
• Business model dynamics: If there are several evolving requirements (ex. Revenue
generating process) then a more iterative, agile approach is required.
• Whatever method you select you must address the assumptions associated with the
methodology
24

25. • PM methodology from PMI is across all project types. SDLC may have more specific
PM activities that can complement.
• Majority of SDLCs focus on addressing requirements via software. There are some
thought leaders (SEI) that are addressing via a new methodology – EPIC. Evolutionary
Process for Integrating COTS-based system.
• OCM: Gap analysis should produce Functional, Technical, and Organizational
Requirements
25

26. •Because of the richness of functionality, the “toy box effect” can take over. Users see
all the functionality available and suddenly they want it now. The scope can grow out of
control.
• Unless there is a mature trusting relationship between Business and IT then it is very
hard for IT to lead with a technology solution. Business may feel confined by
technology.
•Reduce risk: you will have enough organizational impact to manage with the install of
the packaged software. The more change to manage the more time it will take.
•Reduce risk: Evolving requirements can be very challenging and time consuming – this
is true when it’s the first time for the business to perform the activity.
26

27. • Software changes will always be required. The trick is to identify the smart software
changes that add real business value.
• In very simple terms we can look at requirements as needs and wants. You want to
have a requirements gathering approach that only focus on the needs.
27

28. Requirements Driven: Define business requirements independent of the software
Solution Driven: Define business requirements via the software
Configuration Driven: Define business requirements via current software configuration
The more chances you give yourself to define requirements the better your chances for
success.
28

29. •There will always be a gap between business requirements and packaged business
software
• Business requirements will support both value-add and non-value-add activities
• The key is to focus on software changes that create competitive advantage or material
efficiencies.
• Better chances of getting enhancements incorporated into packaged software – which
would reduce TCO.
29

30. • Executive sponsorship is only the beginning. End users and the business process
owners will have lasting impact on success.
• If the expectation is custom software then it will be very difficult to be successful.
• People are the most flexible, adaptable component of a business solution.
• A take it or leave it approach will not foster adoption. Understand where and where
not to make software changes.
• Communication plan and stakeholder analysis next to take it to the next step with a
marketing plan. You need to change the perception!
30

31. Be practical: you will have to give up something to get something.
31

32. 32

33. Role Definition
A business solution architect is a functional resource that has the ability to participate
across all functional areas of a business solution. An implementation partner should
provide a business solution architect that has participated in several implementations of
the targeted business solution. The business solution architect should have an
understanding of both the business and how the packaged software supports the
business. Most important is that a business solution architect must be someone that is
able to lead and persuade others in their recommendations.
Key responsibilities for the business solution architect include:
• Identifying and addressing conflicting business requirements.
• Identifying and addressing conflicting packaged software configuration decisions.
• Performing knowledge transfer with customer to build a business solution architect
capability internally.
• Defining a business process management framework for the customer to leverage
moving forward.
33

34. •Information supports business value but it does not drive business value. Decisions
drive business value.
• Knowledge generation is about providing the information in the appropriate context to
support an informed decision.
34

35. • Only focus on the information you need to directly support the project scope.
• First understand the business then the software.
35

36. 36

37. 37

38. 38

39. 39

40. 40

41. 41

42. 42

43. 43