Loading in 2 Seconds...
Loading in 2 Seconds...
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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
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
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
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
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
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
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
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
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?
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?
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
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
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
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
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
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)
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
Your questions and suggestions • Your • Questions • Ideas • Success Stories • Horror Stories