Demystifying Project Management: Marching Orders

DEMYSTIFYING PROJECT MANAGEMENT:

Step 1. Capture Your Marching Orders

PMI Talent Triangle: Technical

What Does Your Customer Need?

Projects exist because somebody, somewhere, needs something badly enough to pay for it. What exactly does the customer need? This is often described as a needs analysis, problem statement, outcomes identification, or something similar. But whatever you call it, answering this question is the crucial first step in establishing your project marching orders and planning a successful project. Unfortunately, it is also an often-overlooked first step. 

So many project managers want to get straight to defining deliverables and developing schedules. Don’t! Stop!!! Your first step MUST be to get inside your customer’s head and look at the project from their perspective. Ask yourself, who is the customer and who is the user? What problem are they trying to solve? What benefit will they receive when the project is finished?

The customer and the user are often not the same. One example is when the Army buys a weapon for its soldiers. The Army Materiel Command (AMC) is responsible for buying things for soldiers. Their motto is, “If a Soldier shoots it, drives it, flies it, wears it, communicates with it, or eats it – AMC provides it.” So, if my project is to design a new rifle for the Army, I must satisfy both the AMC procurement rules and the soldiers who use it. If I don’t satisfy both, I’ll never make a sale. I can breeze through the AMC procurement process, but if the soldiers don’t like it, the project is a failure. Or, if the soldiers love it but I don’t jump through the hoops required by AMC, the soldiers will never get any of my rifles and, again, the project is a failure. 

My favorite example of distinguishing the customer from the user on a project is a knee replacement. There are four main stakeholders in the transaction: the doctor, the patient, the insurance company, and the knee replacement manufacturer. Who is the customer and who is the seller? Think about it before you read on for the answer…

Most people say that the patient is the customer and the doctor is the seller. But the customer, the party who is paying for the project, is the insurance company. The seller is the knee replacement company, who manufactures and guarantees the product. The patient is the user and the doctor is an influencer, in that the patient usually agrees to except the brand of knee the doctor recommends, and the doctor is also an installer and maintainer. Understanding these dynamics can be important to creating a successful project outcome. 

Always consider who is buying and who is using. Also consider what problem they are facing and what a satisfactory outcome means to them. Once you conduct this needs analysis and understand what is driving the project and what a successful outcome means to them, only then can you successfully establish your marching orders for a project.

Another perspective on the value of the needs analysis is that many project managers take on a project with a narrow focus on deliverables, schedule, and budget. But this is missing the forest for the trees. WHY are these your deliverables? Who is going to benefit from your project? What benefits are they expecting? Without a good understanding of your customers and stakeholders, a PM might execute a project perfectly, but still be considered a failure if the original intent is not met.

Why Bother with Marching Orders?

Marching orders are the formal guidelines that shape a project. It answers the questions:

• What does the customer need?
• Who are the participants in the project?
• What will I deliver to the customer at the end of the project?
• What kind of timeframe do I have to work with?
• What is the expected budget?
• What are the risks?

For those of you familiar with the Project Management Institute (PMI) professional society and its Project Management Body of Knowledge (PMBOK), this exercise to establish your marching orders is equivalent to the “Develop Project Charter” process 4.1. I have found that using the phrase “Establish Your Marching Orders” is intuitively easier to understand for most people than “Develop Project Charter”. In terms of value and importance, the PMBOK defines the Project Charter as “…a document that formally authorizes the existence of the project and provides the project manager with the authority to apply organizational resources to project activities.” 

While this is certainly true, and many companies use project charters extensively for exactly this reason, I like to think of the project charter as “marching orders” that clarify the customer’s need and clearly identifies the project deliverables that will satisfy that need. The marching orders also capture any assumptions about schedule and budget and any risks the Team is aware of up-front. Having the customer and the project manager sign the marching orders helps everyone have the same expectations for the project.

How Do You Create a Set of Marching Orders?

Below is the template I have developed for my projects and my students.

Let’s work a hypothetical example to practice filling out the marching orders. The steps below lead to the example set of marching orders at the end of this section.

Imagine you are developing a new electric bicycle prototype for your company as a candidate for the Christmas product line. Your boss wants to see a prototype of the bicycle and the training/maintenance manual. Your boss asks you to draft up a set of marching orders for this project that he can sign. So you proceed as follows:

Needs Analysis

