Cadence Management Corp
VIP

The Cadence Project Management Methodology
 Jay Christensen, PMP
Vice President, Cadence Management Corporation

Cadence ProjectMaster was developed to enable project managers and project teams to develop the roadmap for achieving project results. In other words, complete the project plan. To provide the proper context for discussion of the project plan, below is a brief description of the project lifecycle. A process for developing the plan can be found later in this document.

Project Lifecycle

Project ideas originate as a change to ongoing operations, as an initiative that will help to deliver an organizational goal, or as an element of a program. Usually, there are far more project ideas than there are people to do them. The temptation is to move the idea to implementation in a split-second, with no thought as to whether this project makes sense. Important questions need to be answered:

  • Can it be staffed properly?
  • Do the ROI numbers work?
  • Does the organization have the technical expertise?
  • Will funding be available, etc?

There needs to be a project lifecycle process which acts as a filtering mechanism for ensuring the limited number of resources available are allocated to the right projects. The lifecycle needs phases and decision points at the end of each phase. At each phase-end, a decision is made to go forward to the next phase or drop the project. Each phase progressively elaborates on the project, driving out successively more risk and uncertainty. As the project becomes more and more defined, more resources (people, dollars, time, etc.) are allocated. The intent is to limit expenditures and free up resources by canceling projects with small ROIs as early as possible.

The Cadence project lifecycle is composed of five distinct phases: Think, Study, Research, Plan and Implement. The following section contains a description of the activities in each phase and the documents that are produced. This lifecycle model applies to a new product/service, enhancements to existing products/services, operational performance improvements, facilities projects or projects brought about by regulatory changes or requirements.

Think Phase

The purpose of the Think Phase is to capture the project idea in writing. The resulting document is called a Request. In addition to the description of the idea, the Request identifies the benefits expected from implementing the project and the other departments or organizations that would be involved in providing resources for the project. The document is typically one page or less in length and is used to communicate enough information about the idea to obtain sponsorship for the next phase. The Request document contains:

  1. A brief description of the idea
  2. Involvement from other organizations

Study Phase

This is the "idea development" phase. The purpose of this phase is to identify opportunities, identify risks/issues, and discover significant problems early. Relevant project information is collected that is readily available without doing extensive research. This is done to limit the expenditure of resources. The Study Document contains issues, facts, assumptions and an estimate of the resources required for the next phase, Research.

The Study Document is usually 2-5 pages in length and provides enough documentation to permit the project to be selected among other projects.

Research Phase

This is the "justification" phase. During the phase, the arguments for developing the product, service or process change are developed and presented. The purpose of the phase is to research whether or not this project makes business sense and to assess risk. Its length and complexity will vary by project. The document produced is termed a Business Case if prepared for internal use or a Proposal if presented externally. It usually contains:

  • An objective containing cost, schedule and performance and is the estimate for completing the Plan and Implement phases
  • A product/service description
  • Market analysis or opportunity analysis
  • Technical analysis
  • Financial analysis
  • Risk analysis
  • Recommendation

The purpose of this document is to provide the documentation by which project can be authorized. Project funds are allocated or set aside for the project in preparation for having the funds available at the end of the Plan phase.

Plan Phase

The document produced in this phase is the Project Plan. It represents the roadmap that will be used to deliver project results. The Plan, when approved by the appropriate governing body, is also used to obtain formal commitment of resources to the project. The project size will determine the recommended components that are to be included in the project plan. The elements of the Project Plan are:

I. Introduction

II. Objective Stated in terms of cost, schedule and performance. This is the 'final' objective and defines the CSP for the Implementation phase of the project. The objective at this point is based on solid data developed during the planning process.

III. Scope.

IV. Work Breakdown Structure.

V. Roles.

VI. Responsibility Matrix.

VII. Schedule. The schedule is the primary control tool for the project and contains calendar, duration, network and the thinking behind the duration estimates (assumptions). Since it is also a key communication tool, it should be a graphic representation of the time necessary to complete all of the project activities. Dependencies between activities are represented with down arrows. Activities, if delayed, that would have a critical impact on the project are indicated with up arrows.

VIII. Budget. The budget is used to derive the Cost element of the project objective. It can be stated in terms of either labor or non-labor or both. An estimated cost for each task is developed by the task team. All task estimates are summed to produce the project budget.

