IT Manager's Handbook: Getting Your New Job Done (28 page)

•
Resource availability might be less of an issue if multiple resources for the same task can be identified. It sounds easier to do than it is, but sometimes you can find others to cover your bases.

•
The risk of implementing new technology can sometimes be mitigated with adequate training and testing time.

•
Interdependencies can sometimes be addressed by simply alerting the various parties that they are part of a larger schedule.

•
The constraint of resources during the year-end closing can sometimes be addressed via juggling the scheduling in ways that don’t affect the final deadline.

The
Project Charter

The Project Charter is the document that really launches a project and covers everything addressed in the previous sections:

•
Scope

•
Objectives

•
Sponsors and stakeholders

•
Constraints, interdependencies, and risks

The Project Charter may also have a formal signature line for sign-off. In addition, it often provides estimates of the items discussed later in this chapter:

•
Time frame estimates

•
Resource estimates

•
Cost estimates

•
Roles and responsibilities

Depending on the project, it may warrant investing some time to determine these so that the estimates just listed are more than educated best guesses.

As mentioned earlier, in addition to identifying what’s in scope in the Project Charter, it could be very valuable to also identify in this document those areas that are out of scope. When complete, the Project Charter often becomes the “bible” for the project. It’s the document that everyone references throughout the life of the project. When there are issues of scope creep, the Project Charter can serve as a reference to determine what’s in and out of bounds for team members to work on.

Get Historical Perspective

Some projects are brand new events with no precedent. But these are the exceptions. Most projects have some history to them—some kind of background that can help you put the entire venture into perspective.

•
Was a project similar to this one undertaken by the company before? If you are installing the servers for the new office in London, see if the notes and personnel for the expansion across the street that was finished last year are still available.

•
Do some of your team members have comparable experience you can leverage? If the two technicians who installed the phone system last month are available, can you get them on this team to help with the network installation?

•
Does the executive management of the company remember similar work? Does your boss recall the two previous laptop upgrade projects? If he doesn’t, remind him that in 2011 (and way back in 2008) it took twice as long as anticipated to get machines in from the field.

Steps like these can help smooth your project planning and management considerably. For a further discussion of the value of historical perspectives for projects, see the section
“Time Estimates”
later in this chapter on
page 112
.

4.3 Phase Two: Develop a Project Plan

Three Critical Components to Any Project

Every project has three critical components: time, money, and resources. You will also see this concept displayed as a triangle (see
Figure 4.1
).

Figure 4.1 
Three key components of a project.

The point of this graphic is that the
interplay
of the three characteristics of a project—time, money, resources, and how each relates to the other—directly affects the quality of a project.

For example:

•
You might have plenty of time to install a new server (the application it will run won’t be installed for another month), but if you don’t have enough money (your boss doesn’t want to pay for the high-end configuration you recommend) or the resources (both technicians who do this work routinely are gone—one has left the company and the other has been reassigned), the quality of the project will suffer.

•
Money may not be an issue (“spend whatever you need” was the instruction you heard from your boss on the new “mission critical” Sales force automation deployment), but if it’s only one person doing all the work for 200 users and the work must be done “yesterday,” the quality of the project will suffer.

•
You might have all the resources you need (you have five people of your own plus two from the vendor for installation of a state-of-the-art video conferencing facility), but you haven’t been given enough money (the whole budget for the setup only included the cost of the hardware and didn’t consider the cost of installing it) or enough time (people are moving in on Monday—
this
Monday), the quality of the project will suffer.

Think about each critical component of a project carefully when developing a project plan.

Write the Project Plan with the
Closeout Report
in Mind

It sounds contradictory to plan the beginning with the end in mind, but in fact, that’s exactly what you should do to achieve maximum project success. Everything you do, from the first planning meeting to the final celebration party, should be executed with the final result in mind. If you plan this way, the end result will force you to constantly act in certain ways, making decisions based on certain criteria. And that way of working will result in a far better outcome. Specifically, write your Project Plan with what you want to say in the Closeout Report; see the section
“Writing a Closeout Report”
on
page 121
later in this chapter.

Now that you know what you’ll say at the end of the project, prepare to be ready to say it at the beginning. Be as specific, actionable, and quantifiable as possible. “Make the Sales department happy” isn’t actionable, specific, or quantifiable; you may (or may not!) make them happy by executing this project. Regardless, it will be hard to quantify. In your plan, write a goal such as “install, upgrade, or refurbish all laptops in the Sales Department by January 1.” When the new year rolls around, you will be able to say that you have achieved the goal of that project. The guidance given in the section
“Development Plans and Goals”
on
page 52
in
Chapter 2, Managing Your IT Team
, for developing staff goals can be very helpful for project goals.

