The Disjoint Between Project Controls and the ERP

Over the last 15-20 years I’ve had many a good debate on the merits of using mainstream ERP systems to manage project finances. Of course, the more accurate term is project cost controls, as opposed to project accounting, as cost engineers know these things to be discrete disciplines.

The confusion stems from where they overlap; that grey area of backward-looking data most often referred to as Actuals. But Actuals are merely a commodity to professional cost engineers who dedicate 95% of their time predicting future outcomes, not counting those of the past. It’s right here, in this grey area, where ERP vendors perpetuate the myth that their toolset was built with both functions in mind.

Pulling the argument into focus, how many AEC/EPC, Oilfield Services, and Construction firms can say all of these statements are true?

  1. There is a high level of cost predictability across the project portfolio, and revenue write downs are uncommon. Forecasts are updated monthly for more than 90% of all projects.
  2. There is a standard project controls platform across the enterprise, and project managers:
    1. are happy with the tool, using it without complaint
    2. don’t waste any time manually extracting data from the ERP
    3. have no need to use offline Excel spreadsheet
  3. Executives and business managers have full visibility into the status of project estimates, budgets, changes, trends and forecasts. Because of this they make decisions quickly and precisely.
  4. Because of the high visibility and tight integration through the project lifecycle (bid > award > execution > close out), project audits are targeted mainly at projects falling outside the bounds of standard performance indicators, e.g., Productivity/CPI, SPI, TCPI, Cost Variance, Burn Rate, and Contract Compliance. Therefore audits aren’t disruptive.
  5. Contract compliance is very high, e.g., budgets and forecasts from contracts, change orders and pending changes are always current due to strong governance and separation of duties. This ensures revenue recognition is always in accordance with FASB and SEC guidelines.
  6. They’re compliant with FASB ASU 2014-09 for percent of completion revenue recognition, and with ANSI 748 Earned Value Management for relevant government projects.

Experience says very few companies can claim all, if any, are true – reason being there’s a massive disconnect between financial management and project cost management. It’s most evident when the real work of project cost controls is performed offline, outside the ERP projects module, in that realm of unbridled freedom we know as Microsoft Excel.

While progressive companies have implemented Enterprise project controls tools to sit alongside their ERP, others are bought into the messaging from the ERP vendors. The following illustrations should help remove any doubt.

Figure 1 – Project Finance-Based Architecture

Figure 2 – Project Controls-Based Architecture

In my time as CIO of a project management and controls consulting firm, I was responsible for a landscape similar to that in figure 1. I was responsible for developing the project finances module depicted, and we developed it from scratch. It served the needs of our Finance organization and was loathed by our Operations function.

Subsequently, as head of the IT Consulting business unit in that same company, I experienced first-hand the pain I had inflicted on the business. I resorted to using my software development resources to build offline tools required to properly manage our projects. What a hypocrite! Though in my defense, there were no good Enterprise project controls tools on the market 8+ years ago.

Today I’d have the Enterprise project controls system in figure 2; effectively serving Finance and Operations. My detailed performance obligations would roll up to my summary financial/commercial obligations. I’d be managing the project first and the money second; because managing cost, price, revenue, margin and cash is merely a function of good project management and controls. I’d allow the Operations/Project managers to determine the right level of detail for their project, provided they could roll up to my core coding standards supported by the ERP. They wouldn’t want (much less need) to manage in Excel, and they’d spend more time managing the project and much less crunching numbers and double entering data.

I’d then change my title to Chief Hero.

Stop The Monthly Madness: 7 Steps to Real Project Control

It’s month end.  The new VP of Engineering recently issued an edict that ALL projects’ forecasts must be updated monthly, regardless of project size and status.  A noble ideal, for sure.  Like many such edicts, however, nothing else changed.  Your control estimates were rushed together with less than 10% of design complete, Work Breakdown Schedule (WBS)/Cost Breakdown Schedule (CBS) coding was left to the discretion of the project manager, long leads were procured with only one purchase order line to ensure timely delivery, changes are being approved verbally for expediency, schedules are in a constant state of flux as scope and design evolves, progress updates lag because contracts prescribed no means of objective measurement, accounts payable moved offshore last year and invoice workflows are optimized for rapid payment instead of validation, overhead allocations and intercompany transfer rules were established by Finance and Accounting without proper consultation with Engineering.

