INTEGRATED COST AND SCHEDULE CONTROL IN PROJECT MANAGEMENT

SECOND EDITION

1 BASIC CONCEPTS

Before exploring the various tools and techniques of integrated cost and schedule control, a number of basic concepts must be understood: What is success? What makes work a project? What does project management mean? Who are the people involved in the project? How important is documentation to the project?

SUCCESS

To understand how integrated cost and schedule control techniques work, we first have to understand the psychological aspects of “success.” We all have mortgages, rent, and/or car payments to make, which means that we all have to get up each day and go to work to earn the money to make these payments. One of the best feelings in the world is getting ready to go to work knowing that you’ll be spending your day working on something that will be successful. This is such a good feeling that it puts a spring in your step. You have a tendency to get more done because you want to keep the good feeling going. We all can think back on how it felt to work on a successful project.

The flip side is that one of the worst feelings in the world is waking up and getting ready to go to work knowing you’ll be spending your day on something you know will not work, or will not get done on time, or will cost too much, or no one will really want or use, or with which the customer will be unhappy. This is not a good feeling. Not only is there no spring in your step, but you’re probably taking longer to get ready for work than normal. You have the tendency to get less done because you don’t really care. We all can think back on a project we worked on that had no chance of being successful and how that felt.

A basic understanding of what makes work successful is the most important part of what integrated cost and schedule control is all about. Whether you are the only one working on your project or you have a team helping you, understanding success—even if it is the delusion of success—is what enables the work to get done. We all need a sense of accomplishment.

Success is the goal that is tantamount to everything we do to control the cost and schedule of the project. That means we must define the project and everything we think might happen on the project as clearly and realistically as possible. We must make sure that we describe the work unambiguously and that the work is attainable. We must use all available tools and techniques to control the project to the best of our abilities. This does not mean that we cannot make the work challenging, but it is self-defeating to expect something to be accomplished that simply cannot be accomplished.

THE PROJECT

Another basic understanding required for integrated cost and schedule control is an internalization of two basic definitions: What is a project? and What is project management? A lot has been written about these two basic concepts, yet misunderstandings abound.

The Project Management Institute’s (PMI) Guide to the Project Management Body of Knowledge (PMBOK® Guide) ¹ defines a project as “a temporary endeavor undertaken to create a unique product or service.” The PMBOK® Guide readily points out that organizational work generally falls into one of two categories, operational work and project work, and that projects are undertaken at all levels of the organization.

Tom Peters, in his book In Pursuit of Wow, ² defines all work as project work in the new economy. He says that work should always add value, and that if it adds value, it is a new, unique endeavor.

Many organizations seem to think that larger projects should no longer be known as projects, but should be called “programs” instead. This view often stems from the notion that we have to promote project managers to the higher position of “program manager.” If the work has a beginning and an end and creates something new and unique, it is a project—no matter how big or small. A program, on the other hand, is usually made up of a collection of projects, but goes beyond the completion of the individual deliverables, through the operation and support of the deliverables, to what is often called the “end of service life” of the deliverables. Understanding that cost and schedule control techniques can be applied consistently to very large, complex projects as well as to small weekend “house” projects will go far in making the work proceed more easily and efficiently.

PROJECT MANAGEMENT

Project management is not a title, nor is it a job description. In fact, it is a process that should be learned and understood by every level of the organization. It is amazing how many people call themselves “project managers” but have very little understanding of the process. Worse yet are the many upper-level managers who believe they are “above” learning the process. These upper-level managers do not seem to grasp that the better all the members of their organization, including themselves, understand the project management process, the higher their chances for overall success within their organization. Instead many of these upper-level managers impede the opportunity for success by not supporting the project management process.

Everyone can do and does projects. Aside from what we do at work, we all have projects underway at home, in our neighborhoods, and at our clubs or places of worship. Planning and managing these projects enable us to get them done. How many times have you set out to accomplish that Saturday morning project, just to find yourself running back to the hardware store in the afternoon? If you had used good project management processes, that might not have happened.

STAKEHOLDERS

Anyone who can “help” or “hurt” your project should be viewed as a stakeholder. Your customer, the users, your management, your team, vendors and suppliers, or other departments that you will depend on, can all “hurt” your project if their needs are not considered. For example:

• The customer who is never happy with the outcome and constantly wants more

• The user who doesn’t use the deliverable of your project

• Your manager who doesn’t provide the support your project needs or who micromanages your project because he or she doesn’t trust your abilities

• Other internal functional managers who refuse to support your project or to give your project the priority it deserves

• Your team members who do not buy in to the project

• Support organizations, such as Purchasing or Finance, that refuse to support the requirements of your project

• Vendors, contractors, and suppliers who do not meet their agreements and do not deliver.