Another useful suggestion is to include how much money you will save the company: “upgrading the Web-hosting facilities will cost the company $10,000 a quarter, but initial estimates are that faster processing time, more availability, and larger storage capacity will save the company a minimum of $25,000 per quarter for the first year alone.”

Time Estimates

Next, determine how much time this project will take. Determining how much money and how many people you’ll need is hard, but figuring out how long a particular project will take is even harder. Most people don’t estimate time well. Some people are excellent at determining the approximate length of a project, but keep in mind that estimating is a poorly practiced art. Knowing this fact in advance will help you evaluate not only your skills in this area but estimates you receive from others.

The best place to start with time estimating is to find out if there is history: Has a project like this been done before? If so, how long did it take? That doesn’t mean that if it took two months to install a previous version of the operating system across the company that it will take two months this time. (OS upgrades have gotten much more efficient and people are much more familiar with the process. But still …)

It may not take you the same amount of time as before, but it gives you a framework to operate under. You have a general idea of how much time this will take. And, when you present your project plan, you can add that historical data to your report. (“In 2010, it took us two months to get everyone up and running with Windows Vista. We propose to do this new Windows version in three weeks maximum.”)

Sometimes, however, you won’t have a historical record to work from. You will be executing a project for the first time. In that case, be sure to do two things:

1.
Have
some
basis for your estimate. If you’re essentially guessing that something will take two years, it should be based on estimates of the time required for the component tasks.

2.
Overestimate
. You’re working with the unknown and you should estimate accordingly. Most people usually plan for things to go well. You also have to try to account for unforeseen problems, conflicting priorities, and “unreasonable” demands.

A helpful way to estimate a project is to get all the key participants in a room to talk about all the things that have to be done, the order in which they have to be addressed, and approximately how long they will take. Ask questions such as “And after that will we be done?” or “What
exactly
do we have to do to get that task done?” Continue to drive things to a finer level of detail and help get all the requirements and tasks out for discussion.

It’s common to come up with a time estimate as a group—members of your project team (see the section
“Decision-Making Techniques”
in this chapter on
page 122
) will all have opinions about how long a project will take. Some managers take the number proposed and double it. That may sound devious, but as mentioned before, time estimation is a notoriously difficult thing to do. You’ll be much happier overestimating than you will underestimating. It seldom occurs that more time is given to an IT project than is required. It happens, of course, but not very often.

Also remember that when time is estimated, everyone has to factor in that all team members are seldom working on only one project. They are usually working on this project as well as several others, in addition to everything else that they have to deal with on a day-to-day basis. For example, a certain task may only take a few hours to complete, but the employee won’t be able to get to it for a week because they are already committed to another project.

Resources Required: Employees (Internal and External to IT)

For team members who report to you, it’s easy enough to assign them to the project, but you can’t simply go into other departments and assign individuals to your project. You need to meet with their department heads and explain your project to them and what resources you’re coming to them for. This may take a great deal of diplomacy, especially if the various department heads don’t have much of an interest in your project. It is at times like this that you’ll need to call on your well-defined objectives, explain how those objectives fit in with the overall company goals, and be ready with an explanation of how your project positively affects the person you are talking with. When the objectives don’t convince them, you can either reevaluate your project and objectives or call on your project sponsor to place a phone call or write a quick e-mail to help dilute the resistance.

Full-Time versus Consultant Employees

For a full discussion of the reasons to hire a full-time employee or a consultant, see
Chapter 3, Staffing Your IT Team
on
page 65
. The short story is that each has its advantages and disadvantages, depending on the circumstances and need. The nature of the work also helps you determine which kind of worker is your best choice. One of the advantages of consultants for projects is that they will usually be dedicated solely to the project, whereas full-time employees usually have many other responsibilities in addition to your project. Also, if a consultant is only needed for the duration of the project, their assignment can be terminated easily when the project wraps up.

Vendors and Service Providers

You may have vendors involved in this project, perhaps on a consulting basis, to implement a new application or on a support basis. You may also have service providers, such as telecom carriers, that are critical for getting certain components implemented.

It’s important that you identify all the resources required and identify constraints and parameters of their involvement. In some cases you may have a resource completely under your direction (such as an employee or consultant) or you may have limited access (such as a vendor’s technician only being available to you for two weeks). In some cases you may feel almost helpless regarding certain resources, such as waiting for your
ISP
to deliver a new circuit or a hardware vendor to ship a particularly constrained item.