PROJECT CHARTER

Project Management

A project is a series of activities and tasks with a specified objective, starting and ending dates, and necessary resources. Resources consumed by the project include time, money, people, and equipment. Project management includes project planning and implementation to achieve:

• The specified goals and objectives,
• At the desired performance or technology level,
• Within the time and cost constraints,
• While utilizing the allocated resources.

The stages of project management are:

1. Planning – deciding what to do
2. Scheduling – deciding when to do it
3. Controlling – ensuring that the desired results are obtained

Key project management elements include:

• Identifying schedule time limits
• Allocation of functional responsibilities
• Establishing continuous reporting methods
• Selecting applicable trade-off methodologies
• Measuring accomplishments against plans
• Identifying problems early
• Applying corrective action to problems
• Knowing when objectives will be met or exceeded
• Improving capabilities for future projects

Project management is concerned with doing things right. Project Management helps in maximizing business benefits is concerned with doing the right things. The person undertaking any improvement projects should have the “ability” to manage projects and reach closure, a persistent drive toward meaningful bottom-line results, and timely completion of projects.  Many businesses have deployed project managers to ensure that complex production processes move through the proper functional elements and make the proper transitions in a timely and cost-effective manner. This form of “matrix management” has proven very effective in improving the on-time delivery of a good product. The project management roles and responsibilities include the following:

• Lead the (cross-functional) team
• Possess excellent interpersonal and meeting facilitation skills
• Develop and manage a detailed project plan
• Schedule and lead team meetings
• Sustain team motivation and stability
• Communicate the benefits of the project to all associated stakeholders
• Track and report milestones and tasks
• The interface between financial and information management

Projects need charters plans and boundaries. Projects may be selected from a broad range of areas including:

• Improved process capabilities
• Customer complaints
• Reduction of internal defects
• Cost reduction opportunities
• Supplier-related improvements
• Lean manufacturing principles?
• Improved workflows
• Administrative service improvements
• Cycle time reductions
• Market share growth

The actual project should be consistent with company strategies for survival and/or growth. The project will be rather specific. Examples may include Reduce scrap costs in the finishing department for closure defects by 20% by May 2013. Improve market share for left-handed widgets by 10% for the 2013 fiscal year. One manufacturer of low-volume, high-value products reported improvements in on-time delivery from less than 25% to 100% when project management was deployed to facilitate the complex production process.

Work Breakdown Structure

The work breakdown structure (WBS) is a detailed plan which expands the project (statement of work) into a detailed listing of activities required to complete the project. The project team leader is usually responsible for the completion of the work breakdown structure, including an assignment of responsibilities for each task to individuals or team groups. Each project task is divided into smaller activities, and then elements until the level are reached in which each element is under one identifiable, individual, or group responsibility. Another way to say this is: you take a long journey one step at a time. Each activity is assigned a duration, along with the interrelationships between activities. If one activity must be completed before another can begin, this is called a predecessor event. After the material, equipment, and personnel needs are established for each activity, the project network can be scheduled. The schedule is a balance between time constraints, resource constraints, and costs.
If the time constraints are fixed, such as a set deadline, then the resource constraints must be flexible to accommodate variations in the project. Time delays during the project require offsetting increases in resources and costs to maintain a  set deadline. One example of a time-constrained project is the construction and delivery of a new product. These projects have fixed completion dates, often with penalties for each day, it is late. The contract is often won on the basis of the company that plans to meet the deadline date and is willing to risk the losses if the project is late. Time-constrained projects are assumed to have unlimited resources. In a practical sense, this means that resources must be acquired until they reach a level that will ensure on-time project completion.
Most projects have relatively fixed levels of resources including manpower and equipment. In resource-constrained projects, the objective is to meet the project duration requirements, without exceeding the resource limits. If these resources are shared within an organization, resource scheduling and coordination between projects becomes vital. For those resources with time conflicts, it may become necessary to schedule planned parallel activities as sequential tasks, using existing slack time and possibly delaying the project completion date.

