Forward Momentum: Delivering Results

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?

By Kathy Martucci, PMP

Editor’s note: This is the third post in a series about implementing PeopleSoft projects. The second post on initial considerations for PeopleSoft implementations can be found here. 

It’s no accident that there are two processes in Project Initiation and twenty in Project Planning according to the Project Management Institute.  Many organizations make the costly mistake of diving right in because there is “no time to plan”.  On the contrary, most projects fail in the beginning as planning efforts are sacrificed for “action”.

In spite of the organization’s impatience, it’s your responsibility as the Project Manager to educate senior management in the advantages of compiling a thoughtful and reasonable plan before jumping into project execution.  

What are the key points to consider when planning a PeopleSoft implementation? Here are some factors to consider: 

1. Scope Definition:  Even if the organization compiled the world’s best Request for Proposal for a suite of software, the process of reviewing and verifying those requirements (and discovering new ones in the process) is absolutely essential for the proper scope definition of a PeopleSoft project. Especially if more than one module is to be implemented, requirements must be considered in light of a tightly integrated system. For example, configuration of the budget and general ledger modules can have a substantial and often irreversible impact on the sub-modules of Accounts Payable and Accounts Receivable. It may be worth dedicated PeopleSoft training for the project team and subject matter experts to increase their understanding of the system in order to articulate those requirements more definitively. 

2. Work Breakdown Structure:  Once the requirements are fully understood and gaps between what is and what should be are clearly identified by your seasoned PeopleSoft integrator, the WBS can be crafted with a solid foundation. However, software configuration and modifications to bridge gaps are only two out of potentially hundreds of other work packages including the elements of communications, stakeholder management, quality, risk management, hardware procurement and set up, testing, and training. 

3. Project Schedule:  Once scope is fully defined and a solid WBS is in place, employ the best possible experts to define, sequence and estimate required resources and time for each work package. When you develop it to your satisfaction and present it to management, resist the temptation to meet their often unrealistic expectations to implement such a game-changing system within their timeframes. If the timeframe doesn’t meet with their approval, craft at a scope that will. Even though the notion of the Triple Constraint (Time, Scope and Cost) is losing favor according to PMI, it is still true in concept. Something’s gotta give!

If the above considerations aren’t daunting in and of themselves, that’s not all. There are seventeen additional processes (according to PMI, that is) that the PM should at least consider before Execution begins in earnest.  Again, it is your duty to lead your organization through these processes even while senior management is questioning what your team is doing all this time.

How will you convince your senior management to invest serious time and effort in the planning process?

By Kathy Martucci, PMP

Editor’s note: This is the second post in a series about implementing PeopleSoft projects. The first post on whether PeopleSoft is right for your organization can be found here.

Your organization just purchased over $1 million worth of PeopleSoft software licenses and, even if it’s never implemented, contractually owes Oracle for hundreds of thousands of dollars in maintenance fees annually. 

NOW WHAT?

As we discussed in the previous blog, any single suite of PeopleSoft (two examples are Supplier Chain Management or Human Capital Management) is a monstrous challenge to implement. And implementing more than one is the definition of an extremely complex project. Talk about replacing all your current systems with PeopleSoft is just crazy talk. 

There are important decisions to ponder and determine before cracking the shrink wrap on the software and diving in: 

1. Hardware infrastructure and software architecture

• How many servers of what size(s) does the organization require to offer the type of performance necessary?
• How many end-users will there be, how many batch processes, how many and what type of transactions? 
• What about redundancy? Need 100% uptime? Automatic failover?  Disaster recovery plans?

Fortunately, Oracle has an entire department dedicated to assisting organizations in sizing their hardware systems for optimum performance. Take advantage of them. Do not underestimate the need for an extremely large and robust infrastructure. 

2. Project model

What type of resources and how many are required for the project? It’s a safe bet that, even if your organization has several competent Oracle database administrators and an overabundance of programmers (yeah, right), the organization doesn’t already employ experienced PeopleSoft implementers. That means a competitive bid for outside systems integrators if you’re in the public sector and some heavy duty due diligence about who to hire even if you’re not. Some of the categories of resources necessary are: 

• Systems engineers
• PeopleSoft functional implementers
• PeopleSoft programmers
• PeopleSoft security experts
• PeopleSoft integrators
• Business analysts
• Organizational subject matter experts for each functional area to be implemented
• Testing experts
• Project managers
• Training and communication staff

