So this is much more about work than horse, but it may lead me there as it is equally important to ask the right question at the right time in either context.
I first came across a stage and gate project approach many years ago in a
private sector context. Basically the idea is that every project has clear and
obvious decision points along its journey. Between those decision points, the
team does its work. While the overall vision is still what guides the journey,
between gates the tasks and work that are done relate to getting you to the next
decision "gate".
At each "gate" there are a series of checks that will be done to allow the
project to get a clean bill of health to start the next leg of its journey.
There is an implication here that a project is never guaranteed a "pass" at
the gate. It may fail the test. In which case it may either take corrective
action and represent, or the project may be closed. The resulting profile of
projects was referred to as a funnel - because there would be more projects in
the early parts of the journey than the later.
At each decision gate, the project would effectively be given delegated
authority to progress and would only need to refer back to the decision group if
the project went outside its approval (time, cost, scope, etc) and hence was in
exception. The approval was to the next gate, but with the long term vision still as the ultimate end point.
As I have worked for other companies since then, it has become clear that
many organisations use a similar approach even if they call it something else,
and their project pipeline has a different profile and shape.
In my (humble) opinion, one of the key factors in a successful stage and gate
approach is being clear what decision is being made and what authority being
delegated at each stage.
For example, an early decision gate might simply be "Is this a good idea ?
Does it align with agreed strategy ?". Such a decision would only require an outline of the idea and would only be
granting approval/authority to take the investigation to the next stage - which
in this case would be to explore feasibility and, inherent in that, options for
delivery. And to make that decision (to explore Feasibility) does not require a
high level of detail or fully explored Cost Benefit Analysis.
Even after Feasibility has been explored, it may only be possible to give a
range of figures for time, cost, scope. But the decision at the end of the
feasibility work is merely to progress to refine the solution, and confirm design
etc. At this stage the decision may be to exclude certain option - for example
"it needs to cost less than...." or "it needs to be complete by....". But again
the information behind the decision only needs to be appropriate for that
decision.
If you skip stages, then you are effectively also slipping decision points.
So you might go straight from "Is it a good idea ?" to "Can the
build/development work start ?". But if you do that, you need the information to
inform the "start" decision rather than the information you would use to agree
feasibility work. This may be absolutely the case where the feasibility and
solution are already well defined - but if it is already that well defined, the
information for a fully detailed business case should also be available with
relatively little effort.
If the decision makers require additional detail and information at the
earlier stages, there are a number of risks. For example that the figures and
detail provided are by their nature much more liable to error and will have a
much lower confidence level. Relying on that detail to inform a decision that
does not require it could mislead the decision making process. There is also a
risk that assessing, for example, financial fitness at an early stage could
provide a false sense of security and lead to less rigorous scrutiny at a later
date - i.e. that there is an implicit "pass" at all future gates if the
information has been seen once (despite its low confidence level).
No comments:
Post a Comment