Kicking the can down the road
I guess it has happened to the best of us. You’re on a project, whether it is during sales, analysis or even development, and your customers utters the sentence: “Well, since we don’t have all the information yet, let’s take this vague path, and we’ll see how it turns out.” The customer just kicked the can down the road.
This innocent sentence is a potential trap since you’re now dealing with a “known unknown”, or to put it in other words: “A Risk”.
When you’re in a similar situation your first reflex should be to ask the following 3 questions:
- WHEN will we evaluate the solution? (Planning)
- WHAT will be the conditions against which to evaluate the solution? (Scope)
- HOW will we react if the solution does NOT pan out like we’ve expected? (Action)
Planning (WHEN)
So, the first question you need to ask is: “WHEN”. It is important that a fixed point in time is communicated with the customer to assure that the new solution is being evaluated.
It is up to the customer and the project manager to decide how much risk they want to take. Are they prepared to wait until the entire solution is developed before evaluating? In this case, the possibility exists that the solution is not fit for use and everything needs to be redone.
A better way to go (especially when the proposed solution is uncertain or vague) is to cut it into smaller iterations and evaluate early. This way, problems can be caught in an early stage and corrective actions can be performed.
Scope (WHAT)
Now that we’ve set out one or more moments of evaluation, it is important to define exactly WHAT we’re going to evaluate. Since a customer (or even your team itself) decided to take an uncertain approach to a vaguely described scope (e.g. we need to generate reporting, yet we don’t know exactly what tool to use, or how data should be represented) it is important that everybody is on the same page as to what criteria need to be fulfilled.
This evaluation process is linked to planning. The later you evaluate the solution, the more precise the scope should be, since there is little or no way of correcting the approach afterwards.
Once again, the greater the uncertainty of the scope, the shorter the iterations should be, but even short iterations need to have fixed criteria, and deliverables up front. These criteria define the scope of the iteration.
Action (HOW)
Last, but most definitely not least, the customer needs to be informed about potential actions, should the result of the evaluation turn out to be unsatisfactory. Usually the “we’ll see” sentiment originates in the inability (or unwillingness) to make long term decisions.
However, kicking the can down the road, is never a good strategy when dealing with projects. Sooner or later these potential time bombs come to detonate, usually in a late stage of the project when budgets and deadlines are tight.
So, it is of utmost importance that the customer is made aware that the suggested solution might not work out. A worst-case scenario needs to be set up in advance, and follow up actions (extra budget, change in deadlines, drop the feature altogether, …) need to be communicated.
Conclusion
So, in conclusion: when working on a project it is important not to fall in the trap of pushing risks down the road because information is missing.
Either delay the development until more information is available, or adapt iterations according the vagueness of the proposed solution. Plan your evaluation moments, define the scope of each iteration and communicate a plan “B” if the worst would come to happen.
Hope you enjoyed my writing!
Please don’t hesitate to contact me if you think I totally missed or hit the mark.
Subscribe to our RSS feed