That frustrating moment when the key piece of advice you hear is, ‘Why can’t they just put more resource on it?’. Managing suppliers when a project has difficulties is the most difficult part of any role I have ever had, and managing the stakeholders around project delays is always the area where the most focus needs to be paid. Creating partnerships with suppliers is always the desire, but, if you are paying for a delivery by a date and the date is of significance for other dependencies then keeping the partnership on the ‘happy path’ needs to be second to managing risks, to ensure communication about the scheduling of dates is clear.
So, what to do when the worst has happened? The supplier has called a meeting and admits that not all is as it seems and delivery needs to be delayed. The immediate reaction is to be bullish isn’t it? You stop and think hang on, we’ve paid for this by this date! And being bullish will make you feel better (in the short term) and certainly the supplier needs to feel some pain but, to achieve something from the delay you still need to work with the supplier.
With this in mind the first item on the to do list needs to be to understand what the new dates look like and gain some confidence in them and then build a recovery plan. Don’t jump ship, keep the faith in the team who undoubtedly will have a vast amount of knowledge about the delivery and are the only ones who can get you moving forward again. Consider a new joint plan with the supplier and ensure they are aware at all levels that you are insistent that dates are achievable dates and not the ‘nice story’ to keep you happy. You have one more chance at this kind of recovery, one change of date will be ok, several false starts indicate that there is a management problem and that you need to apply measures to the delivery to ensure it can deliver.
As well as building the recovery plan it is important to understand how bad the problem is. This will obviously help you in building your confidence in the new schedule. Jan Filochowski, in his book that this blog takes its name from, ‘Too Good to Fail’ defines two types of failure on the Yosemite Curve;
- Niagara Drop – Total system failure
- Panama Canal passage – Shallow failure, one point of recovery
The type of failure will have an impact on how much effort needs to be applied to recover from and create success. When trying to analyse the degree of failure always consider both the wider picture and the immediate impact. For example a delivery that has been in plan for years that is a few weeks late need not be seen by the business as a ‘Niagara Drop’ if the end product can be guaranteed to still bring about the degree of business change and capability that has been promised for the length of the project.
Organisations and project teams are complex, living entities from which the best results are obtained by tapping into what they and the people in them already know. Their underlying experience, skills and wisdom in doing their individual jobs in order to succeed is a key asset. A tactic which a team working on a project that is in difficulty can adopt is known as ‘Increasing the area of the known’. If a supplier has not been entirely honest with a schedule then this can immediately be rectified by getting closer to the dates and by taking ownership of the schedule from a supplier, therefore increasing the project team’s ‘area of the known’. This can work particularly well where an IT solution has been outsourced and delays are experienced in delivery as it lends itself to close management of a delivery agent.
Reid Hoffman, the founder of Linkedin gives advice to the recovery of a failing project, “Fail fast, tackle the most hard problems facing your business because you need to know how you are going to get through it.” Failing fast seems an odd concept, to me it means understand failures quickly, communicate them appropriately and put in place the robust management controls that build confidence in a collaborative manner, avoid alienating the key resources. Admitting that a project is failing to the governance structure of a project requires integrity and honesty, qualities that must be matched by those being reported to. One of the most common reasons for a project moving from a Panama Canal passage to a Niagara Drop is the disenfranchised project delivery team.
There are two erroneous perceptions relating to a failing project:
Firstly, that if a project is failing it is as if it has leprosy, when in fact the right analogy is with a common, curable cold.
Secondly, the skills required to ‘turn things around’ are different to those needed to keep a project on the right track, this is wrong, they are the same skills, perhaps more strongly visible and certainly more dramatically applied.
Correcting these two perceptions is important in ensuring success. Firstly dependencies are there because they are dependant. Because a project has the ‘leprosy’ of failure does not mean that dependencies can be de-coupled, it will be better to accept the ‘common cold’ into dependant projects and cure it than to try to remove them from the delivery schedule. The second perception takes the faith of the organisation. It needs to be assured that the skills of the team are appropriate, once it has this assurance it then needs to enable the dramatic application of the skills to the project.
However, back to the title of the blog, too good to fail, is it a question or a statement? If the organisation has had faith in the delivery of a project, the correct governance and appropriate oversight then it is a statement, if the organisation has let the project run without these things then it should be a question. For informatics projects globally we ‘should’ by now have learnt the lessons and it always be a statement.