In my first blog on how to create a great capital project delivery organization, I introduced a framework we call a Project Excellence System. It’s made up of six dimensions or capabilities – and while each capability is distinct from the others, it’s vital they all work together in a holistic and coordinated way to deliver project success.
In my next six blogs, I’ll examine each of the dimensions in turn – starting in this blog with “integrated project technology”. Throughout the series, you’ll see that one of my key themes is the need for the project leadership to understand all six dimensions when forging ahead with any one of them. Put simply, none of the capabilities should be tackled in isolation – because, in a world where all projects have massive volumes of data to support decisions, it’s critical to help ensure integration and alignment across areas like technology, process, governance and controls and people.
However, I also need to stress that implementing and integrating technology isn’t the be-all and end-all – because the real key to success isn’t the technology applications themselves, but the data flow between and across them. While best practice is still evolving in this area, it’s increasingly clear that the optimal solution for project technology is a vendor-neutral environment: one where all systems speak to each other, and data flows seamlessly from the initial project outline to the concept drawings, from the estimate to the detailed construction specs, from the as-builts to the financials, and through everything in between. This pervasive end-to-end data flow should also link into the asset management part of the equation – not an area I cover in this blog series focus on delivery, but important to bear in mind throughout the build phase.
Alongside the need to focus on data flows before applications, a further vital point is that when we say integrated project technology, the key word is not just “integrated” – but “project”. Why? Well, one of the challenges that we find our clients facing is that they don’t always treat their enterprise and financial-type technologies – their ERP systems and applications like PeopleSoft – and their project technology requirements separately. And the problem here is that the two are very different animals.
Project technology is what it says on the tin: the technology that you would use to deliver major capital programs. It’s often very specialized, allows for a scalable level of flexibility to handle day-to-day project demands, and includes a lot of niche tools from a wide array of vendors. However, project technology is also a market that the big ERP providers are looking to muscle in on – by investing heavily in R&D, acquiring project technology companies, and bringing different technologies together to enter the projects space.
At the same time, new players are coming onto the market with interesting and exciting offerings in areas like analytics, data mining and visualization. With all these developments coming together at the same time, project technology has become a really rich environment, but also a pretty complex one.
As a result, a lot of our work for clients around project technology is helping them figure out what works, what doesn’t, and what’s the best fit for their specific environment. We often find that rather than going out and spending US$25 million on a big implementation, there’s a very simple, low-cost solution that will meet their needs perfectly well.
Going forward, this evolving reality points to the potential for a brighter and more efficient future for project delivery. Our experience shows that if a project’s leadership are getting caught up in the applications and systems, they’re probably missing the key point. As I’ve already highlighted, data – and the way it flows across disparate systems – is the most critical consideration. So instead of thinking first about technology, projects should focus on creating a common language or vocabulary that will facilitate the near-instantaneous sharing of huge volumes of data across platforms, projects, business units, geographies and more.
In my view, this is the future for project technology. So, what's holding it back on today's projects? In many cases, the main barrier is a failure to identify the commonalities between the data seen as critical by IT and the business as a whole. In the ideal Project Excellence environment, those two worlds come together to create well-defined, well-understood and well-managed data flows. But on too many occasions, we see the IT function trying to impose their own enterprise ERP solution and data flows onto the project. And it’s unlikely to be a good fit – especially when the ERP was selected in the first place because everyone else in the same industry seemed to be using it, not because it was applicable to projects.
My overall message is clear: when it comes to project technology, integration across all aspects of the project does matter. But so does separating the enterprise from the project, and getting the right data flows in place to support this. However, as always, there’s a twist – and here it’s that the whole area of project technology is evolving at breath-taking speed, as the migration to cloud solutions gains momentum. So enterprises need to look at the nature of the projects they deliver and the technology drivers, and decide whether they’re comfortable taking their data flows into to the cloud or want to keep everything in-house.
Ultimately, this decision may become a no-brainer. A time will come when you’ll just flick a switch and have a project technology capability on Monday that you didn’t have on Friday, with everybody integrating with everyone else. The days of big IT implementations will be gone.
That day will come. But not quite yet.
Read about the next phase in this process on my next blog on Capital Projects Controls and Governance.