
Tel 07834507200
Our Blogs
Our Blogs
Please find our recent posts below
Please find our recent posts below

How to please the client for Infrastructure Projects
How to please the client for Infrastructure Projects
June 2019
Linked In Article by P.Whitfield Consulting Ltd June 2019
This short article sets out in simple terms how integrated project teams can better enable the process of pleasing a client.
Major infrastructure projects are high stake projects that are in the public eye. Glibly speaking, pleasing the client is easy – just deliver on time, with quality and within budget. Yet the CITB (et al) 2018 “UK Industry Performance Report (Based on the UK Construction Industry Key Performance Indicators)” reported that:
• the Client satisfaction with the service received from contractors dropped back to the 2016 level, with 77% rating their satisfaction as 8 out of 10 or higher. This compares to 81% in the previous survey. On 73% of projects, clients scored value for money as eight out of ten or higher. This is 7 percentage points down from 2017 and the lowest rating since 2003.
•Clients’ overall satisfaction with their consultants has weakened. The proportion of clients rating their consultants’ overall performance at 8 or better of out of 10 slipped from 79% in the 2017 survey to 75%.
Each project and the mix of staff working on it is unique, so the key focus should be demonstrating exemplary understanding of the client and their aspirations for a project.
At the project’s outset you have a written brief (specification), hopefully, and probably also other high-level documents that explain the particular programme of work that a project sits within, and possibly also a Scheme Requirements statement that articulates the desired outcomes in KPI (Key Performance Indicator) terms for the construction and post construction (in-use) stages. But does all of that that guarantee real understanding, and will those messages be cascaded properly through the team? It’s highly unlikely that the client’s documentation alone will be a sound platform, because the relative weights of certain factors won’t be well explained and there will be missing information that wasn’t included, either deliberately or inadvertently. Then there are the various client personalities and their perceptions to understand: the project manager, the technical assurance team, specialist advisors, and the senior leadership team and what is driving their aspirations and performance metrics. And then there are the objective issues and the more subjective issues to sift through and decisions to be made about how these should be weighed and articulated in your delivery approach.
A client will value your services if you strive to understand the project from all conceivable angles. This allows all parties to define and potentially refine the scope. This comes in the main from detailed conversations with key stakeholders, some of whom may have been “outside the tent” when the written information was produced. Good clients will also listen to their project team and will be open to sensible scope challenge, provided they are content that the scope challenge process can be tightly defined before exploration begins. In defining scope, in my view it is important to be rigorous and formal in documenting what is definitely in scope, what is definitely out of scope, and which issues are uncertain and require assessment and governance to record decisions. This process also includes specialist input to shine a light on the potential vagaries across disciplines.
Client expectation surveys are a key method of taking time out to sit with the client project manager and shape these issues. This process should ideally be early, but should not only occur at the very outset as this may result in receiving only one viewpoint and before the major challenges are visible. It is also worth time thinking about how to design this engagement process so that the client can gather their thoughts to inform a genuine two-way conversation.
Each project will have formal project controls over quality, time and cost metrics. The better project teams understand that quality is not just about delivering competent deliverables on time, it is far more than that. It is about showing professional judgement to understand technical challenges and identifying where the resource effort is most needed; concentrating on the big-ticket items and risks that could undo the project at stage-gates. It is about understanding how to brief your team of suppliers and remote work pools on what the client really wants and making sure that each team member can describe these client aspirations to each other with nuance and full comprehension. All too often fundamental messages about project scope get lost unless they are clearly documented and repeatable.
It is about looking for innovation to deliver the project outcomes in a way that helps the client “over- achieve”, not just achieve.
It’s about understanding how the infrastructure will operate and the linkage between the features and that operation.
It’s about showing value. Sometimes this is about getting more for less, but it should always be about getting more, sometimes even at higher capital cost (but always within budget!). Whole life cost, maintainability, safety, operations, sustainability and the environment must all be considered and articulated in a sound value proposition.
It’s about managing stakeholders. That does not always mean delivering everything that stakeholders want, gift-wrapped. It means fully identifying who has an interest, listening to their view, balancing options and then determining what fits with the scheme objectives.
It’s about communications and integration. Whether that be via multi-disciplinary meetings, information management or briefings, each facet should be clearly articulated and targeted to the audience. Good client-supplier relationships can survive mishaps and bad news. Be transparent and work through problems together.
It’s about articulating options to decision makers including explaining all perceived or real disbenefits and benefits of each option. And within that process, it’s about truly understanding the real weighting of the difficult balancing act across various imperatives. Sometimes win-win is just not possible, but good decisions rely on presenting multiple options including rejected options, not a single option.
In summary it can be concluded that many of the key ingredients for success rely on a range of soft skills to create the right background for technical delivery. It is largely unknown what proportion of training budgets and project budgets are used on these skill areas, but it would seem that teams that can better display these key skill attributes will be more likely to please their clients and demonstrate their contribution to pragmatic outcomes.
Linked In Article by P.Whitfield Consulting Ltd June 2019

