Project Management – Professional Study Guide

Chapter 1: What Is a Project?

Overview Congratulations on your decision to study for and take the Project Management Institute (PMI®)’s Project Management Professional (PMP®) certification exam. This book was written with you in mind. The focus and content of this book revolve heavily around the information contained in A Guide to the Project Management Body of Knowledge (PMBOK). I will refer to the Guide to the PMBOK throughout this book and elaborate on those areas that appear on the test.

Keep in mind that the test covers all the project management processes, so don’t skip anything in your study time. When possible, I’ll pass on hints and study tips that I collected while studying for the exam myself. Your first tip is to familiarize yourself with the terminology used in the Guide to the PMBOK. PMI has worked hard to develop and define standard project management terms, and these terms are used interchangeably among industries. For example, resource planning means the same thing to someone working in construction, information technology, or telecommunications.

You’ll find Guide to the PMBOK terms explained throughout this book. Even if you are an experienced project manager, you might find that PMI uses specific terms for things that you call by another name. So, step one is to get familiar with the terminology. This chapter lays the foundation for building and managing your project. We’ll address project and project management definitions as well as organizational structures. Good luck! Is It a Project? The VP of marketing approaches you with a fabulous idea. “Fabulous” because he’s the big boss and because he thought it up. He wants to set up kiosks in local grocery stores as mini offices.

These offices will offer customers the ability to sign up for new wireless phone services, make their wireless phone bill payments, and purchase equipment and accessories. He believes that the exposure in grocery stores will increase awareness of the company’s offerings. After all, everyone has to eat, right? He told you that the board of directors has already cleared the project and he’ll dedicate as many resources to this as he can. He wants the new kiosks in place in 12 stores by the end of next year. The best news is he’s assigned you to head up this project. Your first question should be, “Is it a project? This may seem elementary, but confusing projects with ongoing operations happens often. According to the Guide to the PMBOK, page 4, “…a project is a temporary endeavor undertaken to create a unique product, service or result. ” Note  Quotations from the Guide to the PMBOK are cited in the text with the following abbreviation: Guide to the PMBOK: Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 2000 Edition, Project Management Institute, Inc. , 2000. Projects are temporary in nature, while operations are ongoing. Projects have definitive start dates and definitive end dates.

The project is completed when the goals and objectives of the project are accomplished. Sometimes projects end when it’s determined that the goals and objectives cannot be accomplished and the project is canceled. Operations involve work that is continuous without an ending date and often repeat the same process. Projects exist to bring about a product or service that hasn’t existed before. In this sense, a project is unique. However, don’t get confused by the term unique. For example, Ford Motor Company is in the business of designing and assembling cars. Each model that Ford designs and produces can be considered a project.

The models differ from each other in their features and are marketed to people with various needs. An SUV serves a different purpose and clientele than a luxury model. The design and marketing of these two models are unique projects. The actual assembly of the cars can be considered an operation—a repetitive process that is followed for most makes and models. Determining the characteristics and features of the different car models is carried out through what the Guide to the PMBOK terms as progressive elaboration. This means throughout the project, specific incremental steps re taken to examine the needs and requirements of the product of the project (the SUV, for example) and to fulfill the objectives. These needs are examined in detail and continually monitored and updated throughout the project. A project is successful when it meets or exceeds the expectations of the stakeholders. Stakeholders are those folks with a vested interest in your project. They are the people who have something to either gain or lose as a result of the project. The project sponsor, generally an executive in the organization with the authority to assign resources and enforce decisions regarding the project, is a stakeholder.

The customer is a stakeholder as are contractors and suppliers. The project manager and the managers from other departments in the organization are stakeholders as well. It’s important to identify all the stakeholders in your project up front. If you leave out an important stakeholder or their department’s function and don’t discover the error until well into the project, it could be a project killer. Figure 1. 1 shows a sample listing of the kinds of stakeholders involved on a typical project. Figure 1. 1: Project stakeholders Many times, stakeholders have conflicting interests.

It’s the project manager’s responsibility to understand these conflicts, and try to resolve them. Be certain to identify and meet with all key stakeholders early in the project to understand all their needs and constraints. When in doubt, stakeholder conflicts should always be resolved in favor of the customer. We’ve just learned that a project has several characteristics:

• Projects are unique.
• Projects are temporary in nature and have a definite beginning and ending date.
• Projects are completed when the project goals are achieved.
• A successful project is one that meets or exceeds the expectations of your stakeholders.

Using these criteria, let’s examine the assignment from the VP of marketing to determine if it is a project: Is it unique? Yes, because the kiosks don’t exist in the local grocery stores. This is a new way of offering the company’s services to its customer base. While the service the company is offering isn’t new, the way they are presenting their services is. Does the project have a limited time frame? Yes, the start date of this project is today, and the end date is the end of next year. It is a temporary endeavor. Is there a way to determine when the project is completed?

Yes, the kiosks will be installed, and services will be offered from them. Once all of the kiosks are intact and operating, the project will come to a close. Is there a way to determine stakeholder satisfaction? Yes, the expectations of the stakeholders will be documented in the form of requirements during the planning processes. These requirements will be compared to the finished product to determine if it meets the expectations of the stakeholder. Houston, we have a project. What Is Project Management? You’ve determined that you indeed have a project. What now?

The notes you scratched out on the back of a napkin at coffee break might get you started, but that’s not exactly good project management practice. We have all witnessed this scenario—an assignment is made and the project team jumps directly into the project, busying themselves with building the product or service requested. Often, careful thought is not given to the project-planning process. I’m sure you’ve heard co-workers toss around statements like, “That would be a waste of valuable time” or “Why plan when you can just start building? ” Project progress is rarely measured against the customer requirements.

In the end, the delivered product or service doesn’t meet the expectations of the customer! This is a frustrating experience for all those involved. Unfortunately, many projects follow this poorly constructed path. Project management is a process that involves several things including planning, putting the project plan into action, and measuring progress and performance. Planning is one of the most important functions you’ll perform during the course of a project. It sets the standard for the rest of the project’s life and is used to track future project performance.

Before we begin the planning process, we’ll need to look at some of the skills needed to perform project management functions and some of the constraints found on all projects. Project Constraints In my organization, and I’m sure the same is true in yours, there are far more project requests than we have resources to work on them. In this case, resources are a constraint. You’ll find a similar phenomenon occurs on individual projects as well. Every project must work within the triple constraint combination of time, money, and quality. One or two of the triple constraints, sometimes all three, are limited.

You might work on projects where you have an almost unlimited budget (don’t we wish), but time is the limitation. You can have all the money and people you need to accomplish your project, but you need to complete the project in 24 months. The computer-programming changes required for the year 2000 are an example of a time-constrained project because moving the date wasn’t an option. Other projects might present the opposite scenario. You have all the time you need to complete the project, but the budget is fixed. Still other projects may incorporate two or three of the constraints.

Government agencies are notorious for starting projects that have at least two and sometimes all three constraints. For example, new tax law legislation is passed that impacts the computer programming, requiring new programs to calculate and track the tax changes. Typically, a due date is given when the tax law takes effect, and the organization responsible is required to implement the changes with no additions to budget or staff. In other words, they are told to use existing resources to accomplish the goals of the project. The specific requirements of the project are such that quality cannot be fudged to try to meet the time deadline.

As a project manager, one of your biggest jobs is to balance the triple constraints while meeting or exceeding the expectations of your stakeholders. In most projects, you will usually be faced with balancing only one or two of the triple constraints. For example, if the project goal is a high-quality pro-duct, the saying goes, “I can give it to you fast or I can give to you cheap, but I can’t give it to you fast and cheap. ” Tools and Techniques Project management brings together a set of tools and techniques, performed by people, to describe, organize, and monitor the work of project activities.

Project managers are the people responsible for managing the project processes and applying the tools and techniques used to carry out the project activities. There are many advantages to organizing projects and teams who utilize these techniques. We’ll be examining these advantages in-depth throughout the remainder of this book. Programs are groups of projects that are managed using the same techniques in a coordinated fashion. Sometimes, programs include aspects of ongoing operations as well. This would be the case where a very large program exists with many subprojects under it—for example, building a new shopping mall.

Many subprojects exist underneath this program such as excavation, construction, interior design, store placement, marketing, facilities management, etc. Each of the subprojects is really a project unto itself. Each has its own project manager, who reports to a project manager with responsibility over several of the areas, who in turn reports to the head project manager over the entire program. After the structure itself is built, the management of the facility is considered the ongoing operations part of this program. Project management involves many skills and techniques.

Project managers are generalists with many skills in their repertoire. They are problem solvers who wear many hats. Project managers might indeed possess technical skills, but technical skills are not a prerequisite to project management. Your project team will have technical experts, and they are the people whom the project manager will rely on for technical details. I have seen project managers with many years experience in the construction industry successfully manage multi-million dollar information technology projects. This is because project management techniques apply across industries and across projects.