Project Measures

It should be noted that key project measurements are also difficult to determine until the project selection and charter processes are complete. Careful selection of project measures ensures the overall success of the improvement project. Since most projects deal with time and money issues, most project measures will also be about time and money or will be closely related to them. Project measures provide the data and information needed to analyze, evaluate and improve the business process as well as manage and evaluate, the impact of the six sigma project. Project measures for both cost and revenue factors must be included. After a detailed list of projects, activities have been created (along with the resource requirements, and activity durations) the project budget is determined. During the project, actual costs are collected and used as inputs to the revised estimated project costs. The team leader or project manager compares the revised estimated costs with the budgeted costs to monitor progress. The project budget must be reasonable, attainable, and based on estimates of the tasks to be accomplished.  Revenue factors included in the budget and analyses are:

• Income from additional sales generated as a result of the improved product cost, quality, features, availability to the customer
• Reduced losses for scrap, customer returns, warranty claims, cost of poor quality (COPQ), low throughput, a poor time to market

Cost factors included in the budget are:

• Manpower and labour costs
•  Materials
• Equipment costs, rentals, leases, etc.
•  Subcontracted work or fees
•  Overhead or consulting charges
•  Reserve or contingency funds

Business-level measures will likely be identified and provided by the executive steering committee as part of the project selection process. Detailed operations and process level measures should be chosen to support the business level measures used. The timing of the revenues and costs must also be identified. A project can have a projected net profit but fail because funds were not available in the time frame they were needed. Large corporations manage cash flows on a daily basis. The precision and detail of the project planning phase will have a major impact on the accuracy of the budget. The costs associated with each project task are estimated on the basis of quotes, historical information, standard rates, or similar activities previously performed. These costs are summarized to give the cost estimates for the project.  The budget becomes the measurement standard for project costs. Some organizations use a budget that, once approved, is fixed for the duration of the project. Another method is to update the budget to adjust for deviations from the plan. Estimates of project revenues and costs are described by four types of measurements: budget, forecast, actual, and variance.

• Budget: The approved written plan of the total costs and cash inflows,  expressed in dollar amounts, for the project. The plan includes the timing of the revenue and costs and benefit-cost analysis.
• Forecast: The predicted total revenues and costs, adjusting to include actual information at the point the project is completed.
• Actual: Revenues and costs that have occurred, and for which the
  amounts are known instead of estimated.
• Variance: The difference between the budgeted and actual revenues and costs. A positive variance denotes a favourable deviation and a negative variance denotes an unfavourable deviation.

During project implementation, the actual cash flows are documented by the accounting department, and the information is provided to the team leader or project manager so that adjustments and decisions can be made. A favorable cost variance may be due to good execution, or maybe the result of incomplete work or material shortages.

Project Decision Analysis

In addition to benefit-cost analysis for a project, a decision to proceed must also include an evaluation of the risks associated with the project. To manage project risks, one should first identify and assess all potential risk areas. Risk areas include:

• Business risks
• Insurable risks
• Technology changes
• Property damage
• Competitor actions
• Indirect consequential loss
• Material shortages
• Legal liability
• Health & safety issues
• Personnel injury
• Environmental issues

After the risk areas are identified, each is assigned a probability of occurrence and the consequence of the risk. The project risk factor is then the sum of the products of the probability of occurrence and the consequence of the risk.

Project Risk Factor = Z {(probability of occurrence) X (consequence of risk)}
Risk factors for several projects can be compared if alternative projects are being considered. Projects with lower risk factors are chosen in preference to projects with higher risk factors.

Project Portfolio Analysis

