Essential Elements of an MSP Project Proposal

It was a dark and dreary night... well actually, it was a question raised in an online discussion that resulted in what I hope will be a helpful guide for anyone faced with writing an MSP proposal.

Introduction

My name is Matt Topper and I'm the Director, Security at Gradient MSP.

I have spent over a decade wearing multiple hats at an MSP that grew from small to large; one of my responsibilities, in addition to my security role, was to run the Professional Services department, starting from zero.

Learning to prepare proposals that consistently close and prevent the implementation team from running into unpleasant surprises along the way is something I had to perfect through trial and error. The ideas presented here are ones that were implemented successfully. My intention is to help provide a roadmap for other organizations so that they do not need to start from zero.

Writing proposals for MSP projects is tough. What makes it worse is the mountain of nebulous advice that comes your way, without any concrete examples to guide you.

The format described here is time-consuming, but it is crucial to note that the planning is as important as the outcome and will save you time in the long run.

In other words, the thought required to complete all sections inherently requires proper planning. When potential roadblocks or headaches come up during the initial discussion or planning phase, the need for change orders or scope creep reduces dramatically – in fact, by taking great care in the planning stage, change orders almost never pop up.

Statement of Work Section

When writing a Statement of Work (SOW), the number one objective is to remove ambiguity. There shouldn't be any open questions as you move forward. Questions such as, "is this part of the project?" or "when do we close this?". If there is doubt or hesitation, you missed something.

Summary (or Introduction)

The purpose of this section is to explain the background information that led to the project and provide a high-level explanation of your proposed actions.

Only a few sentences are needed here. This section should also explain why this solution is being proposed over others.

If there are other obvious solutions, here is where you explain why this particular one is being proposed over and above any others. For example, if the suggestion is for a cloud migration, briefly explain the benefits of that vs. a replacement physical server.

Example:

This project is a migration from the existing on-prem Exchange server to hosted Microsoft 365.  25 mailboxes on one domain will be migrated. There is one application that sends email and two copiers that scan email. This was suggested over a server replacement due to the organization's overall migration towards SaaS services.

Scope

This section is where you’ll find the meat of the proposal. It explains what is going to happen and in what order. It’s best to do this as an outline with each outermost item representing a phase.

The level of granularity should roughly map an item to an individual step or ticket in a project. For example, if setting up a new server, something like "provision virtual machine", "install operating system", etc., would be sufficient. You don't want to go more granular than that.

When working with very specific items within a collection, list each item by name. For example, itemize the applications you are moving during a server migration or specific file shares that are being migrated. This is something of a judgment call – there is no need to list each individual mailbox during a Microsoft 365 migration if you are moving every mailbox.

Your project templates will be more granular. For example, in your own documentation system, there would be a guide on how to install Windows, including required configurations. But you don't need steps like "input activation key" in your SOW.

Example:

1. Initial setup
   1. Assemble server
   2. Install and configure the hypervisor
   3. Physical server delivery and network setup
2. File server migration
   1. Create a virtual machine and install Windows
   2. Pre-stage file shares for migration
   3. Cutover

Out of Scope

This section should be a list of items that the MSP specifically isn't performing as part of the project.

This is all about setting expectations and ensuring that there are no surprises. To generate these, ask yourself, "what are things that a client might expect to happen that we haven't included in the estimated labor?" These might change during the discussion with the client before the proposal is signed.

Remember, the goal is to remove ambiguity so that everyone is clear. Items can always be added later, with a corresponding adjustment in the labor estimate, or a change order if the project has already started.

Finally, note that the last statement includes a catchall of anything that is not listed in the scope as being out of scope. While this technically makes listing the specific items redundant, this section limits surprises by listing items that a client might consider to be in-scope that are not accounted for in labor charges. I have never pointed to this last item during a billing dispute; it's there for expectation setting only.

Examples:

• Any configuration changes or repairs necessary to gain access to the existing equipment.
• Any training on new application versions.
• Development work such as configuring custom Excel functions or SharePoint site design.
• Migration of application XYZ, which is no longer used. This application will no longer be available for archive data after this project.
• Any item not explicitly listed in the scope section above is considered out of scope.

Assumptions

This is a list of conditions that must be true for the labor estimate to hold. In other words, if something in this list turns out to be not true, expect a mid-project change order.

This section is often the longest, with the exception of the scope, and it's where you can avoid most project landmines. Below are example scenarios where an assumption will help you in the long run. [these actually happened]:

