Industry Insight No. 12: How software can support project delivery
This article was first published on Lexis®PSL Construction on 6 October 2016.
Construction analysis: Sarah Schütte of Schutte Consulting Limited considers how software can be used to support programme (also known as schedule) and project management in construction projects. She explores the pros and cons of project management software on the market, discusses some of the practical and legal issues arising, and looks at what the future could hold.
Over the past two years, I have been fortunate enough to have been invited to participate in or speak at many conferences and project initiatives relating to one of my key interests, the programme and project management profession (PPM).
As a result, I have developed an interest in how software can support project delivery. This month’s article follows a quarterly user group meeting which I chair, so the issues described are hotoffthepress. The meeting is always a fascinating insight into the users’ experiences, the challenges encountered and the benefits realised. There is always much discussion and usertouser support offered up, no doubt fostered by its open atmosphere.
The use of software to support PPM is a relatively new concept to the UK, but is longstanding in the USA, as I discussed in Industry insight: the future of portfolio, project and programme management—part 1 and part 2. Put simply, project software can produce userfriendly data which can be used for a variety of purposes. Several UK end-users and major contractors and consultancies are now experimenting with it, including Transport for London/London Underground (where I worked between 2006 and 2014), HS2, Atkins and Thames Tideway Tunnel delivery partner C2HM.
There is an urgent need for improved contract management, especially of public sector mega/major projects (and funds), and in particular with the demands imposed by NEC3. I also think that software can play an important role in supporting the human delivery of the project.
The Thames Tideway case study
I recently edited a case study on the Tideway Tunnel megaproject for the UK arm of the global software provider Deltek Inc, written by Niall Faris (Project Controls Lead) and Phil Shatz (UK Sales Manager) of Deltek. The case study examined how Deltek’s project management software Acumen Fuse is being used by CH2M to assist it to manage the overall works plan and incentivise the contractors’ teams to improve the quality of their programmes. This results in better performance and delivery, which in turn saves time and cost. The case study generated plenty of interesting feedback, particularly from the mega-projects community.
There is a variety of software on the market as well as Acumen Fuse, including Oracle’s Primavera 6 and Microsoft Project. Each has its own features. The advantages of using software are these:
Better predictions about time—the more skilled the planner is at plotting logic links (factors affecting duration between activities), the more accurate the plan is and the fragility of the critical path is reduced
Speed—the algorithms can produce data at the click of a button, therefore saving analyst time
Flexibility—software can create simple or complex output, as the parties agree
Visual representations—software can instantly generate dashboards, which distill key information at a glance, which is useful for governance and stakeholder reporting
Multiuser functionality—it can be used by any number of people, and
Easy to use—with basic training, junior planners and project managers can contribute meaningfully to complex projects
From a lawyer’s perspective, I can also see these benefits:
Data output is based on fact, rather than opinion, so it should result in fewer challenges (but be wary of the quality of input which affects the quality of ‘fact’—see below
Software is neutral, so supports the project, rather than one contracting party or another
The output informs and enriches the project record eg an ‘asbuilt’ programme (again, watch for quality)
The requirement for software can incentivise the contractor to improve the schedule quality, provided the contract is appropriately drafted (more difficult than it sounds), and
Earlier prospective visibility of risk factors, which is beneficial to all involved in the project
Practical issues arising
Using project software is not, however, without its pitfalls:
Licencing—you are ‘held’ to one provider, so there needs to be a supportive customer service to answer queries and solve user problems
Cost—the initial expense of the investment in the software licence, the costs of adding users and the annual fee to maintain licences and avail of technical support, and
Operation—the use by the project team of the software (as human input varies in quality—see below)
Legal issues arising
I am certainly a fan of project software—but it must be used in the right way to produce the right results to maximise the value of the investment in the product and the time spent by PPM professionals using it.
The danger is that if the software is not used properly, then the results are likely to be questionable, could well be worthless, and may be damaging to the project and the parties involved.
So the key legal issues for me are these:
1. Quality of data inputted
Everything hinges on this. It is an easy win for an expert planner, working with a clever lawyer, to pick apart a poor quality programme, and destroy claims for extra time and money. There is correlation between budget overrun and schedule quality. The philosophy behind using the software must therefore be to support, not supplant, the human brain’s efforts. I recommend this be stated upfront in the contract, along the lines of NEC3 clause 10.1, to remind the parties of what they have agreed to do (together) (see below as to a proposed protocol).
2. Ownership of data
At the moment, this rarely arises, because the parties each buy their own software. In a true legal partnership arrangement (such as PPC2000), the project record belongs to the ‘project’, so arguably a transparent ‘project’ database is required. For the majority of projects, however this is not the case. Nonetheless, while the majority of data is (and should be) open to all to see, some data produced during the project may be subject to legal privilege and confidentiality and so firewalls or separate password-protected areas of the database must be built. This is particularly so in non-partnership arrangements—even so-called collaborative contracts such as NEC3. Wherever claims arise, there is a lack of trust and transparency, and so the database must be able to respond appropriately.
3. Cybersecurity and data storage
How is the data stored, and where? Is it backedup? Who has access to it? Is it password protected at different levels? Are certain parts of the database open to limited users? Statutory data storage periods differ by jurisdiction and contract, but must be matched when agreeing the time period for storage. There are also questions of who bears the cost of maintaining storage and how access is administered. Finally, I have not seen the issue of protocols for data creation, analysis, use, storage, and destruction addressed anywhere—I am currently drafting a protocol for general application in the industry and would welcome readers’ thoughts and ideas.
4. Legal privilege, confidentiality, ethics and compliance
These issues are complex and serious, and have not been addressed at all, as far as I am aware (not unlike BIM, as I have discussed previously in this pair of articles on Ethics Industry Insight No 8 June 2016 and Ethics Industry Insight No 9 July 2016).
5. Contract requirements
What is the output required for schedule quality? I have seen references to a ‘passfail’ score of 75% and while a scoring mechanism is useful, it is fairly crude. The better approach to improving schedule and delivery quality is to weight the scoring criteria. This could be as simple or sophisticated as the enduser wants, so that the factors which are important to it are specifically measured and tested.
There is a clear link that the more time invested in the exercise, the more accurate, and useful, the tool will be. In order to make this process effective, the contractor must be obliged via an operational clause to comply with it. Therefore, the requirements should be stated both in the contract and in the Works Information (NEC3) or specification (other forms of contract). Involving the contractor properly in the exercise will almost certainly enrich the potential of the tool to drive schedule quality.
What does the industry say is needed now to support project delivery?
In one word, training. The quality of data input can be linked tangibly to the quality of the data output, in my experience. There is little point in investing thousands of pounds in software, and asking your teams to use it—and I whole-heartedly support the investment—if the output has little value, or does not stand up to critical analysis, because you have not also invested in initial training, and updating training, for your teams.
The UK suffers from a shortage of excellent project and programme managers, as well as planners, and so linking this in to coding/computer science education is important, in my view. My clients, big and small, tell me that they want to invest in the software, but they need the humans to be able to operate it.
My clients would also like to be able to invest in programme management expertise early, to help them to create excellent programmes from day one, not to be brought in when disputes arise. Having a ‘go-to’ adviser is recommended, but does not come cheap—however it is likely to come cheaper at the beginning than at the end.
What does the future hold? From the discussions I have participated in, and experts I have talked to, I predict:
Contracts will be more sophisticated in their requirements—but this investment will be at an early pre-contract stage (perhaps through early contractor involvement where the contractor can explore the issues openly with the employer)
Data will belong to the ‘project’, not each party, and therefore will be readily accessible as a neutral project record accordingly (but see above about legal privilege and confidentiality, which do not disappear) —one or two projects are
already testing this capability
Data will link into, or be integrated with, BIM, seamlessly
The software will be ‘live’ and continuously updating its contents—the metadata will be better, and changes made automatically saved, so that they are more easily traceable
Users will become more sophisticated as they gain skills in using the software, and confidence in the potential of the software to be a contract ‘tool’ not a ‘hammer’, and
Planners will be a project ‘musthave’ resource, rather than a ‘nicetohave’
All of these future PPM benefits depend on improving the quality of the data, and therefore on why training is so important. They also require a supportive cushion of a legal (contract) framework, and this could be achieved with a standard protocol and better defined contract outputs. I welcome readers’ comments and ideas.