There’s a lot of talk about Project Controls out there.
There’s a growing awareness and momentum that’s rapidly spreading throughout the world; and more and more organizations big and small are undertaking initiatives to insert Project Controls into the management of their projects. It’s more than just a trend – the need is real, and follows decades of over-spending and lack of project visibility. As you can imagine, some companies embarking on a project controls initiative have a clear understanding of what that means, how to go about it – and have defined objectives as to what they intend to achieve. And some don’t. For those that don’t, this brief article is for you. It’s intended to help you frame a few questions to get you started on the path of knowing how to make the next steps.
Of course, many companies just want to improve. Their momentum stems from an internal need to become better at what they do, and to differentiate their business. Whatever the impetus may be, the challenge any organization faces when embarking on a journey like this is: “How do we get started?” The quick answer to that question is, “What do you want to achieve?” I know that’s the kind of answer that’s not very helpful, so I’ll go on to explain to you what I mean.
It’s easy to get paralyzed with uncertainty since Project Controls is one of those practices that can seem a bit daunting at first. It’s not uncommon for project controls professionals to approach the discipline with a tremendous amount of enthusiasm; and in their zeal, build a very complex process model for their company that may well be unnecessarily complicated for what’s actually required. As with many technical disciplines, project controls is packed with a range of both practical and theoretical formulas & processes that serve a purpose for the broad range of projects that it can be applied on. In other words, there’s a lot you could apply to your projects, but unless you’re running a mega project, you’ll be better off creating a simple project controls plan that gets you the reporting and controls you need. This is why I always tell people to define their objectives first, then work backwards from there. Otherwise, you’ll have you’re new project controls guy with an open-ended requirement to just “do project controls’ – and end up with a scary monster that no-one wants to deal with because it’s too complicated and time-consuming. And worse, they won’t see the value in what they’re doing. I’ve always believed that people don’t mind putting in the effort as long as they can see the point of what they’re doing – and they believe in it.
State Your Objectives First
What I mean by stating your objectives, is to think through what project controls reporting requirements you have – or what information visibility you’d like to have – and what information you’re currently missing. Or, what do your customers & internal stakeholders require from you?
The other variable that will influence your approach, is size of projects you run. Many organizations have a mix of small and large projects. Words like ‘small’ and ‘large’ can be relative, but the project controls you require is relative to the size of the project. This doesn’t mean that you shouldn’t apply project controls to smaller projects – it only means that you should consider a scalable approach that allows you to apply the right processes that make sense for the size of the project. For example, even if your project is 1-week long, you should at least have a budget, and then track your actual costs compared to that budget. That’s project controls at its most basic.
To help get you started, below are a couple of lists of “goals” to give you an idea of the kind of objectives you could include in your list. These are intended to help those companies that are new to project controls and only need the basics to get started – if you’re a seasoned project controls expert, these won’t be new to you.
Project Controls Objectives – First Steps
There are some pretty important objectives to start with that will not only have the biggest impact, but they’ll be the easiest to implement.
- We want to be able to compare Budget against Actual Cost at any point in the project
- We want to be able to use the results of historical projects as benchmark data to feed new project estimates, schedules, plans, etc.
- We need to be able to track and report on Change Orders and their effect on the budget
- We need to create ground-up estimates
- We need a schedule
- At any time, we want to be able to know how far along the project is in terms of percent complete
- We need a good Work Breakdown Structure Design
- We need to establish a simple but effective project cost coding structure (CBS)
- We need to be able to collect Actual Costs in real time – ideally directly from the jobsite
- We want to be able to forecast remaining cost and/or labor hours on the project
Project Controls Objectives – Slightly More Advanced
Once you’ve established the more basic Project Controls processes, you can take on more advanced workflows to increase your reporting ability.
- We need to Time-Phase the Budget against the schedule
- We need to do regular Progress Measurements at pre-defined cutoff points
- We need to report on EVM metrics at all levels of the Work Breakdown Structure
- We need to produce cash flow and spend forecast reports over a timeline
- We need to be able to perform productivity reports such as Hours/unit completed
- We need to plan and report on a collection of projects as a Program
- We need to see timeline curves like: S-Curve, Resource Curves, Spend Curves
These lists should hopefully give you a starting point for taking your first steps into launching project controls in your organization or business units.
Process or Software – which comes first?
We work with a great number of companies that are just starting out with project controls. Lucky for us, they’ll often find us by searching around for a technology solution to help them take their first steps. As with most software solutions, the information you get out of it is only as good as the information you put into it. Software can do a lot of amazing things, and produce reports in milliseconds – reports that may otherwise take days if done manually. Nevertheless, organizations still need to put the processes, policies and definitions in place first, and apply those processes onto the software platform second. This is, of course, a key part of our role as a technology and services provider – making sure that the technology is being setup and utilized correctly, so as to accurately achieve the objectives that were set out in the first place. Which again brings me back to how important it is to define your objectives before you make another move.