The PeopleSoft Project Post Mortem
by Kathy Martucci, PMP:
Editor’s note: This is the fourth and final post in a series about implementing PeopleSoft projects. The other posts in this series are; Choosing PeopleSoft – Is it Right for Your Organization?, Initial Considerations of a PeopleSoft Project and Planning for Your Organization’s PeopleSoft Implementation.
Finally, the project is coming to a close and the team is conducting the lessons learned sessions. With any project, especially one as complex as implementing a suite from the PeopleSoft cadre of products, learning from someone else’s mistakes may be the difference between a successful implementation and a disaster. Let’s take a look.
All through the project, you take a “silo” approach allowing accountants (or worse yet, the implementers) to configure the General Ledger and Accounts Payable staff to configure Accounts Payables. Neither group knows what the other has done and why.
Lesson Learned: Never underestimate the effects and the power behind configuration. Take the time to learn how configuration settings “ripple” through PeopleSoft functionality. Force your integrator to explain these ramifications to you over and over again if necessary. Never stop thinking about tightly integrated modules.
Way-back-when it was too great an operational sacrifice to pull more than one person from a functional area to lend business savvy, re-engineer business processes, test the system, develop functional manuals and train others. Now there is a grand total of four subject matter experts to train and support 500 end users.
Lesson Learned: Cultivate multiple subject matter experts from the start of the project. No matter how much it hurts, plan a deeper bench from the very beginning. Do what it takes to make this happen. If you don’t make this sacrifice early, more work and pressure is heaped on a single pair of shoulders. As the project progresses, a single point starts to become a bottleneck that the organization cannot afford. And in the last few weeks before Go-Live, there is no time to bring new people up to speed to relieve that pressure.
All through the project, functional users have the expectation that any requirement spoken aloud translates to system functionality even if the requirement causes a costly software modification. When the system is delivered, their satisfaction level is directly proportional to the number of their requirements that have NOT been delivered.
Lesson Learned: Establish, communicate and religiously follow a process for requirements management and the software development life cycle. In it, clarify that all requirements are discussed and verified with the functional team and, once accepted as a project necessity, they are documented and reviewed with the technical team who respond with a technical solution and a time frame for delivery.
It is too much work to keep the regional offices involved, so once a month they get a status update at a general meeting which includes several other agenda items. As testing and training begin, none of the end users in the regions can participate nor do they understand how to do their jobs when the new system is implemented.
Lesson Learned: Over-communicate to and involve every stakeholder. A Communications Management Plan (which includes stakeholder identification and management), carefully considered and actively implemented, is essential to ensure people-readiness as the organization implements its new system.
Some team members have been attending status meetings and receive most project communications, but the lion’s share of the work is done by a handful of people (those four subject matter experts mentioned above, most likely). Now these less involved members must be pressed into service during crunch time, but they protest to the point where their management allows them to avoid the work necessary to reach Go-Live.
Lesson Learned: Ensure team members understand and embrace their roles and responsibilities from the very start of the project. Before the Kick-off meeting, document these roles and responsibilities and establish them as unbreakable ground rules. Communicate them verbally and in writing to the team and monitor the team’s involvement during the project so that members who are not actively participating may be considered for removal from the project.
And now, turn these valuable lessons learned over to the other project managers in your organization. Keep the tradition alive to contribute to project success.
What are some of the key lessons you have learned to ensure a successful implementation?
