Project Partners Blog

Oracle published an interesting article that lists the top three trends for the Engineering and Construction industry in 2012. We want to make you aware of this article.

“Technology professionals serving the engineering and construction industry should be aware of three major emerging trends in 2012,” said author Scott Bartlett.

The #1 Trend: Construction projects will continue to increase in complexity

The #2 Trend: Economic pressures will continue to force companies to work globally, with increased competition for the same projects

And the #3 Trend: Owners are demanding a more efficient way of turning over all documents at the end of a project

At Project Partners we see this same focus among our multi-national Engineering and Construction customers and are glad that Oracle’s products support these key trends.

You can read the full article here: http://www.oracle.com/us/corporate/profit/opinion/012312-sbartlett-1496768.html

Introduction

Oracle Projects may be integrated with Inventory and WIP. This integration allows the tracking of project related transactions in Inventory and WIP. Some of those transactions will be interfaced to Oracle Projects. The simplest Inventory transactions that will be cost collected and imported to Oracle Projects are miscellaneous inventory transactions.

• Miscellaneous Issue from stock to a project,
  
• Miscellaneous Receipt from a project into stocks.
  

Those miscellaneous transactions are imported into Projects from any Inventory organization, whether or not the organization was classified as Project Manufacturing Organization. In a PJM organization those transactions are eligible for cost collection only if the stock locator is of another project or has no project at all.

The following transactions will be cost collected and imported into Oracle Projects only when executed within a PJM organization:

• Items receipts of a project related purchase orders for inventory destination. The items are delivered into a project locator of the inventory organization.
  
• Items issued from a project locator to WIP job (work order) of other project, or from a non project locator to a project work order.
  
• Project Transfers transactions which move items from one project locator to another project locator on the same organization, or from a non project to a project locator.
  
• Inter Organizations transfers from a project locator or non-project locator to another project locator in the receiving organization.
  
• Resources charging WIP work orders, which are project related. Resources may be employees’ labor time, outside processing supplier costs, machine usages etc.
  

Cost Management invokes the cost processor program for each inventory and WIP transaction, one by one, following their creation order. It calculates the cost amount of each transaction and may generate the accounting lines. When cost processor is responsible for generating accounting, it uses the accounts set up of Cost Groups and WIP Accounting Class. In a PJM organization you assign each project to the organization, and enter the project parameters. Among them you link a project to a single cost group and may link it to various WIP Accounting Classes. Cost Management system also offers some extensions that may be implemented for changing those default accounts.

Accounting Options for PJM Organization

When Project Manufacturing is enabled for all or certain inventory organizations, there are (starting 11.5.10) several alternative options for accounting, which differ in scope and path. On the setup form of a PJM organization you should select one value for each one of the following parameters:

• GL Posting Option:
  • Manufacturing: All inventory and WIP transactions are accounted by Cost Management process in Inventory, and sent from Inventory to GL. The project-related transactions are interfaced from Inventory to Projects as accounted.
  • Projects: Inventory is not interfacing any material or WIP transactions to GL. The project-related transactions are interfaced from Inventory and WIP to Projects.
• Account Option: This option is applicable only if GL posting option is selected as Projects.
  • Send Accounts to PA: Inventory and WIP transactions are interfaced to Projects with the accounts defined by the source. However, Projects will interface those to GL.
    
  • Use Auto Accounting: Inventory and WIP transactions are imported into Projects unaccounted. Oracle Projects is responsible for distributing those expenditures using Auto Accounting rules.

Inventory miscellaneous transactions imported from a PJM organization will always be accounted by Auto Accounting rules in Projects.

Several points regarding these options are worth noting when implementing Project Manufacturing:

• When selecting the Projects value for the GL Posting option, only transactions that are cost collected into Projects are accounted and posted in GL. All other inventory transactions, which are not charged to projects, will not be affecting any GL accounts. Any inventory transaction that represents a change in the physical on-hand value of inventory without adding or reducing any value to the project accumulated cost will not be cost-collected nor accounted in GL.
  
• WIP transactions represent resources adding value to the project-work-orders; hence those are always cost collected into Projects, and always accounted.
  
• PO delivery transactions into Inventory or Shop-Floor, and any subsequent correction or return transactions will always be accounted and interfaced to Projects as well. This is true for non-project purchase orders as well.
  
• When selecting the Projects value for the GL Posting option you have to enable a project number as a Common Project on the PJM organization setup form. In a PJM organization, users may enter transactions without project and task. By enabling a common project the system will capture any WIP and Inventory transactions with no project data, and interface those to Projects, all assigned to the predefined common project and task.
  

