All projects, regardless of size or complexity, are bounded by a “Triple Constraint” of time, resources, and output.
     The triple constraint is usually visualized as a triangle with each constraint placed at a corner of the triangle. The area of the triangle is the “space” within which the project is done. This is sometimes called project scope.

The Time constraint encompasses all of the time limitations on the project: When it must be delivered, the time demands on the people who must be involved, the time demands on the equipment that must be used, the time constraints placed on the project by management, etc.
     Schedule is the most common driving constraint on most projects. You may be able to deliver a less-than-optimum output if you deliver it on time. While this may seem to be an extension of the “We never have time to do it right but we always find the time to do it over” mentality, there may be other factors involved. For example, the deadline for a project is not usually just “pulled out of the air.” If you ask some questions about it, you will likely find that the deadline is related to some other business need. For example, a process project may need to be implemented by a certain date in order to link up with the delivery of material to be put through the process. A new-product development project may need to be completed to allow the product to be introduced at a national trade show. (It's funny, but those trade show people are really sticky about their dates and they won't delay the show because your product isn't ready.)
     Of all of the constraints placed on projects, the deadline for delivery is usually the least flexible. This does not, however, mean that the way in which the time from the initiation of the project to the deadline is used is also inflexible. On most projects, the amount of time that can be devoted to the work is flexible, based on the importance the organization places on completion of the project.
 

The Resource constraint encompasses all the limitations placed on the project that involve either money or the things money can buy: Material, outside expertise, machinery and equipment, space, and most of all, the time and expertise of the members of the project team.
     If you think of resources as the “currency” you can spend to accomplish your project, then the most common denomination of that currency will be other people's time. Most project leaders in businesses today do not control the budgets for their projects. In many cases, they don't even know what the financial constraints are. Likewise, they do not usually have control over the things that money buys such as outside experts, equipment, raw materials, and space. This doesn't mean project leaders can't influence these expenditures. However, they usually don't have direct authority over them.
 

The Output constraint encompasses all the requirements placed on the final output of the project. This includes all of the performance and quality characteristics: What must the output be able to do or provide when it is delivered.
     Of all the constraints placed on projects, this is generally the most difficult to define clearly at the outset. This is not to say that it is impossible, but it will require work and negotiation to insure that the deliverable at the end meets the expectations set at the beginning. Chapter 2: Project Pre-work, has several tools to help clarify and define project output.

Back to Index

Whatever approach you choose to take (or whatever approach is dictated by circumstances) is appropriate as long as it allows you to reach some level of understanding of each of the issues listed above. You should realize, however, that you will probably end up with an imperfect understanding of one or more of them. This is, unfortunately, the nature of many in-house projects - you must begin (and, in some cases, complete) the project with one or more of the major issues undecided. The goal here is for you to develop the best understanding circumstances will allow.
     The following process is designed to provide a structure for project pre-work. Some situations are very straight-forward and do not require extensive pre-work analysis. Others are ill-defined, poorly thought out, or more complex. Yet others have numerous possible solutions or outcomes, any one of which might address the issue. This pre-work process will guide you through defining the problem and some of the requirements of any solution to it, and assessing overall project risks. In addition, for those projects with multiple possible deliverables, there are three optional steps you can complete to help with developing options and alternatives, analyzing which option will best solve the problem, and assessing overall project risks.
     Many in-house projects are the result of someone (inside or outside the organization) expressing a desire to have something developed that will make their lives easier. This may seem like a simplistic view of the situation but, when all the fancy language and specifications are stripped from many project requests, they sometimes boil down to, “If I had this, I could do my work better, be more successful, have more free time, make my boss happy, etc.” These are the projects that usually fall into the “problem” category. People are usually looking for a personal benefit from the project. They want the problem solved. In these cases, you can look for the benefits they expect and develop a project that will provide them.
     In other cases projects result from a desire to take advantage of an opportunity rather than solve a problem. Most product-development projects fall into this category as do many technology upgrades and a fair number of the "quality of work life" projects such as employee-benefit program upgrades, some training-development projects, etc. Oddly enough, most organizations are more willing to do a more thorough job on the pre-work for “opportunity projects” than on “problem-solving” projects.
     Some organizations seem to have an aversion to going through this process for either type of project. They would rather see something get started rather than spend time trying to detail “why” and “how” it should be done. If yours is such an organization, getting the answers to some of these questions may be difficult. However, just because it isn't easy doesn't mean you should skip it. Get as much of the information as you can and think through the rest - from the customer's point of view. The structured process described here should help you through this activity.
     This project pre-work process involves five “required” steps and two “optional” steps. The two optional steps come into play when you have a project with several possible answers and need some help determining which option to pursue. The steps are (the optional steps are indented):

• Define the problem or opportunity
• Determine Needs and Wants
• Rank Wants according to their importance and gain agreement among stakeholders
• Write the project goal statement
• Develop options to deliver the desired outcome
• Compare options to Needs and Wants
• Assess overall risk

Back to Index

People are the key to any project. People will make the plans, perform the work, solve the problems, track the progress, deliver the output. Some skills in working well with people are critical for any successful project leader. So, before getting too deeply into project planning and implementation processes, a discussion of working with people on the project team and others within the organization seems appropriate.
     In-house project leaders usually work with borrowed resources - people who are already scheduled by their managers to do something else - almost always something unrelated to the project. In most cases, the people working on your project will not report to you in the sense of being your subordinates. You don't manage them. You don't write their performance reviews. You can't grant them raises, bonuses, or promotions. They work for someone else. You only have them on loan.
     In situations like this, you can't manage people in the traditional sense of telling them what to do and expecting that they will do it. You need to lead them. You need to get them to perform through influence rather than authority.
     The material in this chapter covers a wide range of  “people” topics. Not all of them will apply to every situation. However, the chances are quite good that you will eventually use all of them sometime during your career as a project leader.
     In this chapter, we will look at several aspects of working with people, individually and in a project environment. There are six topics that will be discussed:

• The Development and Use of Power and Authority
• Motivation
• Leadership
• How Teams Grow and Change Over Time
• Negotiation
• Communication

Back to Index

If you are a “just do it” kind of person, planning may be a strain. But, it is impossible to overemphasize how important it is. In developing a project plan you are trying to identify and document:

• The actual work that needs to be done.
• The appropriate sequence of that work.
• Which tasks can be done in parallel, which must be done sequentially, and which can overlap.
• When the individual tasks should start and be finished.
• Who should be doing what, when.
• Where and when significant decisions or approvals will be needed and who the decision-makers are.
• Where problems are likely to occur, what impact they might have on the project, and what to do about either preventing or mitigating them.
• Which tasks need to be watched more closely than others.
• What deliverables are being created along the way and how to know if they're any good.
• Which tasks need greater detail in the plan than others.
• When and how the final deliverable of the project will be handed off to the customer.

     At the beginning of a project, all of this is, to some extent, unknown. What is known is usually not in sufficient detail or depth to be of much use in the day-to-day management of the project. Figuring all of this out is the purpose of project planning.
     Project planning, at least at the beginning, is usually a sloppy, chaotic, stop-and-back-up-and-try-it-again kind of process. There is usually some confusion about the work to be done. There will likely be conflicting ideas about how complex or simple it will be. You'll find different opinions about what things need to precede other things, what things can't even be started until other things are finished and what things are otherwise interdependent. There will be questions about who needs to do what, when. Disagreement about what constitutes a major task versus a sub-task or minor task is likely. You and the team will probably experience multiple paranoid fantasies about what is likely to go wrong and what can be done to prevent it. A highly rigid planning process will only make determining all of this (and everything else you need to know before you get deeply into your projects) more difficult.
     In most cases, good project plans are the result of a repetitive process - planning that is done in “layers.” The “layers” are created in successive passes through the plan. In the first several passes, flexibility is the key. If you try to finalize pieces of the plan too early, you'll find that you have forgotten pieces; others are out of their correct order; details are missing; etc. Project plans are almost never “set in stone.” At best, they're set in semi-firm Jell-O®. The chances that some part of the plan will need to be changed as the project progresses are almost 100%. In fact, including “plan review” points as part of the plan is a good way to make sure that the plan continues to reflect the realities of the developing project.

Obviously, an integral part of monitoring and measuring is some form of regular, documented status reporting from team members. You could rely on your ability to contact everyone on the project team on a regular basis and depend on your memory and some notes to always ask the right questions - this is not recommended.
     If you can hold regular team meetings, this is an ideal forum for getting these updates. However, even if you have team meetings - where everyone gives a verbal update on their activities - you still need to have something in writing. You need a document trail of the progress of your project. This is one of the absolutely essential pieces of project documentation.
     It is also important that status reporting be done on a regular basis. Frankly, a weekly schedule is probably the best. If your project has a long lead time and lots of extra time, you could let this slip to bi-weekly - again, not recommended. Tasks left to themselves for any extended period of time have a disturbing tendency to get off track. If you let a task proceed for more than two weeks without checking on it, the chances that it is drifting off track are better than 50/50 (sometimes much better). Status reporting is not that hard and it should be done weekly. You can stimulate and simplify the process for your team by providing them with a fill-in-the-blanks format for activity.

     Status reporting is an excellent application for e-mail technology. It is not a replacement for face-to-face meetings with team members, but it is a good way to collect the written version of the report. If you use e-mail to collect team-member status reports, compiling and summarizing the main points from your team and adding your own status update is an excellent way to create an overall project status report. This can then be sent to management, customers, and other stakeholders.
     Whatever process you use, the key is consistency and regularity. Status reporting should become a process that is part of every project you do. It is your primary source of information for decision-making, problem-solving, tracking, and controlling your projects.

Some documentation of the project's output is needed for virtually every project. This can be as simple as a written description of the characteristics of the project output - what does it do - or it can be as complex as an operating manual containing detailed instructions about how to use the project output.
     Whatever the documentation needed, it should be written in the customer's language and terms. Keep in mind the people who will be using the project output and document it in terms that they can understand and use.
     The output of many projects, particularly process-development projects, requires some degree of training to be carried out during the implementation process in order to fully meet the customer's needs. This training should be fully developed as a part of the project deliverables. Training can be conducted by project-team members (as in the case of many internal process projects and some software projects), or it can involve training by others (as in the case of product or service projects requiring outside-customer training by customer support personnel, or even by a third-party training vendor). These projects usually require participation by members of the project team in training the trainers.
     As with project documentation, training materials can be simple or complex. They should also be written in customer terms and should provide sufficient information for the customer to effectively use the project results.
     Negotiations around these issues should focus on whether the documentation and training meet the needs of the customer and management. Adjustments may be necessary.

There is a relatively new phenomenon that is emerging in some organizations. Distributed teams (virtual teams, multiple-location teams, whatever you want to call them) are becoming much more common. These working groups (they rarely become real teams) are geographically diverse. They share some specific characteristics that impact how projects are done by them. They need to communicate over long distances. They infrequently (if ever) meet in person. They frequently are in different time zones and may even be in different countries. This is not an ideal project environment. But, more and more companies are putting projects together with this type of dislocated group. If you find yourself with one of these projects, you will need to take special care with the communication systems and the general project-management processes for your group. Think of this chapter as one big Process Tip for working in this dislocated environment.
     First of all, many of the processes described in this book won't work as well for you - at least not exactly as they've been described. For example, the whole Post-It® Note planning process becomes a bit difficult to use when everyone is in a different city. Likewise, a team meeting by conference call is not going to work the same way as a meeting where everyone is in the same room. The following are some very general tips for dealing with some of the more obvious problems of working on a project with a distributed team.

Now having made that depressing statement, there are some things that you can do within your projects to help avoid creating your own prioritization problems. The first is to recognize and deal with this issue of some things being more important than others. One tool that can help with this is the Priority Matrix.

     In its simplest form, a Priority Matrix lists requirements down the left and assigns a priority to each. The key is: There can only be ONE activity at each priority level - just one number one, one number two, one number three, etc. Using this tool forces you to make judgments about the relative importance of each activity.
     An example of a completed matrix is shown below. This example shows the six major features, characteristics, or constraints of a particular project. One might surmise that each of these is considered critical to the overall success of the project. Unfortunately, some of them are in conflict. The problem is to determine the relative ranking of each item so that the project leader and the project team can make informed decisions when the inherent conflicts begin to cause problems as the project proceeds. This is not a decision that can be made by most project leaders without input from management and other stakeholders. However, the decision still needs to be made. The Priority Matrix can be a tool to help guide the discussion and force a decision.

     Here is one way to interpret this information:

• Meeting the deadline is the most important thing. Everything else takes second place to that.
• Directly related to meeting the overall project deadline is meeting the interim deadline of having a prototype ready for presentation at a trade show. If these were the only things that the team needed to worry about, this project would probably move ahead rather smoothly. Everything would be geared to meeting these two deadlines.
• The third most important requirement is “meeting every functional specification.” Nice to say; may be hard to do. If every specification must be met by the prototype, the need to mobilize and focus resources to meet that deadline could be a real problem.
• Now, let's complicate things by adding the requirement of meeting a projected cost/price point that has been established by another department (possibly without input from the people who will be doing the actual development).
• Fortunately, the resource constraints are far enough down this list to provide the possibility of either getting more in-house resources to help with the work or, as a last resort, sending some of it outside.

     The real key to using this tool effectively is getting the buy-off of the people who make the ultimate decisions about your project. This is a tool that should be developed and discussed as early in the planning process as possible. Unfortunately, if you simply ask the question: “Which of these requirements is most important?” you are likely to get a response like: “They're all equally important.” This is not much help. One way around this is to develop a series of questions that might go something like this:

• If we have a situation where we can't meet the deadline without additional resources, which would you prefer: That we miss the deadline but keep the resources in check, or that we get whatever resources necessary to meet the deadline?
• If we can meet most of the functional requirements within the deadline and resource constraints to meet the trade show date, but there is one that will require significant extra effort, which do you prefer: That we get the resources necessary to complete it or that we let the prototype go without that feature and work toward getting it done for the final product?
• If we are getting close to one of our deadlines and simply can't hit it with the resources available in house, should we miss the deadline or bring in the outside resources necessary to hit it?

     Phrasing things in this either/or format can force a decision and result in the establishment of fairly realistic priorities.