ITProject Management Overview

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE

• 2.1 Demonstrate knowledge of the typical IT project life cycle and its application to IT projects.

Your decision to take the CompTIA IT Project+ exam is an important step in your IT career. Certification is becoming more important for project managers, and many employers look for evidence of formal education as well as real life experience from job applicants . This book is designed to provide you with the necessary concepts to prepare for the exam. Much of the information here will be based on the knowledge areas documented in A Guide to the Project Management Body of Knowledge (Guide to the PMBOK) published by the Project Management Institute (PMI). We will include tips on how to prepare for the exam, as well as examples and real world IT scenarios to illustrate the concepts.

This chapter will provide you with a high level overview of project management and how it fits into the bigger scheme of an IT operation.

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.

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.

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.

Defining Project Management

You are now equipped to identify a project and have a better idea of what types of IT projects you will be managing. But what exactly is project management? You may have already heard a lot of different answers to that question. To eliminate any confusion, we define project management and associated terms according to the standards set by the Project Management Institute (PMI) . PMI is the leading professional project management association, with over 100,000 members in over 125 countries worldwide. PMI is a leader in the development of project management standards, which are listed in what is called the Guide to the PMBOK .

The Guide to the PMBOK

Project management s standards are documented in A Guide to the Project Management Body of Knowledge ( Guide to the PMBOK) . PMI also manages a very rigorous certification program, the Project Management Professional (PMP) certification. The Guide to the PMBOK is the basis for the exam portion of the PMP certification. If you continue in a career in project management, you may move on to the PMP certification. The material you have studied to prepare for the IT Project+ exam is an excellent foundation on which to build your project management knowledge. PMI members were involved in the revision of the IT Project+ exam, and the questions on the exam are consistent with the Guide to the PMBOK standards.

The Guide to the PMBOK defines project management as the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.

The project manager (PM) is the person who oversees all of the work identified to complete the project and applies a variety of tools and techniques. Successfully managing a project involves dealing with competing needs for your resources, obtaining adequate budget dollars, identifying risks, managing to the project requirements, interacting with stakeholders, staying on schedule, and ensuring a quality product. Sounds a little overwhelming at times, doesnt it? Guide to the PMBOK categorizes each of these into nine knowledge areas. Let look at these in more detail.

Later in this chapter we will look at the five process groups that cover these knowledge areas.

Project Management Knowledge Areas

Successful project management is dependent on the use of key processes. These processes must cover the core knowledge areas critical to project management. The Guide to the PMBOK defines the nine Project Management Knowledge Areas as:

• Scope Management
• Time Management
• Cost Management
• Quality Management
• Human Resources Management
• Communications Management
• Risk Management
• Procurement Management
• Integration Management

As you move through subsequent chapters, we will cover these items in more detail. These areas make up the total realm of project management, and Guide to the PMBOK threads each of these knowledge areas into a series of process groups, which will be discussed later in this chapter. These knowledge areas may not have equal importance in your specific IT job area. For example, if you do not have outside contracts for your project, Procurement Management may not apply. The IT Project+ exam has a strong focus on the knowledge areas that are part of the planning processes and the project execution processes.

General Management Skills

Project managers possess many skill sets that are unique to running a project. Successful project managers also possess general management skills, sometimes referred to as soft skills. These are skills that any good manager uses on a daily basis to manage resources and meet goals. You probably already use some of these skills in your day-to-day work activities. General management encompasses many skill areas including:

• Leadership
• Oral communication
• Written communication
• Listening
• Organization
• Time management
• Planning
• Problem solving
• Consensus building
• Conflict resolution
• Negotiation
• Team building

A project manager looks at the big picture and interacts with a broad spectrum of stakeholders. Good management skills are as critical to the success of a project as the correct technical skills.

In the following sections, we are going to take a look at a few key general management skills and how they apply to project management. We will also examine how these fundamental skills translate into your industry.

Leadership

