The Cart Before the Project System
Capital Controller
“Great to finally meet, Niall, I’m Tom.” This was the last of my three interviews for a Project Control Manager position at a well-known energy company. It also proved the most interesting, as Tom was the outgoing Project Control Manager.
After formalities, he set about describing how the corporation organised its capital projects. Tom spoke about the monthly reporting structure and corporate roll up, and how the Project Control Teams were augmented with contract staff. He also outlined the current ‘flavour of the month’ with regard to contracting strategies, and described various systems supporting the whole shebang. He turned it over to me by asking, “What performance indicators have you relied on in the past to control projects?” I expounded upon the need to have one version of the truth as regards Scope, Schedule and Budget, regardless of how the project was released, funded or contracted. We talked about earned value and the need to enter data once so that all project stakeholders got the information they wanted without having to manually collate or recast any data. “In some ways I really envy you in this role, Niall. We have spent years integrating our Project System of Record (PSoR) with the Corporation’s System of Record (CSoR). Now every Project gets its Budgets, Commits and Spends ’hardwired’ in real-time from the CSoR—no more time-consuming reconciliations. You are getting an excellent system to control the projects.” This certainly piqued my interest, but I heard a warning bell when he implied that the direction was from the CSoR to PSoR. I had to tread carefully since he was certainly very proud of the legacy he was leaving at the corporation.
“You did say from the CSoR to the PSoR? But isn’t that the ‘cart before the horse?” Confronted by his puzzled face, I went on to say that before Budgets, Commits and Spends are posted in the CSoR, they must first be created, routed and approved by the Project Team. This ensures data integrity between the two systems and allows the team to produce Leading Indicators. He countered by saying that, “A Purchase Order is final and real only after it is approved and posted in the CSoR!” While I did not disagree, I did point out these are Lagging Indicators. It’s like saying we have to wait until the patient is dead before we know what, if anything, is wrong. At that point, it is simply too late. Projects are live and dynamic. It is better to produce Cost and Schedule trends as soon as they are apparent.
The CSoR and the PSoR that Tom’s company used are industry standard in their own rights. However, having the data flow from Corporate to Project system is the wrong order. They had set the projects up for a world of reconciliations and workarounds. It is accepted that the closer you get to the original transaction input, the closer you get to Leading Indicators of performance. In this case, Cost and Schedule impacts derived from Bid evaluations, Trend and Forecasting, Request for Payments and Request for Change. Whereas, approved Purchase Orders, Invoices and Current Progress are Lagging Indicators, and there is not much the project team can do about them – “…we are where we are”.
I could see that it was time to wind down the interview. “Don’t get me wrong,” I said, “there is a place for both Leading and Lagging indicators in order to get a confirmed and balanced view of the Project. It is just a question of the effort it takes to get there. The best way, in my experience, is to make sure the ‘horse is in front of the cart’ – the PSoR is driving the data and pulling the CSoR – and thereby efficiently producing Leading and Lagging indicators”. It is also worth mentioning that the Project Team feels more committed to indicators produced by their project systems, as opposed to what emanates from the corporate head office. However, the interview had by then concluded.
“Great to finally meet, Niall, I’m Tom.” This was the last of my three interviews for a Project Control Manager position at a well-known energy company. It also proved the most interesting, as Tom was the outgoing Project Control Manager.
After formalities, he set about describing how the corporation organised its capital projects. Tom spoke about the monthly reporting structure and corporate roll up, and how the Project Control Teams were augmented with contract staff. He also outlined the current ‘flavour of the month’ with regard to contracting strategies, and described various systems supporting the whole shebang. He turned it over to me by asking, “What performance indicators have you relied on in the past to control projects?” I expounded upon the need to have one version of the truth as regards Scope, Schedule and Budget, regardless of how the project was released, funded or contracted. We talked about earned value and the need to enter data once so that all project stakeholders got the information they wanted without having to manually collate or recast any data. “In some ways I really envy you in this role, Niall. We have spent years integrating our Project System of Record (PSoR) with the Corporation’s System of Record (CSoR). Now every Project gets its Budgets, Commits and Spends ’hardwired’ in real-time from the CSoR—no more time-consuming reconciliations. You are getting an excellent system to control the projects.” This certainly piqued my interest, but I heard a warning bell when he implied that the direction was from the CSoR to PSoR. I had to tread carefully since he was certainly very proud of the legacy he was leaving at the corporation.
“You did say from the CSoR to the PSoR? But isn’t that the ‘cart before the horse?” Confronted by his puzzled face, I went on to say that before Budgets, Commits and Spends are posted in the CSoR, they must first be created, routed and approved by the Project Team. This ensures data integrity between the two systems and allows the team to produce Leading Indicators. He countered by saying that, “A Purchase Order is final and real only after it is approved and posted in the CSoR!” While I did not disagree, I did point out these are Lagging Indicators. It’s like saying we have to wait until the patient is dead before we know what, if anything, is wrong. At that point, it is simply too late. Projects are live and dynamic. It is better to produce Cost and Schedule trends as soon as they are apparent.
The CSoR and the PSoR that Tom’s company used are industry standard in their own rights. However, having the data flow from Corporate to Project system is the wrong order. They had set the projects up for a world of reconciliations and workarounds. It is accepted that the closer you get to the original transaction input, the closer you get to Leading Indicators of performance. In this case, Cost and Schedule impacts derived from Bid evaluations, Trend and Forecasting, Request for Payments and Request for Change. Whereas, approved Purchase Orders, Invoices and Current Progress are Lagging Indicators, and there is not much the project team can do about them – “…we are where we are”.
I could see that it was time to wind down the interview. “Don’t get me wrong,” I said, “there is a place for both Leading and Lagging indicators in order to get a confirmed and balanced view of the Project. It is just a question of the effort it takes to get there. The best way, in my experience, is to make sure the ‘horse is in front of the cart’ – the PSoR is driving the data and pulling the CSoR – and thereby efficiently producing Leading and Lagging indicators”. It is also worth mentioning that the Project Team feels more committed to indicators produced by their project systems, as opposed to what emanates from the corporate head office. However, the interview had by then concluded.