Each stakeholder has specific needs that must be determined, considered, and possibly included in the scope of the project. Getting the stakeholders involved and enthusiastic about the project is crucial to the success of cost and schedule control.

THE PROJECT TEAM

The project team is a subset of stakeholders who can either do major damage to your project or be your most valuable asset. The project manager’s leadership abilities will determine which way this goes. The project manager needs to understand and appreciate that unless he or she can do all the work of the project, a project team will be involved.

Some of the best project managers realize that the less autonomous decision making they do during the initial and planning stages of the project, the more leadership stature they maintain throughout the project, because no one can accuse them of making that “bad” planning decision. They encourage involvement of all the team members, which in turn encourages “buy-in” to the project objectives and ultimately to a focus on the cost and schedule control of the project.

The composition of the project team can change substantially throughout the project. For example, the initial project team may be a group of subject matter experts who have the customer familiarity and technical knowledge to assist in defining the overall deliverable. This composition of the team should change based on whether a different potential team member has the skills or knowledge to take over the definition or decomposition of the deliverable from a certain point in the project. The composition of the project team could go through many iterations until the entire scope—down to the true definition of the work involved to complete the scope—is defined, at which time the resource that can best do the work should be identified and should become a member of the project team.

THE PROJECT MANAGER

The project manager is you: you, who has been asked to get something done and to have it done by 2:00 p.m., or by Friday, or by the end of the month; or you, who recognizes a need and believes that you can take care of that need in time to make a difference; or you, who has taken on responsibility for delivering that unique (be it ever so slightly unique) product or service.

It doesn’t matter how big or how small, if the product or service is needed, is something unique, and is required to be delivered by a certain time, it falls into that definition of a project. The words “I need it by…” is what makes it a project. The first step of taking on the responsibility of being a project manager is to make sure that whoever is asking for “it” realizes that “it” is never free. Producing anything takes time and time is money; the management challenge is to make sure the requester can afford “it” and that the time is efficiently planned to get “it” done.

Another aspect of project management is that “it” may be needed to accomplish a different project. In other words, the project that you are managing may be a subproject of the project that whoever requested “it” is trying to manage. This makes your “customer” another project manager.

The realization that all projects are interrelated allows for overall efficiencies of good project management. All workers should recognize the project aspects of their work and how the tools and techniques of integrated cost and schedule control can help them in accomplishing that work.

In today’s world we tend not to recognize an individual worker as a “project manager” until he or she has taken on the responsibility of a large, complex project. The assigned project manager who has not considered him-or herself a project manager before must quickly learn project management tools and techniques. This can be a daunting task, especially when the individual is “thrown to the wolves” well into the lifecycle of a project.

Too often the inexperienced project manager thinks he or she must be “the expert” and should take on the role of defining and planning the entire project. The enlightened project manager knows that this is not true. Some of the best project managers have no technical expertise in the deliverable of the project. They know that their responsibility falls more in facilitating a group of experts (i.e., a project team) to define what the customer deliverable should look like. The project manager doesn’t need this expertise, because the project manager usually is not the person doing the work; however, the project manager must know how to use the terminology of the technical aspects of the deliverable. In other words, the project manager does not need to “walk the walk,” but he or she had better know how to “talk the talk” if they are to maintain their credibility with the project team and stakeholders.

The process of allowing other team members to participate in identifying and decomposing the deliverable, along with the realization that all projects are made up of many subprojects, enables the project manager of a large, complex project to delegate portions of that project to various team members and to assign them as project managers of their subparts.

PROJECT DOCUMENTATION

Good project managers embrace documentation. They understand that documenting everything they do, every process they intend to use, and every decision or assumption they make keeps everything having to do with the project on a business level as opposed to a personal level. Aside from being a mechanism for better communication with all the stakeholders involved in the project, documentation is CYA—“cover your activities” or “cover your assumptions.”

The project charter is one of the first and most important documents of the entire project management process. The PMBOK® Guide defines a project charter as “a document provided by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.”

The project charter provides so much more than that. It provides the history, or the “why” the project is being undertaken in the first place. More importantly, the project charter provides the “outer boundaries” of the project by providing the budget constraint (i.e., how much the customer can afford) and the time constraint (i.e., when the customer needs the deliverable). If you truly believe, as I do, that every project is a subproject of someone else’s project, there would be a number of project charters that “pass down” or delegate authority for the parts of the deliverable of your project to each of the team members who are expected to deliver their parts.

The idea of identifying every team member as a project manager of their subproject, providing them with a project charter that defines their boundaries, and teaching them each the project management process gives those team members “ownership” of providing a deliverable to the customer (which might be you.) The team member/subproject manager quickly learns that they need to perform a requirements analysis and define the “best solution” to meet those requirements.