In the following paragraphs I would like to explain the advantages of interfacing unaccounted Inventory and WIP transactions to Projects.

Many companies use to apply indirect costs on top of direct costs. In Inventory and WIP you may setup overhead rates, and the cost processor calculates the additional cost elements, material overhead and resource overhead. Those overhead materials are cost collected and interfaced as separate burden expenditures. The alternative tool for applying overhead is the burdening functionality of Oracle Projects. Projects will not allow burdening of externally accounted transactions. However, when expenditures are imported as not accounted, Oracle Project’s burdening functionality can process the PJM transactions, and apply burden costs to those expenditures. The ability to use Project Burden allows companies to apply systematically the same burden multipliers on PJM and all other expenditures charged to the projects. For example, employees may sometime charge work order in WIP or charge directly a project and task on their timecard. Using this feature the burden calculation may be shared, and you could save the maintenance of duplicate rates schedules. In addition, Projects’ burdening allows for updates to the burden rates. The ability to re-burden and apply final burden multipliers, replacing the provisory initial multipliers is a unique feature available in Projects. There is no way to revise overhead rates in Inventory. Last point in favor of using project burdening over inventory overhead is the ability to treat differently the burden amounts based on project types. Company may choose to use burden on separate expenditure items (summarized burden items) for contract projects, but use burden on the same item for capital projects.

Some companies also need to account differently for billable versus not billable expenditures. Such feature is easily done in Projects, and is a lot more complex to achieve using the accounting engine of Cost Management in Inventory. You may set up transaction control in Oracle Projects to derive the billability of Inventory and WIP expenditure items. With the expenditure items marked as billable, you can use Auto Accounting rules of Projects to generate the appropriate accounting based on billability.

The accounting generation for project expenditures is easily configured and maintained when you use only Oracle Projects’ Auto Accounting. Companies which need to account for PJM transactions using rules based on project attributes, project organization, project classification, will find the easiest solution is to use Auto Accounting. Alternatively, achieving the same project-based accounting in Cost Management; would require developing the Accounting Generation Extension. This is a separate tool based on workflow engine, which requires extra development and maintenance effort. Even when you are using SLA in Oracle release 12, the configuration of accounting rules for Project’s source transactions is easier than the need to additionally configure similar rules for Inventory’s source transactions.

Sending all project-related transactions to GL through one source – Projects – eliminates the need to reconcile between project costs and their respective journal entries generated and posted by Inventory. Using the single path also eliminates the need to manage the period close of the inventory organization. Since Inventory would no longer be an accounting source, the closing of accounting periods for each inventory organization can be obsoleted.

All the above mentioned factors call for using a unified tool for generating project-based accounting. Those points become clear advantages when meeting the following two characteristics: Inventory and WIP transactions of a PJM organization are mostly project related; and when accounting rules are based on projects flows of revenue versus costs. If, on the other hand, the majority of Inventory cost is non project, you might not use the recommended method above.

In cases where companies require accounting in GL for significantly high amounts of the Inventory Materials asset account, the alternative method may be favorable. In these cases, using the classic Inventory flow for accounting and interface directly to GL has indeed a significant advantage. When there is high value of non-projects transactions in a PJM organization, those costs will charge a single common project. Oracle Projects, however, does a poor job in accounting for the balance of on-hand inventory by the end of each period. Oracle Projects setup at a PJM organization might not be a good solution for physical inventory based accounting.

When projects go wrong, they generally go wrong at the beginning. As my experience is largely in the defense industry, most of the following is derived from those experiences. Poorly defined requirements lead to poorly defined statements of work and specifications which lead to unrealistic expectations both at the customer and at the supplier. This fundamental communications issue blights projects and affects them throughout their life cycle. Why do project teams make these same mistakes over and over and over? After scores of interviews and post-mortems in the last twenty years, it unsurprisingly comes down to poor practices and lack of discipline. Is this the project team’s fault? Only partly. Often it is the customer’s fault, particularly in the world of government contracts. That the US Government attempts to employ good project management practice is a given; however their shortcomings are three-fold.

First, the program managers may be on promotion track, and that means reluctance to admit to problems.

Second, the program controls / Earned Value organization seems often more interested in accounting than in project management.

Third, the persons developing the statements of work and technical requirements fail to make them both clear and realistic.