A project manager needs to be a good leader. A project team comes together for the life of the project, which can sometimes only be a few months. Team members will have very different skill sets and project experience. IT projects commonly have both technical team members and representatives from other areas, such as marketing, sales, customer service, or training. Team members may not have worked together in the past. To add even more complexity, team members may roll on and off the project at different times.

The project manager is accountable for sharing the strategic vision that created the project and providing overall direction to the team members. A good project manager knows how to align and motivate diverse people with varying backgrounds and experience.

Communication

Successful project managers will tell you that they spent a great deal of time communicating. Even the most detailed project schedule can fail without proper communication.

Project managers must develop a communication strategy that includes the following critical components :

• WHAT you want to communicate
• AUDIENCE to receive the communication
• MEDIUM used for communication
• MONITOR outcome of communication

Keeping these components in mind and developing a comprehensive communication plan up front will prevent misunderstanding and conflict as the project progresses.

Problem Solving

Projects always have problems. Some are just more serious than others. Project managers must use problem-solving techniques throughout the life of the project.

Real World Scenario ”Negotiating with the Business Unit

You re working on a software development project for a business unit in your company. You ve gotten past the initial project request steps and you re now in the process of honing in on the details of the requirements for the project.

You require subject matter expertise from the business unit in order to more fully understand and appreciate the business processes that your software is going to automate.

You set up a meeting with the director of the business unit. At the meeting you ask her two things. First, you want to know if you can use someone from the business unit to assist you in understanding the business process flows. You make it clear that the assigned individual must be an SME in the business process. Second, you ask if you can have this individual full-time for a minimum of two weeks. You suggest the name of someone whom you think will perform very adequately as a business SME.

The director is shocked that you require so much time from one of her people. She asks you to more thoroughly explain your need. You explain to her that in order for you to develop software that fully meets the business need, you must understand the flows that are involved in the business process. Further, you describe the process of generating a data flow diagram (DFD), a block diagram that shows, at a very high nontechnical level, the process as you see it, noting that you ll need the SME to validate the DFD.

After some bantering back and forth, the two of you come to an agreement that you can have a week and a half of someone s time and that you ll use not one but two different business SMEs, splitting their efforts accordingly so that neither one has to fully dedicate their time to the business flow discovery process. The director stresses repeatedly to you that her people are so busy, she is being very generous in letting you have them at all.

You agree to the specifications, thank her for her time, and get to work figuring out the best questions to ask the SMEs in order to complete the business flow discovery process in as efficient and timely a manner as possible.

The key to problem solving is to recognize that a potential problem exists. Early recognition of warning signs will simplify the process. Pay close attention not only to your project team s formal progress reports , but also to what team members say and do.

If you do identify a potential problem area, take the time to clearly identify the problem. A vaguely stated problem may drive the wrong solution.

Once a problem is clearly and concisely identified, the project manager works with the appropriate project team members to brainstorm alternatives. These alternatives can now be evaluated and a solution chosen . A project manager monitors the implementation of the solution to ensure that the problem is resolved.

Negotiation

A project manager is involved in negotiating throughout the life of the project. Negotiation is the process of obtaining mutually acceptable agreements with individuals or groups.

Depending on the type of organizational structure, you may start the project by negotiating with functional managers regarding assignment of resources. Project team members may negotiate specific job assignments. Project stakeholders may change the project objectives, which drives negotiations regarding the schedule, the budget, or both. As you execute the project, change requests often involve complex negotiations, as various organizations propose conflicting requests .

If your project includes deliverables from an outside vendor, you will be involved in negotiating a contract. This area is specialized and may involve representatives from a legal or procurement department.

Organization and Time Management

A project manager oversees all aspects of the work involved to meet the project goals. The ongoing responsibilities of a typical project manager include tracking schedule and budget updates, conducting regular team meetings, reviewing team member reports, tracking vendor progress, communicating with stakeholders, meeting individually with team members, preparing formal presentations, and managing change requests.

