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

Area Project Manager

Davai International, Inc.

A Project Management Office

In larger organizations, the volume of project activity is so large that it may warrant the creation of a Project Management Office (
PMO
). In its simplest form, the PMO watches over all projects via the individual project managers and acts to ensure that projects are progressing effectively and that project managers are being vigilant. The PMO also serves as a traffic cop to ensure that projects aren’t interfering with each other, overusing resources, and leveraging from each other’s efforts, spending, etc. Depending on the organization and its size, a PMO may be specific to IT or it may be a resource for the whole company. In the latter situation, a PMO could be overseeing all sorts of projects—everything from re-IP-ing a network to redecorating the cafeteria.

In addition to overseeing the projects, the PMO also sets standards for project methodology within the organization. It can define best practices for project management within the organization; this can include project methodologies that are used, processes for determining justification, return on investment (
ROI
), formats for common types of documentation used within a project, metrics, and more. In highly regulated industries, or particularly complex organizations, the PMO can help ensure that projects are being handled in a consistent manner and adhering to compliance requirements.

4.2 Phase One: Scope the Project

A project generally starts as an idea—either yours or someone else’s. At the very beginning, a project is usually short on specifics. There’s no framework for costs, time frames, or the resources required. In fact, as these areas begin to get quantified, potential projects often get killed because they will take too long, cost too much, require too many staff members to implement, the benefits just aren’t worth the cost or risk, or their goals are too elusive.

Once you have a project, whether you gave it to yourself or someone else gave it to you, it’s your job to manage it properly. Obviously, projects of different sizes aren’t all managed the same way. As mentioned earlier, the size and complexity of projects can vary tremendously; the approach you take to implement a three-year, 75-person project will vary greatly from the way you give a single subordinate an assignment to accomplish in a week.

Clearly Define the Project’s Objective and Scope to Avoid
Scope Creep

First and foremost, the project needs a clearly defined objective. Objectives can take all kinds of shapes. One effective way to think of the objective is to ask yourself, “What is the achievement that will most clearly show that this project is completed and successful?” The objective should also reference the justification, the ROI, company savings, improved efficiencies, increased functionality, and so on. Setting a
project’s
goals are not very different from setting an
employee’s
goals. (See the section
“Development Plans and Goals”
on setting SMART goals on
page 52
of
Chapter 2, Managing Your IT Team
.)

A project objective must have several important characteristics. It must be:

•
Clearly defined

•
Agreed upon by the important people related to the project (see the discussion of stakeholders in the section
“Identify the Stakeholders”
on
page 108
of this chapter.)

•
Documented

•
Measurable

Other issues need to be considered, but you must first define your objective, get it agreed to, and put in on paper. Document not only goals but also decisions so that you won’t hear “I never agreed to that” or “we decided to only allow 50 users into the system.” You want to be able to reply, “No, actually, the number we agreed to was 150 and I have the meeting notes to show you.”

PMI’s definition of “scope creep” is right to the point: “adding features and functionality (project scope) without addressing the effects on time, costs, and resources or without customer approval.” Hallway conversations, side notes in a mid-status report review, and meeting asides are ways that new responsibilities can sneak into your project without you realizing it. If your objective is clear, agreed upon, and documented, you will go a long way toward avoiding scope creep.

Very often, when a project’s scope is documented, there is a section identifying what areas are considered
out of scope
. For example, a project team may be formed to implement a new application, but the team will only be implementing the core modules and not other ancillary modules. Similarly, the scope may only be for domestic use, and international use is out of scope for the project.

Also, be prepared for radical changes in project direction—projects seldom progress as planned. It is important to plan—you need an intelligently designed structure to work within—but be ready when the plan needs to be changed. In addition, be ready with a rough cost/benefit analysis if new features are suddenly required.

A Typical Change in Mid-Project Objectives

When Rob Letterman and Conrad Vernon signed up as directors of
Monsters vs. Aliens
, a computer-generated spectacle from DreamWorks Animation, they were jittery about all the usual things: telling a good story, rounding up the celebrity vocal talent, and surviving a four-year production process without suffering a nervous breakdown.

Then Jeffrey Katzenberg hurled a curveball at them. After work on the movie was well under way, Mr. Katzenberg, DreamWorks Animation’s chief executive, informed the pair that they would also need to deliver the movie in 3D.

“We were totally taken aback,” Mr. Vernon said, sitting in a conference room at DreamWorks headquarters here.

—Barnes, Brooks, The Creatures That jumped off the Screen,
www.nytimes.com/2009/03/22/movies/22barn.html?_r=1&scp=1&sq=3-d&st=cse

Department versus Company Objectives

Carefully match your project’s objectives to the company’s overall objectives. Don’t think of yourself or your department as an island, but instead think and act as if you are part of a dynamic, constantly changing organization. As a consequence, define your project’s objective within the company’s overall goals. This step may sound obvious, but it often isn’t done.

