One of the first things I’ve done for as long as I can recall is write up extensive plans related to projects that clients have required over the years.

In this blog, I share a bit of the project planning methodology and some of the tools that I use.

Whether you are a prospect considering using us or a consultant or freelancer who wants to learn from past success I’ve experienced with developing plans, this blog is for you.


Why do you need a plan?

It’s easy to jump into a project, roll up your sleeves and start getting to the nitty gritty. This can be efficient alot of times because you might be able to knock out half the job faster than you could write up the plan. There’s one thing that should always be present, no matter how small or big the task, or set of tasks ahead might be: You need a scope of work – this is a definition of what you are going to do.


A Scope of work or “SOW” should establish what the agreed upon end result should be, and what constraints are being put on the job. It can be something quite simple, or have many pages of complexities written to it, but in any case – whenever something is begun, establishing a clear scope of work is critical.


Typically the project plan will contain the scope, however it usually has additional details that go beyond that.


What is a project plan?

The aims of a typical plan involves a few components.


First, my plans start off by describing the customer a little bit so that we can establish who we are working with, and what they do. I write this out in my own words because it lets the client see how I perceive and understand their business model, structure and purpose.


To understand the client however can take some discovery and research. I like to ask probing questions about the company to get a detailed grasp of nuances in the client’s business model so that I can best describe their organization.


Project Plan Interview Questions

Next I always ask a series of questions.

The first series relates to understanding how the client is thinking – philosophical points of views that a client has are critical for me to understand so that I can present a solution that fits within the framework of their way of thinking.

What do you need to accomplish?

Here we talk about what they want to do. We specifically avoid talking about subjects from the next 2 questions and we focus this content to the end-result of what impact this project is going to have on their company if it can be successfully implemented.

What are you using to do this today?

Next we discuss any systems, processes or methods in place today which we might be replacing. This may be an existing business structure or system or anything that’s performing a similar or alternative function within the organization. Sometimes there is nothing previously in place and if so, we identify and state that.

Why do you need to do this?

Finally, we get into what underlying pain might be prompting them to want to implement the project. It doesn’t always have to be about pain, but I leverage a specific methodology known as “pain chain management” which generally states that every business decision is driven by some kind of pain. If you can get to the root of the pain, then you can solve it. At this stage in the document we aren’t as worried about establishing the root pain as we are concerned with understanding why the client thinks they need to do this. The perspective of the client may be focused on one thing, while the pain might be centered around another. It’s our job to identify this and remedy it, but we can’t do that if we don’t understand the clients own point of view for what is driving the decision to need to seek this project out.

The issues you Face

Here we go through everything blocking us or that is perceived to be creating any kind of challenge or problem for the organization. What problems and challenges does the overall situation create and what blocks or issues will we face with any solution we might want to implement?

What is your pain?

Having previously laid out what we are doing, why we are doing it, and the problems we are having because it’s not done plus any other issues we know of, now we can dive deeper into the pain if necessary and specify the root cause.


Project Plan Solution Statements

The document takes a bit of a turn here and pivots to discussion of what we are going to do about it. The previous questions are generally part of an intake discussion that we have and in many cases help us qualify the lead specifically to determine if we can help.


Solutions that Define Success

Now that we know who we are working with, what issues they are having and what they want to do about it all, we can start to specify a plan for it.

What will it take to solve the problem?

Specific initiatives are laid out and explained in detail. This section can be either extremely customized, or instantly populated with common solutions from pre-written content, it depends entirely on you. The more proposals you write, the more content you can accrue which can come in handy later to quickly generate proposals based on commonly implemented solutions.

Many times however, the project is quite custom in nature and so it may be necessary to follow a “functional spec” document approach. The purpose of this would be to define specifically what something is to do but it does not get into the technical details of how it will specifically do it.

The main focus on this section should be the “what” part of the question.

How will this solve the problem?

With an understanding of a solution that can be approached, we now can delve into what impact this will have. Here we might use a funnel graph or build some work flow diagrams. We might state how KPI’s will be impacted once the project is completed or explain how we will meet specific standards and goals that had been previously laid out.

We generally don’t need to explain in detail how our solution will be implemented, just what it will do, and what the outcome of implementing it will be.

What are the alternatives including comparisons and trade offs?

Depending on how detailed things need to be, we can dive into alternative proposals now. Sometimes presenting multiple solutions can help provide the client options without requiring them to get additional proposals from other companies. This can make a huge difference in close ratios but designing multiple plans can also be very time consuming and cumbersome. Consider presenting the best plan and focusing on it, but it’s common to also include Low, Mid-Range and High End plans. Typically a mid-range solution is almost always presented and preferred but there’s often cost-saving measures that another plan could implement, or a “cadillac” plan that could be recommended which may be preferred by some organizations.


Project Milestones & Tasks

With a plan defined we should be able to spec a list of milestones and then subtasks for those milestones. Typically this is a table or it can be presented in a Gannt chart.

The man hours or expense calculations are typically stated here. Good projects usually have the labour well defined against the scope of work. Where trouble happens is when “scope creep” occurs where something should be defined as a “change order”. This is a tricky part of project management because the statements in the scope of work should be justification for implementing change orders but if the scope of work is not well defined or is extremely broad, it can be open to interpretation by both parties. Ultimately how well you both can come to agree on the terms then becomes the deciding factor about what is in and what is out of scope.


Executive Summary

The final section of the project plan explains what we talked about, why the client would want to do any of it, and any other personal notes or out takes on the project. Typically it’s the open letter to the executive that finalizes the case for or against doing any of this and any other details regarding expectations.

End the summary thanking the executive for reviewing the proposal and leave them with a call to action.

The final line can be similar to or the same as your email signature.

Formatting the Document

I think it’s very important to present a nicely formatted project planning document. You want your document to set your organization apart, but there’s also some elements that you should implement because they are standard and expected.


The Cover Page

I like to make a unique cover page for my clients proposals that includes their own logo featured prominently in the center, and formatted essentially like this:


[Client Logo]

Project Title

Written by: Preparers Name



[Consultants Logo]

Consultants Company Name and Contact info


Next I have a Table of Contents Page. I always use document formatting and set the paragraph type in my documents as I build them so that my table of contents is built and updated 100% automatically. If you don’t know how to automatically populate a table of contents in your documents, that’s worth learning.


Typically I have a company proposal template pre-fabricated with these settings, and a header that is different from that on the front page. In my document header I often simply use a dividing line like such –


And on my footer, I often use a format along these lines –


Page x of y

You can certainly add more stuff to these if you want but it’s easy to make them too busy.

Document Sections

For the rest of the document, I usually lay it out in the following sections:


  • Overview
  • The Issues You Face
  • Solutions That Define Success
  • Pricing
  • Executive Summary
  • Contract


It is often necessary to execute a contract with a client, so appending to the end of a proposal is a common item to include. It’s typical to already have these pre-written and built on generic boilerplate but that’s not always possible.

Tools for Writing Proposals

While you can use Google Docs or Microsoft Word to build all your proposals quite nicely, I do recommend using a proposal management platform to help you build and deliver a next level experience. Upwork has a good system for managing proposals, milestones and tasks but there are some stand alone platforms that work great as well. My favorite among them is Proposify.


Who you wrote proposals to is typically managed by your CRM but your 3rd party proposal management platform can also help you out greatly here. The reason I like Proposify has to do with how quickly I can generate awesome proposals by dragging and dropping pre-fab content in and the fact I can see rich analytics regarding how frequently which proposals are viewed, or see when a client is looking at them. I can also automate billing and e-signatures with these platforms.