Understanding and applying good project management techniques, along with a solid understanding of general management skills, are career builders for all aspiring project managers. Project Manager’s Tool Bag Project managers have been likened to small-business owners. They need to know a little bit about every aspect of management. The various skills in a project manager’s tool bag can be broken out in a more or less declining scale of importance. Let’s discuss each of the skills in a bit more detail. Communication Skills One of the single most important characteristics of a first-rate project manager is excellent communication skills.

You will also have to organize meetings, put together teams, and perhaps manage and organize media release schedules depending on your project. Closely associated with organizational skills are time management skills. Take some time to attend a time management class if you’ve never attended one. They have some great tips and techniques to help you prioritize problems and interruptions, prioritize your day, and manage your time. Planning is discussed extensively throughout the course of this book. There isn’t any aspect of project management that doesn’t first involve planning.

Planning skills go hand in hand with organizational skills. Combining these two with excellent communication skills is almost a sure guarantee of your success in the project management field. Budgeting Skills Project managers establish and manage budgets and therefore need some knowledge of finance and accounting principles. Especially important in this skill area is the ability to perform cost estimates for project budgeting. There are different methods available to determine the project costs. They range from estimating individual activities and rolling the estimates up, to estimating the project’s cost in one big chunk.

These methods will be discussed more fully in later chapters. After a budget is determined, you can start spending. This sounds more exciting than it actually is. Reading and understanding vendor quotes, preparing or overseeing purchase orders, and reconciling invoices are budgeting skills that will be used by the project manager on most projects. These costs will be linked back to project activities and expense items in the project’s budget. Problem Solving Show me a project and I’ll show you problems. All projects, in fact much of everyday life, have some problems. Isn’t that what they say builds character?

But I digress. Problem solving is really a twofold process. First, you must define the problem. Often when defining problems, we end up just describing the symptoms instead of really getting to the heart of what the problem is. To avoid that, ask yourself questions like, “Is it an internal or external problem? ” or “Is it a technical problem? ” or “Are there interpersonal problems between team members? Is it managerial? ” These kinds of questions will help you to get to the meat of the problem. Next, after the problem has been defined, you have some decisions to make.

It will take a little time to examine and analyze the problem, the situation causing it, and the solution alternatives available. After this analysis, the project manager will determine the best course of action to take and implement the decision. Negotiation and Influencing Effective problem solving requires negotiation and influencing skills. We all utilize negotiation skills in one form or another every day. For example, on a nightly basis I am asked, “Honey, what do you want for dinner? ” Then the negotiations begin, and the fried chicken versus swordfish discussion commences.

Simply put, negotiating is working with others to come to agreement. Negotiation on projects will be necessary in almost every area from scope definition, to budgets, contracts, resource assignments, and more. Influencing is really convincing the other party that swordfish is a better choice than fried chicken even if that is what they want. In other words, it’s the ability to get people to do things they wouldn’t do otherwise. It’s also the ability to change minds and the course of events, and to influence outcomes. These skills will be utilized in all areas of project management.

Start practicing now because, guaranteed, you’ll need these skills on your next project. Leading Leadership and management are not synonymous terms. Leaders impart vision, gain consensus for strategic goals, establish direction, and inspire and motivate others. Managers focus on results and are concerned with getting the job done according to the requirements. Even though leaders and managers are not the same, project managers must exhibit the characteristics of both during different times on the project. Understanding when to switch from leadership to management and then back again is a finely tuned and necessary talent.

Team Building and Human Resources Project managers will rely heavily on team building and human resource management skills. Teams are often formed with people from different parts of the organization. These people may or may not have worked together before—so there may be some component of team-building groundwork that will involve the project manager. The project manager will set the tone for the project team and will help them work through the various team-forming stages to become fully functional. The project manager may take on a variety of roles during this initial team-building process.

An interesting caveat to the team-building role is that project managers many times are responsible for motivating team members who are not their direct reports. This has its own set of challenges and dilemmas. One way to help this situation is to ask the functional manager to allow you to participate in your project team members’ performance reviews. Use the negotiation and influencing skills I talked about earlier to make sure you’re part of this process. A Mile Wide and an Inch Deep Project managers are an interesting bunch. They know a little bit about a lot of things and are excellent communicators.

Or, as one person said, he’s “a mile wide and an inch deep. ” They have the ability to motivate people, even those who have no reason to be loyal to the project, and they can make the hard-line calls when necessary. Project managers can get caught in sticky situations that occasionally require making decisions that are good for the company (or the customer) but aren’t good for certain stakeholders. These offended stakeholders will then drag their feet, and the project manager has to play the heavy in order to motivate and gain their cooperation again.

Some organizations hire contract project managers to run their large, company-altering projects just because they don’t want to burn out a key employee in this role. Fortunately, that doesn’t happen often. Now that you’ve been properly introduced to some of the skills you need in your tool kit, you’ll know to be prepared to communicate, solve problems, lead, and negotiate your way through your next project. Understanding Organizational Structures Just as projects are unique, so are the organizations in which they’re carried out.

The key to determining the type of organization you work in is by measuring how much authority senior management is willing to delegate to project managers. While uniqueness abounds in business cultures, all organizations are structured in one of three ways: functional, projectized, or matrix. Variations and combinations exist among these three structures, such as a projectized structure within a functional organization, and weak matrix, balanced matrix, and strong matrix organizations. It pays to know and understand the organizational structure and the culture of the entity you’re working with.

Companies with aggressive cultures that are comfortable in a leading-edge position within their industry are highly likely to take on risky projects. Project managers who are willing to suggest new ideas and projects that have never been undertaken before are likely to receive a warm reception in this kind of environment. Conversely, organizational cultures that are risk averse and prefer the follow-the-leader position within their industry are highly unlikely to take on risky endeavors. Project managers with risk-inclined, aggressive styles are likely to receive a cool reception in a culture like this.

The level of authority the project manager enjoys is denoted by the organizational structure. For example, a project manager within a functional organization has little to no formal authority. And their title may not be project manager, but instead they’re called a project leader, project coordinator, or perhaps project expeditor. Let’s take a look at each of these organizations individually to better understand how the project management role works in each one. Functional Organizations The most common type of organization is the functional organization.

Chances are you work in this type of organization. This is probably the oldest style of organization and is therefore known as the traditional approach to organizing businesses. Functional organizations are centered on specialties and grouped by function; hence the term functional organization. As an example, the organization might have a human resources department, finance department, marketing department, etc. The work in these departments is specialized and requires people who have the skills sets and experiences in these specialized functions to perform specific duties for the department.

Figure 1. 2 shows a typical org chart for a functional organization. Figure 1. 2: Functional org chart You can see that this type of organization is set up to be a hierarchy. Staff personnel report to managers who report to department heads who report to vice presidents who report to the CEO. In other words, each employee reports to only one manager, and ultimately, one person at the top is in charge. Many companies today, as well as governmental agencies, are structured in a hierarchical fashion. In organizations like this, be aware of the chain of command.

A strict chain of command may exist, and the corporate culture might dictate that you follow it. Roughly translated: Don’t talk to the big boss without first talking to your boss who talks to their boss who talks to the big boss. Wise project managers should determine if there is a chain of command, how strictly it’s enforced, and how the chain is linked before venturing outside of it. Each department or group in a functional organization is managed independently and has a limited span of control. Marketing doesn’t run the finance department or their projects, for example.

The marketing department is concerned with their own functions and projects. If it were necessary for the marketing department to get input from the finance department on a project, the marketing team members would follow the chain of command. A marketing manager would speak to a manager in finance to get the needed information and then pass it back down to the project team. Commonalities exist among the personnel assigned to the various departments in a functional organization. In theory, people with similar skills and experiences are easier to manage as a group.

Instead of scattering them throughout the organization, it is more efficient to keep them functioning together. Work assignments are easily distributed to those who are best suited for the task when everyone with the same skill works together. Along these lines, workers in functional organizations specialize in an area of expertise— finance, for instance—and then become very good at their specialty. Usually, the supervisors and managers of these workers are experienced in the area they supervise and are able to recommend training and career enrichment activities for their employees.

There is a clear upward career path for people in a functional organization. An assistant budget analyst may be promoted to a budget analyst and then eventually to a department manager over many budget analysts. Functional organizations have their disadvantages. If this is the kind of organization you work in, you probably have experienced some of them. One of the greatest disadvantages for the project manager is that they have little to no formal authority. This does not mean that project mana-gers in functional organizations are doomed to failure.

Many projects are undertaken and successfully completed within this type of organization. Good communication, interpersonal, and influencing skills on the part of the project manager are required to bring about a successful project under this structure. In a functional organization, the vice president or senior department manager is usually the one responsible for projects. The title of project manager denotes authority, and in a functional structure, that authority rests with the VP. Projects are typically undertaken in a divided approach in a functional organization.

