Another Quality Post

Testcropped-img_0048.jpg

Project Charter – Building the Team

The Project Charter is a document that comes highly recommended. It is prepared once you have decided that this is a project that needs to be executed before all the other projects that are on deck. After all, there are many challenges confronting your organization. You need a way to evaluate and compare the projects being proposed. Having your people prepare and then present a project charter assures consistency in format. It makes certain that the project leader has thought through the assumptions and that the questions you want answered have been.

I am assuming you have a project management process, with projects being approved by a board, usually composed of company executives.

Let’s begin by listing the elements of the project charter.

Header
Description
Scope
Objectives
Return on Investment
Risk Analysis
Team Roster
Milestones
Authorization

In the previous post, we looked at identifying the risks in our project. One extreme is to plunge ahead regardless of the warning signs. The other is to not leave the starting line at all. The latter course guarantees you will be left behind by the competition and the former is certain to end up in a train wreck. Neither are good places to be, so, a common sense approach for analyzing and mitigating risk is necessary.

In this post, we are going to discuss how to build an effective team. The team members will be listed on the team roster of the Project Charter. You will identify the team members by name and define what their roles will be. These are the people to whom you will assign the project’s tasks.

F.E. Warren Crow Creek Challenge 2013

Roles

Project Sponsor
The Project Sponsor is a member of management. They attend the opening team meeting when the project is rolled out and the closing meeting when the results are certified and project presentation is prepared. In between those two events, the primary purpose of the Sponsor is to remove obstacles that prevent the team from achieving their objective on time and within budget. An example is when two teams need the coding department at the same time to develop an application. The sponsor’s job is to coordinate with the sponsor of the other team and eliminate the resource conflict. They might decide to have the coders work overtime, send one of the jobs to an outside company or adjust one of the team’s timelines to account for the delay. The point being that the teams are not losing focus or falling behind by having to fight each other over resources.

Project Leader
The Project Leader leads the project and as such bears responsibility for the results. The leader needs to know how to:
+ Build the project plan. We covered this in a previous post entitled Project Planning – a Very Basic Primer.
+ Execute the plan. This means keeping the project on schedule, on budget and meeting the project objectives.
+ Keep the team focused and moving forward.

Process Owner
The Process Owner is the person who is accountable for the area of the business that is being improved by your project. It is not unusual for the process owner to feel threatened. They may be thinking that they should have come up with this idea or, they may be thinking that things are fine the way they are. In either case, they will resist the changes. Securing the cooperation of the process owner is key to a successful project and the key to cooperation is solid, up-front communication.

Subject Matter Expert (SME)
The SME has expertise in the area of the business you will be changing. For example, if you are implementing a new ERP system, you will need someone who is an expert in that area to assist you. Often, the SME will be a consultant who will be brought in to get the system up and running and provide operational documentation and training.

Stakeholders
While stakeholders aren’t actually members of the project team, they are often consulted about potential changes which may affect them. Again, securing their cooperation can spell the difference between an organized resistance or smooth sailing.

Other Members
Examples of other team members are:
+ Members who can provide ground-level insight into the current system and generate ideas about how to improve it
+ Purchasing to assist in procuring new equipment at the best possible price
+ Engineers to help set it up
+ Maintenance to install it
+ Members to help write new work instructions and provide training

The team will define the current system, figure out how to improve it, implement the changes and confirm their effectiveness. As such, the leader who doesn’t use their soft skills to keep them on track may find themselves driving a bunch of disengaged individuals with nothing but time on their hands. More often than not, the problem is that the leader has not successfully communicated his or her vision to them or the members aren’t confident in their leadership.

There is a great deal more we could say about how to recruit team members and obtain the optimal performance from them, however, two excellent references are:
The Team Handbook published by Oriel Incorporated
The Memory Jogger published by GOAL/QPC

 I hope you have benefitted as much from reading this post as I have by writing it. As always, I crave your comments.

In the next post, we will look at identifying the major waypoints of the project plan; the Project Milestones.

© Copyright 2016 by Marc W. Richardson

The Project Charter – Return on Investment

The Project Charter is a document that comes highly recommended. It is prepared once you have decided that this is a project that truly needs to be executed now. After all, there are many challenges confronting your organization. You need a way to evaluate and compare the projects being proposed. Having your people prepare and then present a project charter like this one assures consistency in format. It makes certain that the project leader has thought through the assumptions and that the questions you want answered will be.