Let’s start with the last first, as that is where a project can be at risk from inception. The problem with statements of work for major development procurements is that the persons writing them often either do not know how to define the requirements, when the aim is inventing technology, or they may have a jaundiced view of requirements definition, i.e. they want to leave certain things “obscure” in order to maintain a degree of “flexibility” in the future or they want to “challenge” the supplier to create a “better” solution. The former circumstance is merely a fact of life, but the later creates misunderstandings leading to unnecessary changes, do-overs, delays, and increased cost without advancing the project toward the ultimate goal of providing what the end-user needs. Over the last twenty years I worked with several engineering managers who avoided stating firm requirements because of the mistaken ideas that firm requirements tied their hands or reduced “creativity”. This then is a warning sign for the risk identification process…ill-defined requirements mean greater exposure to both buyer and seller.

So how does the “seller” correct this when it means telling the customer the he isn’t really doing a good job? The IT services model of defining requirements through joint analysis and jointly agreeing on requirements is a good one, as is employing the intent of the spiral project life cycle model which allows the risky bits to be identified and resolved at the lowest possible cost. If the risks cannot be reduced, then the project requirements and objectives can be modified or, if the costs begin to exceed the benefits, then the project may be abandoned entirely. This again will require a close relationship with the customer and may be a difficult sell on the supplier’s part. It certainly is worth approaching when you find yourself in the vague statement of work circumstance. One successful technique is to put that reluctant technical manager in the seller’s situation by asking him if he would sign a firm, fixed price contract as a home builder based only on an artist’s sketch of the house. You can infer what to do with the analogy from there. Ideally, we would want that technical manager to hire us to design the house in addition to building it. However, he still must provide basic requirements for us, for him, and for the project to be successful.

Establishing plain, straightforward, and honest communications is the only method for dealing with the first circumstance, that of a customer project or program manager who, for whatever reason, doesn’t want to hear about problems, issues, and risks. This, for the seller, may be a no-win situation, but it is better to have warned the customer’s project manager and to have told him the truth rather than being complicit in a disaster. A manager friend of mine had a sign on his desk “Come to me early with a problem, and you have a partner in finding a solution. Come to me late with a disaster, and you have a judge.” I employed that thought literally when I sat the customer project manager chair. That was one of the first discussions I would have with the seller on a newly contracted development project. It may be painful, but it works, and the pain is short term, rather than a reputation destroyer.

Using earned value as a project management technique is essential. That the Government’s EV people come from a financial background may present a challenge when attempting to design, organize, and build a project that results in meaningful measurements and statistics. I found three things crucial in earned value management: objective measurements, a deliverable/product breakdown structure as opposed to a “product-oriented” WBS (this often required deviation from the government’s contract WBS or MIL-HDBK-881A), and using labor hours for EV measurements on labor efforts. I’ll discuss each of these in a subsequent blog.

You are implementing Primavera P6 and have determined that the delivered reporting tools are not up to snuff.  Before you go out and buy a new report writing tool, take a step back and look in your enterprise toolbox.  You might find you already have a tool that fits the bill.

At Iberdrola Renewables, we have a large contingent of data consumers who need read-only access to project information stored in Primavera.  P6 has proved to be a great and flexible tool for managing vast amounts of project metadata.   Through the configuration of Project Codes, Project UDFs, and Project Layouts in P6 we have streamlined the process of managing project pipeline data and have greatly enhanced data quality.  However, the licensing cost and training effort to get dozens of read-only users access to that information in P6 was disconcerting.  What was needed was a simple to use tool to provide a read-only view of the pipeline data to the casual user. 

To a reporting tool, data is data.  Org Publisher (from Aquire) is a tool designed and marketed to chart and display employee and human resource records via an intuitive browser interface.  At its core, the tool is architected to display hierarchically structured data brought in from any ODBC data source.  As the Project Pipeline data stored in Primavera P6 is also structured hierarchically, via the Enterprise Project Structure (EPS), this was a natural fit.

After creating a custom view that managed the necessary joins to pull a few dozen fields from a half a dozen tables into a single row per project, the Primavera data was ready to be pulled into Org Publisher.  The Org Publisher tool provides multiple views of the data including a graphical Chart View (displaying relationships between records), a Summary View (for Counts and Totaling), a Profile View (to view all data associated to a single record) and a List View (to view all data in spreadsheet layout including download to Excel capability).  Once created, the chart and views were scheduled to refresh nightly and were made available through a web browser on the Intranet.  Below is a sample:

Besides the obvious licensing cost savings associated with not purchasing another tool, there are other advantages to adapting and re-using existing technology.  End users will be thrilled not to be forced to have to learn yet another new tool, easing adoption.  Additionally, the technical resources responsible for supporting the tool will be ready to go even before day one.