5.8. Gaining Validated Project Proposal Approval
By now, you have a solid understanding of the purpose of the project. You've done some initial work with a small expert team and you've developed your project's problem and mission statements, you've looked at potential solutions and narrowed down the list to either one selected, optimal solution or a ranked list of the top potential solutions. You've looked at the corporate and IT strategies and determined which solutions make the best business case and which ones support the direction the company is headed. If these don't all add up to the project everyone had in mind, you've got a minor problem to address. It means the results of your project planning thus far don't map with the assigned project or the project proposal or the problem that was identified. That disconnect is important information that shouldn't just be swept under the carpet. Instead, take time with your team and/or your project sponsor to identify the problem. It might be that in the process of looking at that problem you uncovered a fundamental flaw in your thinking (not necessarily you, personally). This is the best time to discover these kinds of issues because you can develop alternatives and solutions now rather than trying to patch together a solution later in the process. Of course, some companies and some executives just don't want to hear it. That's ok. Your job is to validate the project proposal and bring your findings to your project sponsor for approval. If he or she says, in essence, "I don't care about your findings, just do this project in this way," you'll probably have to do that. Be prepared, however, for problems down the road if the best solution is not the one implemented. On the other hand, also keep in mind that corporate executives often have access to information that you may not have and their rationale for moving forward with a project might be very well founded even if you are not privy to the details.
Earlier in the book, we discussed aligning your IT projects with corporate goals and objectives. If you haven't done so, you should also make the business case for your IT project. That might include doing a cost/benefit analysis or a SWOT analysis (strengths, weaknesses, opportunities, and threats) to verify this project is aligned with IT and corporate goals. Since we covered that earlier, we won't repeat it here, but your project proposal ideally will include the business case for the project as well as the other data discussed.
Once you've got all this data assembled, you should compile a project proposal. If you were handed a project proposal, you can modify or revise it as needed based on your team's findings. Documenting and summarizing your process results (problem statement, mission statement, etc.) to this point in a formal project proposal document will help you keep track of what's been done and why so you don't have to revisit this section of work again and again. Write up the project proposal using whatever format your company prefers or requires (visit www.syngress.com/ solutions for a project proposal template you can download and use) and set up a time to meet with your project sponsor. If you've included a target for scope (the total amount of work to be accomplished), time, cost, and quality, make it absolutely clear these are targets and not commitments at this point. Later, after we've developed additional project detail, we will make commitments on these four elements, but for now, without extensive time and research, you should avoid committing to these targets. That may not always be possible, but it should be your goal. One of the big dangers of targets at this point is that they somehow get translated into commitments through the corporate process. Tread carefully here.
Project proposal approval, ideally, should be a signature on a piece of paper or an e-mail stating approval for the proposed project (see Figure 5.8). It's important to have your project sponsor formally agree to the work and assumptions done this far. After all, you should both have some skin in the game. If you have no formal approval here, it's possible the project sponsor might not back you up if things get political or the project goes south at a later date. Formal approval makes both the project manager and the project sponsor responsible for the project. There are numerous approval points we'll discuss in the project planning and project managing phases and each is important. However, every company has different ways of dealing with these types of activities and if you suddenly show up with a pen and paper for someone to sign when that's not how your company does business, you're going to either get some very strange looks or create a bit of paranoia. Use your best judgment, but do get formal approval in writing (paper or electronically) at each approval point whenever possible.
One last comment here. Sometimes a project makes it to this point and is scrapped. That's why the diagram shown at the opening (and end) of this chapter (refer to Figure 5.1 or Figure 5.9) shows the small oval that says "Terminate project." Sometimes you can't validate the project, other times factors have changed significantly causing you (and/or your project sponsor) to decide to scrap the project or put it on hold. So, sometimes you'll move ahead with a project at this point, sometimes you'll need to go back and rework things and sometimes you'll agree it's time to leave this project behind and move on. If you believe the project still has merit, you'll need to negotiate and make a convincing argument. Otherwise, view a scrapped project as a winyou avoided wasting precious time and resources on a project that should not have proceeded and you've done your job.
Figure 5-8. Validated Project Proposal Approval