This June, I presented at the “Government Contract Pricing Summit”. The topic of the presentation was the integration of TruePlanning and ProPricer. The participants of the summit were generally long time ProPricer users, but not familiar with TruePlanning, so it was a great opportunity to be able to meet new pepole in the price/costing world. When talking with long time ProPricer users the question I would ask them was: “Where do the hours come from?”  ProPricer is an industry leading software for the management and production of bids. ProPricer allows users to setup and maintain costing and burdening data, WBS’s, resource pools, and all of the other minutia surrounding the production of a bid, but the hours that drive all of the other data needs to come from somewhere. How about a repeatable, defendable, easy to use process that is based on both industry and organization specific data?

TruePlanning’s suite of tools is the industry leading parametric cost analytic software suite and is a natural partner for organizations using ProPricer. With TruePlanning users can create a repeatable, reliable, defendable, and easy to use processes for generating the hours that feed ProPricer. And with the integration between TruePlanning and ProPricer, the process of getting hours from TruePlanning into ProPricer is just that much easier. This was the focus of my presentation in June and I’d like to provide the highlights of the presentation by showing the integration between TruePlanning and ProPricer.

To start with let’s review the anatomy of a ProPricer proposal. ProPricer proposals are made up of tasks, and for each task there are resources. It is the resources that have hours attributed to them.

As we can see above, the “ZeusDemo” proposal has set of tasks corresponding to a WBS. Task 2.1 System Engineering is currently selected. In the “Resources” tab in the bottom of the screenshot, three Resources are listed for Task 2.1. Each of these resources has hours attributed to them over time. ProPricer the applies labor rates and burdening factors to the hours to come up with cost and pricing values.

TruePlanning projects have a similar, but slightly different anatomy. A TruePlanning project is based on a Product Breakdown Structure (PBS). The PBS is a representation of the structures that make up the entity being modeled. The PBS is composed of Cost Objects which are the encapsulation of CERs that represent the different types of structures.

The screenshot below contains a typical PBS that represents a GPS unit that can be put into airplanes. It is made up of a single System Cost Object, and multiple Assembly and Hardware Component Cost Objects. There is also a Software Component to cover the software work performed in the design and production of the GPS unit. The Assembly Cost Object’s primary job is to account for effort that comes from integrating things. The Hardware Component Cost Object is used to capture the effort required to design, produce and maintain entities that have weight. They take into consideration structural and electronic components of the same entity.

TruePlanning uses “Activity Based Costing” so the CERs of each Cost Object are based on sets of Activities that are performed by Resources. In the screenshot below the “GPS” Hardware Component has been expanded to show some of the Activities and Resources that make up the Hardware Component. Activities include: Development Engineering, Development Manufacturing, Production Engineering, and many others. The Development Engineering Activity is performed by three Resources: Design Engineering, System Engineering, and Support Engineering.  The activities defined for a Cost Object are fixed because they form the basis for the CER calculations and this is key for the reliability of TruePlanning.

In the above screenshot, in the right pane, the inputs for the GPS Hardware Component are seen. Each Cost Object in TruePlanning, in addition to having Activities and Resources, has a set on “Inputs” that are used by the CERs to calculate effort. The most influential Inputs are listed first and decrease in influence as they are further down in the list of Inputs. For Hardware Components, the most influential Inputs are quantities, operating environment and weight. Astute readers will notice that “Structure” and “Electronics” are broken out. This is because structure and electronics are frequently packaged together, but need to be processed in the CERs differently because what’s true for structure isn’t always true for electronics, particularly concerning weight.

Once a PBS has been created and the Inputs have been populated, TruePlanning, being a “Activity Based Costing” model will generate effort for each resource for each Activity in each Cost Object in the PBS. In the below screenshot, the hours for each Resource belonging to the GPS Cost Object from the above screenshot is listed. The hours are broken out by month. 

What is significant about the screenshot above, is that this is the data that needs to be moved into ProPricer. It is at the Resource level that data from TruePlanning moves to hours into ProPricer. At this point, the astute readers will be calling ‘foul’ because they have noticed that there is a discrepancy between the WBS from the ProPricer proposal and the TruePlanning PBS. This is true! The secret is TrueMapper which allows users to ‘map’ from a PBS to a WBS. It is in TrueMapper where the integration between TruePlanning and ProPricer happens.

In the screenshot below, TrueMapper has been launched from TruePlanning and the PBS from the GPS box can be seen. At the same time there is an empty window on the right, this is where the WBS will go, and it will come from ProPricer!

To import a WBS from ProPricer into TruMapper, users click “External App Imports” and then select “ProPricer”. Users are then asked for login credentials and once the credentials are provided, users are given a dialog to select the target ProPricer proposal, as seen in the screenshot below:

Selecting “ZeusDemo” and clicking the “Open” button results in the WBS from the “ZeusDemo” proposal being loaded into TrueMapper. The screenshot below shows the WBS from the “ZeusDemo” proposal loaded into TrueMapper. 

The cry of the astute readers is once again loud, for they have noticed that the WBS pulled from the ZeusDemo proposal into TrueMapper looks a bit fishy. The WBS has grown in that the resources for each task are now child elements of the WBS. The reason for this is that, as mentioned above, the hours from the TruePlanning resources need to be mapped to the resources that are attributed to tasks in the ProPricer proposal. To allow this to happen, when TrueMapper pulls the WBS from a ProPricer proposal, the WBS is “enhanced” to include the resources. This allows mappings from TruePlanning resources to ProPricer resources.

This article won’t go into the details of performing the mapping, but in the screenshot below a fully mapped project is seen. In TruePlanning a total of 131,092 hours of effort are estimated, and 131,092 hours are attributed to the resources of the ProPricer proposal. 

Once the mapping is complete, all that’s left to do is to get the data into ProPricer. To do this, users simply export the mappings to a *.csv file that is formatted to support the “Resource Hours/Cost” import format for ProPricer. It would be possible to automate the push of data from TrueMapper into ProPricer, but ProPricer users have repeatedly expressed a desire to manage the flow of data into ProPricer using file imports. 

Voila! ProPricer users can now, with authority, say where their hours came from. PRICE is a world leader in cost analytics and the ability to feed ProPricer is just one more way that PRICE helps is users be successful. If there are any questions, or if there is a desire to see a demo, please contact PRICE and we would be happy to help.