And then there are the systems, the very many systems.  Estimating, procurement, accounting, document control, project/contracts admin, and scheduling, at least.  Luckily you have at your disposal the greatest tool known to man, one whose ubiquity is trumped only by its simple complexity, that last bastion of unbridled freedom of expression: Microsoft Excel.  Armed with such a beautiful instrument, updating the forecasts of the 10 projects (7 small, 2 medium and 1 large) under your control within the 5-day month end window can only be a cakewalk.  After all, each of those 5 days is replete with 24 hours – few of these mandating sleep.  You take brief solace in knowing your many peers face a similar situation, and that your superior Excel skills will ensure your level of “compliance” will be nothing less than average.  That’s right, average, that black hole of mediocrity into which many a promising project controls career spirals infinitely into nothingness.

Lest you forgot, it’s month end.  Right now.

If you’re half-smiling, you’ve likely recognized more than a half grain of truth in my prologue.  Rest assured you’re not the only one half smiling, but at least you’re still smiling, if only a little.  The prevalence of incredibly similar scenarios is an alarming indictment on our industry and the project controls profession.  It’s not all your fault.  To a large degree you’re a victim of circumstance.  You’re keenly aware of the root causes of your monthly madness, but your once raucous voice has, after years of protest, understandably quieted.

But what’s the cost?

  • To the corporation: budget overruns, missed forecasts, lost revenue, opportunity cost, reputational damage, high levels of attrition, and business failure.
  • To the individual: dissatisfaction, angst, reputational damage, disenfranchisement, and career change.