Meetings consume valuable project time. Effective meetings do not just happen; they result from good planning. Whether you conduct a formal team meeting or an individual session, you should define the purpose of the meeting and develop an agenda of the topics to be discussed or covered. Time allocation for each item is critical to keep a meeting within the allotted time.

Clear documentation is critical to project success, and it must be available for immediate use. Without an efficient system for maintaining documentation, a project manager will waste precious time searching for the latest version of the schedule.

An excellent way to learn organization and time management techniques is to spend time with an experienced project manager willing to act as a mentor.

Project Processes

As we discussed earlier, PMI defines project management as a series of processes that are executed to apply knowledge, skills, tools, and techniques to project activities to meet project requirements. These processes have been organized into five groups.

The process groups are tightly linked, as the outputs from one group are the inputs to another group . Figure 1.1 shows the links between the groups. The process groups may overlap. You may begin planning the project before all of the initiation activities are complete.

Figure 1.1: PMI Process Groups

As we discuss each group, notice the correlation between the process groups and the domains covered in the CompTIA IT Project+ exam. The process groups are the foundation of project management. You need to understand each group and how it contributes to the completion of the project.

Initiation Processes

Initiation processes include all of the activities that lead up to the authorization to start the project. These activities include such items as business need identification, high-level requirement definition, and cost justification. Because the Initiation process is an integral part of Domain 1.0 on the IT Project+ objective blueprint, we will take a more detailed look at the initiation process in Chapter 2, Project Initiation.

Planning Processes

Planning processes are where the project goals and objectives are refined and broken down into manageable pieces of work. Project managers create time and cost estimates, and determine resource requirements for each activity.

Several other critical areas of managing a project require up-front planning. These areas include communication, risk, quality, and procurement.

Executing Processes

Executing processes are where the work to complete the project is done. The project manager must coordinate all the project team members as well as other resources assigned to the project.

Executing processes include the actual execution of the project plan, team development, quality assurance, and information distribution. We will examine this more closely in Chapter 8, Project Execution.

Controlling Processes

Controlling processes are the activities that monitor the progress of the project to identify any variances from the project plan. Requests for changes to the project scope are included in this process. This area is also where any corrective action will be taken.

Other areas of the Controlling process group are cost control, quality control, performance reporting, and risk control. In Chapter 9, we will spend considerable time discussing the various methods for monitoring progress, specifically change control and quality control.

Closing Processes

The closing processes drive the formal acceptance of the project work and provide a means to fold the product into the ongoing organization structure.

Closing processes include sign-off, archive of project documents, turn over to a maintenance group, release of project team members, and review of lessons learned. Although some of these activities may seem fairly straightforward, several areas deserve close attention. Chapter 10, Project Closure, will explore the last stages of an IT project and how they can differ from other projects.

Project Life Cycles

Every project has a number of phases to mark the beginning, middle, and end of the project. The project life cycle is the composition of these multiple phases, which can be laid out on a timeline. In an ideal world, all deliverables from one phase would be complete and approved prior to the start of the next phase. In reality, the various phases of a life cycle can overlap. The term for starting one phase prior to the completion of a previous phase is fast tracking . This is normally done to shorten the project schedule.

Project life cycles vary widely between different industries and to some degree even within an organization. Although project life cycles are diverse, you will find several key elements. A project life cycle should depict at the highest level the deliverables for each phase and the category of resources involved. A life cycle should also depict how the project will be folded into the operational business on completion.

Now let s take a look at some examples of typical life cycles of IT projects.

IT Project Life Cycles

Every IT project has a life cycle and a series of phases. The software development life cycle (SDLC) closely parallels project management process groups with its five phases: planning, analysis, design, implementation, and operation and support. The following is a closer look at each of these phases.

Systems Planning

The systems planning phase begins with a formal request to IT for a system that will solve a problem, or provide an upgrade or improvement to an existing system. The formal request is called a systems request and embodies the problem and business processes that need to be addressed within the given system.