Sometimes the connection between your project and the company’s overall direction is
not
obvious: it is then your job as the manager of the project to formulate this connection and state it clearly. If your company is an auto parts dealer and you are installing a new upgrade for the phone system, many people in the company might wonder why they have to help and how that activity helps them. You need to have the answers to those questions ready.

Get Proper Sponsorship for the Project

Along with clearly defining the project’s goals, you need to carefully define the sponsors of your project. A
project sponsor
is someone who can:

•
Champion the project at higher levels

•
Clear away organizational obstructions

•
Provide resources (people, budget, software, hardware)

•
Communicate with key stakeholders

•
Keep the project alive by providing funding, authority, and influence

•
Protect the project from those who don’t support it and turf wars

Very often, a project sponsor will send a communication out to everyone involved as the project gets launched. Typically, this communication identifies the overall objectives, the importance to the company, and thanks everyone in advance for their cooperation. A simple communication like this can help pave the way to success for the project and can eliminate the chance of someone saying “this project is news to me.”

Other examples of sponsorships include:

•
Perhaps your boss handed you the project; make sure that you clearly inform her that you will need her support soon.

•
Maybe your boss’s boss came up with this clever idea, and it was passed down to you. If that happens, find out as quickly as possible from the source of the idea how much help you’re going to get when it comes to issues such as funding, personnel, and so on.

•
If you created the project yourself, after clearly outlining its goals, set about finding out how much help you’re going to get from others in the company.

You will almost assuredly need help from people outside your department, and you’ll probably need help from people higher up the corporate ladder. Find out how much help there is going to be before you start making any significant decisions or commitments. Your project may actually be a pet project of the company president or some other high executive. If so, having this type of sponsorship and backing can be enormously helpful to you in eliminating roadblocks, particularly as you try to make use of resources from other parts of the company. If somebody “upstairs” wants everyone to have access to all business applications from mobile devices, you’re going to need a lot of personnel, time, effort, and money to make it happen.

Identify the Stakeholders

“
Project stakeholders
are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or completion” (PMBOK, p. 24). The key word here is the first “or.” Obviously, people and groups working on a project will be affected by its outcome. But stakeholders are also individuals who don’t work on the project but who are affected by it directly. You need to identify
all
the stakeholders in a project. Sometimes this task is a difficult one.

Examples of potential stakeholders in IT projects include:

•
The departments and end users that will be directly impacted by the new system.
An example of stakeholders would be the Accounting and Finance users when the new General Ledger system is put in.

•
Those that will be indirectly impacted by the new system.
Although the warehouse may be the primary beneficiary of the new inventory system, the way it improves efficiency may also have an impact on Sales and Shipping and Receiving, as well as the Procurement Group. Further down the chain it could impact Accounts Receivable and Payables.

•
Oversight groups.
Some departments such as HR and Legal oversee activities of the entire company. A project to scan old personnel records into a new document management system is generally a good idea. However, HR may be concerned about the sensitivity of those documents, who gets assigned to that task, and who gets proper training, whereas Legal may have thoughts about what it means for records retention policies.

•
Direct and indirect sources of funding.
Those that are paying for the project have a vested interest in it. Maybe your department is paying for the required hardware, but other departments are picking up other project costs (software, consultants, training, etc.).

•
Outside vendors.
Maybe your company’s adoption of this new software is a bigger deal to the vendor than you realize. You might be able to wangle better maintenance agreements as a result.

•
Government agencies.
Your company’s expansion into a new country may trigger all kinds of regulatory issues that will have to be addressed. In software companies, for example, what constitutes “non-exportable software” is a big issue. Some cryptographic techniques are prohibited from being shipped outside of the United States.

•
Those further up the corporate ladder.
Your bosses’ superiors may be using the success of this project as part of a means of evaluating your boss, or the department, so the reviews of both you and your manager may be on the line.

Identify the Constraints, Interdependencies, and Risks

Projects aren’t easy to manage. If they were, everyone would do it. There are many factors to consider, many of which are discussed in this section. But note that although some of these factors are under your control, many are not.

Potential Variables

Going into a project, make sure that all the issues and variables that are still uncertain are identified to all members of the team. Examples of these include:

•
Approval of associated costs such as travel expenses for contractors from out of town

•
Availability of identified required resources

•
Risks such as uncertainty of vendor deliveries or implementation of new technology

•
Interdependencies such as the inability to move to a new data center until construction is complete

•
Constraints such as the unavailability of resources from Accounting at the end of the year because of the priority of year-end closing activities

Possible Solutions

You’ll also want to indicate how you’re dealing with those issues. Potential solutions include:

•
Associated costs might be shared with other departments that stand to benefit directly from the project but who aren’t formal members of the team.