• Sufficient UPS outlets are free for new server power supplies
• All mailboxes are 50 GB or below [for migrations to Business Premium]
• All copiers in the scope support TLS 1.2 [for scan to email]

Client Responsibilities

Is the client handling any part of the migration themselves? This refers to anything that the client needs to do that you aren't managing (or billing for) as part of the project.

It doesn't automatically translate into "things the client is doing to cut the project cost down", though if you have any of those, here is where you’ll put them. It’s more about what actions the client needs to take to ensure a successful outcome.

Anything in this section can also go into the assumptions section but separating them out and placing them here improves project clarity. It would cover items such as:

• Accept professional services quote from ERP vendor to migrate data
• Purchase an upgraded version of the software that doesn't allow resellers
• Have an electrician install an L5-30P outlet for UPS [In practice, you'll talk to the electrician yourself. (Do yourself a favor and just give him the UPS datasheet.) This assumption is pointing out that you are not subcontracting the electrical work].

Note about vendor professional services: There is a difference of opinion on whether to resell vendor services for migrations. Taking care of the coordination and packing everything up into one quote is good for the client. However, a vendor's poor support becomes a reflection of you and your company when you resell it. Whether you do this depends on the client and the vendor.

Vendor Support Summary

This section falls into two categories and describes vendor-specific requirements:

1. Tasks that an outside vendor is handling (that are not included in the Client Responsibilities section). This might be a vendor that claims they will migrate an application to a new server without an additional charge, or a copier support company that is going to update the firmware to support TLS 1.2 so scan-to-email works, etc. If you are relying on something like that, this is where it goes.
2. A (brief] summary of applications being migrated and confirmation that they are supported on the new operating system. This is only applicable on server migrations. The main benefit here is in doing the research.

Example:

1. Line-of-Business application has been confirmed to be supported on Windows Server 2022
2. Contoso has indicated via email that it will perform the migration of its application once the server is installed.

Downtime Expectations

This section gets everyone on the same page about sections of the project that will cause downtime. It also helps when determining labor estimates for portions that will need to occur after hours. Finally, if there is a section that has the potential to cause downtime, indicate that here.

This is also an opportunity to save yourself from requests such as, can this be done at 11:00 PM New Year's Eve?  without necessitating a discussion on how that will impact pricing.

Example:

When this application migration begins, no employees will be able to access it until completion. Migration is expected to take 4 hours and will start at 6:00 PM on a date agreed upon.

Closing Criteria

The goal of this section is to make the end of the project clear and objective. Here are some examples resulting from that comment I mentioned earlier. 

Example:

• All mailboxes moved to Microsoft 365
• All users connected to mailbox via Outlook
• Up to one mobile device connected via Outlook Mobile per user
• Exchange uninstalled from old server, server physically shut down and removed from rack
• Two Copiers configured with scan to email
• One week after the MX record cutover will conclude the post-migration support

One of the problems with big migration or implementation projects is that it can get "sticky", where little items keep getting lumped in as "we shouldn't be billed for this as it was really part of the project". If you weren't clear up front about what the scope is, you end up eating those hours and not being able to bill for them. A somewhat moot point if the client is on an all-inclusive plan, but it does skew the profitability of your professional services department. Actually, that's another really good point. More mature MSPs will track the finances of professional services and break/fix separately. So, if you, the professional services team, do something that causes the support desk and the "managed services" department to receive a zillion phone calls, you are going to screw up their metrics just from doing the project and being very clear about what is/isn't in the project. Just avoid this.

The most important item in the closing criteria section is the last one specifying a time limit after which support calls are no longer "part of the project". It creates a clear demarcation point not open to interpretation – it's closed two weeks after cutover.

Usage Notes

Always go over the proposal with the client in an online or in-person meeting, rather than just emailing it and hoping for the best. This is not a pitch – the client should already be on board with the idea of doing the project if you're writing a formal proposal.

This is the chance for everyone to discuss any missing elements. Sometimes a training session is needed. You can add it as part of the project and discuss how it will impact the final project cost

When sending these out, be sure to do it via your quoting system or an e-signature tool so that there is evidence of agreement. Ideally, it should be part of the quote if your quoting system allows for that.

With every item there is an unwritten "reasonableness rule" and the proposal is not intended as a bludgeon for your client. You don't need to start the change order paperwork for something that will cost you an extra 30 minutes. In fact, I can count on one hand the number of times we ever went back and pointed to something being in the "out of scope" section—and those were for egregiously unreasonable requests.

Who should write these and how do you decide what to scope/quote? The answer to that will be provided in part 2.

For more great resources, or to find out how Gradient can simplify your business, check us out.