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
• August 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.