The Root Causes of Project Delay
The following piece is not out of a Management Textbook, but rather the result of the cumulative years of experience of a few consultants working with companies trying to improve their work practices
In countless consulting assignments we were faced by project team members totally frustrated because of unexplained project slippage.
“Everything was going well, then suddenly we started experiencing greater than normal client change requests”.
This is one example of the type of complaint we had to deal with to help our clients get their projects back on track. In greater than 90% of cases we’ve found that a few basic scope requirements were not being met.
They were:
Project deliverables as offered by various stakeholders were not specific enough.
“Must improve customer experience” is definitely not the same as “Intranet and
Internet users must be able to access the application from any device”.
The different stakeholder expectations were not aligned partly due to vague or non-specific expectations. Very little effort was being made to ensure that all the stakeholders agreed on each and every project expectation.
We concluded that for every hour spent working on the initial project deliverables and expectations we were able to eliminate 9 hours of experiencing project difficulties later in the project. This realization is counter-intuitive, as all the team members and the various stakeholders are energized by the project’s potential and in most cases want to get started as soon as possible.
At this stage you need a strict and disciplined project leader to keep reminding everyone of the importance of ensuring alignment and everybody agreeing on deliverables. Imagine the multiple impact this omission would have on the project life cycle.
It is even advised to have deliverables in three categories such as:
· Must have – Project would not be viable without meeting this requirement
· Should have – Highly desirable but if it proves to be too expensive and time consuming this deliverable should rather be handled as a second execution phase.
· Nice to have – Requirements that would provide your project outcome with features that would wow your end users, but unfortunately these requirements are notorious for being the most expensive, most elusive, and most uncertain due to unknown factors.
[Client Success Story]
A Stock Exchange wanted to develop and launch a unique derivatives service. They had an inexperienced Business Analyst doing the Proof of Concept (POC) analyses. The company had difficulty articulating the POC and their excuse was that the product/service was so futuristic that they could not do it properly. We encouraged them to attempt the service launch again and required the stakeholders be as specific as possible in their expectations of this anticipated service. We experienced a lot of “push-back”, but we persevered until they were able to approve a viable POC. Slippage accounted for a loss of $1.5m and 6 months delay. After the more specific end user deliverable requirements were finalized the new remainder scope and budget were adhered to.
When we meet these scope creep issues our first response is to question the level of specificity of deliverables and the level of buy-in from all stakeholders. We know it is a “pain” for project members to do this thoroughly but unfortunately, we know this to be the underlying reasons for issues such as stakeholder conflict, change requests, vendor issues and poor buy-in by certain stakeholders.
The most important lesson learned in this situation was to get the right people involved from the outset and spend as much time as needed to get all the parties with “skin in the game” to be on the same page.