I am assuming you have a project management process, with projects being approved or not by a board, usually composed of company executives.

Let’s begin by listing the elements of the project charter.

Header
Description
Scope
Objectives
Return on Investment
Risk Analysis
Team Roster
Milestones
Authorization

In the previous post, we discussed that by setting the project objective, we have half of the ROI calculation. It is when you determined the expected benefit of your project.

In this post, we are going to discuss return on investment or, ROI. In all probability, your company will already have a method of determining ROI so we won’t focus on formulas. Of course, the return may be difficult to measure in dollars. That doesn’t mean it isn’t a worthy project. An example is a current project to reduce manufacturing lead time. It will almost certainly result in increased sales, but by how much is anyone’s guess.

Old_Calculator

One method of calculating the ROI is to subtract the Investment from the annualized Return and divide the result by the Investment, yielding a ratio.

(Return ($50,000) – Investment ($10,000)) / Investment ($10,000) = 4

The return is the amount of money you expect the improved process to generate. The period over which the return is calculated should be annualized. That way when you are comparing the ROI’s of different projects, you are comparing apples to apples.

The investment is the sum of all the costs associated with making the improvement.

Many people subdivide the investment costs into categories such as:

> Operating costs: the cost of running the business
> Labor: the cost of direct labor, fully burdened including benefits
> Assets: The cost of the capital equipment including transportation
> SG&A: Selling, General and administrative expenses. These include salaries, commissions and travel expenses, advertising costs and payroll expenses
> Material: The cost of materials and subcontracted services processed into finished goods for sale to customers

Your company will may have a policy governing what an acceptable ratio is.

Another method of determining whether the investment is worthwhile is to calculate how long it will take to pay back the loan for that new sales contact tracking software you purchased. “A loan?” you say? Yes, the investment is, in effect, a loan. And just like the bank, your company intends to realize a return on that investment.

This is computed by dividing how much money it will take to make the improvement by how much the improvement will save monthly. An example may suffice:

Expected Investment: $10,000                               Actual: $10,895
Expected monthly increase in revenue: $1,000      Actual: $895
Expected Number of months pay back: 10             Actual: 12.2

Again, the company may have rules regarding how long of a payback period is acceptable.

Accurately calculating the return on investment is crucial to making sound decisions regarding whether a project should be executed at all and if it is, its place in the line-up. Underestimating the return may result in missing the more profitable opportunity. Overestimating may result in a negative impact on the company’s cash flow.

Hopefully you have benefitted as much from reading this post as I have from writing it. As always, I crave your comments and questions.

In the next post, we will discuss the analysis of risk.

Project Charter – Objective

The Project Charter is a document that comes highly recommended. It is prepared once you have decided that this is a project that truly needs to be undertaken now. After all, there are many challenges confronting your organization. You need a way to evaluate all the projects being proposed. Having your people prepare and then present a project charter like this one assures consistency in format. It makes certain that the project leader has given it a lot of thought and that the questions you want answered will be.

I am assuming you have a project management process, with projects being approved or rejected by a board, usually composed of company executives.

Let’s begin by listing the elements of the project charter.

Header
Description
Scope
Objectives
Return on Investment
Risk Analysis
Team Roster
Milestones
Authorization

In the previous post, we discussed the project scope and how the primary purpose of the scope is to guard against scope creep and keep your team focused on finding solutions for the matter at hand.

In this post, we are going to discuss the Project Objective. Immediately, the question will be asked: “Can a project have more than one objective?” In a previous post, I advocated for identifying the Critical Intent of the project. The Critical Intent will drive the primary objective. Other objectives are usually correlates of the primary objective. Progress towards the primary objective is measured by the Key Metric. So we have the Critical Intent, the Primary Objective and the Key Metric.

The methodology we will employ to develop the project objective is well-known. It goes by the acronym SMART, meaning that the objective needs to be
Specific
Measurable
Achievable
Relevant
Time Bound

See the graphic below for an explanation of the SMART objective elements and an example.

SMART Objectives R02

Build the elements of the SMART objective and then construct the really-clumsy but packed-full-of-useful-information Project Objective Statement

