Best use of Consultantsin a PM Implementation

Getting the best ROI for yourconsulting dollar.

Jim McMahonShell Oil Products US

Session Code 3608

Background:

Originated as joint venture of affiliates of Shell Oil Company and Texaco Inc.

Combines the major elements of the the two companies’ former Western and mid-Western U.S. refining and marketing businesses and their nationwide transportation and lubricants businesses

Began operations in January 1998, Shell took sole ownership February 2002 

Headquarters: Houston, TX

President & CEO: Rob Routs

Financial (2000):

Gross Revenues: $50.0 billion

Total Assets: $10.0 billion

Capital Expenditures: $579 million

Shell Oil Products US Fast Facts…..

Currently supporting two main Production environments:

1) traditional 4.6C GUI Environment (live since 1998).Upgraded from 3.1H in early 2002; includes IS-Oil. 4,000+ named users, average 1100 concurrent

2) 4.6B mySAP.com Portal environment (live since 2001); includes approximately 300 users primarily using a handheld device for PM/QM transactions

SOPUS SAP Fast Facts

Help lay the groundwork for those just starting out

Determine if there is a need for a workgroup/ roundtable discussion for November Group Meeting?

Possibly generate a “white paper”?

Goals for today:

Click to add title

Why do we hire consultants?

1) Perform technical tasks which require skill sets unavailable internally.

2) Assist internal staff with new tasks.

3) Act as advisors for current best practice.

4) Deal with tactical staffing needs

5) Free up internal staff for “business specific” tasks

6) Avoid complications of training internal staff to perform tasks specific to the implementation/upgrade.

7) Help train your ongoing support team.

Who should we hire?

Click to add title

1) Depends on the project; like any other hiring situation, sometimes you want experience, sometimes entrylevel is acceptable. If it’s leading edge technology,you may both be learning…….2) Maybe no one; is there value in permanentlyhiring or internally training personnel you can retain? 3) Get the best you can afford, but make sure you can

afford what you get4) Leverage the experience of your industry peers (just a

suggestion….fellow ASUG members?). Research thoroughly; the bigger your company, the easier it is to miss someone’s experience with similar projects.

.

What should we expect them to do?

Click to add title

1) Create complete documentation of each task they perform, including detailed narratives of configuration.

2) Accept and comply with local requirements for system discipline, security and access with as little whining as possible.

3) Make sure they each feel personally responsible for the delivery of the project, on time, on budget, and in scope.

4) Provide detailed instructions about how to support any custom or non-standard code or configuration.

5) Provide objective feedback about the scope of work; there are some places projects shouldn’t go, and their experience should help you avoid the “tarpits”.

6) Respect and cooperate with the support staff.

What should we not expect them to do?

Click to add title1) Know your business better than you do.

2) Improve your existing process without changing how you do things.

3) Know what you want without being told…

4) Convince SAP to change things for you.

5) Handle your “problem children” for you.

How do we best manage their usage?

Click to add title

Perform a good gap analysis of your staffing needs during and after implementation, and assign the consultants based on this analysis. Use for “core competencies”; supply your own admin, word processing, timekeeping, administrative tasks, etc. Make certain the consultants understand their responsibility to help craft and train the support organization, and that this may involve training and support of business personnel. Document everything in a common repository!!! Maintain flexibility by dividing your project into “stand alone” stages (particularly any business processes you change or add). Make sure to make them a real part of the team, and make sure the consultancy leads understand this as well (same rules!). Firm up transition plan to support very early in the process; towards the end, they should be “support for support”.

Things they wish you would do….

Click to add title

1) Have a clearly defined point of contact on the project to approve changes and additions; this should be one person or a small group.

2) Provide an experienced project manager who is familiar with the particular business involved; this individual, along with a full time representative of the business, should share responsibility with the consultant’s project manager to keeping thing moving, and “in scope”

3) If the implementation includes changes to local business processes, announce them before the project starts. Don’t use the project as cover for unpopular business process changes!!!

4) Don’t make the consultants fight your change management battle, unless they are change management consultants; a representative from the business is essential to your team, and should own this piece.

5) Allow the consultancy to complete the original scope of work before adding “Hey, do you think we could…” items.

Are you a good client?

Click to add title1) respect their experience and knowledge- don’t hire consultants, and

then constantly argue with them or ignore their suggestions.2) Take responsibility for project decisions- don’t blame the consultant

if a decision you made with their input isn’t well received. As Colin Powell says, “leadership means sometimes upsetting people”.

3) Allow consultants to be an equal part of the project- don’t allow different rules for members of your team and members of the consultants staff; strive for equal levels of accountability and responsibility for both groups, but remember they have a clearer focus, and may not understand your “non-project” responsibilities

4) Listen…. don’t just let them talk…- take full advantage of their perspective; sometimes things are not exactly as you assume, particularly how well existing process are being followed inside your own business. People in your business may be much more forthcoming with a consultant than with your project team; if this happens, avoid becoming defensive and argumentative.

When (and how…) should they leave?

Click to add title

1) Plan the exit strategy early - clearly define the milestones that indicate The time has come for them to go.

2) Include a formal transition to your support organization –in many cases, the project team, not the normal support organization, will be responsible for end user support at first, particularly if it is an “incremental” rollout versus a “big bang”. Make plans for a transition, since in many cases, the entire project may be new to the support organization 3) Incremental departure- don’t let the project team departure happenall at once. Spread it out over several weeks, at least.

4) Disaster Plan- Design in multiple exit points if there is any possibility the project could be interrupted or cancelled based on incremental progress. If the powers that be determine for whatever reason the project no longer makes sense, you don’t want to deal with ongoing obligations. Each individual component should (in a perfect world) deliver value on it’s own.

Thank you for attending!Please remember to complete and return your evaluation form following this session.

Session Code: 3608Contact Info:Jim McMahonShell Oil Products USjlmcmahon@shellopus.com713-277-7748