Define the Work / General Techniques

2.1.1T Define the Work / General Techniques

The Timing of the Project Charter, Schedule, and Budget (2.1.1T.P1)

The timing of the creation of the Project Charter, schedule and budget may vary depending on the size of the project and how much information is known in the definition process.

Small projects. The Service Request includes the estimated costs and the duration. Since the project is small, all of the information can be gathered simultaneously.
Medium projects. The Abbreviated Project Charter includes the estimated cost and the duration. Since the project is not very complicated, it is likely that all of the information can be gathered simultaneously.
Large projects. The timing of the Project Charter, schedule and budget can be completed in one of two ways depending on your organization and whether you want a high-level Charter approved before the more detailed planning is undertaken.
- Project Charter first, then detailed planning. In this option, the Project Charter is completed first. The scope, risks, assumptions, approach and most all of the sections of the Project Charter can be completed. However, the project schedule is only completed at a milestone level and the cost is estimated at a high level. The Project Charter is then approved. After the approval, the work begins on the detailed schedule and budget, and the detailed information is used to revise the Project Charter as needed. If the estimated duration or cost has changed from the approved high-level Project Charter, the more detailed Project Charter is re-approved.
  
  The advantage of this approach is that the sponsor has a chance to approve the project at a high-level before the more detailed planning begins. This may be a better approach if there is a lot unknown about the project and the sponsor wants to have some high-level information before committing to the cost of the detailed planning.
  
  From a TenStep perspective, this approach means that you would execute Step 2.1P and then Step 2.2P sequentially, with an approval of the high-level Project Charter after Step 2.1P and an approval of the detailed Project Charter after Step 2.2P.
- Project Charter, schedule and budget completed simultaneously. If you do not need to have a high-level Project Charter approved first, you can work on the Project Charter, schedule and budget simultaneously. You will find that as you gather information about scope and deliverables, you can start laying out a high-level schedule. As you gather more information about the work, you can fill in more details on the schedule. When the deliverables, scope, assumptions and approach are complete, you should have enough information to complete an initial schedule. You can then use the initial schedule to estimate the necessary budget, effort and duration - which in turn are used to complete the Project Charter.
  
  From a TenStep perspective this means that you would work on Step 2.1P and Step 2.2P simultaneously, and all of the major definition and planning deliverables would be completed at the same time. The advantage of this approach is that the definition and planning are done more quickly since they can be done at one time, and you do not need two separate approval processes.

The timing of the completion of Step 2.1P and Step 2.2P is dependent on the preference of your organization and sponsor.

Break Large Projects into Smaller Pieces (2.1.1T.P2)

The days of the mega-project are over. Very large projects are simply too difficult to manage and execute successfully. There are a number of problems with very large projects:

The work is less clear the farther out in the future it is. Large projects are usually always long projects as well and that makes them very difficult to plan successfully.
Since the future work is less clear, it is harder to make accurate estimates for effort, duration and cost.
Business and technical conditions change over time, making planning assumptions in the future very uncertain. The business and technical certainties of today can change dramatically over time.
You risk losing organization support if there is a long delay before delivering tangible results. It is very difficult to maintain organizational enthusiasm and support over long periods of time.
It is very difficult to predict resource requirements and availability far into the future. Again, this gets at the difficulty of estimating accurately as you get further out in the future.

Very large efforts are much too difficult and complex to manage as a single project. The better technique is to break the work down into more manageable chunks, each of which is considered its own project, with its own Project Charter and schedule.

For instance, a long IT development effort can be broken into separate sequential projects based on the life cycle. A project is set up for the analysis work. Toward the end of that project a second project is established, based on what you know then, to do the design work. Then a construct / test project is initiated, and finally a project for implementation. Other large initiatives might be broken up into smaller projects that might run in parallel. Some large initiatives can have a combination of smaller projects - some of which must be done sequentially, but others that can be done in parallel. Each team will work to complete its smaller project, but all the work would be coordinated so that the entire effort is successful.

Set up a Program to Coordinate a Set of Related Projects (2.1.1T.P3)

If you break a large effort into a number of related projects, there may still be a need to maintain overall management and coordination. This is the purpose of setting up a 'program'. A program is the umbrella structure established to manage a series of related projects. Each project has a full-time or part-time project manager. The program is led by a program manager. The program does not produce any project deliverables itself; the project teams produce them all. The purpose of the program is to:

Provide overall direction, guidance and leadership for the projects
Make sure the related projects are communicating effectively
Provide a central point of contact and focus for the client and the project teams
Determine how individual projects should be defined to ensure all the work gets completed successfully