Specific
The objective must be specific. It should answer the questions:
What will be achieved?
Within what scope?
If there are any qualifications, anything that you will not do to achieve the objective, it should be stated here.

Measurable
The objective must be measurable and stated in concrete terms. It needs to contain numbers. It is not enough to say you are going to increase profitability, you need to state by how much. This is the specific benefit that will be achieved. It tells you when the project is done. It should answer the questions:
What is the metric now?
What will it be at the end of this project?
By how much will the metric be improved?

Achievable
The objective must be achievable. This calls for more than a simple “Yes.” You need to “do the math” and show that the objective is attainable within the constraints of limited resources such time, money, and the number of people you have.

Relevant
The objective and by extension, the project must be relevant. There are many challenges facing your company. Many things are broken and need to be fixed or replaced. Many things are showing their age and need to be updated or upgraded. You have finite resources. Why does this project need to be undertaken ahead of all the others in the queue?

Time-bound
When does this project need to be completed? And what does completed mean:
When all the tasks listed in the project plan are done?
When all the deliverables have been delivered?
When the projected benefits have been realized?

Adequately defining the project objective is half of the ROI calculation. This is where you determine the expected benefit. If you overestimate how much money this will make your company, the investment may not be worth it. Hopefully you have benefitted as much from reading this post as I have from writing it. As always, I crave your comments and questions.

In the next post, we will calculate the Return on Investment.

Project Charter – Description

The Project Charter is a document that comes highly recommended. It is prepared once you have decided that this is a project that truly needs to be undertaken now. After all, there are many challenges confronting your organization. You need a way to evaluate all the projects being proposed. Having your people prepare and then present a project charter like this one assures consistency in format. It makes certain that the project leader has given it a lot of thought and that the questions you want answered will be.

I am assuming you have a project management process, with projects being approved or denied by a board, usually composed of company executives. The list below contains the elements of a project charter:

Header
Description
Scope
Objectives
Return on Investment
Risk Analysis
Team Roster
Milestones
Authorization

In the previous post, we considered the project charter header. Let us now advance to the description.

In the description, we are going to answer two questions:

What is the challenge?
What is the opportunity?

What is the Challenge?

There are two types of challenges and two decisions that can be made:

  1. Something is broken and we need to fix it
  2. Nothing is broken but we need to improve it

It is good to clarify what type of challenge you have before you build an entire project around it. It will help to determine its urgency.

In this case, we will assume that nothing is broken but we need to improve the process. Here is an example of a challenge statement:

Our core business is to provide add-ins that help our customer’s analyze data in their MRP systems, such as inventory aging, capacity requirements and customer ordering trends. While our competitors aren’t beating us to market yet, they are catching up to us. It takes us six months to bring a new product to market. One year ago it took them ten. Now it only takes eight months. We can’t afford to wait.

So why is this a good description of the challenge? It answers these questions: who, what, when, where and why. At this point, when we ask why, we are asking why this project needs to be undertaken now.  Answering the other why, “Why is this happening, what is the cause?” is part of defining the current state. It is usually unknown when the charter is being prepared. The how questions quantify the challenge and its effects: how much, how long and how often.

-Who is being challenged? We are.
-What is the challenge? Competition is reducing their time to market more rapidly than we are.
-When does this challenge occur? It is occurring now.
-Where does this challenge occur? In the product development segment of our business.
-Why is it important to solve this now? Experience has taught us that once we lose market share, it is extremely difficult to get it back; it is better to stay ahead.
-How much will it cost when it does occur? Lost sales.
-How long has it been occurring? It has been developing over two years.
-How often does this problem occur? They are continually reducing their time to market.

Defining the challenge in this way will save you time when you perform root cause analysis. This because a thorough description will point you in the right direction.  The more specific you can be the better. The object of the problem definition is to explain why this problem needs to be solved now.

What is the opportunity?

In describing the opportunity, we want to show the benefits that will be achieved by executing the project. This is not the place for a detailed financial analysis. We will prepare a ROI later. The intention is to state how the project will directly improve the situation:

The opportunity is to reduce our time to market. In six months I want us to reduce our time to market from six to five months and one year from now I want it to take four months.

This is an unambiguous and concise statement of the desired outcome.

So to summarize, the description enables us to state the challenge and the opportunity in simple terms so that it is clear to the decision makers exactly where this project will take us.

