1 / 19

Successfully Working with Consultants or Getting Help Without Losing Your Mind or Your Pocketbook

Successfully Working with Consultants or Getting Help Without Losing Your Mind or Your Pocketbook. University System of Maryland PeopleSoft Conference June 11, 2004 Ken Epstein, The Cedar Group. Kenneth.Epstein@TheCedarGroup.Com. AGENDA. Introduction Why consultants?

chuck
Download Presentation

Successfully Working with Consultants or Getting Help Without Losing Your Mind or Your Pocketbook

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Successfully Working with ConsultantsorGetting Help Without Losing Your Mind or Your Pocketbook University System of Maryland PeopleSoft Conference June 11, 2004 Ken Epstein, The Cedar Group Kenneth.Epstein@TheCedarGroup.Com

  2. AGENDA • Introduction • Why consultants? • Roles and expectations • What to do • What makes consultants crazy • What makes the project team crazy • Lessons learned • Your questions and suggestions

  3. Why Consultants? We are live, so why are we still thinking about consultants? • Adding new functionality • Solving a particular problem • Providing additional or specialized training • Doing an upgrade SHORT TERM & HIGHLY FOCUSED

  4. Considerations & justifications – Are you sure you need a consultant? Why Consultants? • Who will do the new work? Staff • Who will do the continuing work? • Deadlines Time Cost • Dependencies • Consultants • Staff Training

  5. Why Consultants? What consultants bring to your project • Skills • New, more objective view • Ideas from other clients • Not the first time to set up the software or solve the problem • Company colleague support • Global perspective

  6. Roles and Expectations • You own your system. • Decisions are yours. • Be involved. • The system serves the University community • Involve knowledgeable members of the community in decisions • Bring end users into the process early, and listen to what they say

  7. Roles and Expectations • Consultants are your support. They can • Train • Help solve problems • Offer advice • Guide you through pre-setup decisions and the setup itself • Do research and testing • Develop technical solutions • Consultant’s should not make policy

  8. Roles and Expectations • Balancing acts • How much is the consultant a member of the team? • Team work is consistently listed as one characteristics of successful projects • What meetings should the consultant attend? • How visible and available to the University community is the consultant?

  9. What to do • Define success for yourself, your team, and the consultant • What are your goals • Finish on time and within budget • Gain user community support • Support the software after the consultants are gone • Specific short-term objectives • What are your criteria for success? • How will you know when you are finished?

  10. What to do • Build a plan and use it • Timelines & milestones • Staffing, including vacation time • Training • Community involvement & roll-out • Acceptance test requirements • Who decides? Beware of delays waiting for an administrator to say OK • Meet regularly to update status

  11. What to do • Beware of scope creep • Communicate, good & bad news • Bring issues – project and personnel – into the open quickly and resolve them • If the relationship is not working, get help • “Effective problem resolution may be more important than a flawless project.” • Maintain a formal issues log • Insist that everyone use it • Review the status of issues frequently • Document decisions • Issue resolution • Completing milestones • Be careful of junk documentation

  12. What to do • Be sure you and your staff are accessible • Ideally you and your consultant should be physically close to one another so that you can really work together • Tell your consultant about • Documentation standards, format, storage • Shared network drives • Campus politics and culture • Who to contact for • Technical support • Functional infrastructure • Policy

  13. What makes consultants crazy • The little things that are not done or that are “secrets” (and that waste time and your money) • Network logins and passwords • Local email • PeopleSoft logins and passwords to appropriate instances (including 2 tier with write access to development) • SQL access to the database (write access to development) • Project SOP – Documentation, shared folders, protocols for posting materials • Introductions and access to people, including tech support • Computers with required software • Telecommuting – VPN • Access to offices - keys, clearance with security, parking University calendar, including holidays

  14. What makes consultants crazy • Don’t blame the consultant because PeopleSoft is NOT your legacy system • “We have been customizing our legacy system for 20 years. We cannot expect the new system to fit as well right out of the box.” • We do not expect you to always take our advice, but if you don’t like what we have to say, let’s discuss why. The consultant may bring things to your attention that you did not know. • Last minute extension decisions

  15. What makes the project team crazy • Consultants who think they know more about our institution than we do • Consultants or salespeople who promise more than they can deliver • Consultants who get distracted with some interesting, perhaps related, often technical, point (This is an insidious type of scope creep.) • Factors outside the project team’s control (budget, administrator or faculty indecision, internal politics)

  16. Lessons learned • Be prepared for users who do not want to be empowered • Knowledge transfer requires you • Never stop communicating • Successful implementations are those that help you do your business better

  17. Your questions and suggestions • Your • Questions • Ideas • Success Stories • Horror Stories

More Related