A systems request has two potential outcomes : a preliminary investigation and a feasibility study (depending on the size of the system). The preliminary investigation basically maps to the preliminary requirement-gathering process that you go through when you re in the Initiation process group of project management. From this preliminary investigation you may derive a feasibility study that denotes the cost-benefits associated with the request as well as recommendations that drill down into the various factors involved, such as operational, time, economic, or technical conditions.

But systems planning goes beyond the notion of we ve got a system we d like for you to build. It also gets into the idea of how that system fits into the overall corporate scheme of things ”does the system enhance the corporate vision and goals?

Additionally (and more subtly), good systems planning may well point back to the need for a change in business processes in order to more closely accommodate the stated desired results. Sometimes automation and technology can t (or shouldn t) solve a problem, when a change in the way that a business process is currently being done will do nicely .

Systems Analysis

You ve solidified a feasible system request and you re planning on going forward. The systems analysis segment is the next logical step in your progression. In this phase you develop a logical model of the system by diagramming the logical flows of the data. You ll map out what the requirements are for the new system.

If you understand the goals of the business manager that is requesting the system and you couple that with the logical flows that you derive for the system by going through a business process analysis, you can make your job much easier in diagramming, at a high level, how the proposed new system will operate . A visual representation of the basic business flows will also help others understand how the system parts interoperate and help nontechnical people understand how you think about their business process.

In the analysis phase you begin to knock out what it is ”the nuts and bolts ”that this system consists of. Through your previous analysis process, including interviewing various stakeholders, performing fact-finding analysis, and formulating solid objective ideas about what the system should be comprised of and what it should do, you can build various enterprise models that include the data objects themselves . You also can understand the various process and data models that are involved. Also, fleshing out a prototype at this point will prove to be a worthwhile effort because prototypes give stakeholders a way to visualize the new system.

The systems planning and analysis phases roughly correlate to the Initiation and Planning process groups, which we ll discuss in more detail in Chapter 2.

The final outcome of the systems analysis phase is called a systems requirements document . The document spells out what you heard the business representatives say that they wanted in the new system. You got here by going through a variety of processes including interviewing various experts in the business process, sitting with them to watch how they go about their work, questioning the manager, and other such methods . The document is about the business for the business. Like a da Vinci charcoal drawing intending to help the artist understand what it was he was going to paint, the business requirements doc will help you derive your new system.

Systems Design

In the systems design phase you denote all the components that will be included in your IT project, including all of the inputs (such as data flowing into the system or keyboard input by a data-entry clerk), outputs (such as screen displays or reports ), and processes involved. Additionally, at design time you flesh out the various controls required, whether automated or manual, that will contribute to the system s successful operation. If you re working on a project in which code has to be written, you ll draw out the architecture that the application(s) will use in a document, called the system design specification (SDS), a detailed document that allows the project team members to exactly build the desired system. The SDS illustrates exactly how programmers are to create the system.

If the system doesn t require software development, but does require database or infrastructure creation or enhancement, it s key that all stakeholders, from management to end users, understand what you ve designed and how you imagine it will work, and that technicians be able to build the desired system. If you re using a Commercial Off The Shelf (COTS) program, you ll design its integration into the system that you re building.

Note too that other elements such as infrastructure additions or renovations, cabling upgrades, WAN connectivity (including wireless), new types of computing such as PDAs, telephony integration, and a host of other things may be included in the design of your system. Just because your system primarily uses software does not mean that the underlying components don t need to be addressed and freshened as well.

Systems Implementation

In the systems implementation phase of the IT project life cycle, the system is constructed . Whether that means that programmers write programs, you purchase COTS programs, or you come up with some in-between system that uses elements from both worlds , you ll want to deliver a completely functional and fully documented system.

This phase includes such elements as the conversion of old data to new tables, training the users, testing, and migrating to the new system. You ll also prepare a write-up called the systems evaluation to provide an earmark as to how well the system performs relative to your stipulations in the system design specification.