In our next post, we will discuss how to scope your project.

Project Charter – Scope

The Project Charter is a document that comes highly recommended. It is prepared once you have decided that this is a project that truly needs to be undertaken now. After all, there are many challenges confronting your organization. You need a way to evaluate all the projects being proposed. Having your people prepare and then present a project charter like this one assures consistency in format. It makes certain that the project leader has given it a lot of thought and that the questions you want answered will be.

I am assuming you have a project management process, with projects being approved or rejected by a board, usually composed of company executives.

Let’s begin by listing the elements of the project charter.

Project Charter Elements:

Header
Description
Scope
Objectives
Return on Investment
Risk Analysis
Team Roster
Milestones
Authorization

In a previous post, we discussed the project description and how it is good to clarify what type of challenge you are up against and the rewards to be gained before you build an entire project around it.

Today, we will consider the Project Scope

The primary purpose of the scope is to guard against scope creep; the tendency that project teams have of trying to solve every issue they encounter up to and including world hunger. In order to do this, you must define what the scope is and also what the scope is not. Things that are in scope are what you are going to change during the project and things that are out of scope are what you are going to let alone. The latter may be changed indirectly as a result of the actions you take, but that isn’t your intention. Evaluating how things outside of the scope of your project may be effected is reserved for risk analysis, which will be covered in a future post.

Picture a pasture full of milking cows surrounded by a fence. The objective of your project is to increase the amount of milk that the herd produces and thereby increase revenue. The cows, the grass, the water supply are within the fence, they are in scope. The little stream that runs through the pasture also runs under the fence through a culvert that empties into a river that runs along the southern edge of the farm. You decide to spread fertilizer on the field to make the grass grow faster so that the cows will have more to eat and boost milk production. So far so good, but let’s remember what’s outside of the fence. The little stream is going to carry the runoff from the field beyond the borders of your farm, effecting everyone downstream. Also, cows eating more grass will produce something besides more milk. That will also find its way into the river.

This what the scope looks like.

Untitled drawing

Who Is/ Is Not
Who is targeted for change? Who is not? Who will benefit from the change? Who will not? Who are generally people. In our example, who is the cows.

What Is/Is Not
What will be changed? What will not? The what to be changed is the reason for the project. Examples are processes, equipment, software systems, methods. Scoping the what is particularly important. You want to exclude from the scope the steps in the process that are immediately before and after the step to be changed. So, in the three step process, measure, cut and assemble, you decide to reduce the scrap produced during the cut operation. Measuring and assembling would be out of scope.
“But,” you say, “What if we discover that a method in the measurement process has a direct impact on reducing the scrap in cutting process?” If it directly impacts the thing to be changed, it is in the scope.
An example of what would be considered out of scope would be difficulty in assembling the cut pieces for reasons not related to the cut operation. The temptation is to go ahead and fix it but in the long run, it’s best to park it in the parking lot and save it for another project. 

When Is/Is Not
When will the work be performed? When will it be completed? When is the time frame within which the project will take place.

Where Is/Is Not
Where will the work be done? Where is the thing to be changed? This can be a facility, a country, a spot within a plant. Generally, where is a physical location. You can have two cow pastures on the same farm but in the scope, you clarify only the northern pasture will be effected.

Scope creep is a very common cause of project failure. As the project progresses, the team encounters issues other than the one they originally intended to solve. A laser-like focus on the scope will go a long way towards ensuring the success of your project.

In the next post, we will consider how to define the project’s objective.

Lean – Some Pro’s and Con’s

image19

This is a big topic. Neither list is exhaustive.

Let’s start with some pro’s:
– Lean develops a mentality which identifies waste and eliminates it
– It encourages bias towards action: comprehensive analysis not required or even desirable
– It encourages a bias towards getting in and out in 5 days or less
– Change is viewed as incremental as opposed to looking for big breakthroughs
Some con’s:
– It breeds a dogmatic mentality that is intolerant of people’s genuine concerns
– It encourages making changes before analyzing the risks involved
– It does not encourage understanding the process within which the operation to be improved operates. This very often leads to sub-optimization; showing the gain in the operation targeted for improvement but actually moving it to another upstream or downstream process.
This is where the differentiating between Point, Line, Plane and Cube lean is helpful.