Avoiding the wall of schedule-based resource management
enterprise pipeline management in a moderately PM-mature company
We suspected we had more new product projects on our plate than we could fully staff, but we didn't have the data to know for sure. We needed to track project assignments and staffing requirements for 8,000 people around the world and hundreds of projects. But we didn't have several years and millions of dollars to license, configure, deploy and train everyone on high-end enterprisewide project scheduling software. So we created our own database and web interface to track this information.
High-end scheduling software should theoretically provide organizational resource management ability if you have fully resource loaded schedules for everyone in the organization. But that's the “wall” referred to in the title of the paper: developing fully resource loaded schedules for everyone. While that may be desirable as we increase our maturity, the reality of the situation is that our organization does not yet have the project management maturity or infrastructure to do that.
You may be thinking, but separate high-level resource data isn't integrated with the scheduling software. Yes, that's true. But we concluded that knowing assignments and staffing requirements at a project level provides 80% of what we needed for 20% of the cost. Someday we may be able to achieve complete closed-loop task-level scheduling for everyone, but in the meantime we have sufficient information to make good pipeline capacity management decisions.
Our software, named RAFT (Resource Allocation and Forecasting Tool), is an Oracle database with a web user interface that is available to our global organization of 30,000 people. Of these, 22,000 are in operational (manufacturing) work, and about 8,000 are in project-oriented organizations developing new products. We are currently tracking project assignments for 6,400 people, and the number is steadily growing.
Resource Management Maturity Model
We have observed seven maturity levels in resource management:
1. Ad-hoc decentralized tracking of project assignments by person
2. Centralized tracking of project assignments by person
3. Centralized tracking of project staffing needs
4. Balance total project needs at organizational level
5. Balance skill needs across projects
6. Centralized task level scheduling for all resources
7. Individual feedback on task status (closed-loop)
An organization can quickly achieve benefits from the processes established at the lower levels and at a reasonably low cost. Higher levels become progressively more expensive and require much higher maturity from the users and the organization. Each successive level requires information from the previous level. Theoretically, Needs (Level 3) could be tracked before Assignments (Level 2), but in practice organizations almost always end up doing Assignments first.
1. Ad-hoc decentralized tracking of project assignments by person—This is the starting level for most organizations. Various supervisors develop their own spreadsheets for tracking project assignments. Some of these spreadsheets can be quite elaborate in their capabilities and they work well for small organizations under 100 people (Strevell, 2000). Spreadsheet-based solutions have several difficulties: (a) configuration management issues make it more difficult to roll up data to a higher level, (b) multiple people can't access the data at the same time, and (c) it's difficult to share resources across multiple organizations.
2. Centralized tracking of project assignments by person—A central database is used to track project assignments by person. This resolves most of the difficulties encountered in Level 1. But without project staffing needs, we don't know if projects are fully staffed.
3. Centralized tracking of project staffing needs—A central database is used to track project staffing needs. The ability to track both assignments (Level 2) and needs allows an organization to ensure priority projects are fully staffed.
4. Balance total project needs at organizational level—The infrastructure in Level 2 and 3 provide the ability to ensure that we don't commit to projects unless we have sufficient resources to staff the projects. We simply ensure that available resources equal or exceed total project staffing needs. We don't know yet if we have the right skill mix. But even without knowing skill requirements and availability, we can still do a reasonable job of capacity management. If the organization generally has the right mix of skills in their workforce, this balancing gets them reasonably close. In addition, many team members have more than one skill and can meet other skill requirements.
Exhibit 1. Resource Management Maturity Levels
5. Balance skill needs across projects—We take balancing one step further and ensure that each project has the right mix of skills. This is much harder than just balancing total number of bodies. It is easier if all the divisions and shared resource pools use the same skill list. But getting everyone to agree to a common skill list can be a challenge.
6. Centralized Task level scheduling for all resources—All resources are tracked on a project schedule at the task or activity level. At this level, Resource Management integrates with project scheduling. Conceptually this isn't hard for any one project, and lots of people do this in Microsoft Project. But the ability to do this at the organizational level is a very large step up in software complexity. For this information to roll up in the organization every project and operation has to do it, and everyone has to do it exactly the same way. Costs for hardware, software, training, and support are significantly higher. You're in the big leagues now!
7. Individual feedback on task status (closed-loop)—Individuals enter the actual effort expended on each task and the completion status or expected finish date directly into the software rather than passing the information to the person who maintains the schedule.
In order to use a high-end scheduling tool like TeamPlay, an organization has to go all the way to Level 6—centralized task level scheduling for all resources. That's “The Wall” (see Exhibit 1). Centralized task level scheduling requires a large investment in software, support, and training. The advantage of our approach with RAFT is that we quickly get significant return at a reasonably low cost.
A critical question is whether you should you attempt to go directly from Level 1 to Level 6 or 7 if you have sufficient people, money and organizational commitment. Be very careful. You need to ensure you really do have all the resources needed to scale this wall. We suspect this isn't a practical option for most companies. If you aren't even using a central database to track assignments and needs, it will be a big cultural shift to get everyone on board with centralized resource loaded schedules. We have had several pilots that underestimated the challenge, tried the climb and failed.
Buy vs. Build Decision
Our preference is to use Commercial Off The Shelf (COTS) software rather than build our own. For this reason, we first attempted to implement Resource Management using commercial project management software. Motorola has corporate licenses to two enterprise packages, Advanced Management Solutions (AMS) Real-Time Projects and Primavera TeamPlay. Our initial approach was to make these packages work to support resource management.
Our first goal was to simply balance resource demand with resource availability at the business unit level (as opposed to the individual project level). We wanted to make sure we were fully staffing our existing projects and only approving new projects if we had resources available. We needed software that would address the data entry and reporting needs of both the resource manager as well as the project manager.
Exhibit 2. RAFT Allocation Page Example
Exhibit 3. RAFT Needs Page Example
COTS Support for Organizational Resource Management Weak
After valiant attempts to apply the commercial packages to resource management, we discovered that they are predominately focused on supporting the needs of the individual project manager and did little to support the needs of organizational level resource management.
The complexity of the packages makes it difficult for the average resource manager to focus on the simple job of assigning resources to projects. Resource managers are used to their simple resource spreadsheets where they could quickly assign a given resource to multiple projects. With these packages, a resource manager was required to locate and open each project, assign the resource to that project, save the project, open the next project and so on until all project assignments for an individual had been made. Revising assignments is equally painful. While both packages allow allocating a resource at varying levels of availability over time using multiple assignments, this is much easier in RAFT.
The canned reports in these packages are also focused on the needs of the project manager. Although they did a nice job of looking at resource shortages and over-allocations within an individual project, there was no easy way to see if the resources were over-allocated across multiple projects. We were left with exporting the data into other reporting tools like Oracle Report Writer and Excel to provide a view of current staffing levels and needs at the organization level.
These packages used the concept of assigning generic resources or roles to projects to describe the needed resources. As a general rule, generic resource assignments are replaced as named resources are assigned to the projects. Because of this replacement, the visibility into the overall need for resources becomes obscured. We were left to calculate total needs by adding assigned resources and generic resources. But this calculation is based on the faulty assumption that because a resource is assigned to a project, that resource must be needed. At times, this is not the case.
COTS Enterprise Software Expensive
An additional wall to climb was the cost of implementing these software packages when compared to the cost of RAFT. Licensing and IT infrastructure costs are high (for example, the TeamPlay list price is $4,000 per license, although a site license significantly lowers the cost per user). In addition, these feature-rich, complex packages require very skilled users. Due to the overwhelming number of ways they could be used, these packages required significant handholding and oversight to get them used effectively. The people responsible for deployment needed to have enough savvy to advise their users which features to disregard and how to use the packages in a “dumbed down” fashion. Building this bevy of skilled resources was a significant challenge made more difficult due to the feature richness of these packages. The approach recommended by the software vendors was to hire consultants to mentor the organization, which drives up the cost of implementation considerably.
Both AMS and Primavera have acknowledged their limitations in organizational resource management and have expressed interest in RAFT, which we have discussed with them. For these reasons, we built our own resource management database.
Building a Resource Management Database
Resource management has two fundamental inputs: resource Allocations (i.e., individual project assignments) and resource Needs. The RAFT user interface is simple and role-based, allowing the efficient entry of these two inputs. For example, functional managers see what they need to assign people to projects, while database administrators see other functions for creating skill lists and projects.
Because RAFT was specifically designed to support Resource Management, the resource manager can focus on that and quickly enter resource assignments. The RAFT Allocation screen (see Exhibit 2) resembles the Excel tables that many of the resource managers had grown accustomed to, making the transition to RAFT straightforward. Additionally, the allocation process allows the resource manager to allocate a given resource across multiple projects all in the same screen, unlike the commercially available packages. In a parallel fashion, the project manager enters project Needs using an intentionally similar tabular interface (see Exhibit 3).
Exhibit 4. “Shale” Chart—Staffing and Needs Report
Good Output Reports Critical
Good reporting capability is critical to the success of any database. If users can't get their data out in ways that want to see it, they won't use the database. We spent significant effort in designing reports to support the needs of organization level resource management. The Staffing and Needs report allows an organization to review its overall staffing commitments compared to the resource needs. This report provides the information necessary to balance resource supply and demand and smooth the organization project pipeline. They also allow management to answer basic questions such as “Do we have the resources to develop a new product?” and “What projects we should delay or cancel to provide needed resources to a higher priority project?” Additional reports allow a resource manager to identify their staff not 100% allocated to projects. Hyperlinks from these reports to the resource allocation screen allows the resource manager to easily assign resource to projects in need.
We have various canned (specialized predeveloped queries) reports available to the users in tables. In addition, each report can be exported to a Microsoft Excel ™ spreadsheet. This allows the users to create charts as can been seen in Figure 4. The canned reports are:
Project Staffing Rollup—Displays rolled up resource levels for all projects based on employee project assignments. Shown in Full Time Equivalents for the selected division and time range. This report allows the user to drill-down on each program hierarchy.
Project GAP Analysis—Shows the delta between project assignments and project needs for selected programs or projects by skill.
Project Staffing Detail—Displays resource levels for all projects based on employee project assignments. Shown in Full Time Equivalents for the selected division and time range.
Project Staffing and Needs—Displays resource levels for all projects based on employee project assignments from Start date to Change-over date, and based on project needs from Change-over date to End date. Shown in Full Time Equivalents for the selected division and time range (see Exhibit 4).
Employee Project Assignments—Displays monthly project assignments for each employee in the selected organization for a given time range.
Resource Skill Capacity—Displays the number of resources broken out by organization skill list, with mapping to Sector Standard Skill list. Based on Employee Primary Skill.
People Assigned to a Project—Shows the percentage assignments for all people assigned to a specific program, project or subproject
Resource Allocations and Project Needs Export File—A spreadsheet file of active employees, employee information, and project assignments for a selected organization. This file will also show all needs by skill for all projects in the selected organization. (Can be used with Excel pivot tables to create custom reports.)
Exhibit 5. Entity Resource Diagram
We recognized that we wouldn't be able to design every report a user might want. So we included a report that lists all resource allocations and needs by organization for a user-defined period of time. All reports can be exported in a comma-separated format (csv) that can be opened in Excel for further analysis and charting. Useful reports and easy access to the data helps our users focus on the real goal, which is properly staffing and approving new product projects based on facts.
Keep Allocations and Needs Distinct
RAFT captures the complete picture of resource “Haves” (i.e., Allocations) and project Needs. Unlike the commercial software, Needs are not replaced as named resources are assigned to the projects. Project Needs are explicitly captured and maintained by the project manager. Explicitly defining Needs in this manner provides a true picture of the gaps between needed project resources and committed resources. There is no need to infer what the needs probably are by adding generic assignments and real assignments as in the packaged solutions. The difference between what a project manager says he or she needs and what the functional managers have assigned represents the shortage (or less commonly, the overage) of resources.
Maintaining project Needs in this explicit manner is critical in that it provides the basis for asking for resources from the functional managers. It provides the necessary data to make tradeoff decisions about projects in the pipeline. And it provides the history for future project planning.
The simplicity of RAFT and its focus on resource management has made implementation straightforward. A functional manager can learn what they need to know about RAFT in less than an hour. We have the skills necessary to provide training and coaching on the use of RAFT, thus avoiding the costs of external consultants and trainers that are usually required with the commercial software.
To estimate the Return On Investment (ROI) for RAFT, we assumed effective resource management software would yield a 5% improvement in resource utilization. We believe this 5% improvement is conservative. RAFT's forecast ROI of 8,000% (yes—saves 80 times the development cost) was critical in getting IT support for custom developed software. The $367,000 development cost of RAFT is significantly lower than the license and infrastructure costs of TeamPlay ($2.7M). Because RAFT was custom developed, we were able to tailor RAFT to our specific and simple needs. We can modify RAFT as the resource management process matures in the organization. But we don't plan on integrating RAFT with scheduling tools. That's a big step. When commercial software becomes available that meets our requirements, and our organization is mature enough to handle that capability, we would prefer to buy it.
Database and Data
RAFT has 6,400 people loaded, and 1,160 of those are supervisors. Each division (average size is 220 people) has a RAFT data administrator who is responsible for the data. This is usually the project controller for the organization. Today, 348 people interact directly with the RAFT. These are usually the data administrators and their assistants. We expect the number of users to increase as supervisors themselves begin to directly enter project assignment information for their people. The highest number of concurrent users is around 60.
RAFT has 38,000 lines of source code broken down into 200 procedures. It was developed over 16 months with a maximum of three people working on the system part-time. The IT development and support effort has been 48 staff-months at a cost of $367,402.
The database consists of 13 Oracle tables (see Exhibit 5) with 1.2 GB of data. We expect the database to increase in size by 35% this year and 15% each year thereafter.
Any enterprise wide system will require central servers. As the software increases in complexity, performance demands on the servers also increase. While this may seem obvious, client-server performance was a significant issue in our TeamPlay pilot.
We find that users generally expect the same speed from RAFT that they had with their spreadsheets on their local computer. That's a hard standard to meet, but we have spent appreciable effort designing the screens so as to minimize the amount of time users have to wait for a screen update. In order to deal with latency issues, we provide the users with as much relevant data as possible with each screen update so as to reduce the number of screen updates required. As a result, our screens are more complex than a typical public website.
We use two computer servers for RAFT: one to run the Oracle database and one to handle the web interface. The database server is a Sun™ Enterprise™ 450, with two 480MHz/8 MB cache UltraSPARC-II™ processors and 1-GB RAM. This machine costs approximately $50,000. We are currently sharing the database server with several other databases, and the performance has been unacceptable. Users frequently have to wait 10 seconds for a screen update, even for minor changes (i.e., not processor intensive). By the time you read this, we will have moved to a higher performance server. We hope this will significantly reduce the time to update the users screen.
The Web server is running Apache HTTP Server 2.0 on a Sun Ultra™ 60 with a 450MHz ULTRASPARC-II™ processor and 1-GB RAM that costs $9,500. In addition to these two servers, we use separate servers for development and testing.
Rapid Development Approach
We developed and rolled out the capability in small increments so as to derive business value sooner. Many application development houses recommend this incremental development approach. According to Kent Beck, the formulator of “Extreme Programming,” (http://extremeprogramming.org) to go fast and win, you have to live through change after change after change. Feedback is vital, and the most critical feedback is that of prototyping and acceptance testing.
We would have liked to deploy from the outset commercial, enterprisewide resource and program management software that we could use at a low maturity level and continue to use as we matured. But it was too expensive and complex. Our in-house RAFT database meets our current needs at a low cost, and will support us through Level 5 out of the seven levels on the Resource Management Maturity Model we describe in this paper. If and when we want to move to a higher level, we will have good resource management data in a relational database. In closing, we leave you with some lessons learned from our deployment of resource management software.
Lessons Learned on Resource Management
• An organization must “learn to walk before it runs”—don't fall into the trap of implementing software to support Level 7 of maturity if your organization is currently at Level 1.
• Feature rich tools aren't always better—they must provide user interfaces that are role based and intuitive
• Managers must demand and use the information to make their project staffing and selection decisions
• If you build your own database, you must invest significant effort in developing good canned reports
• Users don't tolerate slow screen updates in web-based applications—they want it as fast as their local spreadsheet
• You need a committed person to drive the implementation in each organization
• Reorganizations are inevitable—you must plan for reorganizations by providing utilities to move resources, allocations, and projects to different organizations
• The commercial software we evaluated does not focus on the negotiation and interaction between functional managers and project managers
• While the fundamentals of resource management are simple (“Haves” and “Needs”), we had to establish rules to keep the data consistent with the Human Resources database and to control access rights
• Establishing a standard skill list is another “big wall.” While we have avoided this by allowing organization to have their own list, this makes balancing Needs and Haves by skill more difficult when sharing resources between organizations.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 · San Antonio, Texas, USA