Chapter 1: ITProject Management Overview

Defining a Project

What makes a new assignment a project? How do you know if you are working on a project? What distinguishes a project from an ongoing operational activity? Both new project managers and team members frequently ask these questions. Projects involve a team of people, but so does day-to-day business. Projects and ongoing operations often fight for the same limited resources. They both involve following a plan or a process with consequences for actions taken. So what is so special about a project?

A project is a temporary work effort that delivers an exclusive product or service. A project always has a designated start and finish—thus it is temporary. A project has clearly defined and measurable goals, which are used to determine project completion and success. A project brings about a unique product or service—something that has not existed in the organization heretofore.

Tip

The word “service” is tricky in this definition because, obviously, there is a difference between ongoing service (operations) and a one-time or specified period of time service (project). Providing janitorial services on contract is operations; providing contract JAVA coders for 18 months to work on an IT project (providing programming services) is a project .

Another project management term you may have heard is program. A program is a grouping of related projects, that are managed together in some sort of harmonized fashion. Programs are often used in the defense industry or large government contracts. From an IT perspective, a large customer support application can be set up as a program, with separate projects representing billing, sales, and repair.

Let’s take a closer look at the criteria that defines a project.

A project is typically undertaken to meet a specific business objective.  It involves doing something new, which means that the end result should be a unique product or service. These products may be marketed to external clients, or they may be used internally.

A project is always temporary. In addition to a unique end result, it has a defined start and a defined finish.  Projects can vary in length from a few weeks to several years, depending on the complexity of the product, but they are not an ongoing set of daily activities.

A project must begin with a clear goal and stakeholders.  A project starts when the goal is clearly defined and the appropriate stakeholders have provided approval. A project ends when those goals have been met. A project can also end by being canceled if it is determined that the goal can no longer be met.

With this information under our belts, let’s take a look at some IT scenarios to determine whether they are projects or an ongoing operations.

Defining an IT Project

The activities associated with an IT project cross the entire genre of things typically categorized as projects, whether large or small. The reason is in almost every project, some component of IT must be included in the project plan.

For example, if you were building a submarine, you’d need to provide a datacenter, servers, infrastructure wiring, and many other IT elements associated with the project. If your project was to create a manufacturing facility, again, you would need to consider how computers and IT fall into such an effort.

Setting up a vineyard and winery? Again, the scientific basis behind today’s wineries is completely enveloped in the things that IT can offer—any great winery would also have a great facility for ascertaining when those grapes are precisely ready for the crush.

You would probably agree that you could come up with very few projects that do not in some way involve aspects of IT.

So What Is an IT Project?

While an IT project can and should closely follow the regimen of the project management guidelines PMI set, how closely you follow that regimen, of course, depends on the complexity of the project before you. All of the characteristics of any well-managed project, no matter how large or small, are embodied within the Guide to the PMBOK . The size and complexity of the project will dictate the level of detail that you go to in order to bring about the project’s deliverables.

Let’s take a minute to discuss some of the different IT projects you may find before you.

Software Development

When working on a software development project, not only must you follow high-quality project management techniques, but also be conscious of the software development methodology that you use. You will learn the project phases specific to software development later in this chapter.

Infrastructure—Old or New

When we say infrastructure , generally we’re talking about the cabling, wide area network (WAN) connectivity, and routing/switching plant. In many cases the infrastructure also includes the telephone wiring and switching infrastructure as well.

You might, for example, be moving into a new building with virtually no infrastructure— your project is to come up with the design and deployment of that infrastructure. Or, you may have projects in which you rewire the building, upgrade the switches and routers, or upgrade the WAN connectivity you have between sites. All of these kinds of projects involve the infrastructure.

The primary room where most of the cabling terminates, typically called the datacenter (see the following), is usually referred to as the Main Data Facility (MDF) . Wiring then flows from the MDF to switchgear and routers in other closets within your campus or building. These other closets are called Intermediate Data Facilities (IDF) . A building may have many IDF closets spread throughout but generally speaking there is only one MDF per building.

Datacenter Creation/Improvements