Systems Operation and Support

Mapping somewhat to the Closing process group, which we ll discuss in just a moment, the systems operation and support phase means that you put the system into routine operation, and provide a method whereby the system can be supported if there is trouble. However, the operation and support phase goes beyond Closing in that it calls for elements such as change management where you have maintenance or enhancements that need to be performed and you provide for some modicum of scalability in the system, should it need to be added to later.

You need to know two other things as a manager of projects in the IT project life cycle: setting milestones and checkpoints. Let s discuss this further.

Project Concept Documentation

Let us mention here another type of document that you might want to consider when you re meshing two management methodologies together (i.e., project management and the SDLC): the Project Concept Document. At initial requirements-gathering time, the systems analyst will generate a document that contains the high-level requirements she discovered upon examining the customer request. This document could act as a starting point in the project planning process as well. A systems analyst may not be a project manager, or may be ”it depends on the way your company is laid out and the complexity of the project before you. But we know that good quality systems analysis and design leads to high-efficiency systems, especially when built under a well-developed project management paradigm. A starting-point document for both players ”the project concept document ”is an ideal way to flesh out the skeleton of the project and get the two parties talking.

Note that the systems analyst will go on to develop some very elaborate flows out of her initial requirements ”the project manager must be in lockstep with the elements being worked out.

IT Project Milestones and Checkpoints

Any good SDLC process should include the milestones on which you see the project pivoting. For example, perhaps a significant milestone for an e-commerce project would be the purchase, acquisition, installation, configuration, and deployment of the web servers that will be used for the system. A very discreet set of tasks are needed in order to accomplish this milestone. At its accomplishment, in the systems design world, we d step back and ask project stakeholders such as the managers and technicians to give us a go/no-go decision regarding whether the project should move forward.

Additionally, in between milestones, good projects include several checkpoints along the way that reveal whether we re on time and within budget in our project. A prudent number of checkpoints (not too many to be burdensome) can reveal the pulse of the project at any given point.

Organizational Structure Impacts

The structure of your organization has a great impact on many aspects of project management, including the authority of the project manager and the process to assign resources.

Project managers can often become frustrated by what appear to be roadblocks in moving the project forward. It many cases the root issue is the organizational structure and how it operates. You must understand how your project fits within the organization in order to know the correct approach to resolving issues.

Functional Organization

The classic organization structure is the functional organization , as shown in Figure 1.2. In this structure, the staff is organized along departmental lines, such as IT, marketing, sales, network, public relations, customer support, and legal. Each person within a department has a clearly identified superior .

Figure 1.2: The Functional Organization

A project that is approved within a functional organization often has silos of work that are completed independently within each department. These silos may even be managed as separate projects.

The typical characteristics of a functional organization are limited authority for the project manager, part-time rather than full-time project resources, and an issue resolution process that must go up the departmental chain of command and laterally to other departments.

Project managers in functional organizations are often frustrated, because they are held accountable for the results of the project, but they have no means of holding team members accountable for project deliverables. The functional manager controls a team member s salary, bonus, and job rating. You may see some functional organizations that allow project managers input into team member compensation and rating, but the amount of weight it carries may not always be in proportion to the time spent on the project.

A project manager in a functional organization will benefit greatly from developing a good relationship with the functional managers. These managers can greatly influence the success of the project. Often they are asked to provide more resources to projects than they have available or qualified people. Working with the functional manager to resolve these issues is critical.

Matrix Organization

Another common organizational structure is the matrix organization , which is depicted in Figure 1.3. Matrix organizations typically are organized along departmental lines, like a functional organization, but resources assigned to a project are accountable to the project manager for all work associated with the project.. The project manager is often a peer of the functional staff managers. The project team members have two or more bosses; their functional manager and the project manager(s) they are reporting to.

Figure 1.3: The Matrix Organization