IX. Key Issues/Risks/Assumptions. These items collected during all phases of the project. Key Issues are matched to tasks to ensure that they are addressed. If a task does not exist to address the issue, then one is created, responsibility assigned and scheduled.

X. Change control. Changes that impact CSP and that occur after plan approval need to be managed with a change control process. The process should identify the change request form, how the change is routed and who has approval authority for the change. Once the change is approved, the plan needs to be updated.

XI. Administration. Important and useful project information that doesn't fit in the other plan elements are placed in the administration section. Typical topics are: standard meetings (day & time), distribution lists, problem severity coding/handling, glossary, etc.

This plan is used to both drive and control the project and to prove that the cost, schedule and performance parameters are obtainable. When the plan is approved, the resources allocated at the end of the research phase are released for implementation.

Implement Phase

This phase is the actual work of completing the project successfully by meeting cost, schedule and performance. It is the 'Do It' phase. The document produced at the end of this phase is the Final Report. It should contain:

  • A recap of the project results of what was intended to be done and what was accomplished. High points and low points as well as recommended features for the next phase may be included.
  • A review of the project in terms of the significant learning experiences, what worked, what didn't work, and what we would do differently.
  • Recognition and thanks to the team and others who made significant contributions to project results.

This document is prepared to document the project experience for future learning and too officially close the project.

Now that the context for the Plan has been established within the project lifecycle, The process for completing the project plan can be described. The steps presented below are followed in sequence. One step builds upon the work done in previous steps. Also, as the team progressively develops understanding of the project, they may refine the results of the previous steps.

Getting Started with Planning

Planning Team Identification

The project manager first identifies who will be involved in the planning meeting. These planning team members will have been communicated by the person making the project assignment or the project manager will identify who are the people best suited to work on the project. Concurrence from the functional managers to pull people into to the planning meeting may be necessary.

Planning Meeting Announcement

Once the team has been identified, formal notification of the planning meeting is sent to each team member. The meeting announcement should state that the agenda for the meeting is to develop the project objective and scope, and to record issues, problems, risks and concerns. The announcement should ask people to begin thinking about their project issues and concerns and potential scope.

Project Introduction

This is a brief discussion of why the project is being done. It is used to explain the justification for doing the project and what goal(s) the project supports. The background and history of the project may also be included. The Introduction is usually about 1/2 page in length.

The Introduction is usually given to the project manager either verbally or in writing at the time of the project assignment. It can be distributed as a part of the meeting announcement with instructions to raise content questions to the project manager in advance of the planning meeting. The answers to the questions can be incorporated into successive versions of the Introduction, thereby improving its quality and communication value. By the time the planning meeting occurs, the Introduction can be nearly complete.

The Planning Meeting

The meeting room should be large enough to comfortably accommodate all of the team members. There should be sufficient wall space so as to enable flip chart pages and wall charts to be hung for everyone to see the planning information as it is developed and captured. Use of LCD projectors or other computer display devices is not recommended. There is a very limited amount of information that can be displayed at one time via a data plate. People can not walk up to the information and interact with it as they can with flip chart pages mounted on the wall.

A meeting facilitator or gatekeeper can be very beneficial for helping the team stay on course. This person can also help the team follow meeting rules, allowing everyone to have airtime with only one person speaking at once. The facilitator can help the team avoid getting stuck on issues by reminding the team to board an issue after a reasonable period of discussion (about 3 - 5 minutes) and then moving on. Should the facilitator be a team member or the project manager? Preferably not, as these folks should have the full opportunity to contribute to the generating of planning information and not to be worried about the meeting process.

People usually think of planning information randomly, not serially. The room needs to be setup so that data can be recorded easily. Having at least 3 flipcharts in the room will help capture the project planning information as people express their thoughts.

The Plan Components

Project Objective

The project objective should not be complex or overly detailed. It should be a simple statement of 25 words or less and contain the project cost, schedule and performance. Cost is stated in either hours (amount of effort) or dollars necessary to complete the project. The schedule is stated as the month, day and year the project will be completed. It is the end date for the project. Performance is the major deliverable of the project. It is further defined as scope and quality. The objective is a critical tool for communicating what the target of the project is. The project objective should be specific, not overly complex, measurable, tangible and verifiable, realistic and attainable, consistent with resources available or anticipated, consistent with organizational plans, policies and procedures.

