Project Go – No-Go Decisions – Part 1

Posted by Brad Egeland

About 10 years ago I worked at an organization that featured a centralized PMO and required all project managers to go through the following exercise:

  • Kickoff the project with the customer
  • Document high-level requirements with the customer
  • Ballpark a solution and an estimate
  • Perform a formal project presentation to a technology council

Two things to understand first before going any further:

  • Nearly all projects at this company for the project managers were internal
  • The Tech Council was made up of internal executives

The sole purpose of the Tech Council and the PM presentations was to ensure that the project was worthwhile taking on (since everything was internal and really represented a shifting of money from one department to another rather than actual income – except where costs were being saved) and to ensure that legacy technology was not going to be used in a long-term solution when that technology was planning to be phased out and unsupported in the near future.

So, in a sense, the Tech Council was basically a go – no-go decision point early in the project. Even though it was early in the project it was a good time to ask:

  • Is this problem worth solving?
  • Does a potential solution exist?
  • Are we going about this solution in the right way?
  • Does this fall in line with our overall company goals and mission?

Justication and Feasibility

Buried in these four questions is the addressing of the issues of justification and feasibility. You should address both issues before continuing no matter what customer base you’re servicing – internal or external. If not, you run the risk of wasting time and money on problems that should not or cannot be solved. Justification—particularly financial justification—is very difficult to assess at the requirements stage, because not much is really known about the project. Nonetheless, it’s wise to try to assess whether or not you can justify continuing the project. You may be able to do this by executing a simple cost vs. benefit analysis.

The benefit component is relatively easy to estimate: it’s the value of satisfying the need. In many cases, this is nothing more than calculating how much the problem is costing today. Estimating the cost of the solution is more difficult, because you’re not sure what you’re going to do or how you’re going to do it. One approach you may wish to consider consists of working backwards through the financial calculations. By doing this, you can determine the most you’d be able to spend on a solution. If none of your proposed solutions can be executed for less than that amount of money, the project will ultimately be unjustifiable—at least from a purely financial standpoint.

The second issue, feasibility, comes down to a basic question: Do you believe that a solution exists? In other words, can this problem even be solved? This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.

Next, we’ll look at working to identify the best solution for the project and the necessity to proceed.

Share this post:
  • LinkedIn
  • TwitThis
  • Facebook
  • del.icio.us
  • Digg
  • StumbleUpon
  • Sphinn
  • Mixx
  • Propeller
  • Technorati
  • Print this article!

Related posts:

  1. Project Go – No-Go Decisions – Part 2
  2. Determining Feasibility of the End Product
  3. Process Trumps Technology
  4. Project Go – No-Go Decisions – Part 3
  5. What if…The Project Budget had No Limits?

Tags: , , , , , , , , , , , , , , , , , ,

3 Comments to “Project Go – No-Go Decisions – Part 1”

Post comment

Spam protection by WP Captcha-Free