The typical characteristics of a matrix organization are low to moderate authority for the project manager, a mix of full-time and part-time project resources, and better interdepartmental communication. There are both weak and strong matrix organizations: the stronger the matrix, the more authority for the project manager.

Project managers in a matrix organization need to be very clear with both the project team members and their respective functional managers which results the team member is accountable for to the project manager and which are accountable to the functional manager. The team member should only be accountable to one person for a given result to avoid conflicting direction. Another trouble area in a matrix organization is how thin resources may be spread. If you have a resource assigned 50 percent to your project, it should be reflected in the work assigned by the functional manager or other projects to which the team member has been assigned. Addressing resource issues up front will prevent problems down the road.

Projectized Organization

The last type of organization structure we are going to discuss is the projectized organization , which is depicted in Figure 1.4. This organization is far less common in our experience than the other two. In this type of an organization, most of the work is project work, and the company is organized by projects.

Figure 1.4: The Projectized Organization

The typical characteristics of a projectized organization are a high level of authority for the project manager, full-time project resources, and a dedicated project support staff.

Project managers in a projectized organization are responsible for all decisions regarding the project. Team members are usually colocated , which enhances communication and efficiency.

The big drawback of a projectized organization is the how to handle staffing as one project ends. There may not always be a new project waiting for resources. The timing of increasing or decreasing resources can become very complex.

Summary

A project is a group of activities that produces a unique product or service with a measurable goal. It has a defined start and finish. Project management is the application of tools and techniques to organize the project activities to successfully meet the project goal. A project manager manages these activities.

A project manager needs not only technical knowledge of the product or service being produced by the project, but also a wide range of general management skills. Key general management skills include leadership, communication, problem solving, negotiation, organization, and time management.

Projects have life cycles that are composed of multiple phases. Applying tools and techniques from process groups completes these phases. The five process groups defined by the Guide to the PMBOK are Initiation, Planning, Executing, Controlling, and Closing. The type of organizational structure impacts how projects are managed and staffed. The primary structures are functional, matrix, and projectized. The traditional departmental hierarchy in a functional organization provides the project manager with the least authority. The other end of the spectrum is the projectized organization, where resources are organized around projects, and the project manager has the authority to take action and make decisions regarding the project. The matrix organization is a middle ground between the functional and the projectized organization.

The Systems Development Life Cycle (SDLC), with its distinct phases of Planning, Analysis, Design, Implementation and Operations and Support augments the overall project planning elements. In a new software development project, for example, not only would you utilize highquality project planning principles, but youd mesh them with the elements of SDLC so youre assured that the system youre delivering is adequate and correct for the requestors.

Exam Essentials

Be able to define a project. A project is an effort to develop a unique product or service. The effort is temporary and has a definite start and end date.

Know the four main components of any project. They are phases, deliverables, people, and constraints.

Be able to name the three primary constraints. Youll encounter the time, quality, and costs (budget) constraints in any project. You should be able to understand the TQB equilibrium is one of the keys to solid project management.

Understand the five basic phases of any project. They are Initiation, Planning, Executing, Controlling, and Closing.

Be able to identify the difference between a project and ongoing operational work. A project is a temporary endeavor to create a unique product or service. Operational work is ongoing.

Name the three types of organization structure. Organizations can either be functional, matrix, or projectized .

Be able to define the role of a project manager. A project manager is the person who leads the project team and oversees all of the work required to complete the project.

Understand what skills are needed to manage a project beyond technical knowledge of the product. General management skills are important, as the project manager must interact with the sponsor, the project team members , and other key stakeholders. Key general management skills include leadership, communication, problem solving, negotiation, organization, and time management.

Key Terms

Before you take the exam, be certain you are familiar with the following terms:

Review Questions

1. How is a project is defined?
   1. A group of interrelated activities performed over an unspecified period of time
   2. A repeatable process
   3. A temporary endeavor undertaken to create a unique product or service
   4. All of the above

2. What organization is recognized worldwide for setting project management standards?
   1. PMC
   2. PMI
   3. PMP
   4. CompTIA

