Windows Foundation
That First Step Is Tricky
You're responsible for soup-to-nuts implementation of a new system. Before you start, here are a few suggestions to make the project run smoothly.
- By Bill Heldman
- 08/01/2003
The IT world has gotten so complex that technicians might sometimes have
difficulty catching up with all that’s going on. So how is it that
when admins are given a new project by their managers, admins are eager
and ready to adopt the new effort without even necessarily understanding
the scope of the entire project? Take this scenario, where your CIO comes
to you and says: “Jenny, I want you to bring up a wireless networking
environment in our company. Please have this work done by the end of the
third quarter of this year.”
Generally, the experience I’ve had with projects like this includes
some or all of the following efforts:
- Go out to the Web and research a little about the technology and
associated products.
- Read a review of one or two of the best products.
- Compile a list of things we need to order to get the project going.
- Get the stuff in, assemble and deploy.
Don’t you think there are quite a few items missing from this list?
Have you talked to the customers (end users) to see what they’d
like to have out of the new system? Have you talked to the folks who manage
these end users (stakeholders) to see what sorts of growth elements they’d
like to see in a new environment? What are the risks associated with such
a deployment? How would we mitigate those risks should they arise during
the implementation of the project? Precisely how are we going to roll
out this new technology? What are the timelines and milestones? Who are
the people that will assist with this rollout?
In the information technology world we’ve entered a time when it’s
imperative that we practice good quality IT Project Management (PM). By
taking the time to design a project plan around the CIO’s request,
you will have a much better handle on what it is you need to do, who’s
impacted by your efforts and how you’re going to get to the end-product
deployment stage. Let’s take some time to discuss some basic IT
project planning elements.
Basic Project Management Elements
First of all, let’s get the definition of a project out of
the way:
A project is any temporary effort that produces a good or service
and has a definite start and end date.
Therefore, you cannot call it a project if you’re developing an
Access application that’s going to be used by your engineering staff
and you continuously keep going back to the application to refine it.
If it doesn’t have a definite finish date, it’s not a project.
Unfortunately, in IT circles, we have what I call “the vultures
circling”—endeavors that we call projects but which have taken
on a life of their own and refuse to end. We’re all just waiting
for the project to die (end), but it won’t.
Who
Needs a
Project Management Cert? |
| Personally, I don’t think it is imperative—or
even necessary—for a technician to obtain the Project
Management Institute (PMI), Project Management Professional
(PMP) certification. PMI’s project management ideologies,
while well able to fit in with small to moderately-sized
IT projects, are overkill for most of these projects.
I'd comfortably recommend a PMP for projects such as the
construction of a satellite, bridge or high-rise skyscraper—even
a very large scale deployment of an EAP such as PeopleSoft
or J.D. Edwards—but I wouldn't require this certification
for someone who needs to deploy servers with specialized
applications or even larger scale projects such as SAN/NAS
deployments. The PMI ideologies are simply too rigorous
for the average IT junket. |
|
|
Next let’s define the players in the project:
Sponsor The project sponsors are those individuals
are able to authorize the resources necessary to implement the project
from start to finish. The key operational word here is authorize.
A team-lead or supervisor may possess some authority to get things going,
but if the project’s very large at all or if it spans different
departments, she may not have the decision-making authority to get the
entire thing deployed. Lots of projects wind up in project Purgatory thanks
to not understanding who the project sponsor is.
Stakeholder Stakeholders are those who have
a vested interest in the project, regardless of the length of time they’re
engaged. You might have a variety of folks who walk into and then back
out of the project at any given time. A vendor, for example, might supply
some component of the project, but after that element of the work is done,
so is the vendor. The vendor is temporarily a stakeholder in the project—he
or she has a vested interest in that aspect of the project’s outcome.
You can see that there is quite a disparity in the kinds of stakeholders
involved in the project.
| Who's
In Charge? |
| You will probably have two sponsors in
most IT projects: Your big boss (CIO, IT director, etc.)
and the department head for the department that’s
going to actually receive and use the project’s
output. When more than one department is involved, you
have a multiplicity of sponsors. In situations like this,
it’s wise to denote an executive project sponsor—the
person designated should be able to manage all aspects
of the undertaking. |
|
|
It’s important to denote who the stakeholders are because, second
only to scope creep, poor stakeholder communications is the primary cause
of project failure. If you don’t bother to identify all the stakeholders
and then make sure that adequate communications are going forward to those
people, you’re likely to anger someone and, more importantly, have
the person push the STOP button on the whole thing. I’ve seen it
happen time and time again in IT projects.
Project Team The project team consists of those
who are going about the process of creating the outcomes (called the deliverables)
of the project.
There are several key folks:
- Project manager—The one who assembles the project team,
interfaces with sponsors, prepares all of the documentation and communicates
with stakeholders. It is the PM’s job to make sure that deliverables
are brought to the customer on the date stated and within the budget
allocated.
- Business analysts—BAs make sure that the project is
adequately meeting the requirements of the customer. In fact, BAs are
generally responsible for going through the requirements gathering phase
with the customers in order to ascertain what it is the customers are
really after. This is not as easy as it sounds. Customers, for a variety
of reasons, might hide information from you, or might simply not be
sure of all of the things you need in order to meet their needs.
There are two kinds of BAs. A technical
BA understands more about the technical components of the project than
the customer components. However, a technical BA is expected to interact
with the customers. A business BA isn’t expected to understand
the technical components of the project, but he must be a subject matter
expert (SME) in how the business operates.
Often the project is so small that the
PM, business BA and technical BA are one and the same person! It is
imperative that this person not lose sight of the ultimate outcome of
the project while he or she is wearing each of these hats. The PM has
a different goal in the project than a business BA does—but all
three persons are trying to get the project to the same final end-point—the
satisfactory on-time and under-budget consummation of the deliverables.
- Project technicians—There might be a variety of folks
working on the project at any time. You might need internetworking (router,
switch, wiring) specialists, server administrators, programmers, script
writers, and so forth.
Project Documentation
OK, so you’ve been given an IT project and you sense that
you need to assemble a project team in order to effectively deploy the
deliverables of the project. Now what? Before assembling the team, you
need to develop some documentation—a road-map, if you will—to
guide you through the project.
Why document? You might not think you need to go through the extra effort
to create a bunch of additional documentation, but the truth is that it’s
going to save your bacon when you’re in the heat of a project, the
thing has slipped way out of time and budget and you’re trying to
reign things back in. Think of project documentation as an agreement between
the sponsors, stakeholders and you.
At a minimum, you need the following documentation for any given IT project
that you sense requires some formality:
- Requirements document—The requirements document is
the result of BA visits with the customers. You want to know exactly
what the customer is looking for in order to meet a business need. This
phase can be much more difficult than you may at first imagine. Consider
the deployment of Exchange Server 2003 for a moment. Who is your customer?
Who are the stakeholders? Who are the sponsors? What are the requirements?
You can immediately see the difficulty with requirements gathering.
Nevertheless, if you don’t clearly stipulate requirements, you
can’t make good logical decisions about how you’re going
to deploy. The requirements document is your document; that is, you
can use it when the customers ask for stuff beyond the bounds of the
original request. The Requirements doc clearly stipulates the deliverables.
- Scope document—This document says what you are going
to do and, more importantly, what you’re not going to do. Why
define the scope? So that you can identify when a project has slipped
out of bounds and needs to be put back on track. The scope document
is for your customers; it’s an agreement between them and you
to specifically tell them what you’re planning on doing. The scope
document should include some robust risk assessment (including risk
mitigation plans) so that you can deal with problems that might arise
during the undertaking.
- Work Breakdown Structure (WBS)—Typically done in Microsoft
Project, this document explicitly shows the phases, steps, milestones,
dependencies, resources and start and end dates associated with the
project. Project is easy to use and remarkably suited (go figure) for
IT projects. I recommend that you whip up a project plan for almost
any IT undertaking of any size, regardless of whether you’re going
to assemble a formal project plan.
- Closure documents—These documents include Lessons
Learned, a document that denotes what went wrong and how you dealt with
them; any training or help desk documents that are required and Closure
documents that talk about the closing phases of the endeavor.
All of these documents are bound up into one binder and are called the
Project Book. The Requirements and Scope docs can be combined—but
it’s important for you to get the sponsors to sign-off on the documents.
By signing these documents, you enter into an agreement to provide the
deliverables and in return you’re authorized to utilize the resources
necessary to get the job done. You should have the WBS done at Requirements/Scope
sign-off time so that all parties understand the projected due dates.
The Time/Budget/Quality Ruler
There are three measurements that are in a delicate balance with one another
and that can be adjusted in order to accomplish minor changes in scope:
- Time—The due dates of the project are generally written
in stone. You’ve committed to getting the deliverables out the
door on a specific date and you need to abide, as much as is possible,
to that commitment. Slip on the due dates and you’ve put the scope
out of whack, thereby potentially affecting the quality and certainly
affecting the project budget.
- Budget—The budget is one of the variables that requires
rigorous accounting. Slip up on a parts estimate and you have to go
back to the project sponsors for more dough. Microsoft Project allows
you to keep track of the project’s budget—including giving
you the ability to add in each of the project member’s salaries,
parts estimates, etc. Adding these figures is called loading the project.
Slip on the budget and something has to go: either a slippage in quality
or time.
- Quality—By undercutting the budget or the time to delivery,
you directly affect the quality of the project’s deliverables.
The TBQ rulers, as I call them, are in precise balance with one another.
The WBS should, properly prepared, eloquently bring this out in clear
definable form. It’s on the PM’s shoulders to make sure that
the rulers are balanced in order to bring the project deliverables in.
If one of the rulers slips, the others must move the other way to compensate
for the slippage.
Preventing Scope Creep
Scope creep is the term we use to denote a project that has grown
larger than its original boundaries. The most popular (and well-hidden)
way that scope creep happens is by the customer walking up and requesting
that another “little” element be added to the project outcome.
While this one little element may be easy to get done, if you let the
customer do too much of this miniscule scope adjustment stuff, soon you’ll
have a customer that thinks it’s perfectly all right to randomly
add elements to the project—next thing you know the vultures are
circling. It is paramount that the PM monitor and manage scope creep.
I tell newbies to IT project management that scope creep is actually
Phase II of the project. Once you and the sponsors have signed off on
the requirements and deliverables, generally-speaking requests for additions
should be considered in Phase II and not implemented in the current project.
Note that some projects may require some sort of formal change-management
process to be set up as a deliverable so that little changes can be made
on an ongoing basis.
The most difficult thing a PM has to do is manage the TBQ rulers by making
sure the project team is dedicated to working on their tasks, the stakeholders
are continuously updated as to the project’s progress, the sponsors
are notified regularly as to the status of the deliverable’s development
as well as the project budget and the customers are somehow made aware
of the project’s status.
Good quality IT project management can lead to very high-quality outcomes
which can lead to things like notoriety, fame and fortune, fast cars,
trips to the Bahamas and other perks that the average riff-raff administrators
simply don’t enjoy.
OK, not. But it is true that if you effectively manage your IT projects
and roll out high-quality deployments, you’ll be looked at as one
who can successfully deliver and you’ll be entrusted with more responsibility.
For more information on IT project management, I’d recommend visiting
www.gantthead.com or www.techrepublic.com.
One Final Note
This is my last column for MCP Magazine. I’ve had
a wonderful ride as a feature writer, columnist and speaker at MCP
TechMentor conferences. However, my regular job has taken a new direction.
I’m getting higher into management and less technical in my work.
Therefore, I think it’s time to head the horses down a new trail.