So how to right the ship and where to start – people, processes or systems?

  • People – You already have experienced people; they collectively bring decades, or even centuries, of real world project experience from a vast array of companies.  Therein lies the problem.  The startling absence of real, implementable industry standards forced them time and again to make it up on-the-run.  They took what they learned to the next project, and learned again. But the good things learned at every step of the way have been warped to the point of unrecognition.  Industry bodies don’t help in this regard – PMI and AACEi provide frameworks that stop short of helping get the job done.  Neither provides the cornerstone of world class project controls, a standard set of coding structures (WBS, CBS, OBS, RBS).  Yes, they’ll advise on how to create coding structures but aren’t prescriptive, choosing to leave that to organizations like CSI and ANSI.  The OmniClass Construction Classification System (known as OmniClass or OCCS) is a promising means of organizing and retrieving information specifically designed for the construction industry.  However, OCCS adoption levels are seemingly low – a common theme for the engineering and construction industries.  Underlying all people-related challenges is the nonexistence of project controls within higher education; the exception being Quantity Surveying, which is a much broader discipline than Project Controls and is rapidly becoming a form of Project Management.
  • Processes – Now we’re talking.  You’re to overcome the challenges presented in the People section by launching an initiative to standardize your Project Controls Processes and Systems, culminating in the development of a training program aimed at nurturing expertise.  Indeed, that’s why People came first, because you can’t expect to develop a world class set of processes until you’ve hired qualified people.  You’ve decided to focus on the People and Processes areas before even thinking about Systems.  Over the course of the initiative you’ll crack out the Visio diagrams, wisely choosing to extend AACEi’s Total Cost Management (TCM) framework to avoid reinventing part of the wheel.  You know that TCM only takes you so far and it must be extended and wrapped around the unique aspects of your organization.  You visualize an online reference guide with contextual links between sections – just like Wikipedia!  Now off you go – see you in 3 to 5 years.  Just don’t forget it’s still month end, and will be every month for the duration.  By the way, you’re not allowed to involve planning, estimating, scheduling, procurement and accounting.  They’re too busy on their own initiatives.
  • Systems – You’ve long since stopped trying to convince Management you need a Project Controls system.  On multiple occasions they’ve corrected your misperceptions that the combination of your Enterprise Resource Planning (ERP) software and Excel cannot get the job done.  At least that’s what IT and Finance told them.  They’ve spent millions on this ERP system so you just need to knuckle down and help them extract maximum value.  Stop fixating on its rigidity and clunkiness, you’re merely making excuses for not updating (and missing) your forecasts (again).  In any case, you haven’t hired the right people and have yet to standardize your processes, so what use is a newfangled Project Controls system?  It’s important to acknowledge not all companies are still using Excel to mask the weaknesses of their ERP system.  Many have purchased commercially available systems (industry leaders have implemented one system in particular), and many have developed in-house or bespoke systems.  The latter of these two groups deserves attention because, speaking from personal experience, developing software, more than at any time in the last 30 years, must be left to software development companies.  At the point in time our world transitioned from Windows to the web, software development became numerous orders of magnitude more complex.  10-20 years ago I hired and worked with software developers.  In the last 10 years they became Platform Architects, Database Administrators, Performance Architects, Data Architects, Integration Architects, Web Developers, UI/X Developers, Content Managers, and the list goes on.  The proliferation of specialization is a reflection of the complexity of your average multi-tiered, enterprise application.  This complexity took many companies by surprise.  They thought the task of migrating their long established, successful Windows applications to the web would be a formality.  Trying to draw a simple analogy, developing enterprise software is like trying to manufacture an island in the middle of the Pacific.  The residents (users) want nothing more than an idyllic paradise replete with beautiful mountains, lakes, rivers, waterfalls, forests, beaches and wildlife.  And these things aren’t that difficult to construct.  Nor, in shallow water, is the island’s foundation needed to affix it securely to the sea bed.  However, the development team learned late that the Pacific is 20,000 feet deep and requires an unfathomable infrastructure – one that will take 80% of the project budget and timeline to create.  Equate this infrastructure to the platform that underlies modern enterprise applications architecture – database, integration, web services, security, cross-platform compatibility, etc. Consider the ongoing revolution of BYOD (Bring Your Own Device) and the effort required merely for cross-platform compatibility ratcheted up more than just a few notches. Now where did that sea bed go?  For these reasons, the smart companies in our industry have retired their homegrown tools and selected a particular commercial product, saving many millions of dollars and achieving much higher levels of agility along the way.  Moreover, future evolution will be focused largely on business requirements – or on improving the sanctity of the island paradise, if you will.

These arguments are not fabrications – they’re pulled from my many experiences over the last 25 years.  Project Controls is the poor cousin of Finance and Accounting.  Budgets and forecasts continue to be blown.  It’s time for a revolution.  Take the following as a manifesto for success:

  1. First select and implement a particular commercial Project Controls system.
  2. Leverage the system provider’s experience in implementing the system in parallel with process improvements.
  3. Focus on a core set of business requirements, e.g., the production of a cost report, including change management and forecasting.  Address only high-value, high-volume areas so as to maximize benefits and efficiencies, and minimize time to value.
  4. Limit the initial implementation to 6-8 months or less.  Stakeholders need rapid results if they’re to provide long-term support.
  5. Take what the system gives out of the box and apply that to your existing environment.  As needed, modify your processes to support systems integration, allowing data to flow automatically from all source systems mentioned above into your new system.  As needed, modify the system configuration to accommodate your critical processes and data structures. This requires a flexible system that can be modified through configuration, not coding or development.
  6. Create system-oriented work instructions and integrate them with the system contextually.
  7. Retain smart, experienced individuals and immerse them in your new systems so as to educate them on the underlying processes/dataflows, and even deeper lying organizational interdependencies.

NOTE: Though I deliberately haven’t discussed organizational change management, stakeholder engagement, project planning and execution, I trust you’re more than equipped to handle these critical areas.

So have you given up, or is there one last fight deep within you?  I think so.  I also think you owe it to yourself, and our profession, to step up to the plate one more time.  Come on, let’s rise up together.