The formula for the objective statement is: To (verb + major deliverable) by (mm/dd/yy) within a cost of (hours or dollars).

The project manager can enter a straw objective on the flipchart in advance. This will usually help to get people started discussing the project. It will cause questions to be asked or challenges to be expressed or to spur thinking about what is contained within the major deliverable. Also, if the project assignment has been made with a due date or cost already established, pre-recording the objective provides the opportunity to inform the team of the project constraints at the outset of planning.

The objective is discussed and wordsmithed until the team has achieved alignment or can agree to continue with the planning process. Discussing the objective is important because doing so will help to establish the proper context for the remainder of the planning meeting. It is natural and to be expected that issues and questions will surface. They need to be recorded for tracking and resolution.

Project Scope

Deliverables

Deliverables are the outcomes expected by the customer and are turned over at the end of the project. They are used in ongoing operations and can be such things as functions, features, requirements, components, training materials, processes, manuals, procedures, drawings, etc. They should be tangible and verifiable and stated as nouns.

Deliverables are recorded on a flipchart page as a list. Initially, the list of deliverables is recorded generally as stated without much editing. They will be refined, combined or eliminated as the team continues with project definition. See the Project Sizing Grid guidelines for recommended number of deliverables.

Intermediate outcomes produced by the project team that are not given as final outcomes to the customer or that do not explicitly address a customer's need are not included in the deliverables list. This rule of thumb will help the team focus on delivering the customer's expectations.

Measures

Measures are what the customer will use as the quantifiable criteria for acceptance of the project results. Measures are standards or qualifiers that are expressed with as many numbers or percentages as possible. Doing so helps to make the measures more quantifiable and therefore more useful. Categories of measures are: magnitude, distance, weight, length, color, speed, poll/survey results, decibel level, etc. They may be applied against the deliverables one-for-one or to the project as a whole. Also, measures can be included with the deliverable description.

Measures are captured in a list on a flipchart page just as deliverables. Developing measures is critical for achieving project success in the eyes of the customer. The team needs to know up front what the customer will be using to accept the project results at project end. Otherwise, the team will take the project in a totally different direction than what the customer is expecting.

Exclusions

Exclusions define the outer boundary of the project and state what the project will not do or only what the project will deliver. Exclusions are used to explicitly identify what is not a part of the project scope. Keywords used in exclusions are NOT or ONLY. Features, functions, specifications, etc. that will be included in future releases or in later projects may be specified in exclusions. What is not explicitly stated as beyond the project scope will usually be implicitly assumed as included in the scope by the customer. Exclusions help to overcome this communication problem.

During the identification of deliverables and measures, team members will either state or question that a specific outcome will not be included in the project. These statements are captured on the flipchart as exclusions, randomly as they occur during the meeting.

Key Issues/Problems/Risks/Assumptions

In the process of developing the project objective and scope, issues will surface which need to be recorded. In fact, issues and concerns usually occur during the Study and Research phases and, if not resolved, are carried into the Planning phase. People have a natural tendency to want to discuss an issue at length or resolve problems when and where they arise. Unless carefully monitored and managed, problems and issues can seriously hamper and delay planning progress. A rule of thumb is board an issue if it has been discussed for 3-5 minutes.

Issues can be political, organizational, technical or financial in nature and if not resolved, can hold up a project. Frequently, they are not under the direct control of the project manager and will require resolution by other people. These types of issues are key decisions that must be made and the decision-maker needs to be explicitly identified.

Interim Review of Project Profile

Unless there has been other dialog and depending on the size, complexity and risk of the project, conducting an interim review of the project profile is a good idea. The project Introduction, Objective and Scope are collectively known as the Project Profile. The review of the Profile is done with the sponsor, governing body or customer. The purpose is to achieve alignment on the scope of the project so that the team can cost-effectively invest their time finishing the plan. And, this review is used to prepare for obtaining approval from this same person or group at the end of Plan development. The nature of the project may require significant effort to complete the plan and the team needs to ensure they are investing their time wisely.

This point in the Plan development would be a good time to identify and attend to the issues that need to be resolved before the plan can be finished. Others can be addressed as part of the implementation activities.

Work Breakdown Structure

