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

3

4

5

• This slide provides a list of the key potential advantages for packaged software.

• Important to note that these advantages are not guaranteed.

6

7

• 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

•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

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

•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

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

13

14

15

• 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

• 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

• 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

• Directing – telling others what to do

• Coaching – instruction others

• Facilitating – coordinating input from others

• Supporting – providing assistance where needed

19

• 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

• 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

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

• 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

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

• 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

•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

• 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

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

•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

• 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

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

31

32

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

•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

• Only focus on the information you need to directly support the project scope.

• First understand the business then the software.

35

36

37

38

39

40

41

42

43