For example, the marketing department will work on their portion of the project and then hand it off to the manufacturing department to complete their part of the project and so on. The work the marketing department does is considered a marketing project, while the work the manu-facturing department does is considered a manufacturing project. Some projects require project team members from different departments to work together at the same time on various aspects of the project. Project team members in this structure will more than likely remain loyal to their functional manager.

The functional manager is responsible for their performance reviews, and their career opportunities lie within the functional department—not within the project team. Exhibiting leadership skills by forming a common vision regarding the project and the ability to motivate people to work toward that vision are great skills to exercise in this situation. As previously mentioned, it also doesn’t hurt to have the project manager work with the functional manager in contributing to the employee’s performance review.

Competition for resources and project priorities can become fierce when multiple projects are undertaken within a functional organization. For example, in my organization, it’s common to have competing project requests from three or more departments all vying for the same resources. Thrown into the heap is the requirement to make mandated tax law changes, which automatically usurps all other priorities. This sometimes causes frustration and political infighting. One department thinks their project is more important than another and will do anything to get that project pushed ahead of the others.

Again, it takes great skill and diplomatic abilities to keep projects on track and functioning smoothly. In a later chapter, we’ll discuss the importance of gaining stakeholder buy-in, prioritization, and communication distribution to avert some of these problems. Functional organizations are the most common form of organization. Project managers have little authority in these organizations, but with the right skills, they can successfully accomplish many projects. Table 1. 1 highlights the advantages and disadvantages of this type of organization. Table 1. 1: Functional Organizations Advantages Disadvantages|

Enduring organizational structure. Project manager has little to no formal authority. Clear career path with separation of functions allowing specialty skills to flourish. Multiple projects compete for limited resources and priority. Employees have one supervisor with a clear chain of command. Project team members are loyal to the functional manager. Projectized Organizations Projectized organizations are nearly the opposite of functional organizations. The focus of this type of organization is the project itself. The idea behind a projectized organization is to develop loyalty to the project, not to a functional manager.

Figure 1. 3 shows a typical org chart for a projectized organization. Figure 1. 3: Projectized org chart Organizational resources are dedicated to projects and project work in purely projectized organizations. Project managers almost always have ultimate authority over the project in this structure and report directly to the CEO. In a purely projectized organization, supporting departments like human resources and accounting might report directly to the project manager as well. Project managers are responsible for making decisions regarding the project and acquiring and assigning resources.

They have the authority to choose and assign resources from other areas in the organization or to hire them from outside if needed. However, project managers in all organizational structures are limited by the triple constraints. For example, if the budget doesn’t exist to hire additional resources, the project manager will have to come up with alternatives to solve this problem. Teams are formed and often collocated, which means that team members physically work at the same location. Project team members report to the project manager, not a functional or departmental manager.

One obvious drawback to a projectized organization is that project team members may find themselves out of work at the end of the project. An example of this might be a consultant who works on a project until completion and then is put on the bench or let go at the end of the project. Some inefficiency exists in this kind of organization when it comes to resource utilization. If you have a situation where you need a highly specialized skill at certain times throughout the project, the resource you’re using to perform this function might be idle during other times in the project.

The Real World Scenario—The Projectized Graphic Artist

You’ve been appointed project manager for your company’s website design and implementation. You’re working in a projectized organization, so you have the authority to acquire and assign resources. You put together your team including programmers, technical writers, testers, and business analysts. Debbie, a highly qualified graphic arts designer, is also part of your team. Debbie’s specialized graphic arts skills are needed only at certain times throughout the project. When she has completed the graphics design portion of the screen she’s working on, there isn’t anything else for her to do until the next page is ready.

Depending on how involved the project is and how the work is structured, days or weeks might pass before Debbie’s skills are needed. This is where the inefficiency occurs in a purely projectized organization. The project manager will have to find other duties that Debbie can perform during these downtimes. It’s not practical to let her go and then hire her back when she’s needed again. In this situation, you might assign Debbie to other project duties when she’s not working on graphics design. Perhaps she can edit the text for the web pages or assist with the design of the upcoming marketing campaign.

You might also share Debbie’s time with another project manager in the organization. During the planning process, you will discover the skills and abilities of all your team members so that you can plan their schedule accordingly and eliminate idle time. Projectized structures can coexist within functional organizations. In the case of a high-profile, critical project, for instance, the functional organization might appoint a special project team to work only on that project. The team is structured outside the bounds of the functional organization, and the project manager has ultimate authority for the project.

This is a workable project management approach and ensures open communication between project manager and team members. At the end of the project, the project team is dissolved, and the project members return to their functional areas to resume their usual duties. In summary, projectized organizations are identified several ways:

• Project managers have ultimate authority over the project.
• The focus of the organization is the project.
• The organization’s resources are focused on projects and project work.
• Team members are collocated.
• Loyalties are formed to the project, not to a functional manager.

Matrix Organizations Matrix organizations came about to minimize the differences between, and take advantage of, the strengths and weaknesses of functional and projectized organizations. The idea at play here is that the best of both organizational structures can be realized by combining them into one. The project objectives are fulfilled, and good project management techniques are utilized while still maintaining a hierarchical structure in the organization. Employees in a matrix organization report to one functional manager and at least one project manager.

It’s possible that employees could report to multiple project managers if they are working on multiple projects at one time. Functional managers pick up the administrative portion of the duties and assign employees to projects. They also monitor the work of their employees on the various projects. Project managers are responsible for executing the project and giving out work assignments based on project activities. Project managers and functional managers share the responsibility of performance reviews for the employee.

In a nutshell, functional managers assign employees to projects, while project managers assign tasks associated with the project. Matrix organizations allow project managers to focus on the project and project work just like in a projectized organization. The project team is free to focus on the project objectives without distractions from the functional department. Project managers should take care when working up activity and project estimates for the project in a matrix organization. The estimates should be given to the functional managers for input before publishing.

The functional manager is the one in charge of assigning or freeing up resources to work on projects. If the project manager is counting on a certain employee to work on the project at a certain time, the project manager should determine their availability up front with the functional manager. Project estimates might have to be modified if it’s discovered that the employee they were counting on is not available when needed. As we’ve discussed, a lot of communication and negotiation takes place between the project manager and the functional manager.

This calls for a balance of power between the two, or one will dominate the other. In a strong matrix organization, the balance of power rests with the project manager. They have the ability to strong-arm the functional managers into giving up their best resources for projects. Sometimes, more resources than necessary are assembled for the project, and then project managers negotiate these resources among themselves, cutting out the functional manager altogether, as you can see in Figure 1. 4. Figure 1. 4: Strong matrix org chart

On the other end of the spectrum is the weak matrix (see Figure 1. 5). As you would suspect, the functional managers have all the power in this structure. Project managers are really project coordinators or expeditors with part-time responsibilities on projects in a weak matrix organization. Project managers have little to no authority, just like in the functional organization. On the other hand, the functional managers have a lot of authority and make all the work assignments. The project manager simply expedites the project. Figure 1. : Weak matrix org chart In between the weak matrix and the strong matrix is an organizational structure called the balanced matrix (see Figure 1. 6). The features of the balanced matrix are what we’ve been discussing throughout this section. The power is balanced between project managers and functional managers. Each manager has responsibility for their parts of the project or organization, and employees get assigned to projects based on the needs of the project, not the strength or weakness of the manager’s position. Figure 1. 6: Balanced matrix org chart

Matrix organizations have subtle differences, and it’s important to understand their differences for the exam. The easiest way to remember them is that the weak matrix has many of the same characteristics as the functional organization, while the strong matrix has many of the same characteristics as the projectized organization. The balanced matrix is exactly that—a balance between weak and strong where the project manager shares authority and responsibility with the functional manager.

Organizations are unique, as are the projects they undertake. Understanding the organizational structure will help you, as a project manager, with the cultural influences and communication avenues that exist in the organization to gain cooperation and successfully bring your projects to a close. Understanding Project Life Cycles and Project Management Processes Project life cycles are similar to the life cycle that parents experience raising their children to adulthood. Children start out as infants and generate lots of excitement wherever they go. However, not much is known about them at first. So we study them as they grow and assess their needs.

Over time, they mature and grow (and cost a lot of money in the process), until one day the parents’ job is done. Projects start out just like this and progress along a similar path. Someone comes up with a great idea for a project and actively solicits support for the project. The project, after being approved, progresses through the intermediate phases to the ending phase, where the project is completed and closed out. Project Life Cycles and Phases All projects are divided into phases, and all projects, large or small, have a similar life cycle structure. At a minimum, a project will have a beginning or initiation phase, an intermediate phase or phases, and an ending phase. The number of phases depends on the project complexity and its industry.

