Is Oracle Projects PRM a Good Fit?
First, there is a limitation that is a showstopper for many: PRM does not allow the assignment of resources (aka, people) at the task level. So, if you need to plan your resources against specific tasks, you will need to use a more detailed tool such as Primavera or even Microsoft Project.
First, there is a limitation that is a showstopper for many: PRM does not allow the assignment of resources (aka, people) at the task level. So, if you need to plan your resources against specific tasks, you will need to use a more detailed tool such as Primavera or even Microsoft Project.
If you can live with planning resources at the project level, then the next challenge is cultural. Many organizations handle resource management via spreadsheets or custom applications. Your team will have to accept the idea of doing PRM within Oracle. It may sound simple, but the next point illustrates why it can be much more difficult than it sounds.
Next, your organization may require some revamping. There are three steps to PRM: 1) Creating requirements against a project, 2) Nominating candidates to fill those requirements, and 3) Filling the requirements with selected candidates. This normally takes 3 types of managers to accomplish: Project, Resource, and Staffing. Project Managers will typically do step 1 (and sometimes step 2). Resource Managers will do step 3. Finally, Staffing Managers commonly oversee the whole process, but can perform any of the steps if necessary. If your organization doesn’t clearly define these roles prior to rolling out PRM, the system may never be embraced as a must-have tool.
Another aspect of PRM that may require organization changes is the way jobs are organized. An important concept to grasp is that project requirements are named after roles. When you create a requirement, you select from a role list. This list contains all of the potential roles that could be needed on your projects. Some clients choose to make the role list match 1:1 with the jobs in Human Resources (HR). Others use a many-to-one match. I personally prefer the 1:1 match for simplicity, but that may not work for everyone. Setting up the project roles can take a lot of time because customers often use this time as an opportunity to clean up their HR jobs.
An often overlooked key to a successful PRM rollout is visibility. PRM deals with a lot of data and the ability to manage requirements and assignments efficiently hinges upon the ease of which managers can see the big picture. Availability, Overcommitment, and Utilization are three elements that are commonly monitored. These are handled through a combination of self-service pages and Discoverer reports. In fact, Oracle relies on Discoverer to provide just about all of the daily tools that managers will need to effectively use PRM. If your organization doesn’t currently leverage Discoverer, plan to spend a large amount of time developing custom reports in alternative tools.
Key Challenges
The biggest hurdle in a PRM installation is the creation and assignment of competencies. These are used to help select qualified employees for a given role. To allow this logic to work, each role should have a list of default competencies to be matched against the competencies of each employee. For large organizations, creation of these associations can take weeks. Loading the data can be quickly accomplished by a data loader program, but getting consensus among all business groups on the data is the hard part. This is a process that should kick-off as soon as the PRM installation starts so that it can carry on in the background and be ready by the time testing and demos begin.
Another key setup is Organization Authority. Start off by assigning Project and Resource Authority for all child organizations to your Staffing Managers. That will allow them to monitor and control the entire enterprise-wide PRM process. Project Authority identifies what project organizations they will be able to see open requirements for. Resource Authority enables them to control resource assignments in the organizations listed. Next, assign Project Authority to the Resource Managers. This will ensure that they only see open requirements for the project orgs they are responsible for. You don’t need to assign Resource Authority for Resource Managers; it defaults based on their supervisory assignments in HR. Project Managers do not need Organization Authority.
So, now that we have looked at the basics of setting up a PRM installation, let’s see what a typical installation might look like. Out of the box, the functionality is pretty simple:
1) Create Requirements
2) Nominate Candidates to fill those Requirements
3) Select and Assign Resources to the Requirements
Taking PRM to the Next Level
In many instances, this is the end of the functionality. We have found and assigned people to our project. However, maybe we want to have a more complete solution that actually ties the financial plans and workplans together. While Oracle doesn’t support the integration of PRM with the financial plans, this can be accomplished with some minor customization.
Let’s examine a more complex workflow involving multiple departments working on the same project:
1) Sales creates a high-level bid (financial plan)
2) A project analyst turns that bid into a budget (another financial plan), complete with all resource requirements (project roles)
3) When the project status changes to “Approved”, a program pulls the labor resource requirements from the budget (financial tab) to PRM (resource tab)
4) The Project Manager reviews the resource requirements and adjusts the timeframes to fit the project schedule
5) Staffing and/or Resource Managers fill the open requirements
6) Once the resources and schedule are set, the Project Manager runs a program that does two functions: a) It brings the named resources to the workplan, and b) it brings the non-labor resources from the budget to the workplan
7) Actual costs hit the project via the workplan, which automatically tracks progress
8) On a monthly basis, a program creates a forecast (financial plan) from the workplan
The concurrent programs described in steps 3, 6, and 8 are all based on Oracle’s Activity Management Gateway (AMG) API. If the work breakdown structure in the workplan contains multiple tasks, the program in step 6 can use the task structure of the budget as a reference. (Of course, this assumes that the Financial Plans and Workplan are using a Fully Shared Structure.) However, since PRM doesn’t work on the task level, there could be conflicts if the same person is assigned to the same budget task in more than one role.
One of the keys to implementing this approach is careful setup of the Planning Resource Lists. In this example, the resource list used in the bid and budget contains jobs (aka, roles), while the list used in the workplan and forecast contains people by name (aka, assigned resources). This allows the plans to be used at the level of detail required as the project evolves. For example, early on in a project, we don’t know who will be working on the project, but we have some idea as to what roles will be required. We make our bid and budgets based on this level of detail. Once the budget and roles are firmed up, we can start assigning resources (people). We’ll use these named resources for the remainder of the project and so they will show up in the workplan and financial forecasts.
Migrating to PRM
The AMG API can also assist in moving the client from legacy systems or spreadsheets to PRM. Commonly, there could be a lot of data massaging that needs to take place because things like project names and people names don’t match those stored in Oracle. Plan to spend a significant amount of time on these tasks. Make the client responsible for this work, but be prepared to support them with reference data to compare against.
It is essential that you have universal acceptance from your user base before adopting PRM. This generally involves Staffing, Resource, and Project Managers. But it also may involve the resources themselves. For example, since assigning all of the competencies to each person would be a huge task, some organizations find it easier to let the resources themselves specify their own competencies (from a predefined list). Oracle simplifies this task by allow the user to pre-populate their list with defaults for their job from HR. Then, they can simply identify their skill level for each competency and add new ones as required. Of course, all of these setups must be confirmed by the person’s resource manager before they are usable in PRM.
In every organization, there will be a core group of users who are more skilled at using the system than others, even in a new installation. Be sure to leverage these“Super Users” as mentors and trainers. Encourage these users to lead both demonstration and test sessions with the new software. This will increase self-reliance and can reduce barriers to user acceptance.
Hopefully, we have provided some insight into the keys to a successful PRM rollout. Oracle’s direction for PRM in Fusion and beyond relies more heavily on Primavera, but I hope we have shown that there is still some life left in the legacy product.
No comments:
Post a Comment