Work With Your Client When He Cannot Completely Define the Project (2.1.1T.P4)

Sometimes the project manager places too high an expectation on the amount of foresight and vision that clients have. In many cases, the project manager will go to the client looking for answers to help define the project and the client will not have all of the information needed. This happens all the time and it does not mean that the client does not know what he is doing. In many cases, especially for large projects, the client has a vision of what the end results will be, but cannot yet articulate this vision into concrete deliverables. He may also not know all of the answers on scope, risks, project organization, etc. Based on having less-than-complete information, the project manager may feel the need to guess on the details. This is not a good solution. Instead, if you are faced with this situation there are a couple ways that you can proceed.

State up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty of the work. Your estimate may have a contingency of 20%, 40% or even higher.
Although you do not know everything, you should at least know enough that you can plan the work for the first 90 days. You plan the short-term work in more detail, and leave the long-term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more-detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.
Break the work down into a series of smaller projects (as described previously). Even if the final results cannot be clearly defined, there should be some amount of work that is well-defined, which will, in turn lead to the information needed for the final solution. You should only define a project to cover as far as you can comfortably “see” at the time. Then, define and plan subsequent projects to cover the remaining work as more details are known. For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables.

Make Sure Everyone Understands Project Roles and Responsibilities (2.1.1T.P5)

For small projects, the organization is pretty simple - maybe just the project manager and the client / sponsor. The person who is managing the project may be the only person actually working on the project as well.

However, for large projects, there may end up being an elaborate and formal organizational structure. You may have team members, an executive sponsor, a project sponsor, a client manager, a project director, a steering committee, vendors, clients, and others involved. You do not want to get overly complex, but the more people that are involved in the project the more important it is that everyone be clear on what his roles and responsibilities are. For example, the last thing you want is to have someone give you direction as if he were the sponsor when really he may just be a management stakeholder.

One aspect of defining the project is to define the organization structure and the roles and responsibilities of all the major participants. Usually the typical roles and responsibilities can be defined ahead of time for your organization and then reused as appropriate from project to project. Many of the common project roles and responsibilities are outlined in 2.1.4T Define Work / Roles and Responsibilities.

Seek Project Approvals from the Right People (1.2.P6)

Once the project has been defined, the project manager should seek formal approval from the appropriate sponsor and management stakeholders. There are many ways to gain formal project approval. Like most other activities in the TenStep Project Management Process, a little bit of planning is the key. For small projects, one signature from the main client or project sponsor is probably sufficient to show approval of the work to begin. This approval could also be via email confirmation. However, it should not be verbal.

For larger projects, ask your manager and the project sponsor to identify who should have explicit approval of the Project Charter, who should have implicit approval and who needs to get a copy for informational purposes only. In general, use the following approach as your starting point:

Project Sponsor and key stakeholders. Get an explicit approval. This approval can be a formal signature on a paper copy of the Project Charter. It could also be an email specifically stating approval. You might also have some type of formal workflow approval. The key is that the approval is explicit and that you save a record of the approval. The sponsor and other key stakeholders should have seen prior draft copies before you circulate the final version. This final approval should be a formality only. You don’t want to be in a position where you are trying to gain final approval and yet the sponsor has further concerns or questions.
Other management stakeholders. Get an implicit approval. Implicit means that you assume they approve the Project Charter unless they get back to you otherwise. You would first send them a soft or hard copy of the Project Charter. Let them know you would like them to review the material and provide feedback, especially if they have questions or concerns. Then give them a date for replying and let them know that if you do not hear back from them before the date you will assume they are granting their approval. If they come back to you with concerns, address them or take them to the project sponsor for resolution. It is important that these people have seen a prior draft and have a chance to provide input. When you are sending the Project Charter out for final approval, you want all concerns to have been expressed already. You don’t want to be dealing with problems, concerns or uncertainty while you are trying to gain final approval from the sponsor.
Other interested parties. Send them a copy of the Project Charter. Let them know that it is for their information only. You should be available to discuss any content so that they can better understand the material, but you are not sending it to them for their approval. This may be the first time that these people have seen the Project Charter. However, you are not in a position to take requests to change the document since you probably already have sponsor approval. If there are any major concerns, the person with the concerns should take them directly to the sponsor.

Establish the Triple Constraint when the Project Charter is Approved (2.1.1T.P7)

