Project Justification Guidelines

After a very lengthy explanation process we finally received budget approval on a network expansion/reconfiguration project. This approval process was made exceptionally difficult due to recent upper management changes that left the main decision makers consisting of managers with no I.T. knowledge or experience. This is a common problem in a Japanese owned company where the upper management cycles out every four to five years. This problem is often compounded by language limitations as well.

However, we made mistakes in the way we prepared the explanation and documentation for approval. Here’s some project justification guidelines we normally abide by, but in this case detoured from.

1. Each part of a project must be treated as if it has to be justified on it’s own merits. Our network expansion was a small part of a much larger project that included building remodeling and the moving of some departments and offices. We made the mistake of assuming that since the over-all project approval was a forgone conclusion that our portion would be easily approved as well. We did not do the depth of work that normally is done.

2. Know your audience, their’ level of knowledge on your subject matter, and anticipate what their questions may be. When questions were asked about the network expansion that required technical explanations, we were not prepared with material at the proper level that would make for an easy explanation. Our additional material was much too technical to be easily understood by our audience, leading to confusion and lengthy explanations.

3. Offer more then one solution for consideration and clearly explain your choice or recommendations. In our case the selection of the source for outside services was a given. We’ve had a long-term relationship with a company that has done work here before, knows our network, provides a quality service, and a fair price. We know this, but the new upper-managers did not. We still needed to confirm that the services we were getting were best for our company.

4. Layout the whole story. Explanations should always follow the basic storyboard format when possible. Parts of the story include:

• The Current Situation ‚Äì Explain what the current situation is.
• The Problem ‚Äì Explain the problem with the current situation. This may be an on-going issue that requires a countermeasure or simply an improvement.
• Problem Solutions – Solution/Countermeasure Comparison ‚Äì Examine and compare possible solutions. Show all possible solutions and explain selection criteria.
• Selected Solution, Expected Results, and Schedule – Expand on selection solution and project expected results. Define a overall schedule for implementing the solution.

Use as much graphical/visual representation as possible in your explanations. Pictures, charts, and graphs are pluses. Flow one section of your story into the next using guiding arrows or lines. Make it easy for your audience to follow your thought process and reach the same conclusions you did. If they can, then agreement is much easier gained. In our recent network project experience we didn’t do step four because of the assumption that I explained in step one (expecting a rubber stamp approval). Our mistake. If we’d followed these guidelines it would have cut a month off the approval process.

I would be interested to know if anyone else has similar or different guidelines.