The Work Breakdown Structure (WBS) is a hierarchical view of the activities necessary to produce project results. The tool is used for medium and large projects. The WBS can contain up to 6 levels as illustrated below.

Deliverables from Scope are moved to the Work Breakdown Structure and the tasks necessary to complete the deliverables are identified. About 3 - 15 tasks per deliverable is a reasonable guideline. When deliverables are stated in terms of specifications, or if the project is a construction project, then blocks-of-activity (or development phases) may be used on the Work Breakdown Structure. Additionally, if there are a number of activities that do not fit under a particular deliverable, then the block-of-activity is used.

The WBS is taken only to the Task level during the first pass. There may be no need for lower levels of activity and unnecessary work can be avoided. Sub-tasks may be added during scheduling. Work packages may be added during scheduling. In either of these cases, the WBS can be updated with the additional detail.

Task descriptions need to be of a reasonable length (less than 60 characters) and contain a verb and a noun. The format is action/result or verb/object-of-the-verb. The purpose for this rigor is to be able to determine the tangible, verifiable outcome from each task. This helps to communicate the results of activities and to verify completion of the task.

The WBS needs to be wide rather than deep. This means a large number of tasks instead of lower levels of detail, i.e., sub-tasks and work packages. A reason for this guide is to make more of the project visible to all of the team members. Errors and misunderstandings will be caught much earlier this way.

This is a natural place to begin editing deliverables. Some deliverables can be broken apart. If there are a large number of tasks for a particular deliverable, it usually means the deliverable is very big and can be divided.

The deliverables and tasks can be roughly sequenced at this point. This can be thought of as the order of work decomposition. However, in the schedule, the sequence of completion by date and dependencies will likely be different. If debates or lengthy discussions about sequence erupt, they need to be tabled. At this point, sequence is not critical and should not delay the planning process.

Flipchart pages and 3" x 3" post-it notes are used to construct the WBS. The blank pages are hung on the wall close together so that a horizontal line can be drawn at the second level in order to connect the deliverables and blocks-of-activity. The generation of the tasks can be done by the team or individually by a person who is particularly knowledgeable about the activities necessary to complete the deliverable. A pad of post-it notes is given to each team member. Tasks are written on the post-it note, a single task for one note. The person then places the task underneath the appropriate deliverable.

Near the end of the WBS development, a walk-thru is done for all the tasks. The purpose is to ensure the task descriptions accurately describe the activity and that people understand what the task is intending to accomplish. The project manager usually conducts the walk-thru although the person who wrote the task can also walk-thru the tasks they developed. The task description is read aloud. If there is any question about the meaning of the task, it should be wordsmithed so that the outcome of the activity is clear and understood by all.

Roles

Roles are used to define the kind of participation a person (sponsor) or group of people (team members) will have in the project. They can be seen as temporary job descriptions. Roles can pertain to a specific individual but most often relate to the general functions on the project. Roles usually are developed for the Project Manager, Team Members, Technical Team Leads, Project Coordinator, Steering Committee, and Functional Managers. When appropriate, they also may be developed for Champion, Suppliers, Customers, Vendors, etc. Role descriptions need to be developed and agreed upon by those affected. People on the project certainly need to be informed of what is expected in their particular role on the project. Role definition helps to resolve territorial disputes in the Plan phase - before they have the opportunity to impact project progress during the Implementation phase.

Responsibility Matrix

The Responsibility Matrix is a graphic representation of who does what on the project at the task level. It is a primary communication tool and explicitly identifies who is the owner for tasks and who are the task contributors. Commitment to accomplishing the tasks of the project is critical to successful project management. The Cadence Responsibility Matrix is the tool to gain this commitment.

The team completes the Matrix just as they do the other plan components. In fact, team participation is even more critical here as people will be accepting task ownership and delivering task results. Additionally, the team members must buy-in to completing work on the task in order to help the task owner deliver his/her commitment. If people do not accept this commitment personally or if the commitment is assigned to them without their participation, the likelihood that they will honor their commitment is very low.

If the project size is medium or large, the tasks are copied from the WBS to the Responsibility Matrix. If the project is small, the task descriptions are generated here. A Matrix is not completed for a micro-sized project. The project team is entered on the left side of the page; the tasks are recorded horizontally. Task due dates are not entered with the task descriptions. This tool is meant to indicate only who is responsible for what — not when or how much.