3. What is the term for a group of related projects managed in a coordinated fashion?
   1. Life cycle
   2. Phase
   3. Process group
   4. Program

4. Which of the following is NOT one of the PMBOK Knowledge Areas?
   1. Quality
   2. Time
   3. Negotiation
   4. Cost

5. Which of the following is NOT a general management skill?
   1. Programming
   2. Communications
   3. Leadership
   4. Problem Solving

6. What are Initiation, Planning, Executing, Controlling, and Closing?
   1. Life cycles
   2. Process groups
   3. Management skills
   4. All of the above

7. The sales director comes to you with a request for a new order entry system. What project process group are you in?
   1. Planning
   2. Executing
   3. Initiating
   4. Controlling

8. You have moved into the Planning phase before the initiating phase is formally approved. This is an example of
   1. Scope creep
   2. Poor management
   3. Fast tracking
   4. Problem solving

9. A project manager has the most authority under which organizational structure?
   1. Projectized
   2. Functional
   3. Weak matrix
   4. None of the above

10. You are assigned to install a software upgrade to the customer support servers. Why would this not be considered a project?
    1. You already know how to install a software upgrade.
    2. It does not create a unique product or service.
    3. It is not temporary.
    4. All of the above

11. Which items represent milestones? (Select all that apply.)
    1. Assembling of team members
    2. Key software module finished
    3. Servers procured and shipped
    4. Sponsors sign off on requirements

12. Frederico, the director of the marketing department, has approached you with an idea for a project. What is your next step in getting the project going?
    1. Business-case analysis
    2. Project concept document
    3. Project charter
    4. Stakeholder determination

13. Youve been given an idea for a project by a customer. After some preliminary business-case analysis, youve developed a project concept document and submitted it to the customer for review. The customer has some minor changes shed like to make to the way youve analyzed the project. Where do the changes need to be made?
    1. Project concept document revision
    2. First draft of the project charter
    3. Project charter scope change
    4. Not necessary to note changes

14. In terms of resource loss, who has the most at risk with any given project?
    1. Customer
    2. Stakeholders
    3. Project sponsor
    4. Project manager

15. Given no preset corporate criteria for a project charter, what are some of the minimum requirements youd want to put into a charter? (Select all that apply.)
    1. Projected costs
    2. Milestones
    3. Business case
    4. Deadlines
    5. Project manager

16. When is a project concept document required? (Select all that apply.)
    1. Always
    2. Always if required by the company as a part of their project management standards
    3. For large projects
    4. For projects that will be reviewed by a central committee
    5. Never

17. A person whos in charge of working through the design process in a computerized system is called:
    1. Project manager
    2. Systems analyst
    3. Business analyst
    4. Chief architect

18. Your boss approaches you to develop a project plan to install an upgrade to some existing server software. You tell your boss that this activity doesnt really qualify as a project. When he asks why, what reasons do you give him? (Select all that apply.)
    1. This activity doesnt create a unique product or service.
    2. This activity isnt temporary.
    3. This activity cant be broken out into phases.
    4. This activity doesnt have any constraints associated with it.

19. Some of your project team members are driving you crazy! Theyre not adhering to the projects schedule, and theyre falling way behind. You need to jump-start them. What phase of the project are you in?
    1. Initiation
    2. Planning
    3. Executing
    4. Controlling
    5. Closing

20. Suppose that youre a project manager working on a software development project. You are working hand-in-hand with a systems analyst. Which person is it who actually makes the decisions about the projectthe requirements, scope, etc?
    1. Project manager
    2. Systems analyst
    3. Project manager with input from systems analyst
    4. Systems analyst with input from project manager

Answers to Review Questions