When there is a portfolio of project opportunities and limited resources, as in the real world, management must make decisions to approve, postpone, or reject project proposals. These decisions are based on the project benefit-cost analysis and the evaluation of the risks. The decision-maker may also make project approval decisions based upon the track record of the project team leader and on intuition or “gut-feel” for the non-financial benefits of the project and the likelihood of success. Regardless of the method(s) used for evaluating the project(s), ROA, ROI, NPV, IRR, payback period, risk factor, etc., each project will be compared against the other projects in the portfolio, and against a criteria amount established by the organization for that measure. For example, the organization may require a minimum ROI of 8% or a minimum NPV of $10,000 for the project to be considered. Typically, the project with the highest financial benefit, shortest payback period, or lowest risk factor is chosen for implementation first.

Documenting Projects

The initial project documentation is the project proposal. The proposal is usually in response to meeting an improvement objective. The proposal should include the objective(s), project plan, and budget. Approval of the proposal is management’s indication of support for the project objectives and commitment to providing funding and resources. During the implementation of the project, status reports are the communication vehicle to management (or the customer) on the progress and health of the project.

1 Project Review

The project review is a formal and documented critique conducted by a committee of qualified company personnel. The project review extends over all phases of development, from inception to completion. The review process is established by management policy or customer specification, or both. A project review considers all of the important factors in the creation of mature product design. Some of the fundamental review topics include: –

• The adequacy of personnel, time, equipment, and money
• The project effectiveness as determined by internal and external information
• The effectiveness and reliability of corrective actions
• The true quality level of the delivered product and/or service

Results of project reviews will be retained along with the other project documentation and archived for future reference.

2. Measurement of Project Activity

During the planning stage of project management, the monitoring and measuring requirements should be defined. In most cases, upper management requires scheduled briefing sessions during the project. These sessions range in depth from an overview of the project milestones to comprehensive reports. The project monitoring plan should address the following areas:

• What is being monitored
• The purpose of the monitoring
• Timing or frequency of reporting
• Method of reporting (written reports, verbal summaries, forms used)
• Procedure for indicating a need for assistance
• Criteria for reporting of unusual events or urgent information
• The channel for feedback (to whom and how the information is sent)
• Assignment of feedback loop responsibilities
• Action to be taken when performance differs from requirements

The feedback loop defines the methods for monitoring and adjusting the process if results are different than desired. Planning for feedback is analogous to designing an automatic control system. The success or failure of a project is measured in the following dimensions:

• Were the specified goals and objectives achieved?
• Within the time deadlines?
• At or below cost constraints?
• Utilizing the allocated resources?

Well executed project plans meet all of the above criteria. As project complexity, project duration, or innovative technology increase, the more likely the project will not meet the desired time target. Crash programs, to return a project to the desired time schedule, are done at the expense of higher costs and resource usage. It is possible for a project to be considered a success, even when the project is late, over budget, or does not meet the stated objectives. An example of this type of success is when the project accomplishes a significant feat. Nearly every project encounters unanticipated events or problems, but this is not an acceptable excuse for failure to meet the performance standards. The skillful project leader will manage the resources to resolve the issues and maintain the project schedule and budgets. Performance is measured on results, not effort. The project timeline is the most visible yardstick for the measurement of project activities. The unit of measurement is time in minutes, hours, days, weeks, months, or years, and is readily understood by all participants on a project. The overall project has definite starting and ending dates, both planned and attained. From a quality viewpoint, both early and late projects have the opportunity for poor quality compared to the project on schedule. For projects ahead of schedule, the skeptical question is asked, “What corners were cut?” For projects behind schedule, an appropriate question is, “What is not being done properly in an effort to regain lost time?” Methods for planning, monitoring, and controlling projects range from manual techniques (using plain paper, graph paper, grease boards, and colored magnetic markers) to computer software.

Advantages of manual project management methods include:

• Ease of use
• Low cost
• Best for monitoring schedules and timing of events
• A hands-on feel for the status of the project
• Easily customized for the specific project needs
• Minimal training requirements

Advantages of computer-automated project management methods include:

• Able to model what-if scenarios
• Able to show the impact of alternate options
• Can present information in a variety of formats and detail
• Schedules are automatically calculated
• Variances from the plan are known in almost real-time
• Project status reports are easier to generate
• People at different locations can input data and share the same information
• Projects can be easily summarized
• Some data collection activities can be automated

Whichever method is used by the project team, keep in mind that the method is only a tool to organize and summarize the data and the completion of the project is the objective, not the status boards or bar charts.

3. Milestones Reporting

Milestones are significant points in the project which are planned to be completed at specific points in time. Intermediate milestones serve the purpose of refocusing priorities on the longer-range objectives, and at the same time providing the status of progress. Milestones typically occur at points where they act as a gate for a go/no-go decision to continue the project. The project team leader would be expected to make a presentation to management at each major milestone. The status of the project relative to the milestone, any potential roadblocks for the completion of the project, and plans for dealing with roadblocks, would be presented. The date and time for the milestone and the milestone activity are set very early on in the project planning phase. Once set and approved, the milestones are not normally subject to change or negotiation. If the project is late on meeting a milestone, this fact will reach the visibility of upper management quite quickly.

4. Project Report

The final report is the report card on project performance for completion of objectives, comparison of actual benefits and costs with budgets, and measures of major activity completion dates versus milestones. The next step of project closure is postmortem analysis. An analysis of what went well and what went wrong is used as a learning tool for future projects. The intent is to avoid making the same mistakes and to benefit from effective processes.

5.Document Archiving

The final project stage is documented archiving. This includes test data, traceability of materials, key process variables, and reports generated during the project. The documents must be complete and organized. Storage requirements include:

• Protection from damage, including fire, water, and other deterioration
• Security of access
• Retrievability within a reasonable period, e.g. 3 days
• Adequate markings and an indication of storage location
• Consideration of duplicate copies at different sites
• Use of a medium with a life longer than the record retention period

Project Charter

A critical element in the establishment of an improvement team is the development and acceptance of a charter. A charter is a written document that defines the team’s mission, the scope of operation, objectives, time frames, and consequences. Charters can be developed by top management and presented to teams, or teams can create their own charters and present them to top management. Either way, top management’s endorsement of a team’s charter is a critical factor in giving the team the direction and support it needs to succeed. The charter begins with a purpose statement. This is a one or two-line statement explaining why the team is being formed. The purpose statement should align with, and support, the organization’s vision, and mission statements. The charter should also identify the objectives the team is expected to achieve. Objectives should always be stated in measurable terms. The charter should also define the operating scope. This is an opportunity to identify the organizational or operational boundaries within which the team is expected and permitted to operate. Defining boundaries is crucial to avoid energy-draining and time delaying turf wars. Teams need to know what top management expects of them. The team has the authority, permission, and blessing from the necessary levels of management to operate, conduct research, consider and implement any changes needed to achieve the expected project results. A charter provides the following advantages:

• Eliminates any confusion
• Defines the subject boundaries
• Identifies areas which should not be addressed
• Identifies the deliverable product
• Provides a basis for team goal setting
• Authorizes the team to collect relevant data
• Provides access to necessary resources
• Approves time for team members to address problems

Moen suggests that a team project charter should contain the following key points:

• Business case (financial impact)
• Problem statement
•  Project scope (boundaries)
•  Goal statement
•  Role of team members
•  Milestones deliverables (end products of the project)
•  Resources required

Identifying the above details, in written form, will provide a constant and consistent target for the team.

Business Case

