Case Study: Growing a Wildly Successful MSP Project Portfolio

This post is brought to you by our incredibly talented guest contributor Stephen Buyze. To add additional to this article Stephen has put together a detailed Project Roadmap and Template offer that you won’t want to miss!

Recently, Members of a Managed Service Provider Owners Peer Group requested a 3-day Face to Face meeting to discuss Project Management. During the 3-day event, I was asked to present on my experience with an MSP growing from about 8 projects per year to over 500, and what that path looked like. Here’s what I came up with.

Here are some of the basic questions Owners wanted answers to, I’m willing to bet you can relate to a couple of these:

How do I know when to hire a full-time PM?
What do I need to be aware of when working with sub-contractors engaged on a per-project basis?
How can I best manage projects without taking away from supporting my Managed Service Agreements?
What is the best way to structure my project management tracking?
- Should I use my PSA’s Project module for everything, or can you still manage projects with tickets?
How can I clearly differentiate a project from every other type of Customer request?
How can I get Customers to pay for Project Management?
- Should I discount my project fees because they are MS clients?
Should every new managed services contract start with an onboarding project? How should these be structured?

A Project Management Story from My Past…

Here is a personal anecdote that I shared with the Peer Group members in order to answer their project related questions:

Before I joined an MSP in 2010, the company was only doing about 8 projects per year. They were not clearly defined, and at that time, the MSP was small enough (40 Employees) for one person to navigate by his gut. That person was the Service Manager, and he managed projects part-time in addition to all of his other Service Delivery responsibilities. This amounted to managing about 2 projects at a time leading up to about 8 projects for the year.

I was hired with the title of Customer Service Manager, and had one directive:

Take the company from a reactive environment to a proactive, data-driven, highly competitive Service Delivery operation.

A year later, my supervisor mentioned he was frustrated that he was not seeing enough proactive data driving. We reviewed what I had been working on, which was fixing the Service Delivery process and procedures so the data could be transformed into information with which decisions could then be made. Coincidently, the process of amending the underlying data was nearing completion, and the information the company needed was starting to appear.

At the same time, a couple of Executive decisions were made that would change the landscape of the Service Delivery environment forever. The key decision was that Project Management labor (a minimum of 4 hours) would be added to all project opportunities in the sales pipeline.

However, along with this decision was the need for a clear definition (16 hours of estimated labor) of exactly what a project was. This was necessary so that both Sales and Engineering knew when an opportunity needed to go through the Sales Pipeline and when the existing “Please Create A Ticket” request could be used.

What surprised us, or at least me, was that not only would Customers pay for Project Management, they would actually beg for it. This in itself became a competitive advantage as the word got out that we could deliver IT Projects on-time and on budget with a dedicated focus from a resource guiding Customers through the whole process. Shortly after this realization, we hired our first full-time dedicated Project Manager.

We naturally became known for providing a rich Customer Experience with great communications when it came to managing IT projects. Today, the Project Management Team consists of 5 Project Managers and two Project Coordinators.

The first Project Managers were expected to manage 5 projects at a time. As the program grew, they are now managing 20-30 projects each, with 10-15 in progress at any given time. Projects being managed are typical of most any MSP operation, such as:

New Customer Onboarding
PC rollout (especially with Win 7 EoL)
Network Upgrades
Azure, Office 365, VMware, Citrix, etc.

In this case, the size of the projects supported a target Customer base of 35 to 200 seats.

When I asked what changed, I was told in the beginning; there was no process, expectations, templates, or experience. As the repetitive documentation was put in place, and as lessons learned were applied to improving the documentation and templates, the ability of Project Managers to manage more projects rapidly increased.

I also believe that as stakeholders’ knowledge of Project Management grew, it became easier to manage more and more projects. Once everyone (Customers, Sales, Lead Techs, Network Engineers, Support Teams, Inside Sales, Customer Service, Chief-Cook-and-Bottle-Washer) knew what to expect when it came to projects, the Project Managers were spending less time explaining, coaching, and training and more time managing.

Here are some key examples of stakeholder knowledge that lead to this transformation:

Customers consistently wanted to know what they were getting for their money.
- PS. My giveaway Project workflows are perfect for helping you to explain the value of what Customers get for their investment with you.
Salespeople needed to understand the benefit to them in participating in the Project Sales Pipeline. Which quite frankly is more time on the streets by providing a rich, warm handoff to Project Management and an early release from bird-dogging what was promised.
Engineers wanted their role and responsibilities clearly laid out; including how their work benefited the Project and how their performance would be evaluated.
Supporting roles wanted to know what they were responsible for and when they were needed to deliver by so they could best manage their time and priorities.

Why Jargon is Crucial

Another significant impact that enabled the ability to manage more projects was addressing the terminology being used. When it comes to projects, most of the terms found in the Project Management Institute’s Project Management Book of Knowledge (PMI’s PMBOK) are foreign to a Managed Service Provider.

The collision of the two worlds was violent, stressful, and explosions could interrupt at a moment’s notice over simple semantics. What emerged wasn’t Managed Service Provider or PMI’s Project Management best practices, but a very different Project Management for MSP’s product. One that takes the best of both worlds and makes Project Management work for part-time Project Managers and full-time Service Delivery Managers.

While there is a reference to a volcano, in reality, the transformation took years and was more like a continental uplift than a series of violent explosions.

The first pivotal change was agreeing on how to best define a project to make sure all project opportunities followed the Project Sales Pipeline protocol.
The next step was to develop the Sales Protocol and determine at which point Sales and Engineering would interject into the process. Once this happened, trust between Sales and Engineering started to grow.
The final step was to release the Salesperson from the opportunity once it closed, so they could go back on the street and look for the next opportunity. This triggered Project Management to take over and allow for both Sales and Project Management team members to partner on the Customer facing transition that took place. While this was an important step, it took documenting many lessons learned and folding them back into the process before trust in Project Managers was developed and Sales felt ready to let go.

Spreadsheets & Expertise: Growth Contributors

Two other important factors also contributed to the growth of the portfolio to over 500 projects per year.

Developing a dynamic Project Portfolio Spreadsheet to manage the project portfolio.
- GIVEAWAY: For access to a templated Project Portfolio planning resource to accomplish just this, please click here to subscribe and download a detailed step by step framework including:
Developing Resource Planning expertise. While projects are King, supporting the Managed Service Agreements is the economic engine for the Managed Service Provider. The expertise needed includes:
- Developing thorough Resource Planning processes
- Establishing Operational Performance benchmarks
- Adequately Staffing Management skills

The reason this is so important (in the MSP world) is that balancing Incidents, Service Requests, Projects, and Network Administration visits that live together in the same Service Delivery environment – while pulling from the same pool of resources – is a very complex problem. If this is something you’d like to learn more about, please click here to subscribe and view a 30-minute “Resource Planning for MSP” presentation video.

One more note about PM’s: In the MSP world, some Project Managers are PMI PMP certified, but their responsibilities do not match what the PMI book of knowledge expects.

In the case of a Project Manager working for an MSP, they are more like Project Coordinators, handling internal and Customer Communications, Project and Parts coordination and documentation.

Having a single point of contact for all projects is important – Project Manager, Lead Tech, Service Manager, etc. – but in the end, it is really the Lead Tech / Sr. Engineer managing the actual project with the guidance of well-trained Management staff.

Meet Steve. Learn How He Can Help!

We trust that we have just painted the picture of your IT Service Delivery operations in our second scenario. Yes? No? Prefer not to state? If you’d like a second opinion on how your team operates.
Steve is ready to help! Contact Steve today.