Archive for the ‘- Kathy Martucci’ Category

Planning for Your Organization’s PeopleSoft Implementation

Posted on January 9th, 2012 in - Kathy Martucci, Constraints, IT, Leadership, Project Management, Schedule, Scope, Work Breakdown Structure (WBS) | No Comments »

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?

Initial Considerations of a PeopleSoft Project

Posted on November 7th, 2011 in - Kathy Martucci, IT, Leadership | No Comments »

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?

Choosing PeopleSoft – Is it Right for Your Organization?

Posted on September 6th, 2011 in - Kathy Martucci, IT, Leadership | No Comments »

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?

Getting to Know You – Project Stakeholder Management

Posted on June 22nd, 2011 in - Kathy Martucci, Project Management | 2 Comments »

By Kathy Martucci, PMP

You’d swear that you and your team are doing everything possible to create buy-in, communicate to and assist your stakeholders.  Your stakeholders think you ignore them, hide things and hinder their progress. What is going here? Is this a matter of perspective or fact?

Good stakeholder management may be in the eye of the beholder, but it’s a critical success factor in any project large or small. So, if your customers perceive (and their perception is reality!) that you and your team are doing a less than stellar job of communicating, what can a conscientious PM do?

Stakeholder identification is key. All stakeholders, even those deemed “observers” and not active participants, should be included in any stakeholder involvement plan. Granted, the observers may not have as much influence on the project, but they are part of your community nevertheless. They must be considered.

So who does exert the most influence? That person is not necessarily highest in the organization chart. Maybe it’s the person who is most vocal and will stop at nothing to get their point across and make a statement regardless of your project objectives, schedule or budget. You know who I’m talking about – you all have THAT person’s face in your mind right now!  Analyze your stakeholders and understand how each general grouping (executives, supporters, killers, PITA’s…etc.) learns, communicates and can contribute to the success of the project.

And now the question every stakeholder has on their mind: “What’s in it for ME?”  Project politics at its best uncovers and understands the concerns of the stakeholders and does not attribute every negative or seemingly obstructive statement to a bad attitude.  Does the project provide real benefits whether they are of a personal or corporate nature?  If so, what are they in terms the stakeholder can understand and fully embrace?

While addressing those concerns based on fact, there are stakeholders that whine, complain and otherwise make your life miserable without a sound basis for their complaints.  When pressed, they cannot articulate anything you can do to assist them or allay their fears.  Many times I have been tempted to just ignore “bad” stakeholders.  Perhaps they should get less attention, but they are stakeholders no matter what and it’s our job to handle them.  Even acting as a sounding board (if you can stand it) may be helpful.

One critical factor in stakeholder management that is often overlooked is periodic review and evaluation of stakeholder identification, classification and methodologies to engage as the project evolves. Especially important in longer projects with significantly shifting scope, a re-evaluation may be a sound foundation to continuing success of the project.  Getting to Know You is an iterative process!

What have you done to make project stakeholder management work for you?

Forward Momentum Logo
Forward Momentum Logo