Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

There’s a Tool for That! Why Project Delivery System Implementations Fail.

Why is it that many organisations look to solve problems by finding a new program/tool without looking at the fundamentals of the problems they are trying to solve?  I’ve been at the forefront of many Project Delivery and Project Controls program implementations and there are some very good tools out in the marketplace.  However from experience it is rare to see one that has been implemented fully and successfully to its full capabilities.  Surely, with the quality of programs and resources out in the marketplace it should be a simple matter to implement a new tool within an organisation?  Certainly if you listen to the sales representatives, these tools will solve all your problems and do wondrous things – yet the outcome rarely lives up to the expectations.  So why is this?   

1.      Lack of understanding and definition of the problem and expected outcomes

My favourite quotation is from Edward Deming “Without data you’re just another person with an opinion”, yet every day managers make decisions based upon what they believe is the truth rather than on fact. When it comes to Project Controls systems, metrics such as the size and type of projects currently undertaken, the duration, the control methodology (Earned Value, Agile, Prince2), current tools and processes used and their effectiveness, type of clients and markets are all essential in understanding where we are now.

Getting input from subject matter experts and end users can aid in defining the root cause issues and give management better clarity as to the problems they need to solve. For example, if Project Managers, Project Leaders or Project Directors do not understand basic performance metrics, (what they mean and how to use them) to control the outcomes of the projects, how can anyone expect a program or tool to make a significant impact?  Are there processes for controlling scope, collecting time and schedule data and physical progress, and if so, are the people responsible for using them making the best use of the information?  Do we have meaningful Work Breakdown Structure (WBS) and Organisational Breakdown Structures (OBS) that allow visibility of data to enable decision making?   Who are the ultimate users of the project data and how does this data integrate with enterprise level reporting and other company systems and requirements?  How do these issues affect the profitability of the projects and what are the steps to resolving these problems?

This level of clarity and definition at an identifiable, measurable level can lead to more effective systems and solutions overall and a good tool then becomes an integral part of that system to meet the expectations of solving these problems. 

2.      Lack of supporting processes, systems and procedures

A tool is a repository for data that can be accessed to assist in the decision making process.  Therefore the quality of the data along with the processes and procedures that collect the data are as important or even more important that the tool. After all, if you are doing things ineffectively, then the software will only make you more efficient at doing ineffective things.  Again this comes down to understanding how information currently flows within your business and understanding how the structure, quality and timeliness of the data flow will affect how the tool is utilised. Data is at the core of any system.  It’s the commonality of that data that allows for the integration of information throughout the various systems within the company to allow informed decision making.

From the project level up, cost management procedures and processes are a fundamental tool in controlling costs on projects.  Management and control of project scope, tracking of commercial changes and trends, identification and management of risk are all essential to the successful delivery of projects.

When common definitions and procedures are joined with a standard tool kit, accuracy of information and confidence in decision making is increased.  This information can be aggregated across projects to provide actionable intelligence and visibility across portfolios of work, or within business units.

Applying common coding across corporate systems from finance, estimating, project management, and resource management enables data to be exchanged.  This allows greater integration of information to enable better visibility and control throughout the organisation.  A project cost management tool, for example, should not be used for financial reporting, however the data used and generated can be used for financial functions. Rather than make one tool solve all the problems, a correct and common coding system can allow data to be accessed across the business by multiple systems and tools for various purposes. 

Common coding structures include OBS, CBS or WBS, Discipline, resource and commodity coding.  Understanding how data will be collected and used is essential to any system.  A cost system needs the ability to collect and manage data at a lower level than say a finance system, however both systems are reliant often on the same data.  Allowing cost structures that support the functionality of controlling cost on a project in a meaningful way, based on how the project is being delivered, rather than being dictated by a financial requirement is essential.  Yet the needs of the financial requirements such as asset based costing or project profit recognition cannot be ignored.  The importance of common coding structures cannot be disregarded as they form not only the means to control and deliver projects but the basis of communication and data flow between various stakeholders – both internally and externally.

3.      Lack of mandate and buy in

There are often many reasons why the adopting of a new tool fails.  All employees must believe in the strategy, supporting program and software and be educated in not only the usage but the underlying reasons for using the tool. Implementing the tool in stages, rather than an all at once approach will allow small successes to generate bigger outcomes.  Appropriate training and support is critical, as is ensuring that there are correct processes and procedures in place, and used, to support the flow of accurate data into the tool. With any new tool, it does comes down to the end user.  Ensuring that person is at an appropriate level of experience, not only to technically use the tool, but also to understand Project Controls methodology and use the tool to generate meaningful analysis to provide strategies to control the outcome of the project.  Too many times I’ve seen a high end Project Controls tool used by a junior engineer to “do a bit of project controls” and the end result is that the tool is not effective.  This leads to a poor perception of what the tool can actually do and ultimately lack of adoption on other projects.

Likewise, upper management needs to support and mandate the tool as well as the processes and practices behind it.  This becomes a critical management and communication issue.  Do managers understand the performance metrics on the project and how to use the data in a meaningful way?  Are they asked to justify their project performance with project reviews and performance targets? Are project leaders/ divisional leaders reviewing project statistics within these targets? A lot of companies have good project delivery procedures in place, however they are often not mandated or used.  Without giving management a reason change then they will continue along the same path of least resistance and ultimately no change will be effective.

 

So why do these tools fail…because they are just that – tools.  Like any tool in placed in the wrong hands or used the wrong way they will be seen as ineffective and no longer used.  Cost systems, rely on supporting processes and methodology to feed data into the tool which can be analysed.  There are some exceptional project delivery tools and programs in the marketplace.  Supported by strong underlying practices, processes and people they can make a difference to both projects and the organisations using them. 

 _____________________________________________________________________________________________

Carmen Bates is a Project Delivery professional with over 27 years’ experience in Project Controls, Project Accounting and Commercial Management on major projects.  Carmen has considerable expertise in project delivery system implementations and the development of processes and systems that improve results

Comments

I was involved with a massive

I was involved with a massive implementation of PRISM that fell flat on its face. The group functional leads sat in glass ceilings hob nobbing with ARES consultants; whereas the rest of the company had to operate projects based on client requirements. When the final implementation came, none of the projects was able to use it despite a tonne of training. The cause was simple - the tool did not fit the requirements of the vast array of projects. Additionally, I personally found that the only way to update PRISM was by way of a lot of excel feeder sheets. EVentually it was easier to just manage the job with the excel feeder sheets. 

So in general, with all the project control systems, they all seem to be so complex and try to handle every possible situation, so for specific projects they can be absolutely AWESOME. However for general rollouts, not so good. To hard customizing every project. 

Good rollouts will utilize that. Cater to the specific projects, and build expertise slowly. 

Market Place

Primavera P6 and Microsoft Project books, on-line video training courses and training material available from an internationally recognised publisher. Teach yourself using on-line or book based learning or run your own in-house or public courses.