No one contends that we should not expend effort in evaluating project requests prior to their approval. Even organizations that only use the "squeaky wheel gets the grease" process for project selection and prioritization will usually expend a minimum amount of effort to ensure that truly insane concepts don't get furthered.
The dilemma is to know whether the effort being spent results in a cost justifiable improvement in project predictability. This is where measurement and agile techniques can help.
Measurement begins with capturing effort spent on project request analysis and evaluation activities separately from other time reporting "buckets". This is not a normal non-project activity category in most organization's time reporting systems, and there should be clear guidelines on its usage. Ideally, it should be used to capture any effort spent on project request analysis from the point of initial submission tol the point of official approval (at which time further effort spent against the project would be considered part of the cost of that project). This effort should be reported to governance bodies at quarterly or semi-annual intervals and can help to tune your work intake processes.
Checklists or other such tools can improve the efficiency of processing requests and can improve the consistency of the assessment projects. For certain types of projects, commercial estimation tools can accelerate the process of coming up with ballpark costs using either parametric or analogous estimation methods.
However, agile principles can best guide us to avoid wasting unnecessary effort on detailed planning, especially when there is a significant potential for requirements or scope flux.
Project requests should be able to demonstrate the delivery of business value in a phased or iterative approach as opposed to the traditional "big bang". This can reduce the organization's sunk cost in low value projects and will help to increase the realism or accuracy of business cases.
Assuming a phased value delivery approach, request evaluation can focus on the first couple of iterations. If a project does not merit funding based on those, there is a high likelihood that it would not benefit the organization after its final iteration. This sounds like classic “short term” thinking, but it avoids “Holy Grail” quests that consume tremendous resources but return very little when they are finally over.
Analysis of project requests to support “go/no-go” decisions is not free, but through regular effort measurement and by the appropriate application of agile principles, the value achieved through better project selection and prioritization can justify its costs.
Don’t forget to leave your comments below