The business case is a short summary of the strategic reasons for the project. The general rationale for a business case would normally involve quality, cost, or delivery of a product with financial justification. Moen  suggests that there are four basic activities:
– Design of a new product
– Redesign of an existing product
– Design of a new process
– Redesign of an existing process
Eckes reports that a common problem for many projects is the lack of a company impact measurement. For example, if the existing quality defective rate is at 5,000 defectives per million opportunities; the possible justification is a reduction to 250 defectives per million opportunities with a cost savings of $1,000,000. Another example would be a reduction of product cycle time from 6 weeks to 5 days for an additional 10,000 units of production, resulting in an additional $1,000,000 of revenues. A project improvement team should follow typical financial department justification guidelines. The advantages and disadvantages of a project should be researched. Other individuals or departments should be involved, if necessary, to examine the key costs and resources for a successful project. Projects which do not show a significant financial impact to the company should be stopped or eliminated as soon as possible.

Problem Statement

A problem statement will detail the issue that the team wants to improve. Eckes explains the problem statement should be crafted to be as descriptive as possible. That is, how long has the problem existed, what measurable item is affected, what is the business impact, and what is the performance gap. The problem statement should be neutral, to avoid jumping to conclusions. A sample problem statement might be: “The ABC Company, in 2007, has experienced a 25% drop in sales, with a 40% drop in net profits.” The problem statement should include a reference to a baseline measure for guidance. A baseline measure is the level of performance of a particular metric at the initial start of a project. The collection of good data and process performance measurements will provide a picture of the areas in the company that are in greatest need of improvement. In addition, the measurement system will provide a foundation for other teams to use to pursue other projects. If the baseline measures differ from the assumptions of the team or company, more clarification may be necessary.

Project Scope

The project scope refers to the boundaries of the project. It is an attempt to outline the range of the team’s activities. In the area of product development, the team may decide to limit itself to the launching of a new product at a single manufacturing site. Issues or problems regarding market research, prototype development, or financial investments would be outside the scope of the team activities. Each team works very hard in its first meetings to clarify the project scope. The team champion, the team leader, and the team will all be involved in this process.

Goal Statement

The goal statement will be created and agreed to by the team and team champion. Hopefully, the goals will be achievable within a 120 to 160 day period. A typical “rule of thumb” for goals is a requirement of a 50% reduction in some initial metric (or improvement of 50%). For example, reduce the collectables from 120 days to 60 days; reduce the scrap from 5% to 2.5%.

Milestones/Deliverables

For any well-managed project, a set of stages or milestones are used to keep the project on track and to help bring a project to completion.   A typical milestone chart might be:

• Day 0:  Start team activities
• Day 1:  Start the define portion of the project
• Day 40: Begin the measure portion of the project
• Day 80:  Start the analysis portion of the project
• Day 120:  Start the improvement phase of the project
• Day 160:  Conclude the project with a management presentation
• >Day 160:  Bulk of project control elements in progress

Resources Required

The resources required for a project must be detailed. Typical resources required for a project could include:

• Qualified people
• Machine time
•  Equipment
• Phones and faxes
•  Machinery
• Computer equipment
•  Lab or office space
• Utilities, etc.

The following information should be provided for the team  champion,  team leader, and team members:

1. Importance of the project
2. Goals of the project
3.  Knowledge of the team champion, leader and members
4.  Scope of the project in terms of time and budget resources
5.  The key process involved
6.  Current baseline metrics
7.  What the customer requirements are

Developing a project charter

In developing a project charter, there are several inputs to the process:

1. Contract – The contract that is used as an input is the contract between your organization and the organization you’re asking to provide a product or service.
2. Statement of Work (SOW) – An SOW is a narrative description of products, services, or results to be supplied. The SOW indicates a business need, a product scope description, or a strategic plan.
3. Enterprise environmental factors – Enterprise environmental factors are any external environmental factors and internal organizational environmental factors that surround or influence the project’s success. These factors include organizational culture and structure, infrastructure, existing resources, industry databases, and market conditions.
4. Organizational process assets – Organizational process assets are any or all process-related assets, from any or all of the organizations involved in the project, that can be or are used to influence the project’s success. These include processes and procedures as well as the organization’s lessons learned and other historical information.

The inputs for creating a Project Charter are contracts, Statements of Work, enterprise environmental factors, and organizational process assets. You may not use all of these inputs for every Project Charter, but using some of these inputs is a good place to start before chartering.