The datacenter is the place where the servers, mid-range computers, mainframes, large tapebackup devices, and telephony equipment such as Post Branch Exchanges (PBXs — telephone switchgear) live. The WAN connections coming into a building, be they T1 Frame Relay, Asynchronous Transfer Mode (ATM — a WAN protocol), Integrated Services Digital Networks (ISDN — a telecommunications protocol), or other are demarcated at the datacenter (MDF) location. As a general rule, the datacenter and demarcation location (or “demark”) are usually one and the same, though some companies may have a demark at a different spot in the building than the datacenter. In any event, you should think about a datacenter as the place where the hub of your computing business gets done.

Datacenters include elements such as a raised floor (for air-conditioning airflow under the servers as opposed to above), commercial quality power- and air-conditioning units, security systems for secure entry into the datacenter, uninterruptible power supplies (UPS), and often a power generator in the event that the power fails to the datacenter.

A datacenter project might involve installing a datacenter in a new building, replacing old power- or air-conditioning equipment, adding server racks to accommodate new servers, or upgrading the power distribution units (PDUs) that provide breakers and power for different systems. Note that a datacenter project isn’t necessarily about servers—it’s about the place where you’re keeping the servers.

Server/System Deployment

With the exception of regular file servers, which store user files, you will seldom deploy servers without planning on some sort of system for running on them. For example, you might have a large database system that you need to deploy. Or you might have a Commercial Off The Shelf (COTS) program that your company purchased to fulfill a business requirement and it needs a place to run. Or, you might have a combination of some code that your company’s software development shop wrote, coupled with a database and other systems in the enterprise. A deployment that relies on the components of several disparate systems is called an integrated system and requires careful dexterity on the part of the project manager so that all the parts work together harmoniously.

It’s not unreasonable to expect that your telephony systems might need to interact with a server system. For example, perhaps you have a project to install some call-routing software that handles call-center traffic, making sure that customer calls are answered as quickly as possible.

Generally speaking, most system deployments are going to require, at a minimum, server(s), the network operating system (NOS) to run on them, any required software applications, network connections, and testing. A system may be deployed across several campuses, greatly increasing the complexity and requirements of the project.

Storage Area Network (SAN)

Another unique IT project is the installation of a Storage Area Network (SAN) . This installation is specialized and may involve fiber-channel switches, fiber-optic cabling, big SAN arrays, WAN connectivity, and so forth. To set up a moderately sized SAN you’re facing a fairly complex project that’s going to consume several months of your project team’s time. A big SAN installation is one in which you’re very likely to require contract assistance from the manufacturer for deployment.

Enterprise Resource Planning (ERP)

The largest and most complex of IT projects centers on the installation of Enterprise Resource Planning (ERP) software such as that offered by SAP, Siebel, PeopleSoft, Oracle, Great Plains, Lawson, or other ERP manufacturers. ERP software is designed to handle most of an enterprise’s business computing needs from human resources to accounting and payroll and even manufacturing. As a result, the systems can be complex and esoteric in nature, requiring significant contract expertise to deploy.

ERP rollouts generally require massive server power, coupled with large-scale enterprise databases such as Oracle or Microsoft SQL Server. Additionally, because an ERP rollout can create diversity of roles—including the implementation of a portal—no one individual can know it all about the deployment. Many different business functions must be involved, requiring the participation of several different managers and stakeholders, encompassing the notion of matrix management of a project.

Note

When we talk about matrix management—the notion that you’re deriving workers from various departments and thus you and their supervisor must jointly manage their time—you should keep in mind that an ERP rollout probably represents most fully the notion of matrix management within the realm of IT projects.

Automated Systems

Some systems can be migrated from a manual process to a more automated approach. Think of an assembly line where cars are built. In the early days of automobile production, people assembled cars by hand. Today, robots do much of the welding and assembly of the components of the cars.

The same is true of many systems within industry; electronic pharmaceutical delivery systems count pills and put them in bottles, freeing pharmacists to do other things, for example. An IT project in which you’re going to replace a formerly manual process with an automated one will require robust understanding of the business function that you’re augmenting and may include plenty of training.