At the intersection of a person and a task, a person has one of three choices. One, they have no involvement in the task at all. Two, they contribute to the task. Or, three, they are the task owner. A graphic symbol is entered at the intersection to indicate the type of role the person has. A dot indicates a Contributor role; a dot with a circle around it (circle-dot) means the person is responsible for that task.

The team boxes (those up the left side) can have only one person's name in the box. Otherwise, single-point responsibility will be compromised. The department or organization the person represents is entered into the box. This indicates where resources are being drawn from to complete the project. The person's e-mail address or phone number is also entered in the box to provide access information in case anyone from outside the team has a question or needs to contact the team member.

If there are multiple people from the same department or organization on the project team, then each person will get a separate box. A person's title is usually left out of the box. If a title is present, people will attempt to turn the tool into some form of an organizational chart, which is entirely the wrong idea. The tool is meant to represent a project team.

A team member contributes to the task by doing work on the task, providing duration estimates during scheduling, providing cost estimates during budgeting and helping to define lower levels of detail for the task, if necessary. A general rule of thumb is to examine the size of the task if there are more than 4 team members contributing. This can be an indication that the task is to big and needs to be broken apart into smaller activities. Or, it may be entirely appropriate to have more than 4 - a kickoff meeting for example. The point is to take a look at the task and determine the appropriate course of action. A person needs to accept being assigned to the task - if they are forced their level of commitment is usually very low.

A task owner is responsible for closing work out on the task. This is the person who will deliver cost, schedule and performance for the task. The responsible person manages the task team to deliver task results and is the focal point of communication for that task. There can be only one person responsible for a task - otherwise ownership is diluted and no one can be held accountable for task results. This is another way of saying that the task can have only one circle-dot.

During the completion of the Matrix, the team may discover that they are missing one or more team members. While seeking resolution to this resource problem, several situations can arise.

First, a functional manager, who has people in his/her department with the skills appropriate to contribute to this project's tasks, does not have a person to assign to the project now but will have a person on a specific date. In this case, TBA (To Be Assigned) is entered into the box along with the date the assignment will be made.

Second, a functional manager, who normally would have a person in his/her department to contribute to this project's tasks, does not have a person to assign now nor for the foreseeable future. In this case, Unavailable is entered into the box along with the date the project will be impacted if a resource isn't identified. The project manager, with the help of the team, needs to generate alternative solutions to this problem. Then, the functional manager is presented the options and asked for their preferred solution or additional options. The project manager and functional manager agree on the recommendation they want to present to management. The problem and recommendation is taken to management for concurrence and/or resolution.

Issues are addressed when the first pass of completing the Matrix is finished. Each unresolved issue is matched against the tasks on the Matrix. The purpose is to find the task(s) that, when completed, will address the issue. When a match is found, the issue has already been addressed. If no match is found, the issue is worded into task format (action/result), recorded on the Matrix and responsibility assigned. In either case, the issue number is added to the end of the task description. The task number is, in turn, added to the end of the issue. This indicates which tasks resolve which issue. The issues are left in their original form in the Issues/Risks/Assumptions section of the project plan. In so doing, the team can demonstrate that issues are present on the project and that they have been addressed by specific tasks with a specific person responsible for issue resolution. Coincidentally, risks can be managed in the same way.

Schedule

The schedule is the key control tool for the project. It is the one tool that is always used regardless of the project size. The schedule has several elements: calendar, project timeline, activities (tasks, sub-tasks and work packages), duration, network, and assumptions or notes. It can also contain the person responsible for a task and the start date/end date for each activity.

For micro-sized project where neither a WBS nor a Responsibility Matrix is completed, tasks are developed here in the schedule. In fact, deliverables are included in the task descriptions since the micro project plan does not include a scope statement. And, name of the person responsible for a task is entered next to the task description.

For a small, medium and large projects, tasks on the Matrix are sequenced and moved over to the schedule.

The Cadence methodology uses several scheduling conventions. A graphic illustration for each is included below.

1. Project Timeline

This depicts the total duration of the project, from start to end. It is usually the sum of all task durations less overlap. However, when the project is in red status and the team is working on alternatives for minimizing or eliminating the slip, a red bar with a red open triangle is drawn beyond the green planned bar. (See Planned and Actual Slip below.)