A project manager requires an appropriate set of tools and techniques to build a Project Charter. With these tools and techniques, the project manager and project team can act on the inputs to create outputs. Creating a good charter often requires relying on appropriate tools and techniques:

• Project selection methods – Project selection methods are used by the performing organization to determine which projects to undertake. Such methods include benefit measurement methods, constrained optimization (mathematical models), and decision models.
• Project management methodology – The methodology refers to a collection of processes, project process groups, and control functions that include formal and informal methods to help a team develop a charter. One such methodology is called the agile development lifecycle another could be ITIL release management.
• Project management information systems (PMISs) – A PMIS is a set of automated tools accessible within an organization and integrated into a system. It is used by a team to create a Project Charter, elicit feedback, manage changes, and submit the approved document. Some organizations successfully use project central and SharePoint as their PMIS.
• Expert judgment – Expert judgement is used to evaluate the inputs needed for Project Charter development. People with specialized knowledge apply expertise to project details during the Project Charter development process.

By applying these tools and techniques to the Project Charter inputs, the project manager and project team can develop the Project Charter. Developing the Project Charter is the start of the rest of the project. The inputs and tools and techniques are used to create the Project Charter, which is the output of the Develop Project Charter process. A Project Charter provides an overview of the project and its goals. The Project Charter details the project purpose, overview, goals, and high-level deliverables.

The elements of a Project Charter are:

1. Define what the customer expects  from the project by Writing an Overview   of the Project Scope
2. Define where the project starts and ends by Determining the Team’s Boundaries for Creating the Deliverables.
3. Defining the Customers’ Criteria for Acceptance by Establishing the factors that are critical for satisfying the customers of the project.
4. Determine the  Required Reviews  & Approvals by deciding who must be involved in  review and approval process.
5.  Establish Risk Limits by Identifying the degree of risk the organization will accept in doing the project.
6. Select the project leaders and team members by  Identifying who must be on the team for the project to succeed.
7. Set Deadlines for Delivery of the Final Deliverables by setting a date when the final deliverables will be given to customers. 
8. Set the limit on the amount of money or time that can be devoted to the project.
9. Create a list of required reports and Identify the reports that are needed to monitor and communicate the Required progress of the project.
10. Identify Organizational Constraints & Project Priorities and clarify the priorities within the project. 
11. Assemble the Project charter and distribute it to key stakeholders.

Write an Overview of the Project Scope

1. Briefly describe the purpose of the project.  Limit the description to three sentences or less.
2. Give the project a name. Choose a name that reflects the purpose or the anticipated final deliverable of the project.
3. Identify the customers of the project. Identify who will use the final deliverables of the project. Who will receive the products, services, processes, or plans that are created as a result of the project? These are the customers of the project.
4. Define the customer’s’ needs and requirements. Determine what problem the customer wants to solve by using a specific final deliverable (Customer need.) Find out if the customer is looking for specific features in the final deliverable, or has defined specifications for the final deliverable. (Customer requirement.)
5. Identify and list the final deliverables of the project. A final deliverable is a product, service, process, or plan, which is delivered to the customers of the project and must satisfy customer needs and requirements. A project usually has only one or two major final deliverables.
6. Define any deliverables that must be created for the organization. A deliverable for the organization is a product, service, process, or plan that is created to meet an organizational need or requirement, not a customer need. These deliverables are byproducts or additional deliverables of the project. A deliverable that is created for the organization and delivered to the sponsor is called an organizational deliverable.
   Example: a report on a new area of technology that a team used in its production of a final deliverable for a customer.
7. Define any additional organizational goals for the project that are not deliverables.

Some examples of organizational goals that are not deliverables are:
– To generate a specific amount of savings as a result of a reengineering project.
– To enter into a new market or technology.
– To use the project as an opportunity to cross-train team members.

Determine the Team’s Boundaries for Creating the Deliverables