1. C. A project creates a unique product or service and has a defined start and finish.
2. B. The Project Management Institute (PMI) is the leading professional project management association with over 100,000 members worldwide.
3. D. A program is a group of related projects that can benefit from coordinated management.
4. C. The nine PMBOK Knowledge Areas are Scope, Time, Cost, Quality, Human Resources, Communications, Risk, Procurement, and Integration.
5. A. General management skills are the skills required of any manager to be successful at achieving goals. They include leadership, communications, problem solving, negotiation, and time management. Programming is a skill set specific to an IT organization.
6. B. The five process groups are Initiation, Planning, Executing, Controlling, and Closing
7. C. Discussions of a clients high-level requirements are part of the Initiation process group.
8. C. The overlapping of project phases is called fast tracking.
9. A. A projectized organization is designed around project work, and resources are assigned to projects. The project manager makes decisions affecting the project work.
10. B. The work you are undertaking does not create a unique product or service. It is part of the ongoing operational maintenance.
11. B. The procuring and shipment of servers is a budget and time constraint item, not a milestone. The placing of a server into duty might represent a milestone, however. The assembling of team members and sponsors signing off on requirements dont represent milestones, but functional aspects of formulating the project plan and scope document, respectively.
12. A. As a project manager, you start by running through a business-case analysis so that you can validate what the customer is requesting and whether or not the project is viable. A combination of people can help you with this analysistechnical people who understand the technology that can make the project happen, as well as people in the line of business (in this case, marketing) who understand the nuances of whats desired from a business perspective. You could certainly formulate a project concept document even if the project isnt viable , just so that everyone knows what was studied and what determinations were made. In larger projects with more esoteric inputs and outputs, you might ask for a feasibility study from a contractor.
13. A. Before writing the project charter, its important to make sure youve clearly stated the business case within the project concept document. Since the customer has said to you This is almost correct, but I have these things Id like to change, now is the time for you to update the project concept document before putting it in the charter. The charter is a document that shouldnt really be altered unless there are heavily mitigating circumstances.
14. C. The project sponsor is the one who authorizes the project and approves the use of the resources necessary to accomplish the projects goals. From a resource perspective, the project sponsor is the one with the most to lose. You might lose your job if the project goes very poorly, the customer wont get the refinements he or she asked for, and the stakeholders will be disappointed, but its the project sponsor wholl have to answer for the waste of time, money, and resources. Its the project sponsor who will be in the hot seat when others above him or her are asking the hard questions about how he or shes going to go about fixing a broken and costly project.
15. C, E. The project charter contains the name of the project manager and the business case for the project (as well as the name of the project sponsor). The other things listed are a part of the actual project plana different document than the project charter.
16. B, C. If a corporation has no rule regarding project concept documents, then you dont need to write one. However, for large projects these documents are a must-have because they set up the written dialog between the project manager and the customer and provide a paper path that can be backtracked in case the project goes awry.
17. B. A systems analyst is one who understands the Systems Development Life Cycle (SDLC) phases (and quite possibly does not understand anything about formal project management processes as denoted in PMI). She has had training in developing systems by working through the requirements for a given system and then boiling them down into procedures that developers can work from. She uses five distinct phases: Planning, Analysis, Design, Implementation and Operations and Support for the system.
18. A. Certainly, upgrading server software is a temporary phenomenon ; however, what youre doing isnt creating anything unique, therefore you really dont have a project on your hands. That being said, it would be no big deal to whip up a quick mini-project plan that details the steps required to systematically come up with a successful upgrade. Upgrading server software can be really scary.
19. D. The controlling phase happens when youve launched the project and youre underway. Now, as project manager, you segue into the role of having to keep people motivated and moving forward.
20. C. Think of it as similar to an engineer who designs an automobile and a project manager who gets all of the processes rolling to actually manufacture that automobile. The systems analyst is going to formally work out all of the necessary details to get the software developed. In larger shops, she may (either informally or formally ) don two hats: systems analyst and project manager, but the processes are very distinct. In larger shops , the project manager has under her a systems analyst (or two or more) doing the systems design work, and then feeding the project manager with (some of) the input necessary to get the deliverables manufactured and out the door.