All the collective phases the project progresses through in concert are called the project life cycle. The end of each phase allows the project manager, stakeholders, and project sponsor the opportunity to determine if the project should continue to the next phase. Project phases evolve through the life cycle in a series of “handoffs. ” The end of one phase typically marks the beginning of the next. For example, in the construction industry, feasibility studies often take place in the beginning phase of a project. The purpose of the feasibility study might be to determine if the project is worth undertaking and whether the project will be profitable for the construction company.

The completion and approval of the feasibility study trigger the beginning of the planning and design phase. You will recognize phase completion because each phase has a specific deliverable, or multiple deliverables, that marks the end of the phase. A deliverable is an output that must be produced to bring the phase or project to completion. Deliverables are tangible and can be measured and easily proved. For instance, a hypothetical deliverable produced in the beginning phase of our construction industry example would be the feasibility study. Deliverables might also include things like design documents, project budgets, blueprints, project schedules, prototypes, etc.

This analysis allows those involved the opportunity to determine if the project should continue to the next phase. The feasibility study might show that environmental impacts of an enormous nature would result if the construction project were undertaken at the proposed location. Based on this information, a go or no-go decision can be made at the end of this phase. The end of a phase also gives the project manager the ability to discover, address, and take corrective action against errors discovered during the phase. There are times when phases are overlapped to shorten or compress the project schedule. The Guide to the PMBOK terms this fast tracking.

Fast tracking means that a later phase is started prior to completing and approving the phase, or phases, that come before it. All projects follow the life cycle pattern and, as a result, have the following things in common. In the beginning phase, which is where the Initiation process occurs, costs are low, and there are few team members assigned to the project. As the project progresses, costs and staffing increases and then tapers off at the closing phase. The potential that the project will come to a successful ending is lowest at the beginning of the project with an increasing chance for success as the project progresses through the life cycle stages.

Project Management Processes

Project management processes, according to the Guide to the PMBOK, organize and describe the work of the project. These processes are performed by people and, much like the project phases, are interrelated and dependent on one another. For example, it would be difficult to identify specific project activities without first having an understanding of the project requirements. PMI Process Groups The Guide to the PMBOK documents five process groups in the project management process: Initiation, Planning, Executing, Controlling, and Closing. We’ll look at an overview of each process here and go into more detail in later chapters. Initiation The Initiation process, as its name implies, occurs at the beginning of the project or phase.

Initiation acknowledges that a project, or the next project phase, should begin. Initiation grants the approval to commit the organization’s resources to working on the project or phase. Planning Planning is the process of formulating and revising planning documents to be used throughout the remainder of the project. This process group is where the project requirements are fleshed out and stakeholders are identified. Planning has more processes than any of the other project management processes. The Executing, Controlling, and Closing process groups all rely on the Planning process group and the documentation produced during the Planning processes in order to carry out their functions.

Project managers will perform frequent iterations of the Planning processes prior to project completion. Projects are unique, and as such have never been done before. Therefore, Planning must encompass all areas of project management and consider budgets, activity definition, scope planning, schedule development, risk identification, staff acquisition, procurement planning, and more. The greatest conflicts a project manger will encounter in this process group are project prioritization issues. Executing The Executing process group involves putting the project plans into action. It’s here that the project manager will coordinate and direct project resources to meet the objectives of the project plan.

The Executing process keeps the project plan on track and ensures that future execution of project plans stays in line with project objectives. The Executing process group will utilize the most project time and resources. Costs are usually highest during the Executing process. Project managers will experience the greatest conflicts over schedules in this phase. Controlling The Controlling process group is where project performance measurements are taken and analyzed to determine if the project is staying true to the project plan. If it’s discovered that variances exist, corrective action is taken to get the project activities aligned with the project plan.

This might require additional passes through the Planning process to realign to the project objectives. Closing The Closing process group is probably the most often skipped process in project management. Once the project objectives have been met, most of us are ready to move on to the next project. However, Closing is important as all the project information is gathered now and stored for future reference. The documentation collected during Closing processes can be reviewed and utilized to avert potential problems on future projects. Contract closeout occurs here, and formal acceptance and approval are obtained from project stakeholders. The Process Flow

The five process groups are iterative and should not be thought of as one-time processes. These processes will be revisited throughout the project life cycle several times as the project is refined. PMI calls this process of going back through the process groups an iterative process. The completion of each process allows the project manager and stakeholders to reexamine the business needs of the project and determine if the project is satisfying those needs. And it is another opportunity to make a go or no-go decision. Figure 1. 7 shows the five process groups in a typical project life cycle. Keep in mind that during phases of a project, the Closing phase can provide input to the Initiation phase.

For example, once the feasibility study we discussed earlier is accepted or closed, it becomes input to the Initiation phase of design and planning. Figure 1. 7: Project management process groups It’s important to understand the flow of these processes for the exam. If you remember the processes and their inputs and outputs, it will help you when you’re trying to decipher an exam question. Sometimes just understanding which process the question is asking about will help you determine the answer.