And that is just the beginning.

3. Project Methodology

All the PeopleSoft implementers use basically the same project life cycle methodology – they just give it their own special brand name in order to differentiate them from their competitors.  The organization should thoroughly understand the project life cycle and the inputs, strategies and outputs of each and every step along the way. Then and only then will the organization and not the contractor be in charge of the project and its processes. If the project management maturity of the organization is relatively low, the very best strategy is to hire a seasoned project manager early in the process.

Conclusion

These are only three out of dozens of potential challenges and questions to be considered. 

What will be your organization’s first steps now?

By Kathy Martucci, PMP

I have been involved in PeopleSoft implementations for over 10 years – before the product was web-enabled, in fact. Overall, the product is extremely robust and offers literally thousands of functional threads to its customers. Some of the business areas addressed by PeopleSoft applications include: 

• Financials
• Human Capital Management (read Human Resources)
• Payroll
• Customer Relationship Management
• Campus Solutions

Each of these major areas are comprised of several sub-modules (e.g., Financials = General Ledger, Budget, Accounts Payable, Accounts Receivable, etc.)  that are so complex that sales reps, sales support associates, and implementers generally specialize in one sub-module. Herein lies one of the biggest challenges of selecting this software. It can be so overwhelming as to render mere sales calls and demos practically useless since these discussions barely scrape the surface of what is really happening within the software. Given that fact, it can be difficult to determine the real effort behind an implementation and how your company’s business processes and employees will be impacted.

Having said that, how does an organization know if PeopleSoft is right for their corporation and their culture? What are the key factors and business drivers leading an organization to the purchase and implementation of one of the most powerful software suites in the world?

For simplicity’s sake, let’s go with one suite and say a mid-size company is going to replace its backend financials system. The old system was “home grown” and has evolved over the last 25 years. There are no labor unions and the corporate culture is fairly agile.

Some of the questions to be answered include: 

1. Is there a strategic plan for the company? If so, and if the plan necessitates new systems to support the future initiatives, are the projects prioritized and budgeted? Is there an Enterprise Technical Architecture Plan? How do the two relate? Technology for technology’s sake alone is rarely the right path to follow.
2. What is the maturity level of project resources, especially project management, in the organization? Even if the company is capable of paying substantial sums for an outsourced project team, there is no success factor more critical than having an in-house project manager (and, preferably, team) who know the business and can successfully support the project throughout its life cycle.
3. What technical resources does the organization already have? Is there a robust network, experienced database administrators (preferably familiar with Oracle), programmers, and skilled business analysts?
4. Can the organization afford to allow the most knowledgeable staff (who know the business processes and the current systems) to work on what is sure to be a multi-year project (in spite of what the Oracle sales team is telling you)?
5. What business sector does the organization inhabit…public, private, not-for profit? Once upon a time, PeopleSoft offered a public sector product and a commercial sector product. Over the years, these two products have morphed together. Many public sector organizations conduct their accounting on a cash basis (PeopleSoft doesn’t) and fund accounting (with a lot of attention paid to configuring the General Ledger (GL), this can be done).
6. Does the chart of accounts need to be re-defined? This is a major undertaking even before any technical consideration can be given to the GL. However, even though project team members may understand the business’ accounting and financials, they also need to have a deep understanding of PeopleSoft General Ledger and Commitment Control (budgeting) or most attempts to define a new chart of accounts and properly define budgets takes several months up to years.
7. What is the status of the current data in the financial system? Does it need substantial clean up before conversion can be defined? If so, this is also a parallel, separate project that will absorb project resources.
8. What is the company’s readiness quotient to re-engineer business processes? It surely doesn’t pay to undergo what could be a $20-50M project just to offer a web-enabled version of the existing financial system.

The above represent a tiny fraction of the questions that organizations should be asking themselves as they contemplate a PeopleSoft implementation. Frank, open answers to the questions and a realistic approach can only be advantages going forward. 

In addition to formal due diligence, one of the best ways for an organization to thoroughly understand the road map ahead is to connect with similar organizations that have completed an implementation. Oracle may not be the best place to get candid conversation; however, there are several active user groups and Oracle hosts a convention every fall where users congregate and are only too happy to relate their stories, good and bad. It is absolutely essential to mine these resources for lessons learned. 

How will you assess your organization and connect with other users?