Determine the Life cycle stage where project team members will begin their work and the stage in which their work will end. In general, the life-cycle stage where a project ends determines what final deliverable is produced. The word “boundaries” applies to the starting and ending points for creating each final deliverable. The creation of any product, service, process, or plan will move through all of the development stages, from concept to delivery, and eventually to retirement, but a single project team may not be responsible for all of the stages. The project team may be responsible for one, some, or all of the stages.  It is the sponsor’s responsibility to tell team members where their boundary of involvement begins and ends for each final deliverable.

Define the Customers’ Criteria for Acceptance

Determine the customers’ criteria for accepting the final deliverables.  Ask customers for these criteria, whenever possible.  If it isn’t feasible to ask customers what criteria are most important to their satisfaction with the final deliverable, make the best possible decision on what the criteria should be. Determine a way to measure the customers’ level of satisfaction with the final deliverable.

Determine the Required Reviews and Approvals

Make a list of the deliverables (interim and final) that require review or approval. Identify who will provide the review and approval for each deliverable. Note the reason why the deliverable should be reviewed or approved. Depending on the project, it may be beneficial to also include customers in the review and approval process. For example: If the project is to improve an internal information system, the customers (potential users) may want to provide review and probably approval at certain stages in the development of the information system.

Establish Risk Limits

Assign a limit for the maximum degree of risk that the organization is willing to accept for each final deliverable. This risk is the uncertainty of not being able to physically produce the final deliverable according to the criteria set by the customer–of not having the ability, skill, or technological knowledge to create the final deliverable as promised. It does not include the risk of not having the needed resources, such as time, people, or money, to create the final deliverable. Using a scale from 1–10, assign a number to represent the risk limit for each final deliverable.
1 = an extremely low degree of risk or risk-free
10 = an extremely high degree of risk
Where possible, provide an explanation as to which types of risks are acceptable and which are not.

Select the Project Leader and Team Members

1. Assign a project leader. Look for someone who is skilled in these areas of Leadership, Facilitation, Coordinating tasks, Communication,  Project management knowledge.  The project leader should be a key stakeholder. A key stakeholder has a strong interest in making the project succeed because he or she (or the area he or she represents) is affected by the activities or deliverables of the project.
2. Select the members of the project team. Consider the types of skills, knowledge, and expertise that are important for the project.  Although all key stakeholders should be considered for membership, they don’t necessarily need to have regular membership status (attend all team meetings). Some can be ad hoc members (attend team meetings when their presence is required) and some can be kept informed of the progress of the project through reports and meetings with the team liaison. Usually, the smaller the size of the team, the better.

Set Deadlines for Delivery of the Final Deliverables

1. Determine when the final deliverables must be delivered to the customer. The team will build the project schedule around these dates.

2. Record any other deadlines that apply to the project. Are there any other deadlines that must be met, such as deadlines for completing any of the lifecycle stages? For completing the project plan? Record only critical deadlines that, if not met, will have a significant impact on the project.

Set Limits on Staffing and Spending

1. Define the limit for how much time the staff can devote to the project. This limit applies to internal staff time only. Staff time can be expressed in hours, weeks, months, or years. Some ways to express staff time may be:
“No more than 20% of people’s time.”
“One day every two weeks for three months.”
“One two-hour meeting once a week.”

2. Define the spending limits for the internal and/ or external costs that will be expended during the project.
• Internal costs = cost for staff time and other internal charges, e.g., supplies, copies, equipment
• External costs = outside purchases, e.g., contract labor, materials, equipment

Create a List of Required Reports

Create a list of all the reports that are required to monitor the progress of the project. The team will create a list of reports to help monitor its own progress. The sponsor needs to specify the reports that management needs to monitor the status of the project. On the list, include the following:
– Type of report
– Person requesting the report
– Date required or frequency
– Content of the report

Identify Organizational Constraints and Project Priorities