At the end of the Definition and Planning process (Steps 2.1 and 2.2) you should have an agreement with your sponsor on the work that will be completed and the cost (time) and duration that are needed to complete the work. These three items then form a concept called the “triple constraint”. The key aspect of the triple constraint is that if one of the three items change, at least one, if not both, of the other items need to change as well. (The triple constraint is actually written a couple similar ways. The cost item can also be referred to as effort, which makes more sense if the labor costs are all internal and if there are no non-labor costs. Sometimes, the scope item is referred to as quality, which then focuses on delivering a certain quality level for a certain cost and duration. This is a more narrow aspect of the triple constraint, but the general concepts still hold true.)

For further information on how to manage the project using the triple constraint model, see 4.1.1.1T.P11.

Try to Understand Your Client’s Expressed Needs and Their Real Needs (2.1.1T.P8)

The Project Charter describes the project at a high level. The Project Charter specifically describes the needs of the client, as well as the project team’s estimate of the effort, duration and cost to fulfill those needs. The details of the client’s need are then defined in more detail through the gathering of business requirements.

It is important for the project manager and project team to understand that the true needs of the client may or may not be the same as the needs that are expressed to you and that are the foundation of the Project Charter and the business requirements. In many cases, the client does not understand his true needs when the project starts. The true needs can sometimes evolve over the course of the project. Likewise, the client may have a clear vision of his needs, but he may have a hard time expressing the needs to the project team. To a certain extent, this is the purpose of scope change management – to allow the client to change the requirements of the project while it is in-progress.

The project team can do nothing better than to document the expressed needs of the client and use the expressed needs as the basis for the approval of the Project Charter and the Business Requirements. However, it is also true that the project team should do as good a job as possible uncovering the true needs of the client. This involves techniques such as asking good questions, asking targeted follow-up questions, gathering input from all key stakeholders, asking more questions when requirements don’t seem to make sense, etc. Obviously, the project team should do whatever it can to try to uncover the true needs of the client. The closer the true needs of the client are to his expressed needs, the closer you will be to getting the project right the first time.

Use a Separate “Discovery Project” to Define the Work for a Large Project (2.1.1T.P9)

For very large projects, there is a tendency for the project definition work to become very lengthy and unfocused. Defining the work for very large projects may take enough time that it should be structured as a project itself. This is the purpose of defining a separate Discovery Project.

This should make sense. For example, if the project is ultimately going to take 50,000 effort hours, it may take a number of months to get the project defined and approved. In these cases, a distinct first project is established to define the second larger project itself. The final deliverable for a Discovery Project is a completed Project Charter, Project Management Plan and project schedule for the subsequent large project. All the other project deliverables will be produced as a part of the next follow-up project.

Discovery Projects, like all projects, come in all sizes. You should estimate the effort and duration required for the Discovery Project. Based on the effort required for the Discovery Project, you can categorize the Discovery Project itself as small / medium / large using the same project criteria described earlier. Remember that this is the relative size of the Discovery Project, not the final project. Depending on the size of the Discovery Project, you again have three options on how to define the work.

For a small Discovery Project, a service request can be created, but it is not required. For this size of effort, just continue to do the definition work, as defined in the 2.1.2P Define the Work / Medium Projects. It is assumed that if you are defining a Discovery Project the final project will be large enough to require a full Project Charter.

For a medium-sized Discovery Project, follow the TenStep Project Management Process for a medium project. The Discovery Project should have an Abbreviated Project Charter and project schedule, and be managed just like any other medium-size project, including managing issues, scope, risk, etc. (A Project Management Plan document does not need to be created for the Discovery Project itself.) When the Discovery Project is complete, the Project Charter, Project Management Plan and project schedule for the subsequent project should be created. The approval process for these documents should be a part of the Discovery Project. Assuming that the Project Charter has been approved, the subsequent large project can start at any time. However, steps 2.1P Define the Work and 2.2P Build the Schedule and Budget will already be completed (these were the purpose of the Discovery Project). The project management process for this subsequent project can begin in Step 4.1P Manage the Schedule and Budget.

If the size of your Discovery Project is, in fact, a large project itself, you should follow the steps required for defining large projects. Let’s look at an example. Let’s say you are trying to define a very large project – perhaps even a program (a set of related projects managed as a whole). Let’s further assume the Discovery Project itself takes 5,000 hours. If the Discovery Project is a large project, the subsequent project actually being defined would have to be very, very large. The Discovery Project would then be managed as a large project. When the Discovery Project is completed, the larger project can start, since the Discovery Project deliverables include the Project Charter, schedule and Project Management Plan.