2. Sub-tasks are usually indented to show their relationship to their parent task. The WBS number can also be used to illustrate this relationship.

3. When an activity needs an outcome from another task to start work, then that dependency is shown as a down-arrow. As an example, Task B is dependent upon an outcome from Task A before B can start. A is the dependent task and the down-arrow is drawn from Task A to Task B. The dependency arrow always emanates from the end of the dependent task.

4. When Task A produces it's outcome before B needs it and if B cannot start the task early, then Slack exists.

5. If Task B may be able to start the task early but will not commit to an early start, then Task B is said to have a Potential Early Start.

6. When an activity is delayed and the delay will likely cause an impact to the parent task, then the activity is identified as a Critical Impact. This relationship can exist between a task and the project timeline, between a sub-task and its parent task, and between a work-package and its sub-task.

7. A green bar with an unfilled triangle indicates Planned duration.

8. A green bar with filled triangle indicates the Task is complete when planned. It is termed Actual On Time.

9. When the filled triangle is to the left of the unfilled triangle, the task has been completed earlier than planned. This is called Actual Early.

10. If the task is will be completed later than originally thought, then the new Plan end is drawn to the right of the original. This is called a Planned Slip.

11. If the task was completed later than originally thought, then the new Actual end is drawn to the right of the planned end. This is called Actual Late.

If the duration of an activity is longer than 3 weeks and the activity is not broken down, then it is likely the activity will be completed late. This is usually because the work necessary to complete the activity hasn't been thoroughly thought through. A rule of thumb is to break an activity down to the next lower level if it is longer than 3 weeks - as illustrated below.

One of the most powerful tools for managing a schedule is to use task Assumptions. In dictionary terms, assumptions are defined as 'To take for granted as true in the absence of specific facts.' In the scheduling context, assumptions are the thinking behind activity durations. They can be based upon history, extrapolation or hunch. Assumptions help to document and, in some cases, quantify the degree of uncertainty pertaining to a particular duration.

Assumptions are used to:

  1. Assess and improve schedule viability
  2. Modify the duration of an activity
  3. Assess risk and develop an off-page contingency plan
  4. Get an early warning of a schedule problem

Assumptions are listed next to the task they pertain too. These assumptions are different than those found elsewhere in the project plan in that they are task specific.

The detail contained in the assumptions will help to explain the duration of activity in more concrete terms. In this way, when management challenges an assumption and the challenge is addressed to management's satisfaction, then the confidence and viability of the schedule is dramatically improved.

If the specific data for establishing activity duration is documented, then the duration can be modified by changing the data. This is an intelligent, fact-based technique for modifying a schedule rather than using rationale based upon emotion or guesses. The quality of the resulting plan is much higher when the schedule is modified in this way. Of course, changing an assumption needs to be evaluated to determine what the effect may have on the cost or performance of the project. The impact may necessitate the need for management or sponsor approval. Purchasing technology to reduce task duration is an example.

For critical tasks, the assumptions are tested to confirm or deny that they are remaining true. If not, then likely the task represents a high-risk activity, which if delayed, will cause the project schedule to slip. A decision can be made as to whether or not an off-page contingency plan should be developed. This is 'Plan B' and will be implemented when the Contingency Plan Trigger Point occurs. This alternate plan can be costly, which is the reason for not using it in the first place and is also the reason why the project team does not want to use it unless forced to. The entire purpose of the contingency plan is to deliver the project schedule and the targeted quality. The contingency plan is thought out well in advance of the need, when schedule pressure is low. The quality of both is enhanced in this environment.

The Contingency Plan Trigger Point (CPTP) is documented alongside the task with the task assumption. Implementing the contingency plan can be a tough decision and can be a judgment call under pressure. Additionally, if the cutover to the contingency plan is not done in a timely fashion, its mitigating effect can be totally lost or significantly reduced. The CPTP describes the conditions under which Plan B will be implemented. This removes the judgmental nature of the cutover decision and preserves the maximum effect of the contingency plan.

Assumptions can also be tested before the task begins or during execution to get an early warning of a schedule problem. If the assumption is remaining true, then the task status is green and will be delivered on time. If the assumption is not holding true then task delivery is in jeopardy. In advance of the impact, alternatives for reducing or eliminating the affect of the problem can be identified, evaluated and implemented, thus putting the task back in green status.

