Decision Gates in a staged project process

(More work/project related content that was written at work. I'm not sure the final quote is the best - but basically what I was wanted to say was "do the right thing at the right time") 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. 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 Feasbility 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 feasbility 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 feasbility 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). As Robert H Schuller said Never cut down a tree in wintertime