Section 6.9. Solutions Fast Track

6.9. Solutions Fast Track

6.9.1.

6.9.1.1. Identifying Project Objectives

Develop the project objective statement, which helps focus you on what outcome(s) you're trying to achieve.

Develop three to five major objectives or major deliverables based on the work you've done to this point (problem, mission and solution, target scope, time, budget, and quality).

It's usually helpful to define what is and is not included in the project to avoid making incorrect assumptions.

6.9.1.2. Identifying Stakeholders

Stakeholders are those people or groups who have a vested interest in the outcome of the project. Users are a particular subset of stakeholders who are most impacted by (and who impact) the project.

Stakeholders should be identified before requirements are developed because ideally, requirements should be the result of identifying and addressing stakeholder needs.

Stakeholders can be categorized to help you sort through their needs, demands, and requirements. Three categories that might be helpful to you are influential, involved, and informed.

Influential stakeholders typically include users who both influence the project's direction and are influenced by the final result.

Involved stakeholders are those who need to be involved at some point during the life of the project. This might include the Marketing or HR departments, for instance.

Informed stakeholders are those who need to be informed at certain points along the way, but do not need to be directly involved in the project. This might mean keeping other departments up to date on the status of your project even if your project work or results have no direct bearing on them.

6.9.1.3. Identifying Project Requirements

Identifying requirements begins with correctly and thoroughly identifying and categorizing stakeholders.

Defining the project's requirements is an iterative process that may also involve negotiation. As the IT project manager, you have a good idea about what's possible and what's not given a certain scope, time, cost, and quality requirement.

A project that does not meet user requirements is, by definition, a failure. Make sure you negotiate and gain agreement on user requirements before moving forward.

Requirements typically fall into one of four categories: user, business, technical, and functional.

6.9.1.4. Refining Project Parameters

Success criteria and acceptance criteria are two very important parameters to define for your project. Success criteria are specific (preferably measurable) measurements you, your team, and your project sponsor will use to determine that the project is/was successful. Acceptance criteria are typically used when users must accept (which often translates into pay for) tangible deliverables from the project. It is critical to define these criteria clearly and in a binary manner.

You should refine your target or estimates for scope, schedule, cost, and quality for the project at this point. You will continue to refine these metrics moving forward, but as you more specifically define the project, you should be able to home in on these estimates.

The flexibility grid helps you identify which elements of the project are most and least flexible according to your project sponsor. This helps you make decisions about change later in the project that are aligned with the sponsor's priorities.

If you are aware of constraints, limits, and risks to the project at this point, they are worth noting. In some cases, these may be quite significant and cause you (or the project sponsor) to re-evaluate the feasibility or desirability of the project. If the project is terminated as a result, you should view this as a win for stopping a "bad" project from going forward.

If you are aware of any milestones at this point, you can also record those. Milestones are not typically developed until later in the planning process, but if you are aware of any, they should be recorded now so they are not overlooked later.

The initial project plan, which is the result of the steps in this chapter, may also be used as the basis for a Statement of Work or Project Charter document. Some companies use these terms interchangeably, and some have specific elements they require for such documents. All three (SOW, PC, and IPP) serve to clarify and document the high-level information about the project so the project can gain the official green light to move forward.

6.9.1.5. Defining Project Infrastructure

The infrastructure needed for the project may include communication and collaboration tools for the team, communications devices (cell phones, PDAs, laptops, etc.), and other technology components needed to successfully complete the project.

Infrastructure also includes the project team's needs in terms of office/desk space, office equipment (desks, cubicles, chairs, etc.), conference rooms, labs, or test equipment needed to successfully complete the project.

6.9.1.6. Defining Project Processes

If you have defined project processes and procedures in the past that have worked well, reuse those.

If your company has defined processes and procedures you are required to use, start with those and add only as many additional processes or procedures as needed to drive project quality and efficiency. Too many procedures can hinder productivity and quality.

There are many different kinds or processes and procedures you can define. Some of the more commonly used ones include defining how status will be reported, how issues will be tracked, how changes to the project will be requested and approved, and how issues will be escalated.

Additional plans related to the project may be required and these can be defined as project procedures. These may include a communications plan, a deployment plan, an operations plan, and a training plan. Not all projects require all of these plans; some projects require other plans not listed here.