One trick you could use to memorize these processes is to remember syrup of ipecac. (You probably have some of this poison antidote in your medicine cabinet at home. When you sound out the first initial of each of the processes, it sounds like “ipecac”—IPECC (Initiation, Planning, Executing, Controlling, and Closing). Processes exist within most of the process groups. For example, the Closing life cycle process group consists of two processes, Contract Closeout and Administrative Closure. Each process takes inputs and uses them in conjunction with various tools and techniques to produce outputs. It’s outside the scope of this book to list all the inputs, tools and techniques, and outputs for each process in each life cycle phase. You’ll find these detailed in the Guide to the PMBOK, and I highly recommend you get familiar with them. There are test questions regarding inputs, tools and techniques, and outputs.

One way to keep them all straight is to remember tools and techniques usually require action of some sort, be it measuring, applying some skill or technique, planning, or using expert judgment. Outputs are usually in the form of a deliverable. Remember that a deliverable is characterized with results or outcomes that can be measured, are tangible, and are provable. Last but not least, outputs from one process sometimes serve as inputs to another process. Establishing the Project Management Office The concept of a project management office, sometimes referred to as the PMO, has been around for several years. You won’t need to know anything about PMOs for the exam.

However, in practice, you’ll find many organizations are establishing PMOs in many different forms. The purposes of establishing a PMO, and its benefits, are many. The most common reason a company starts a project management office is to establish and maintain procedures and standards for project management methodologies to be used throughout the organization. In some organizations, project managers might work directly for the PMO and are assigned from this office to projects as they are initiated. The PMO, depending on its size and function, sometimes has experts available that assist project managers in project planning, estimating, and business assumption verification tasks.

They serve as mentors to junior-level project managers and act as consultants to the senior project managers. The PMO takes responsibility for maintaining and archiving project documentation. All project documentation and information is collected and tracked by the PMO for future reference. This office compares project goals with project progress and gives feedback to the project teams. This office also measures the project performance of active projects and suggests corrective actions. The PMO evaluates completed projects for their adherence to the triple constraints and asks the following: Did the project meet the time frames established, did it stay within budget, and was the quality acceptable?

Project management offices are becoming more common in organizations today, if for no other reason, simply to serve as a collection point for project documentation. Some PMOs are fairly sophisticated and prescribe the standards and methodologies to be used in all project phases across the enterprise. Still others provide all these functions and also offer project management consulting services. However, the establishment of a PMO is not required in order for you to apply good project management practices to your next project. Summary Phew, we covered a lot of ground in this chapter. We learned that projects exist to bring about a unique product or service.

Projects are temporary in nature and have definite beginning and ending dates. Stakeholders are those people or organizations that have a vested interest in the outcome of the project. Stakeholders include people like the project sponsor, the customer, key management personnel, the project manager, contractors, suppliers, and more. Projects are considered complete when the project meets or exceeds the expectations of the stakeholders. Project management is a discipline that brings together a set of tools and techniques to describe, organize, and monitor the work of project activities. Project managers are the ones responsible for carrying out these activities.

Every project must work within constraints. The primary constraints that will affect all projects are the triple constraints of budget, time, and quality. Project managers have a wide variety of skills. Not only should they be versed in the field they’re working in, but in general management skills as well. Communication is the most important skill a project manager will use in the course of a project. Organizational structures come in variations of three forms: functional, projectized, and matrix organizations. Functional organizations are traditional with hierarchical reporting structures. Project managers have little to no authority in this organization.

Projectized organizations are structured around project work, and staff personnel report to project managers. Project managers have full authority in this organizational structure. Matrix organ-izations are a combination of the functional and projectized. A project manager’s authority varies depending on the structure of the matrix, be it a weak matrix, balanced matrix, or strong matrix. Projects progress along a life cycle path. The life cycle consists of phases, and the Guide to the PMBOK process groups are performed throughout the project’s life cycle. The Guide to the PMBOK process groups are Initiation, Planning, Executing, Controlling, and Closing.

Project management offices are a way to organize and establish standards for project management techniques within an organization. They can also serve as a project library, housing project documentation for future reference. Exam Essentials Be able to describe the difference between projects and operations. A project is temporary in nature with a definite beginning and ending date. Operations are ongoing. Be able to denote some of the skills every good project manager should possess. Communication, budgeting, organizational, problem solving, negotiation and influencing, leading, and team building. Be able to differentiate the different organizational structures.

These new products will be offered indefinitely starting with the spring catalog release. Which of the following is true? This is a project because this new product line has never been manufactured and sold by this company before. This is an ongoing operation because the company is in the business of manufacturing kitchen appliances. Introducing designer colors and features is simply a new twist on an existing process. This is an ongoing operation because the new product line will be sold indefinitely. It’s not temporary. This is not a project or an ongoing operation. This is a new product introduction not affecting ongoing operations. Your company manufactures small kitchen appliances.

They are introducing a new product line of appliances in designer colors with distinctive features for kitchens in small spaces. These new products will be offered indefinitely starting with the spring catalog release. In order to determine the characteristics and features of the new product line, you will have to perform which of the following?. Fast tracking. Consulting with the stakeholders. Planning the project life cycle. Progressive elaboration 5. A project is considered successful when:. The product of the project has been manufactured. The project sponsor announces the completion of the project. The product of the project is turned over to the operations area to handle the ongoing aspects of the project.

The project meets or exceeds the expectations of the stakeholders. The VP of customer service has expressed concern over a project you’re involved in. His specific concern is that if the project is implemented as planned, he’ll have to purchase additional equipment to staff his customer service center. The cost is substantial and was not taken into consideration in the project budget. The project sponsor insists that the project must go forward as originally planned or the customer will suffer. Which of the following is true?. The VP of customer service is correct. Since the cost was not taken into account at the beginning of the project, the project should not go forward as planned.

The project objective is to construct a set of outbuildings to house the Olympic support team that will be arriving in your city 18 months from the project start date. Resources are not readily available as they are currently assigned to other projects. Jack, an expert crane operator, is needed for this project two months from today. Which of the following skills will you use to get Jack assigned to your project? Negotiation and influencing skills. Communication and organizational skills. Communication skills. Problem-solving skills 11. You are a project manager with technical expertise in the pharmaceutical industry. You’ve decided to try your hand at project management in the entertainment industry. Which of the following is true?

You will likely be successful because communication skills are your strong suit. You anticipate having technical experts on your project team to address industry specifics that you’re not familiar with. You will likely be successful because your organizational skills are excellent. You anticipate having technical experts on your project team to address industry specifics that you’re not familiar with. You will probably be successful because you have a friend in the entertainment industry that has briefed you on all the important aspects of this project that you’ll need to know. You anticipate having technical experts on your project team to address industry specifics that you’re not familiar with.

You will probably not be successful because you have little knowledge of the entertainment industry even though you anticipate having technical experts on your project team to address industry specifics that you’re not familiar with. You are managing a project to install a new postage software system that will automatically print labels and administer postage for certified mailings, overnight packages, and other special mailing needs. You’ve attempted to gain the cooperation of the business analyst working on this project and need some answers. She is elusive and tells you that this project is not her top priority. To avoid situations like this in the future, you should:

Establish the business analyst’s duties well ahead of due dates and tell her you’ll be reporting on her performance to her functional manager. Establish the business analyst’s duties well ahead of due dates and tell her you are expecting her to meet these expectations because the customer is counting on the project meeting due dates to save significant costs on their annual mailings. Negotiate with the business analyst’s functional manager during the planning process to establish expectations and request to participate in the business analyst’s annual performance review. Negotiate with the business analyst’s functional manager during the planning process to establish expectations and inform the functional manager of the requirements of the project.

You are in charge of the demolition phase of this project, and you report to the project manager in charge of this project. You have been hired on contract and will be released at the completion of the demolition phase. What type of organizational structure does this represent?. Functional organization. Weak matrix organization. Projectized organization. Balanced matrix organization 17. What are the five project management process groups, in order?. Initiation, Executing, Planning, Controlling, and Closing. Initiation, Controlling, Planning, Executing, and Closing. Initiation, Planning, Controlling, Executing, and Closing. Initiation, Planning, Executing, Controlling, and Closing 18. You have been assigned to a project in which the objectives are to expand three miles of the north-south highway through your city by two lanes in each direction. You are interested in implementing a new project process called design-build in order to speed up the project schedule. The idea is that the construction team will work on the first mile of the highway reconstruction at the same time the design team is coming up with plans for the third mile of the reconstruction rather than completing all design before any construction begins. This is an example of:. Managing the projects as a program. Fast tracking. Progressive elaboration. Collocation 19. During which project management process are risk and stakeholder’s ability to influence project outcomes the highest at the beginning of the process?. Planning. Executing. Initiation. Controlling 20. You are a project manager working on gathering requirements and establishing estimates for the project. Which process group are you in?. Planning. Executing. Initiation.

Chapter 2: Initiating the Project

And, as you’ve probably already guessed, we’ll be using some of the general management skills we outlined in Chapter 1 also. One of the first skills you are going to put to use will be your communication skills. Are you surprised? Of course you’re not. It all starts with communication. You can’t start defining the project until you’ve first talked to the project sponsor, key stakeholders, and management personnel. All good project managers have honed their communication skills to a nice sharp edge. You’ll remember from Chapter 1 that project Initiation is the first process in a project life cycle. You can think of it as the official project kickoff. Initiation acknowledges that the project, or the next phase in an active project, should begin.

Initiation then culminates in the publication of a project charter. We’ll discuss project charters in Chapter 3 in more depth. But we’ve got work to do before we’re ready to produce the project charter, so we’ll wrap up this chapter with a discussion of the preliminary elements of a charter document. We will also talk about project Initiation and introduce some of the things that make up this process. But before we dive into Initiation, we’ll first take a look at what PMI calls the Project Management Knowledge Areas. Knowledge areas are a collection of processes that share similar themes and, therefore, benefit from the expertise of specific knowledge and skills in each of these areas.

At the end of this chapter, we’ll introduce a case study that will illustrate the main points of the chapter. We’ll take this case study with us from chapter to chapter and begin building a project from each of things we learned. The Project Management Knowledge Areas According to the Guide to the PMBOK, project Initiation, as we’ve discussed, is the first project management process group in the life cycle of a project. In addition to the project process groups, the Guide to the PMBOK classifies the processes that make up each project management process group into nine Project Management Knowledge Areas. These groupings, or know-ledge areas, bring together processes that have things in common.

For example, Project Cost Management involves all aspects of the budgeting process, as you would suspect, such as Resource Planning, Cost Estimating, Cost Budgeting, and Cost Control. These processes belong to different project management process groups, but because they all involve costs and budgeting, they share many aspects in common. Understanding the Project Management Knowledge Areas Let’s take a closer look at each area so we really understand how their role works with the process groups. Included in each of the following subsections is a figure that illustrates the knowledge area, the processes that make up each knowledge area, and the project management process groups that each process belongs to.

This will help you to see the big picture in terms of process groups versus knowledge areas. We will be discussing each of the processes in the various knowledge areas throughout the book, but for now, let’s take a high-level look at each of them. Project Integration Management Project Integration Management (see Figure 2. 1) is comprised of three processes: Project Plan Development, Project Plan Execution, and Integrated Change Control. The Project Integration knowledge area is concerned with coordinating all aspects of the project plan and is highly interactive. Project planning, project execution, and change control occur throughout the project and are repeated continuously while working on the project.

Project planning and execution involve weighing the objectives of the project against alternatives to bring the project to a successful completion. Change control impacts the project plan, which in turn impacts execution, so you can see that these three processes are very tightly linked. The processes in this area also interact with other processes in the remaining knowledge areas. Figure 2. 1: Project Integration Management Project Scope Management Project Scope Management (see Figure 2. 2) has five processes: Initiation, Scope Planning, Scope Definition, Scope Verification, and Scope Change Control. Project Scope Management is concerned with the work of the project.

All of the processes involved with the work of the project, and only the work that is required to complete the project, are found in this knowledge area. We’ll talk about Initiation in more detail in the remainder of this chapter. Scope Planning, Scope Definition, Scope Verification, and Scope Change Control involve detailing the requirements of the product of the project and the activities that will eventually comprise the project plan, verifying those details using measurement techniques, and controlling changes to these processes. Figure 2. 2: Project Scope Management Project Time Management The Project Time Management knowledge area (see Figure 2. ) also has five processes: Activity Definition, Activity Sequencing, Activity Duration Estimating, Schedule Development, and Schedule Control. This knowledge area is concerned with estimating the duration of the project plan activities, devising a project schedule, and monitoring and controlling deviations from the schedule. Collectively, this knowledge area deals with completing the project in a timely manner. In many cases, all of the activity processes described here along with schedule development are completed as one activity. Sometimes, only one person is needed to complete these five processes, and they’re all worked on at the same time.

Time management is an important aspect of project management as it concerns keeping the project activities on track and monitoring those activities against the project plan to assure the project is completed on time. Figure 2. 3: Project Time Management Project Cost Management As its name implies, the Project Cost Management knowledge area (see Figure 2. 4) centers around costs and budgets. The processes that make up this knowledge area are as follows: Resource Planning, Cost Estimating, Cost Budgeting, and Cost Control. The activities in the Project Cost Management knowledge area establish estimates for costs and resources and keep watch over those costs to ensure that the project stays within the approved budget. Depending on the complexity of the project, these processes might need the involvement of more than one person.

For example, the finance person might not have expertise in the Resource Planning area, so the project manager will need to bring in a staff member with those skills to complete the Resource Planning process. Figure 2. 4: Project Cost Management Project Quality Management The Project Quality Management knowledge area (see Figure 2. 5) assures that the project meets the requirements that the project was undertaken to produce. These processes measure overall performance, and monitor project results and compare them to the quality standards set out in the project-planning process to assure that the customer will receive the product or service they thought they purchased.

Project Quality Management is composed of the following three processes: Quality Planning, Quality Assurance, and Quality Control. Figure 2. 5: Project Quality Management Project Human Resource Management Project Human Resource Management (see Figure 2. 6) involves all aspects of people management and personal interaction including leading, coaching, dealing with conflict, and more. Some of the project participants whom you’ll get to practice these skills on include stakeholders, team members, and customers. Each requires the use of different communication styles, leadership skills, and team-building skills. A good project manager knows when to enact certain skills and communication styles based on the situation.

The Project Human Resource knowledge area contains the following processes: Organizational Planning, Staff Acquisition, and Team Development. Figure 2. 6: Project Human Resource Management Project Communications Management The processes that make up the Project Communications Management knowledge area (see Figure 2. 7) are as follows: Communications Planning, Information Distribution, Performance Reporting, and Administrative Closure. The processes in the Project Communications knowledge area are related to general communication skills but aren’t the same thing. Communication skills are considered general management skills that the project manager utilizes on a daily basis.

The processes in the Communications knowledge area seek to ensure that all project information including project plans, risk assessments, meeting notes, and more is collected and documented. These processes also ensure information is distributed and shared with appropriate stakeholders and project members. At project close, the information is archived and used as a reference for future projects. This is referred to as historical information in several project processes. Figure 2. 7: Project Communications Management Project Risk Management Project Risk Management (see Figure 2. 8) contains six processes: Risk Management Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, and Risk Monitoring and Control.

As the name of this knowledge area implies, these processes are concerned with identifying and planning for potential risks that may impact the project. Organizations will often combine several of these processes into one step. For example, Risk Identification, Qualitative Risk Analysis, and Quantitative Risk Analysis might be performed at the same time. The important thing about this process is that you should strive to identify all the risks and develop responses for those with the greatest consequences to the project objectives. Figure 2. 8: Project Risk Management Project Procurement Management The Project Procurement Management knowledge area (see Figure 2. ) includes the processes involved with purchasing goods or services from external vendors, contractors, and suppliers. When discussing the Procurement Management processes, it’s assumed that the discussion is taking place from the perspective of the buyer. As the project manager, you would be the buyer purchasing the goods or services from a supplier or contractor, so these processes should be examined from that perspective. The processes in the Project Procurement Management knowledge area are as follows: Procurement Planning, Solicitation Planning, Solicitation, Source Selection, Contract Administration, and Contract Closeout. The PMP exam will most likely have a question or two regarding the processes that make up a knowledge area.

Remember that knowledge areas bring together processes by commonalities, so thinking about the knowledge area itself should tip you off to the processes that belong to it. Projects are executed in process group order, but the knowledge areas allow a project manager to think about groups of processes that require specific skills. This makes the job of assigning resources easier because team members with specific skills might be able to work on and complete several processes at once. Figure 2. 9: Project Procurement Management The remainder of this book will deal with processes and process groups as they occur in life cycle order (i. e. , Initiation, Planning, Executing, Controlling, and Closing) as this is the way you will encounter and manage them during a project. Defining the Project Initiation Process

Your company’s quarterly meeting is scheduled for today. You take your seat, and each of the department heads gets up and starts giving their usual “ain’t this great” rah-rah speech one after the other. You barely notice that the CEO takes the stage. He starts out his part of the program pretty much the same way the department heads did. Suddenly, your daydreaming trance is shattered when you hear the CEO say, “…and the new phone system will be installed by Thanksgiving. ” Wait a minute. You work in the telecom department and haven’t heard a word about this project until today. You also have a funny feeling that you’ve been elected to manage this project.

It’s amazing how good communication skills are so important for project managers but not…well, we won’t go there. Project Initiation Project Initiation is the formal recognition that a project should begin and resources should be committed to the project. Unfortunately, many projects are initiated the way our CEO did in this example. Each of us, at one time or another, has experienced being handed a project with little to no information and told to “make it happen. ” The new phone system scenario is an excellent example of how not to initiate a project. Taking one step back from Initiation leads us to ask, “How do projects come about in the first place?

Do CEOs just make them up like in this example? ” Even though our CEO announced this new project at the company meeting with no forewarning, there is no doubt it came about as a result of a legitimate need. Believe it or not, CEOs don’t just dream projects up to give us all something to do. They’re concerned about the future of the company and the needs of the business and its customers. The business itself might drive the need for a project, customers might demand changes to products, or legal requirements may create the need for a new project. According to the Guide to the PMBOK, projects come about as a result of one of six needs or demands.

Needs and Demands

Organizations exist to generate profits or serve the public. To stay competitive, organizations are always examining new ways of creating business, better ways of gaining efficiencies, or better ways to serve their customers. Sometimes laws are passed to force organizations to make their products safer or to protect the environment. Projects result from all of these needs. Most projects will fit one of the six needs or demands described below. It is those needs and/or demands that dictate the germination of a project. In the following sections, let’s take a closer look at each of these areas. Marketing Demand The demands of the marketplace can drive the need for a project.

For example, a bank initiates a project to offer customers the ability to apply for mortgage loans over the Internet due to a drop in interest rates and an increase in demand for refinances and new home loans. Business Need The new phone system we talked about earlier that was announced at the quarterly meeting came about as a result of a business need. The CEO, on advice from his staff, was advised that call volumes were maxed on the existing system. Without a new system, customer service response times would suffer, and that would eventually affect the bottom line. Customer Request Customer requests run the gamut. Generally speaking, most companies have customers, and their requests can drive new projects. Customers can be internal or external to the organization.

Government agencies don’t have external customers per se (we’re captive customers at any rate), but there are internal customers within departments and across agencies. Perhaps you work for a company that sells remittance-processing equipment and you’ve just landed a contract with a local utility company. This project is driven by the need of the utility company to automate their process, or upgrade their existing process. The utility company’s request to purchase your equipment and consulting services is the project driver. Technological Advance Do you happen to own one of those electronic personal digital assistants? They keep names and addresses handy and usually come with a calendar and a to-do list of some kind. I couldn’t live without mine.

However, there is always a newer, better version coming to market. The introduction of satellite communications now allows these little devices to connect to the Web or get e-mail almost anywhere in the world. The introduction of the satellite communications ability is an example of a technological advance. Due to this introduction, electronics manufacturers revamped their products to take advantage of this new technology. Legal Requirement Private industry as well as government agencies generate new projects as a result of laws passed every legislative season. For example, new sales tax laws might require modifications or new programming to the existing sales tax system.

The requirement that food labels appear on every package describing the ingredients and the recommended daily allowances of certain vitamins is another example of a project driven by legal requirements. Social Need The last need is a result of social demands. For example, perhaps a developing country is experiencing a fast-spreading disease that’s infecting large portions of the population. Medical supplies and facilities are needed to vaccinate and cure those infected with the disease. Another example might include cleaning up waste products from the water supply of manufacturing plants prior to putting the water back into a local river or stream to prevent contamination. Project Initiation Process Initiation is part of the Project Scope Management knowledge area.

As we’ve learned, this knowledge area deals with identifying a project, the stakeholders, and the project requirements. The Initiation process lays the groundwork for the Planning process group that follows Initiation. A high percentage of projects fail due to poor planning or no planning. Properly planning your project up front dramatically increases the project’s chance for success. Since Initiation is the foundation of Planning, the importance of Initiation is self evident. The project Initiation process has several inputs: product description, strategic plan, project selection criteria, and historical information. Each of these inputs is processed using tools and techniques to produce the final outputs, one of which is the project charter.

Now, we’ll examine each of these inputs in a bit more detail. Product Description As you might deduce, the product description describes the product. The product description should be documented and should clearly outline the characteristics of the product or service. This description should also include the business need that’s driving the reason for the project. Product descriptions contain less detail in the early phases of a project and more detail as the project progresses. Product details are progressively elaborated to come up with the final product description. It will contain the greatest amount of detail at the project Execution process.

When a project is performed under contract, typically the buyer of the product or service will provide the product description to the vendor or contractor. The product description serves as a statement of work when the project is contracted to a vendor. A statement of work describes the product or service in enough detail so that the vendor can accurately price the contract and satisfactorily fulfill the requirements of the project. The statement of work is covered in more detail in Chapter 6. Strategic Plan Part of the responsibility of a project manager during the Initiation process is to take into consideration the company’s strategic plan. Perhaps the strategic plan states that one of the company goals is to build 15 new stores by the end of the fiscal year.

If the project your company is considering undertaking is to install a new human resources software system, it would make sense to write the requirements for your project with the 15 new stores in mind. Your management team will refer to the strategic plan when choosing which new projects to initiate and which ones to drop depending on their relationship to the strategic vision of the company. Project Selection Criteria Project selection involves making determinations regarding which projects to accept or reject based on criteria such as financial data, sales potential in the marketplace, etc. This subject will be dealt with more thoroughly in Chapter 3.

Historical Information

Historical information can be very useful to project managers and to stakeholders. When you’re evaluating new projects, historical information about previous projects of a similar nature can be very handy in determining if the new project should be accepted and initiated. Historical information on an active project gathered and documented during the project can be examined to assist in determining whether the project should proceed to the next phase. Historical information will help you in determining project goals, with estimating activities, and during the project-planning processes. You’ll find that historical information is an input to several processes .

Developing a Project Overview

One of the first steps a project manager will take in the Initiation process is to develop a project overview. Some organizations call this a project concept document. The four inputs described in the last section will help to outline the project overview and will be used again when formulating the final project charter. It should be noted that the Guide to the PMBOK holds the view that a project manager is identified and assigned at the completion of the Initiation process. While sometimes that’s true, in practice it’s common that the project manager is involved at the beginning of the Initiation process and assists with the project overview and information-gathering tasks.

At the completion of the Initiation process, the organization has committed to fund the project and provide the necessary resources to carry it out, or has killed the project. The project has the lowest probability of succeeding during Initiation. That’s because no action has been taken regarding project activities. In other words, you haven’t actually begun to produce the product of the project. Quite a bit of work will have gone into the project at this stage, but most of it regards the overview of the project and the business justification for the project. The stakeholders have greatest ability to influence project outcome at this stage because nothing has been cast in stone yet.

There is still time for them to negotiate requirements and deliverables. Risk is highest during Initiation because any number of things can happen between now and the time the project is completed. The project might not be approved, the funding might not be approved, the strategic direction of the company could change and the project no longer fits in with the new vision, the customer could change her mind, etc. This list could become quite lengthy. Project failure can be controlled and minimized by accurately applying project management techniques to your project and by proper planning.

Real World Scenario—The Diet-Cola Marketing Opportunity

Elizabeth is the project manager for a large soft drink beverage company located in Tallahassee, Florida. One sunny morning, Roger Bruist, the marketing vice president, pays her a visit. “I asked your boss if it was okay to directly talk to you about this project—she said it would be fine,” he starts. “As you’ve probably heard, we’re test marketing a new diet-cola opportunity that we thought would be a big seller. Long story short, I had lunch the other day with a friend of mine from the club. He ordered his usual diet cola but requested three slices of lemon with it. I stared at him while he squeezed those lemons into his diet and dunked the last rind into the mix. Well, I have to tell you the taste is fabulous! We’ve toyed around with the exact lemon-to-cola mixture in the lab and have come up with what we think is the optimum mix that results in the tastiness factor we’re looking for. “We’ve worked together, and I know your work is top-notch. What we’d like for you to do is put together a project that test markets our new soda in three test areas. We want to target markets that utilize a lot of diet soda. We think the best places to target would be Denver, Las Vegas, and the Seattle area. “We want a project plan that details the distributors we’ll send the soda to and how we’ll obtain the demographics we’re looking for. My department will supply you with the marketing profiles and plans you need to implement in your project plan.

We’d also like a page added to the company’s website that talks about the new beverage. The project should also include key players from the National Soft Drink Association and have a large, splashy intro on their website as well. You can visit their site at www. nsda. org. ” As a project manager, you will often have projects presented to you that are barely past the big-picture stage. Roger has a good idea of how he wants to test market this new product, but many other processes must come into play here such as planning, budgeting, risk assessment, reporting, and so on. A lot of energy is focused on the vision of the project and the wants and needs of the stakeholders.

It’s your job to take the vision, examine the needs of all the stakeholders including Roger’s, and bring the vision to fruition. Determining the Project Goals Several terms are tossed about and sometimes used interchangeably when talking about projects. They are words such as goals (sometimes called objectives), requirements, and deliverables. Their meanings are sometimes blurred together, but there is some differentiation between these terms. Goals and objectives are the purpose for undertaking the project, and they describe the final result of the project. “Increase warehouse space to house the new product line for distribution” or “provide faster turnaround times on loan application services” are both examples of goals.

In other words, the purpose for the project is to do something or accomplish something—a goal. Project Goals Goals describe the what it is you’re trying to do, accomplish, or produce. Goals and objectives should be stated in tangible terms. If your goal is to increase warehouse space, it would be better to say the goal is to build four new warehouses. Describing the number of new warehouses to be built is specific and tangible. For that reason, we’ll know the project is completed when this goal is met. The goal of offering faster loan approvals might be better stated that the company will provide loan applications over the Internet to speed the application process. There’s no hard and fast rule here.

Goals and objectives can be combined and simply called goals. What’s important is that you come away understanding what the end purpose of the project is and how to identify when it’s been accomplished. You’ve probably seen this acronym regarding goal setting a dozen times, but it’s worth repeating. Goals should follow the SMART rule: S—Specific Goals should be specific and written in clear, concise, understandable terms. M—Measurable Goals should be measurable. A—Accurate Goals should be accurate and should describe precisely what’s required. R—Realistic and tangible Goals that are impossible to accomplish are not realistic and not attainable. Goals must be centered in reality.

It’s not likely you and I will be sending up rocket ships full of chocolate candies to sell to tourists visiting the moon anytime soon. T—Time bound Goals should have a time frame with an end date assigned to them. Hmm, this all sounds familiar. It seems there are some similarities between goal setting and how we describe and document projects. Let’s look at that acronym again from a project perspective: S—Specific The project goals are specific and stated in clear, concise, understandable terms and are documented in the project charter and scope statement. Projects exist to bring about a unique, specific product or service that hasn’t existed before.

M—Measurable The deliverables of the project or project phase are measurable against verifiable outcomes or results. A—Accurate The verification and measurement of requirements and deliverables are used to determine accuracy and also to ascertain if the project is on track according to the project plan. R—Realistic and tangible Projects are unique and produce tangible products or services. The triple constraints of any project help to define realistic goals and realistic requirements based on the limitations the constraints put on the project. T—Time bound Projects are performed in specific time frames with a definite beginning and definite end date. Project Requirements Requirements are not the same as goals and objectives.

Requirements are specifications of the goal or deliverables. Requirements help answer the question, “How will we know it’s successful? ” Requirements are the specifications or necessary prerequisites that make up the product or service you’re producing. Let’s say you’re building those four warehouses. Some of the requirements might be the square footage of each building, the number of loading docks, the location of the warehouses, etc. Project Deliverables Deliverables are measurable outcomes, measurable results, or specific items that must be produced to consider the project or project phase completed. Deliverables, like goals, must be specific and verifiable.

A manufacturing unit that is part of a larger project might be required to produce widgets with a 3-inch diameter. These will in turn be assembled into the final product. This deliverable is specific and measurable. However, if the deliverable was not documented or not communicated to the manager responsible for the manufacturing unit, there could be a disaster waiting to happen. If they deliver 2-inch widgets instead of the required 3-inch version, it would throw the entire project off schedule or, perhaps, cause the project to fail. This could be a career-limiting move for the project manager because it’s the project manager’s responsibility to document deliverables and monitor the progress of those deliverables throughout the project or project phase.

A project phase can have multiple deliverables. As in the example above, if you are assembling a new product with many parts, each of the parts could be considered independent deliverables. The bottom line is this: No matter how well you apply your project skills, if the wrong deliverables are produced or the project is managed to the wrong goals, you will have an unsuccessful project on your hands. Stakeholders Now we’re ready to identify and talk to those stakeholders about the project and get more specifics regarding the goals and deliverables of the project. Our objective at this point is to compile a project overview, or project definition.

The overview will have enough information to describe the project, the business requirements, the project’s objectives, and how we’ll recognize when the project is successfully completed. Think of stakeholders and project participants as a highly polished orchestra. Each participant has a part to play. Some play more than others. And alas, some play their parts better than others. An integral part of project management is getting to know your stakeholders and the parts they play. You’ll remember from Chapter 1 that stakeholders are those people or organizations who have a vested interest in the outcome of the project. They have something to either gain or lose as a result of the project. According to the Guide to the PMBOK, stakeholders are officially identified in the Planning process.

In practice, key stakeholders will have to be contacted early on to get their input for the project overview, goals, and deliverables. Identifying key stakeholders at this point should be fairly easy. Stakeholders might include the project sponsor, the customer (who might be one in the same as the project sponsor), the project manager, project team members, management personnel, contractors, suppliers, etc. Stakeholders can be internal or external to the organization. One way to uncover stakeholders whom you might not have thought about right at the start is to ask known stakeholders if they’re aware of anyone else that might be impacted by this project. Ask team members if they’re aware of stakeholders who haven’t been identified.

Stakeholders might come to the forefront once you start uncovering some of the goals and deliverables of the project also. Don’t forget important stakeholders. That could be a project killer. Leaving out an important stakeholder, or one whose business processes weren’t considered during project Initiation and Planning, could spell disaster for your project. Not to mention it could be another one of those career-limiting moves for the project manager. It’s important for the project manager to understand each stakeholder’s role in the project and their role in the organization. Get to know them and their interests. Determine the relationship structure among the various stakeholders.

Start cultivating partnerships with these stakeholders now as it’s going to get pretty cozy during the course of your project. If you establish good working relationships up front and learn a little about their business concerns and needs, it might be easier to negotiate or motivate them later on when you have a pressing issue that needs action. Knowing which stakeholders work well together and which don’t can also help you in the future. One stakeholder may have the authority or influence to twist the arm of another, figuratively speaking of course. Or conversely, you might know of two stakeholders who act like oil and water when put into the same room together.

This can be valuable information to keep under your hat for future reference. Communicating with Stakeholders Now those finely honed communication skills are going to come in handy. In order to determine the specific goals of your project, you’ll want to meet with each of the key stakeholders and document their ideas of the project goals. It’s also a good idea at this point to gain an understanding of their needs and concerns regarding the project. Ask them why the project is needed. Ask what business process the project will change, enhance, or replace. Perhaps the existing business processes, and the systems that support them, are so old that little documentation exists for them.

Determine if there is a critical business need for this project or if it’s a “nice to have” as we say around our office. What will be the result of this project? Will customer service be improved, or sales increased? Find out what prevents the stakeholders today from achieving the results they hope the project will accomplish. Ask about the deliverables and how they can be verified and measured. And always ask the stakeholder how they will know that the project was completed successfully. Remember that the definition of a successful project is one that meets or exceeds stakeholders’ expectations. Understand and document those expectations and you’re off to a good start. We’ll talk about managing to those expectations in a later chapter.

One way to help identify project goals is to talk about what is not included in a project. For example, let’s say you’re working on a highway project to create a new on-ramp from a downtown city street. The goal of this project is to have a new on-ramp constructed and ready for traffic in 18 months from the project start date. Specifically excluded from this project is the demolition of a deteriorating bridge adjacent to the new on-ramp. Make sure you state this in the project overview. The Project Overview Document The project overview document is a high-level look at the project goals and deliverables. It serves the purpose of capturing the intended outcome of the project and its deliverables.

It will provide a brief background of the project and describe the business opportunity the company is attempting to capitalize on. It will also describe the business objectives the project should meet. The overview lays the groundwork for future consensus on deliverables and project expectations. Some organizations will require a feasibility study at this point in the project. Feasibility studies are undertaken for several reasons. One is to determine if the project is a viable project. They’ll also determine the probability of the project succeeding. Feasibility studies can also examine the viability of the product of the project. For example, the study might ask, “Will the new lemon-flavored soda be a hit?

Or, is it marketable? ” The study might also look at the technical issues related to the project and determine if the technology proposed is feasible, reliable, and easily assimilated into the organization’s existing technology structure. The group of people conducting the feasibility study should not be the same ones who will work on the project. Project team members may have built-in biases toward the project and will tend to influence the feasibility outcome toward those biases. Real World Scenario—The Interactive Voice Response Tax-Filing System Jason, Sam, and Kate are web programmers working for the Department of Revenue in the State of Bliss.

Ron, their manager, approaches them one day with an idea. “Team, business unit managers are thinking it would be a great idea to offer taxpayers the ability to file their income tax over the telephone. We already offer them the ability to file on the Internet, thanks to all your efforts on that project last year. It’s been a fabulous success. No other state has had the success that Bliss has had with our Internet system. “Kate, I know you’ve had previous experience with IVR technology, but I’m not sure about you guys, so this is new territory for us. I’d like to hear what each of you thinks about this project. ” Jason speaks up first. “I think it’s a great idea.

You know me, I’m always up for learning new things, especially when it comes to programming. When can we start? ” Sam echoes Jason’s comments. “This technology is pretty sophisticated,” Kate says. “Jason and Sam are excellent coders and could work on the programming side of things, but I would have to pick up the telephony piece on my own. After we’re up and running, we could go over the telephony portions step by step so Jason and Sam can help me support it going forward. I’d really like to take on this project. It would be good for the team and good for the department. ” Ron thinks for a minute. “I think a feasibility study is in order. The senior director over the tax business unit doesn’t know if this project is cost ustified and has some concerns about its life span. Looks like we might have some technical issues to deal with on our side, and I don’t want Kate going it alone without first examining all the impacts. ” Now that we’ve fleshed out the project goals and have a high-level view of the deliverables, it’s time for the next step. But never fear, we’ll be reviewing goals and refining deliverables over the next few chapters. We’ll also be using them to help formulate requirements and project estimates. But we’re getting ahead of ourselves. We need to constrain this chapter to the topic at hand. Which brings up the next topic—project constraints.

Identifying the Project Constraints We introduced the triple constraints in Chapter 1. They are time, budget, and quality. All project managers have to deal with these constraints in all projects. No project manager I know has ever been given unlimited funding and unlimited time to produce a perfect product. In reality, if we were given unlimited funding and unlimited time, some of us probably wouldn’t accomplish much. This is especially true for all of you out there who are the perfectionist types. Just tweak this and then tweak that, it will be perfect next iteration…I know because I’m one of you! Constraints are one of the outputs of the Initiation process.

Constraints are anything that either restricts the actions of the project team or dictates the actions of the project team. Constraints put you in a box. (I hope you’re not claustrophobic. ) As a project manager, you have to manage to the project constraints, which sometimes requires creativity. Like most disciplines, project management is as much art as it is science. Types of Constraints As I said, time can be a project constraint. This usually comes in the form of an enforced deadline, commonly known as the “make it happen now” scenario. If you are in charge of the company’s holiday bash scheduled for December 10, your project is time constrained.

Once the invitations are out and the hall has been rented, you can’t move the date. All activities on this project are driven by the due date. Budgets are another one of the triple constraints. Budgets limit the project team’s ability to obtain resources and might potentially limit the scope of the project. For example, component X cannot be part of this project because the budget doesn’t support it. Quality would typically be restricted by the specifications of the product or service. Those 3-inch widgets we talked about earlier could be considered a quality constraint. Most of the time, if quality is a constraint, one of the other constraints— time or budget—has to have some give.

You can’t produce high quality on a restricted budget and within a tightly restricted time schedule. Of course, there are exceptions, but only in the movies. Schedule constraints can cause interesting dilemmas for the project manager. For example, say you’re the project manager in charge of building a new football stadium in your city. The construction of the stadium will require the use of cranes—and crane operators—at certain times during the project. If crane operators are not available when your project plan calls for them, you’ll have to make schedule adjustments so that the crane operators can come in at the right time. Technology is a marvelous thing.

In fact, how did humans survive prior to the invention of computers and cell phones? Technology certainly can be marvelous, but it can also be a project constraint. For example, your project might require the use of brand-new technology that is still so new it’s not been released on a wide-scale basis. One impact might be that the project will take an additional six months because existing technologies need to be used instead of the new technology. Directives from management can be constraints as well. If you’ve never experienced a directive from management, you’re not working in the real world. And, when performing work on contract, the provisions of the contract can be constraints. Managing Constraints

Constraints, particularly the triple constraints, can be used to help drive out the goals of the project. If it’s difficult to discern which constraint is the primary constraint, ask the project sponsor something like this, “Ms. Sponsor, if you could only have one of these two alternatives, which would you choose? The project is delivered on the date you’ve stated, or the quality is manufactured to the exact specifications you’ve given. ” If Ms. Sponsor replies with the quality response, you know your primary constraint is quality. If push comes to shove during the project Planning process, time might have to give because quality cannot. Be sure to document your