The needs analysis captures the fact that this project has been initiated by the WeBeBicycles Vice President for New Product Development to break into the electric bicycle market. The goal is to have a prototype built, tested and approved in time to ramp up manufacturing for the Christmas shopping season. This is documented in the “Needs Analysis” section of the marching orders. 

Main Project Participants

The reason for identifying the main participants is to make sure all the important stakeholders are considered and consulted during project planning and execution. The way I like to go about it is to consider

• Up
• Down
• Over

Up is the customer, the user and others who will benefit from the project. These are the people you need to satisfy in order for your project to be considered successful. Down is the people who will be supporting you in actually doing the work on the project. They must be involved in planning to make sure the project plan is realistic and achievable. Over would be others who have worked on similar projects that you can turn to for advice when you need it. Putting this list together helps you think through who you need to keep updated on project progress (up), who will be doing the actual work on the project (down) and who to turn to for problem-solving advice (over). Don't overthink it, just make sure all the important players have a voice on the project. See the electric bicycle example at the end of this blog for an idea of who might be the key players on this project.

Deliverables & Acceptance

Now that you have a good understanding of your customer’s need and have identified all the key players, list the main things you will be delivering to the customer at the end of the project. There is usually the main item, like a bicycle or go-cart, (often called the "Prime Mission Product") but often there other things like packaging for that item, instructions for use or maintenance, training, spare parts, and so on. List all of them. In this case we have only 2: the electric bicycle prototype and the Training/Maintenance manual. 

The project will be considered complete when it has been accepted by the VP of New Product Development. The VP will accept it after: 1) the WeBeBicycles product test team has tested the bicycle enough to make sure the product is durable and user-friendly and, 2) that the data management team has verified the Training/Maintenance manual is well-written and useful. 

Schedule Milestones

The deadline you have to meet on this project is to make sure the product test team gets the product prototype and the manual in time to conduct its assessment. Additionally, the manufacturing team needs enough time to set up the assembly line for the bicycle. Standard policy at WeBeBicycles is for this hand-off to happen on or before June 1 in order to make a product available for the Christmas buying season. However, when talking with Norman Newton, the project manager for a previous company project to develop an electric scooter, he tells you he had trouble with the electric drive system you will be using. The electric drive system was not robust enough in the scooter prototype to pass the product test team standards.  The product was therefore late to market and senior management was not happy. If that electric drive problem causes trouble on the bicycle project, the June 1 deadline will be missed and you will also face the wrath of an unhappy senior management team, so you capture this potential issue in your marching orders as well. 

Expected Budget and Resources

Technically, a project budget is not assembled until the deliverables are well defined and the action plan (schedule) has been created. But customers always have a price tag in mind when they kick off the project. Based on your conversations with Mr. Newton you know it cost $150,000 to develop the electric scooter but with lessons learned from the scooter project, you believe that you can build the electric bicycle for $100,000. When you discuss this with your engineering team, you are reminded that the electric drive system is a big wild card. The engineers estimate that adapting the drive system could add another $25,000 to the price tag. Again, you capture all this in the marching orders below. 

Why the Project Might Run into Trouble

Before you give the marching orders to your boss, you gather your team together and ask them if there is anything they are concerned about that might cause problems down the road. One young engineer speaks up and points out that in order for the electric bicycle to have a usable range of 20 miles, a target the team has been given, the battery pack might be too large to be practical. You add that to the marching orders as a reason why the project might run into trouble, commonly known as a risk.

In conclusion, a set of marching orders like this is very simple and doesn't take much time to put together.  But you will be glad you have it later in the project when people begin to question the goals and motivations for your project or your progress.  This is often the case when senior management experiences turnover and the people you worked with to create the project are gone and the new senior management team has a different perspective on the business mission.  It also helps when you take over an existing project and need to understand the mind-set behind the project, especially if it is a troubled project.  Remember, don't go straight for the deliverables, budget, and schedule - establish your marching orders first!

Dr. Bill Carswell, PMP

Director of Programs

7-Step Project Manager

Please use the comments feedback area below to let us know your thoughts. How do you capture your customer's needs and the problems they are trying to solve? Is there anything else you try to capture when getting a project off the ground? 7stepPM readers want to know!

After you have spent 15 minutes reading this blog and participating in the discussion forum below, don’t forget to fill out the Pennies for PDUs form to get your certificate of PDU credit.