In Chapter 5, you learned how to validate a project proposal that was assigned to you and to develop a high-level definition of an IT project. In this chapter, we're going to continue along that same line, adding detail and organizing the project as well. As you know, IT project management (IT PM) is an iterative process and you'll revisit various steps more than once. It's also true that in many instances, IT PM steps occur concurrently or out of order. For instance, it's possible that during the high-level definition stage, you also developed additional project definitions and data that we'll discuss in this chapter. While there is a logical flow to the IT PM steps, in the real world things don't always follow an ideal order. The key is to properly define and organize your IT project before you start actually doing the work of the project, whenever possible.
If a project is in trouble, the steps we're going to discuss in this chapter are often the ones that were skipped. If you're taking over a project, especially one that's flirting with disaster, go back and review or verify the steps listed in Chapter 5 and this chapter. You need not do all the steps with the same rigor or with the same level of detail, but you should verify these steps were performed and performed correctly if you're working on a project that is faltering. You should also review the conclusions and decisions made if the project is in trouble because it's often here that trouble begins (usually by skipping these important preliminary steps).
In this chapter, we're going to develop a bit more project detail including elements such as priorities, specifications, user requirements, and project infrastructure, to name just a few. Before we get into the details, let's review our IT project management overview diagram, shown in Figure 6.1, to keep track of where we are and where we're headed.
Figure 6-1. IT Project Management Process Overview
Now that you see where we are in the process, let's define a few terms we'll be using in this chapter.
Assumptions The information and concepts that are assumed to be true (or false) at the outset of the planning phase of the project. Clearly identifying relevant assumptions can be helpful in avoiding mistakes later in the project.
Customer or user A customer or user is defined here as anyone who will use or rely upon the output of the project. Customers/users can be internal or external, existing (current), or targeted (desired).
Derived requirements The requirements that are derived or come from primary requirements of the project. They may be additional technical requirements that stem from stakeholder requirements.
Flexibility matrix A matrix or grid indicating the relative flexibility of project scope, schedule, and resources. This is used as a decision-making tool to help the team make appropriate decisions throughout the project management process. Schedule-driven projects have the least flexibility in the schedule, for example.
Framework The processes and procedures your project and project team will use to successfully implement and manage the project.
Major deliverables This term is used interchangeably with objectives to indicate the high-level outcomes for the project.
Objectives High-level statements about what the project will accomplish. These are typically categories of work to be accomplished in the project. This can also be called major deliverables.
Precision The term precision will be used interchangeably with rigor. How precisely you execute each step of the project management process will depend greatly on the complexity, expense, and criticality of the project.
Project organization The team that will be involved in the project including the project manager, project sponsor, core project team, and contributor team.
Project parameters The defining of the project objectives, scope, budget, timeline, quality, success criteria, flexibility grid, and deliverables. This may also include hardware or software boundaries or requirements that set the minimum criteria for project expectations.
Requirements The elements the project must deliver to meet the expectations of the stakeholder(s) and project sponsor. Also called primary requirements.
Rigor Rigor, or precision, is used to define how much or how little detail and effort you apply in each step or phase. Very rigorous planning is required for complex, expensive, or critical projects. Less rigor is often acceptable for shorter, more "casual" projects.
Stakeholder Anyone with a stake, or interest, in the outcome of the project. This typically includes those people outside of the project including the project sponsor, users, customers, vendors, corporate executives, and/or shareholders. Although the project management and project team have an interest in the outcome of the project, they are internal to the project and are usually excluded from the collective term stakeholder as it pertains to project outcomes.
Success criteria The clear, concise, accurate statements that indicate how the team, project sponsor, and organization will know that the project is successful.
As we did in Chapter 5, we also have a flowchart for the inputs, actions, and outputs of this phase of the IT project planning process. Figure 6.2 depicts these elements. If you're not a flowchart kind of person, don't be put off by these diagrams. They are intended to simply help you visualize the process we'll describe in this chapter.
Figure 6-2. IT Project Organizing Phase
Within the Organizing the Project step or phase, there are six discrete steps. Let's discuss each one briefly so you know what the inputs, actions, and outputs are for this phase.
INPUT The input in this case is the validated, approved project proposal, which was the output from the previous step (see Chapter 5). If your organization does not use a formal project proposal, you should at least have the data collected during the defining stage of the process, which includes the problem statement, mission statement, potential solutions, selected solution, target scope, target timeline, target budget, and target quality.
ACTION Using your project proposal (or equivalent data) as the starting point, we'll go into the project organizing process described in this chapter. This process is a defined set of steps you'll use that will result in a more detailed project document. It is at this point that the project should begin to take form. You should have key data compiled and you should create a formal method for storing this data. You should also have defined the ways in which you and your team will work with the project sponsor.
OUTPUT The output from this phase or step is a formalized system or method of storing project data. This is referred to as the project notebook, project workbook, or high-level project plan, and it can be in the form of a physical notebook, a virtual notebook containing files stored in a folder on a shared network drive, or files stored using your company's collaboration tools (Lotus Notes, Microsoft SharePoint, corporate intranet, etc.). Regardless of the form it takes, there should be a formal document storage process in place before you go on to the next phase.
CHECKPOINT All the high-level data should be approved by the project sponsor at this point. This includes the project objectives, parameters, and stakeholders, among others. In some projects, this step may not be necessary, but typically you should gain agreement from your project sponsor on the content and frequency of project checkpoints moving forward.
DECISION POINT Based on the response of your project sponsor, you'll either need to go back and re-work parts of your project documentation or continue on to the next step, planning your project. If the sponsor gives the project the go ahead, you continue. If not, you will have to address the project sponsor's specific concerns and revise the project parameters and submit it for approval again. This may be an iterative process where you'll need to make several revisions before the project sponsor agrees to the document. It's also possible that based on the information gathered thus far, the project sponsor (or project manager) recommends terminating the project. This can occur if it becomes clear that with the additional data provided that the project just doesn't make sense. A project can (and should) be cancelled at any point before actual work begins if the project parameters shift or if the external environment shifts in such a way that the project no longer makes sense.
NEXT STEP Once you have approval from the project sponsor for the additional project details developed in this stage, you can move on to the detailed project planning process. These steps are discussed in Chapter 7.
Defining and Organizing Your IT Project
In Chapter 5 and in this chapter, we're discussing ways to define and organize your project before you get into the detailed planning stage. The reason for this is because if you don't properly define what you're going to do, the detailed planning may either have to be redone or your project may ultimately address the wrong problem or provide a "useless" solution. Through these stages, you not only get a good idea of what the project will look like, but you have a great opportunity to get feedback from the project sponsor. Changes are very easy to make at this stage and if you can define the project clearly and concisely at this point, your detailed planning stage will be a lot easier. Lack of clearly defined project goals and objectives are a major cause of project failure, so success starts here.
Keep in mind that if you have a small project, you can abbreviate these steps and phases. You shouldn't skip any of these steps, but you can shorten them. For instance, on a small, two-week project, you may write up a one-page project proposal that identifies the problem, mission, solution, target scope, budget, and timeline. You should be able to generate this document in under 30 minutes. The project sponsor can approve this document and you can move on to the organizing and planning stages quickly. A short, easy project requires far less detail and far less structure than a large, complex project, though the steps you take each project through should always be the same. Remember, process for process' sake is a waste of time, but having a defined process or methodology that you can expand or shrink as needed will make your planning more consistent and your projects more successful.