Project Rescue: How Projects Reach Crisis
Kinneir Dufort is often called in when a project is in trouble or facing seemingly unsurmountable challenges. In this article, our Head of Technology, Paul Jennings will be sharing common pitfalls, how to recognise them, what to do about them and how to avoid this unhappy situation when planning a product development.
Having worked in consultancy for over a third of his career, Paul has witnessed both successful and unsuccessful technical project developments and says the team have become somewhat familiar with the “rescue” process. In this article, he draws from his experience and talks about how he has observed the causes of a failed project remain consistent and predictable (on the whole) and yet sadly, they are repeated time and again irrespective of company, product or sector.
Let’s start with the pitfalls.
Forgotten Magic of Marketing
Sales and marketing should be your eyes and ears on your customers’ world
A project can, of course, be destined for trouble even before it has started. This happens when internal discussions have not been extensive enough and, in some cases, have not taken place at all. In other words, key stakeholders have not been identified or involved. The most obvious of these is the lack of involvement of sales and marketing. Although sometimes the butt of engineering department jokes, sales and marketing should be your eyes and ears on your customers’ world. If you can’t sell it, there is no point making it. If the price point is wrong or the feature list provides no benefit over the competition, you won’t sell it. If it doesn’t fit with the company’s core business, the risks and the cost of entry into a new market may be too high. In smaller companies and start-ups, everyone is part of the process and this is less likely to be a problem but in larger ones, it is surprising how many “pet” projects get a long way down the line without these discussions taking place.
Misguided hope that it can be sorted out later
A less obvious trouble spot in the early stages are the commercial agreements. If the project needs external specialisms that can only be covered by an external agency or contractor, and the business is not used to dealing with such resource, commercial departments can often try to impose unworkable service level agreements (SLAs) or terms and conditions (T&Cs) on a design partner. Again, this is more likely in a large corporation where the distinction between a distributor or parts manufacturer and a service provider is not understood – particularly when the use of a design consultancy is new to the business. If project work is engaged prior to the resolution of conflicts at this stage (with the misguided hope that it can be sorted out later) there is a real danger that an impasse will terminate the project.
FINDING the Balance
A change of course has both time and cost implications
The next pitfall is one of the most ubiquitous – that of failing to adequately specify the requirements. Dare I use that much-used quote from Albert Einstein? – “If you can’t explain it simply, you don’t understand it well enough”.
I’d rather use “clearly” as opposed to “simply” in this context but nevertheless, the sentiment remains the same. If you consider the specification phase to be a waste of time, or that perhaps you know exactly what you want and can personally guide the development, or that once again the it can be “sorted out later” (there’s a theme developing here!) – then think again.
Failure to specify adequately almost certainly leads to trouble down the line. Even the simplest requirement can have far-reaching implications. For example, if a product must “show its status on an LED” then this, as a requirement, is insufficient. You might well ask:
What are the status conditions, and how many are there?
What’s the priority if more than one condition is coincidental?
Can they all be shown on one LED and if so, does this include flash sequences or multi-colours?
The implications for both hardware and software can be clearly understood even in this trivial example. Invariably, poor specification will only delay these questions arising – often when design choices have been made and a change of course has both time and cost implications.
There is, however, the opposing issue of over-specification. This is practically impossible for functional specifications but particularly relevant when asking a design partner to develop hardware, whether this is from a mechanical, industrial design or electronics viewpoint. If your decisions and constraints are based on tribal knowledge, quick internet searches or any other cursory study, it may be as insufficient as our LED example – but far more costly to rectify. In the worst case, it could prevent the solution from delivering against the functional specification.
So with contracts sorted and the project well specified – what else can go wrong? Plenty.
Project costs are under-estimated for several reasons but over-run can lead to a decision to terminate a project, and I have seen this even when millions of pounds have already been spent. Pressure to deliver to a set budget without de-scoping the requirements can lead to blind optimism if the project is internally run, or to selection of the cheapest quote after pushing design partners to the limit (or beyond). There is, of course, nothing wrong with obtaining a good deal but unless this is tempered by careful consideration of trust and added value, it could spell disaster.
CHOOSING YOUR TEAM
Not to put too fine a point on it – you may have selected the wrong team
This can happen both externally and internally. An external team selected on price alone may not have relevant experience or be adequately resourced. If this is the case, they will burn precious time and money “getting up to speed” and may shift resource around to keep the plates spinning - and that is highly inefficient.
A trusted partner will not try to rip you off. They will have your interests at heart, have the right credentials and you will have a relationship that will see you through the inevitable tough times in the project development lifecycle. They may even be pushing the boundaries of their own experience but if you know that they are particularly technically adept, this may reduce the risk.
An incorrectly selected internal team will also lack the relevant experience but now they are unable to critique, verify or constructively challenge the external team. The nightmare scenario is where the wrong internal team is driven by the wrong external team – and no-one understands what is going on.
Plan, Plan and Plan Again
Failure to take dependencies into account can...question the financial viability of a project
We have considered poor specification but poor planning is another common error. A poor plan fails to properly address tasks, resource and (more commonly overlooked) dependencies. The better your tasking out and resource allocation is, the better chance you have - but failure to take dependencies into account can lead to severe slippage, possibly beyond a launch date. This of course leads to lost revenue and may call into question the financial viability of the project. Dependencies cannot be confined to simple task blocks but must be extended to include logistics considerations.
Culture and Location
You are in an enviable position if...
You are in an enviable position if all your team members, design partners and manufacturers are on the same continent, let alone in the same country. Fail to make allowance for the additional overheads of dispersed teams working across time zones, the differences between cultures, communications challenges and shipping times, and you will be planning for failure..
Legitimate as these (RISKS) may seem, most can be avoided through well-defined project quality procedures
Finally, there are the seemingly legitimate reasons for project failure, such as technical roadblocks, changes to the business case, or unforeseen changes in legislation. For example, and at time of writing, the R&TTE directive is to be replaced by RED on 13th June 2017. For anyone already embarked on a connected device development containing either a radio transmitter or receiver, this could have significant financial and technical impact. Then there is component obsolescence, the demise of a single source supplier etc… But legitimate as these may seem, most can be avoided through well-defined project quality procedures. Under EN ISO 13485 for example, risk assessment and ongoing risk analysis would address most of these. Technical roadblocks are seldom fatal and a partner with both a broad and specialist knowledge base should be able to minimise this risk, unless the project has a high research content. Changes in business case, however, returns to where we started and the involvement of the right stakeholders.
Like building your house on sand
We have covered many aspects of project failure, however briefly. How many do you need before things go wrong? It’s hard to answer this with certainty, and it depends on severity and combinations. You may get away with a poor specification if your team is co-located, agile and creative. You are likely to get away with a lack of internal experience provided you have selected the right partner. You are more than likely to fail if you have no experience and you select the wrong partner, or if planning is poor. And failure to engage the right stakeholders at the beginning is like building your house on sand.
Project rescue is about assessment of all these factors explained above, and getting a project back on a firm footing. If you would like to talk to the team about any of the topics mentioned in this article, or if you are at a tricky stage with your current project which you would like to talk through, don't hesitate to get in touch - we would love to hear from you. email@example.com
Paul Jennings, Head of Technology at Kinneir Dufort