IT Project Considerations

IT projects rely on expertise, process, and communication in order to be successful. For all IT projects you put together the necessary hardware and software components, utilizing expertise in each area in order to make things work. Think about a building engineer responsible for managing a project to erect a high-rise building. The engineer doesn’t necessarily have to understand how the hundreds of sinks and toilets in the building operate, but the engineer must understand that they are connected to a big piping system. So it is with your IT project—you may not understand absolutely every nuance of the system you’re putting together, but you’re far better off if you can put in context how all the pieces interoperate.

The key to understanding IT projects is to think about the process of getting from point A to point B and the highway that got you there. How does, for example, an Internet user navigate a screen that in turn communicates with a database? By moving through servers and security processes over cabling, routing, and switching components. All of these elements, whether germane to your particular project or not, are part of the end-to-end process that you must consider.

Finally, it’s important that IT project teams are highly communicative. You can’t afford to have a rogue programmer miscommunicate the way that he or she designed the system, for example. When you have live business personnel testing it (called a pilot test ), you don’t want to run into any programming surprises.

Common Job Roles for the IT Project Manager

IT project managers have a difficult job. They must fit into a variety of molds in order to fully comprehend the project and to bring it in on time and under budget. Following are some of the hats that an IT project manager wears:

Project manager (PM)  As the project manager (PM) it is your primary responsibility to formulate the project team, develop and assign tasks, and manage the project in such a way that the deliverables are built and deployed on time, with the required quality, and within budget.

Business analyst (BA)  While the business unit may donate a Subject Matter Expert (SME) or two to help you flesh out the project’s requirements, as the business analyst (BA) you must have some understanding of what the business entity does. You must have a robust comprehension of the various departments in your company, the job functions of each department, the constraints and obstacles that for each job, the type of people who work in the business unit, how they’re managed, and the impact that they have on meeting corporate objectives. You must, in essence, be a corporate department SME of sorts, well able to describe all of the departments (at least the major ones) in your organization.

Systems analyst (SA)  In larger projects, the systems analyst (SA) function may well wind up being handled by another person, but you still must have a solid grasp of systems analysis and design techniques (see sidebar “Understanding SDLC, Systems Analysis, and Business Processes”). In smaller projects, the SA is also the BA.

Negotiator  Not only do you have to negotiate with business unit heads, you must also negotiate with contractors, vendors, and other business unit managers who need to supply you with elements that you require.

Budget analyst  As a budget analyst , you also have to keep track of the project’s budget. Generally you’re given a specific pot of money with which to accomplish your goals and you will have some heavy explaining to do if you go over budget.

Legal analyst  IT PMs must also understand the legal, ethical, and regulatory ramifications of their projects. This subject has become much more important since the advent of Sarbanes-Oxley document retention mandates, among others.

Technologist  IT PMs, while not necessarily heavily technological, must have a modicum of understanding of most things having to do with IT. You can’t be in the middle of a meeting with the network manager, for example, and not know the difference between a switch and a router. All the network manager will have to do is step up to a whiteboard and draw a few diagrams and you’ll be completely snowed! It’s key that you familiarize yourself with all elements of IT related to your project, at least at a conversational level. This is a large thing to say and we’re certainly not mandating that you be an expert in all things IT—it’s not possible even if you’re in IT—but you should be clear in your communications when you’re confronted with a term or concept you don’t understand to try to gain some clarity on the subject.

Visionary and strategist  This function is tightly coupled with technologist. You have to read up on the latest trends in IT. For example, you may not want to recommend a fat client/server system when browser-based technologies are all the rage and your new system would benefit from a thin client. That being said, you also don’t want to put your project out on the “bleeding edge” utilizing unproven new technology.

Communicator  The most important job of all is to be a precise and thorough communicator. You’ll translate statements from one group to another. You’ll keep people abreast of the project’s status. You’ll be in front of important people telling them what the project is about— seeking their buy in. You’ll communicate with vendors and contractors. You’ll have regular meetings with your project team. You must have highly developed oral and written communications skills, the most important of which is listening .