1. Identify any constraints that the organization will impose on the project. Constraints are limitations placed on the project such as “No unscheduled equipment downtime,” or “No additions to headcount.”
2. Consider which of the following factors such as lower cost, earlier delivery, or more features for the final deliverable has the highest improvement priority for the project, and which factor has the lowest improvement priority. As a baseline, assume the project will meet the deadline, the spending limits, and the customers’  minimum criteria for acceptance.  Give a rank of 1 to the highest priority, a rank of 2 to the next highest priority, and a rank of 3 to the lowest priority.

Assemble the Project Charter

1. Assemble the charter using the following four divisions:
• Project Scope:  Describe the scope of the project, including the project objectives; customer needs and requirements; each final deliverable with its life-cycle boundaries and customer acceptance criteria; each organizational deliverable with its life-cycle boundaries and sponsor acceptance criteria; any organizational goals for the project; and the reviews and approvals required for the project.
• Project Scope Risk:  List the risk limit for each final deliverable for the project, and the reason for the limit. Also, list the risk limit for each organizational deliverable and the reason for the limit.
• Project Resources:  Define the resource limitations (deadlines, staffing limits, cost limits) and priorities of the project. List the team assignments.
• Project Status Reports:  List the reports that will be required by management to monitor the status of the project.

2. If required, get the charter approved. The sponsor may need to have the customer and/ or the project steering group approve the charter. If the project team completed the charter, the project leader will need to review it with the sponsor, make whatever modifications might be needed, and then have the sponsor approve it.

3. Issue the charter. Distribute copies of the charter to:
– Project sponsor
– All members of the project team (both regular and ad hoc)
– Functional managers who will be affected by the project
– The customer, where appropriate
– The project steering group or project office
– Anyone else who has a stake in the project

When the sponsor or sponsors sign off on the charter, it marks the beginning of the planning phase of a project.​

Template-for-project-charter

1. Review the problem statement on your charter
2. Review the data from the Measure step of the DMAIC method to get clues about the specifics (i.e., who, what, when, where, which) of the problem you are addressing
3. Complete a worksheet using the questions provided to develop a Focused Problem Statement. There are no rules that tell you when a problem is focused enough. Trying to develop a Focused Problem Statement is a balancing act. You want to have enough focus so that it is easy to identify causes and take effective action, but you don’t want to spend so much time, effort, and money on this step that you never get around to taking action! At some point, therefore, you have to decide whether the cost of getting more data and more focus is worth the investment.

Charter Negotiation

The project charter can be created and presented to the team by upper management. However, the project team might be closer to the actual facts and might propose a different mode of attack than envisioned by management. Hence, charter negotiation may be required.

Consider the following examples:

1. Objectives: The final customer product or internal process may require a substantial redesign that was not envisioned.
2. Scope: The boundaries of the project could require expansion. The project may be sufficiently large to require dividing into more manageable pieces. This could I require two or three projects in succession by a single team or additional project teams working on a portion of the original project.
3. Boundaries: The project team may discover that additional areas (engineering, maintenance, finishing, etc.) should be included in the solution.
4.  Resources: Excessive project resources are rarely provided. Generally, an oversight of some key resource components is encountered. These needed resources can be internal or external to a company. Management may be called upon to prioritize certain fixed resources outside of the team’s control.
5. Project transition: The transition of a project to normal company controls may necessitate either a time extension or additional monitoring on the part of another group. This may or may not require lengthier team involvement.
6.  Project closure: The improvement team could discover that related processes or products need the same type of effort as that which was undertaken for the initial project. In some cases, the project closure date might be moved up because of such diverse events as unexpected success or shifts in customer preference.

Obviously, both the project team and upper management are interested in success, not failure. There should be a willingness on the part of both parties to negotiate a number of project details. Generally, it is best to handle charter negotiations at the start of a project. However, all pertinent information may not be apparent at this point. Charter negotiations can be required at any point during the project.