Section 5.3. Project Origins

5.3. Project Origins

In organizations, there are essentially two different types of projects arising from different needs. The bottom-up project is typically needs-driven. Someone in the organization sees a problem or need and a project is born to solve the problem. The second type is the top-down project and that is typically solution-oriented. Someone at the top of the organization wants something to exist and creates a project to make it happen. Sometimes a project has already been proposed and defined (it may have already been planned) and is then placed on hold or modified in some way before it's handed to you. We call these project proposals to differentiate them from a solution that's been handed to you or a problem that's been identified. While this may seem like splitting hairs, it's important to differentiate because these are your project inputs (see Figure 5.2, Step 1) and each requires a slightly different approach.

Some projects are driven by internal needs, while some result from external needs (client, customer, or perhaps vendor). These external projects are often projects for which clients are paying, so while the overall process is the same, there may be different checkpoints, approval points, and signatures required. We'll point out the places where these differences exist as we go.

Notice in Figure 5.2 that regardless of your inputs (where the project comes from), the steps are the same. If you're starting with a project proposal, which assumes much of the project information has been developed, you'll be validating instead of creating data. If your input is a solution or a problem, you'll be creating the project data related to the definition step to validate the problem, solution, and approach.

As we discussed in Chapter 3, corporate politics have a lot to do with project success and how you manage the political environment is key. When a project is needs-driven, it's often (though not always) easier to get the project approved, especially when everyone feels the pain. An example of that would be the need to upgrade the desktop operating system to a newer version because everyone (including the CEO or company owner) experiences the "blue screen of death" or other symptoms of system instability. The downside is that if the project is needs-driven and it's not a need that is clearly defined or directly felt by top executives, it may be hard to gain project approval. An example of this type of project is rewriting part of an internal application to provide more seamless integration with a financial package so less manual work occurs (and therefore fewer errors). This type of project is invisible to almost everyone in the organization and can be difficult to sell unless you make a strong business case (see Chapter 2 on aligning IT with business strategies).

The second type of project is the assigned project, or proposed solution. These typically come about because an executive wants to see some sort of result. This might be in response to a unique opportunity in the market that an executive wants to capitalize on or it could be a pet project of someone at the top. While this type of project may still be responding to a need, it is often assigned based on a desired outcome or proposed solution. The good news for these types of projects is that they typically have strong executive support (though there may be politics at a higher level in the organization that could cause problems later on) and that executive will use political and organizational influence to ensure the project is a success. The downside to these projects is that they are rarely researched or validated and some (or all) of the objectives may be unrealistic. We'll talk more about this in just a moment.

The third project type is the project proposal. This type of project has already been formalized to some degree. It might be a project that was planned six or twelve months ago and put on hold or it could be a project that was defined and planned and handed to you. Regardless of how much work has been done on the project, you should spend time validating the project proposal. Probably the only exception would be if you were handed a full-blown project plan that had been developed by a competent project team and you are assigned as the project manager. Even in that case, it wouldn't hurt to go back over the project plan and validate each step. After all, you're the project manager and you're the one who will be held accountable for results. It would be good to know, going in, that the project was feasible and positioned for success rather than an impossible project for which you'll be the fall guy (or gal).

Whether your project comes from the bottom up or the top down, your steps are going to be almost the same. There are a few key differences and when we run into them, we'll discuss them so you know exactly how to proceed. We're going to look at all of these elements in detail in this chapter.