Time manager  IT PMs must keep their finger on the pulse of all of the project’s activities and when there is a task slow-down, find out why. The PM has the clock running against him or her.

Team builder  The IT PM must able to manage a highly diversified team of people with significantly different skill sets in order to achieve the project goals. You’ll have project teams that have programmers, networking professionals, server administrators, security analysts, web page designers, and a potential host of other technological folks on your team. Getting these people to relate to one another and to work as a well-oiled team can be very challenging.

Clearly, the IT PM has a broad role, one that is crucial and sometimes unpopular. It’s vital that IT PMs understand the “20-60-20” rule of management. Twenty percent of the people are going to dislike you no matter what you do or don’t do. Sixty percent are neutral about you and have no opinion one way or the other. The remaining 20 percent think you’re the greatest thing since sliced bread and would swim across the ocean for you. As an IT PM you’re going to hear a wide variety of opinions, dissension, arguments, persuasion, and other kinds of communication. Some of the decisions you make and things you do will not be popular, at least with one or another group of people. But you can’t live in the popularity contest world. You have to operate within the context of producing the finest-quality deliverables possible within the budget and time constraints you’ve been given.

Understanding SDLC, Systems Analysis, and Business Processes

While the IT Project+ test doesn’t test you on your knowledge of the software development life cycle (SDLC) , when you’re working with software development teams you’re going to have to make sure that you have a solid understanding of it. It’ll be of great benefit to you to understand how SDLC maps to the PMI process groups so that you manage your project according to solid project management standards, while being able to recognize what SDLC phase your software development is in at any given time. The two do not precisely correlate, but they are similar enough that you’ll be able to precisely manage your project and keep your coders happy at the same time.

We strongly suggest that you consider taking a course in systems analysis and design so that you fully augment your understanding of project management with the essential design elements of a technological system. In a systems analysis and design class you’ll learn how Data Flow Diagrams (DFDs) , context diagrams, Entity Relationship Diagrams (ERDs), and other outputs will assist you in rapidly deploying a fully functional, robust system that meets your customer’s needs.

It’s also important to note that in the initial business request and requirement-gathering phases of your project, you do not try to apply any given technology as a solution to the request. Instead, your focus should be on the business process . If you understand the order of flows that users go through to accomplish their tasks, you’ll find that the technology will logically evolve. If you’re heavily technological, you might have a tendency to think in terms of how a given software or hardware solution from a well-known company will meet the business need. But you should reverse that and first think of the business need, then try to apply various technological alternatives to the process that you’ve discovered.

Finally, by paying attention to the business process first, you may find areas where the process can be changed in some way to simplify it, or reduce the complexity of the technologies you’re going to introduce. This is called business process re-engineering (BPR) and is often the first thing a systems analyst will recommend prior to applying any technology.

While developers know about and understand the SDLC, they don’t get it when it comes to project management. So, the trick is to translate where you are in the SDLC into the PMI process groups so that you can manage the project utilizing consistent methodologies that have been highly refined and are well understood.

Communication among the Various IT Job Roles

As an IT PM, you’ll deal with a wide variety of people. When speaking with executives, you’ll have to relate to them on their level so you put on your negotiator or your “businessperson” hat, in order to get your point across. Likewise, when you talk to a software developer, you will rely on your technical skills.With the executive, you probably won’t use heavily technical language or computer acronyms. With the software developer, he or she probably won’t have much tolerance for listening to budget dialog. The point is that you put on the appropriate hat for the person that you’re dealing with. So the IT PM must get into the habit of being able to switch communication hats very quickly in order to accurately convey the message.

Try to make your language as clear as possible for the person you’re dealing with. Avoid acronyms unless they’re likely to be well-understood by the person or group you’re talking to.

Note

The IT Project+ exam doesn’t actually test you directly on these elements, but you’ll find a certain indirect flavor in the questions regarding the different hats that the IT PM wears. When a question tells you, for example, that you are speaking with the project sponsor, think about that individual differently than you would a technical team member and see if it doesn’t make a difference in the answer you’d give.