Project managers need real-time data--and a couple ERP modules of their own
by Pat Garrehy
ARE YOUR PROJECTS on budget? Do you know their estimates to completion? What are the actual versus the earned values? Odds are, you have answers to the above, but they are over a month old. Why? In most organizations, project management teams are provided ERP (enterprise resource planning) data on a batch basis at the end of the month. Information is received after the fact, too late for many corrections to be caught before expenditures are wasted.
The White Rabbit wouldn't have been late if somebody had given him timely information about the tea party.
This goes a long way toward explaining why a defense contractor's unique solution can run tens of millions of dollars over budget, a bridge can cost 50 to 100 percent more than expected, or a movie can make its budget overrun into headlines. Being over budget on projects is almost a self-fulfilling prophecy with a built-in excuse: “We didn't have the data in time.”
What's interesting is that most companies in which major projects are a significant component of the business mix will actually take pride in that their computer infrastructures are sound, providing answers when needed. After all, most questions are fielded in minutes or seconds—except those from project management. In reality, the answer is provided quickly; it's just based on old, bad data. While the rest of the company is working with real-time, accurate data, project management isn't.
Patrick J. Garrehy is president and founder of Relevant Business Systems, developer of INFIMACS II, an Enterprise Resource Planning software product for project-oriented companies.
The reasons are actually quite simple. For the “business as usual,” there are departments recognized by all—accounts receivable, purchasing, customer service, warehouse, manufacturing and information technology, to name a few. These departments are stable. They've always been a part of the business as usual and will continue to be. And year after year, the same people tend to staff and manage them.
Not so with project managers! They're in flux. staffers move from project to project. so do their managers. In fact, they're typically not even part of the business-as-usual mainstream, reporting directly to the CEO's or COO's office, bypassing other departments in the organization. on top of that, they're usually working on items to which the business-as-usual personnel are not privy. Not seen and not heard, it's no wonder the new computer infrastructure bypasses them. They weren't asked about their needs. They didn't offer suggestions. What's more, they didn't even get the chance.
However, like other groups within the organization, they, too, need a friend in the IT department. But, they need a friend who speaks their language, filled with vocabulary and acronyms unused anywhere else in the corporation.
BCWPs, Earned Value, and Other Project Speak. “Project speak” is not really that difficult to understand, and actually makes sense.
Whenever a group starts a project, it sets up milestones, with a budget for meeting each. When a milestone is reached, the project team has “earned” its estimated cost, accomplishing that feat in a specified amount of time.
For instance, if by the end of week four, you were supposed to have completed the prototype housing for your new widget at a cost of $10,000 and did it, you would have earned a value of $10,000 within your time schedule. oh, perfect world!
However, since perfection is not a term typically associated with projects, project managers have created their own acronyms. Among the most important are:
BCWP - Budgeted Cost of Work Performed
ACWP - Actual Cost of Work Performed
BCWs - Budgeted Cost of Work scheduled.
It's easy to see how the relationships among these acronyms can measure a project's performance. The comparison of BCWs and BCWP provides the schedule variance, and the relationship of BCWP to ACWP provides the cost variance. of course, there are many more acronyms and calculations that measure the performance of a project. The good news is that several fine software programs do so excellently. That's not the problem.
The data they get is old and not in a proper format. Why?
Remember that enterprisewide data infrastructure that was implemented for the business-as-usual departments, the one that bypassed project management? At the end of the month, data reports are batched by the business-as-usual people and given to product management to analyze or run through its project management software.
Of course, if variances among their project management acronyms show up, too much money and time have already been wasted. The lack of proper real-time input to the project management group does not allow the people in the group to take corrective measures at the time of variance, only later—often one or more months—when the variance finally becomes known.
Beyond Real-Time—Needing Proper Data. If real-time was all that we needed, the solution would be quite simple: send any data gathered by the business-as-usual modules directly to the project management software. This brings up the other problem: all those acronyms described earlier want different data than the business-as-usual departments can provide. As an example, let's explore costs.
Already, various people in the organization look at costs with different glasses. Costs, along with payables and receivables information of the corporation, can be compared from quarter to quarter. Costs by product determine where money is being spent. Labor costs might be compartmentalized by employee grade. Another person wants to compartmentalize department costs. Contract and job shop manufacturers might want costs segregated by customer or job order—a project!
For the latter, we now have the ability to monitor the actual procurement and production of a project or job against an estimate. Material, labor, overhead, subcontract and other direct charges for the project can be summed at any point and compared against the total estimate for the project.
We can now determine, through any given period, our earned value.
In order for this project cost system to have such a capability, it must capture and record costs through the end of each period, as well as budgets for each cost element, as well as the BCWP for each period. Each charge must be stamped with a time period. Plus, the program or project manager must make sure there is a budgeted amount, for each cost element, for each time period.
Therefore, the ERP system must not only be able to tell us that a widget flange costs $30 but that we spent this $30 during May and that we had budgeted to spend $X on it by a certain time frame. With this data, we can calculate our variances. Yes, it's starting to get complicated now.
Let's do a reality check for complexity. Pretend that, instead of our widget, we're engineering, prototyping and running full production of a space shuttle. Engineering is composed of software design, electronic engineering, mechanical development, and more. Prototyping includes detailed design, electrical, mechanical, and final assembly.
A budget for each period must also be established for every subgroup, with a cost account manager responsible for each. Their budgets will be developed by period and by cost element.
We have just entered the world of the Work Breakdown structure. Described is a three-level WBs, the top level reporting to the program manager, the second level being the individual department manager's WBs, and the sub-department cost account manager level being the third. In this three-level WBs, cost accumulation, the budget and the cost performance measurement must be available at the lowest level.
This seems to require a lot more data. And let's not forget the people working in business as usual, who will be very unhappy if all this project data starts to impact their data and data reporting.
ERP Project Control and WBS Programs Solve the Problem. For the ERP modules to support real-time benefits, they must possess four architectural capabilities:
Inventories, costs, shop orders, purchase orders, requisitions, receipts and sales orders must be maintained by item number as well as by project and WBS account.
Costed transactions, including all material movement and labor transactions, not only are the basis for accounting's business-as-usual general journal entries, but also, in real-time, update the project/WBS cost components of material, labor, overhead, subcontract and other direct costs, and selling, general and administrative, which are used in all ACWP and BCWP calculations.
A cross-reference must be maintained between the ACWP costed transaction and the general journal entry.
ACWP and BCWP costed transactions must be as to-the-minute for the project management department as the journal entries emanating from the business-as-usual departments are for the general accounting department.
Lastly, the system must provide these architectural capabilities without hindering the business-as-usual departments.
In practice, here's how it works. A project control module allows the association of inventory items, sales orders, work orders, purchase requisitions and purchase orders with each project. Project-oriented material resource planning gives the user the flexibility to plan by project or not. For instance, certain items can be planned without regard to projects to increase procurement or manufacturing efficiencies. This could include such items as a subcomponent used throughout the organization's products. Project control, then controls the allocation of material (or those finished subcomponents) to specific projects.
To stress the importance of such flexibility, some inventory items may very well want to be allied to a company's inventory (i.e., a home project) and later distributed to specific projects. The data infrastructure must be able to handle this.
Each manufacturing work order and purchase order line will ultimately be associated with an individual project. Thus, at any point in the program, online project status—in real-time—will be achieved with proper data.
For instance, at any point, a user could enter a specific customer and sales order and immediately receive to-the-second status regarding purchase requisitions, purchase orders, and production work orders that have been established to meet the requirements of this specific project.
Working in consort with the project control module would be a WBS module that provides the work breakdown structure for each project and each multilevel of the project. WBS definition begins with a WBS program, a standard project structure that defines the posting-level accounts and the summarization program that will be used to roll up costs from the lowest level to the higher levels.
As the user receives individual contracts or sales orders, they are entered into the system. users will want to enter budget figures, in both dollars and hours, for each account. Multiple budgets will now be provided—original, revised and current. As transactions are processed throughout other modules, such as manufacturing, the costs associated will be posted to the WBS structure.
With WBS processing, project/program managers can aggressively manage their projects. Project-to-date reporting, actual-versus-budget and estimate-to-complete reporting become readily available. Corrective actions can be taken the moment variances occur.
IF A COMPANY IS undertaking one project, it probably has multiple projects. Without appropriate, on-time data, several projects could start going bad at the same time. The enterprise would be in trouble without even knowing it!
Reader Service Number 5027
February 1999 PM Network