Steps to Creating a Schedule

1. Before scheduling can begin, the team needs to sequence the tasks on the responsibility matrix. Or, if this is a micro project, tasks need to be generated and sequenced. The scheduling sequence is usually much different than the WBS sequence. As a matter of fact, when the tasks are entered on the schedule, their descriptions are prefaced with the WBS sequence number. This provides a visual reference of the location and sequence of the task in the WBS.

A low-tech method for sequencing is to use a pad of post-it notes. A sequential number is written on each post-it, up to the number of tasks on the responsibility matrix. The team determines the sequence number of the task on the matrix and affixes the appropriately-numbered post-it on the task description. All tasks are assigned a sequence number. As sequence changes are discovered, it is easy and convenient to move the post-its around. Then, the task descriptions are written on the schedule in the order specified by the post-it notes.

2. After sequencing and in preparation for the scheduling session, the project manager asks the circle-dot people (task owners) to work independently with their task teams. They are given 6 assignments:

a. Identify their tasks from the Matrix.

b. Identify the predecessor requirements for their tasks. This means to make a list of the other activities in the project that a particular task depends upon to start its work.

c. Estimate the duration tasks.

d. If a task is longer than 3 weeks, identify subtasks and estimate their duration.

e. Take notes on assumptions.

f. Identify the most critical tasks.

3. Enter tasks in sequence from the Responsibility Matrix.

a. If a task will take 3 weeks or less, enter estimated duration bar. If longer,

b. enter subtasks and estimated duration bar for each.

c. Draw task line to cover total duration of tasks.

4. In the first scheduling pass, enter duration estimates without challenge.

5. Review the first draft with the team, adding assumptions, dependency arrows and overlapping tasks.

6. Draw impact arrows from critical tasks to the project timeline. Draw an impact arrow from a subtask to the task above it if the subtask is critical to the task delivery.

7. Identify opportunities to be investigated which will result in shorter duration.

8. Schedule the next scheduling meeting.

Scheduling Tips

Include questions, issues, problems and other notes in the Assumptions column next to the tasks. The schedule is a key control tool as well as a communication tool. This additional information is used to keep items of importance in front of the project team and others who review the schedule.

Show individual vacations as tasks in the schedule. Before the schedule complete, people are asked if there are any vacations to add or any that need changed. Vacations can cause nasty surprises that can have a tremendous impact on the schedule unless they are documented and planned for.

Plan for the negative impacts for activities that always occur on schedules. These are activities like rework, retest, redesign, etc. They are a fact of life and the schedule needs an allowance for them. If the item does not occur, or does not have the impact anticipated, then the schedule has reserve for other problems.

Speaking of reserve: Through the use of assumptions, challenges and refinements, the team develops a realistic, doable schedule that they are confident they can deliver. The schedule is trim, without padding. The plan is approved and implementation begins. The team now needs to create schedule reserve through early deliveries at the beginning of the project. When this has occurred, the team should not pull in the end-date of the project. Problems will always occur and schedule gain can be used to work out the resolutions without impacting the project end date.

And then there is the other situation: The schedule has slipped beyond the date specified in the project objective. In order to address this problem, the team needs to examine task assumptions - looking for opportunities to modify the assumptions and eliminate or minimize the slippage. Then, the project manager can inform management of the slip, alternatives for dealing with the slip, and a recommended course of action.

The Planning Process

The team develops the Project Plan in the following sequence:

  1. Introduction
  2. Objective
  3. Roles
  4. Scope
  5. Issues, Risks, and Concerns (begin collecting them here, but they are recorded during the entire planning process)
  6. Work Breakdown Structure
  7. Responsibility Matrix
  8. Schedule

Depending on the size of the project, the team should set aside 2 or 3 full contiguous days to create the initial plan draft- preferably off-site without interruptions. The objective, scope and WBS can usually be completed in one day, leaving the responsibility matrix, schedule and roles for days 2 and 3. If possible, a review of the project scope should be done with the sponsor at the end of day 1. This is done to confirm the project deliverables and make any necessary changes before proceeding with additional planning.

 

.
© 2005 Cadence Management Corporation. Reservados todos los derechos.