Doing the Project Hokey Cokey - what's in and what's out?
August 2018, Linked In article
After more years than I care to remember reviewing technical reports and presentations a recurring problem I see is for designers and clients to struggle to clearly articulate project design scope and hence what is in and what is out [aka the Hokey Cokey, or in the USA the Hokey Pokey apparently].
Report authors are normally very good at stating what the project includes. However they are typically poor at considering what has been omitted and why. I cannot provide evidence as to whether this approach is related to putting a "gloss" on things and always presenting the project in an optimistic and factual fashion, or whether it's simply inherent in how we train our planners and engineers to not explain things transparently.
Each project will have objectives, budgets and timescales and it's fully understandable that there is always a finite limit to what any project can achieve. That said, I believe there is far more room for greater transparency in terms of project-visioning so that anyone with an interest (stakeholders) can better understand why the inclusions were in and why the exclusions were out. In many walks of life (e.g. maintenance engineer) we see checklists and the compiler will fill it in to explain what is included and what is not. Whilst each engineering project is unique and may not lend itself to a checklist approach, it is surely feasible to always "vision" a project to develop a potential scope list. Within that list there will be fundamental "givens", but also a number of greyer areas that require deeper consideration and effort.
This same theme also applies when looking at options for a particular feature design. There are plenty of good models for this - for example, once a decision is taken to include a footbridge in a road project, the process requires options to be examined for the structural form, thereby also documenting a number of rejected options giving a thorough audit trail. This allows the designer, client and others to understand, and possibly challenge the decision. This type of process does not always follow through to all elements of a road design. Highway engineers do have to provide an audit trail of rejected options when proposing a departure from standards, but this behaviour is not always so strong when more generally explaining the overall highway design concept. More often than not the design is well intentioned and appropriate, but if not articulated in writing then it becomes harder to rely on the unwritten common sense that has been used. This makes reviewers uncomfortable. It can also lead to future operators and maintainers getting the wrong impression of the design process with a resultant lack of confidence in the scope of the project. Design processes are evolving and the scrutiny is becoming more intense from user groups and operators. Designers must be able to place themselves into those shoes and think what the end user wants. Further, designers should be confident to challenge their client's Brief which may have been drafted at a very early stage and hence may not best represent the client's overall corporate interests.
So, to conclude I would suggest that a well written technical report should always explain the design rationale of what is included but also what is excluded, with reasons. This additional drafting effort will ensure greater transparency and also give rise to the possibility of grasping opportunities for project betterment within the overall scope.

Expert Witness Services
Expert Witness Services
19 September 2019
This week I've attended the Expert Witness Foundation Course at the Academy of Experts at Gray's Inn London. This course covered the importance of the structure of the Expert's Report and record keeping at Expert's Meetings. I look forward to putting these new found skills into use very soon. I am able to offer Advisory Expert Services and Part35 Expert Witness role for highway design aspects.