4 Big Reasons Client Projects Crash And Burn On MSPs

By Derrick Wlodarz, FireLogic

Too many projects taken on by fellow MSPs in our community end in some mixture of disappointment, cost overruns, or downright failure. Yet, after dissecting the root causes of derailment on both my projects and those of fellow MSP owners I’ve talked with, most of these stressful situations could have been managed or outright avoided with some proper course correction.

What are the largest items that cause IT projects to run afoul? Here are the top four you should be mindful of before extending your next SoW (Scope of Work) and cost proposal.

1. Scope Creep Is Allowed To Run Wild

This is a project pitfall that naturally perpetuates from the best of intentions. At times, it’s upper management that feels the need to tuck a few more deliverables into an engagement, believing that it’s “now or never.” But just as often, MSP project managers think they can slide in a few value-adds, thinking they will win brownie points from clients for their good deeds. But time and again, the road to (project) hell is paved full of such good intentions.

Project scopes of work (SOWs) that have been agreed to by both the MSP and client should be adhered to – whether that’s the time frame, deliverables, or cost. Changing the goalposts, which is pretty much what scope creep represents, shifts expectations that were clearly defined to the detriment of one or more parties. Convince clients that it’s in everyone’s best interest to bundle all the late-game “nice to haves” into a follow-up project. This way, you as the MSP can be properly compensated for the extra work, and clients have a chance to bake in their new technologies – which will better home in on what exactly they want, and how it should be implemented.

2. Clients Get Caught In A “Cart Before The Horse” Dilemma

Some of the absolute worst trainwrecks of IT projects I’ve been involved with have entailed whizbang, fancy technologies that were chosen before any business or functional requirements were outlined. In one real-life scenario, upper management wanted to move their file server to the cloud and was convinced on going to SharePoint – even though they never considered UX pitfalls for their Mac users. Or the time a firm asked us to convert their on-prem Exchange system to Google Workspace hosted email – and never bothered to research how reliant their staff was on Outlook desktop software functionality.

In my earlier years, I didn’t have the foresight to help prevent these trainwrecks and was too anxious to take any project that came my way. But now, with years of experience and dozens of projects behind me, I’ve become very keen on weeding out these “cart before the horse” project initiatives before they ever get signed off on.

Anytime you get a phone call or email from a decision maker asking what it will cost to migrate to fancy platform Y or Z, raise an eyebrow and peel the onion beyond the low-hanging fruit of trying to win an easy sale. What business requirements does said platform fulfill? What alternatives were considered? What legacy platform is currently in play? And what pain points currently exist? The more questions you can ask upfront, and the more you can avoid playing up datasheet talking points of any platform a client has pre-conceived notions about, the more likely you can get to the heart of what you should be discussing: what problem are we trying to solve, and what are the needs vs wants of any potential solution.

3. Failed To Plan? Then You Planned To Fail

If you’re still shotgunning 100-person rollouts the same way you would approach a 5-person deployment, you’re playing with fire that can have serious blowback. I know many MSPs are juggling tough existing support workloads and tossing on the added weight of projects brings considerable stress onto even well-managed technical departments. But solid planning can remove a lot of easy stressors and also keep projects on track.

You don’t have to be Microsoft Project certified to manage well-oiled deployment plans. Most PSA platforms include quite capable PM capabilities out of the box, and they don’t take a lot of effort to learn. Our firm FireLogic is on Autotask, and we leverage the native project toolset for complex rollouts. We can juggle and oversee dynamic variables like phase timelines, all subtasks for a given phase, and end-to-end duration – with abilities to spit out status reports for end clients and watch our over/under on time rendered.

As if good project plans didn’t already carry enough benefit, they serve the role of additional crutch during cost and scope negotiations, as well as leverage when it comes to justifying change order billing. The client failed to turn around fact-finding documents that were asked for in the agreed period. Or did they let loose that there was an extra file share that was never disclosed as being necessary for migration? All grounds for justified project timeline extension, as well as additional billable labor. Most digital PM platforms, like the one we use in Autotask, can even adjust waterfall-based timeline durations and cascade downstream phases, so all parties can see the trickle down from unexpected change orders.

4. Communication (With Stakeholders) Is Key

In many smaller organizations, solely keeping the one who signs project checks happy is an untold reality many MSPs naturally abide by. But the more complex your projects get, and the larger the client seat counts are, the greater the need exists for smooth communication with a number of parties that play critical roles in project success (or failure).

For large projects, stakeholders should be identified early on, well before any actual project labor begins. Said parties should be involved from kickoff; during any major mid-project status calls; and even pulled in on wrap-up capstone chats. Usually, involved stakeholders can help play the role of “cheerleaders” for complex projects, ensuring that regular staff upholds their end of project deliverable success – a delicate area that can derail even the best-planned engagements.

And to help prevent larger fissures in project progression, we’ve found that it’s always best to assign someone on the MSP team as the lead POC (point of contact) for any project. Sometimes this is considered the PM (project manager) but this doesn’t always have to be the case. The POC can ensure that key feedback and info is getting to the technicians necessary while playing quarterback for items that can be classified as out of scope or which are being shelved as a change order for a later date.

Scaling Project Management Success Is More Art Than Science

I’m grateful that I had the chance to study the best practices of IT project management while chasing a master’s degree of the same program name. But I know that I am in the minority of MSP leaders I network with, and that’s absolutely fine because the truth of the matter is: you don’t need a fancy degree to lead successful projects. I’ll be the first to admit that.

Take an approach of implementing baby step changes into your project methodology, building upon successes that work and writing off dead ends as you see fit. Best practices that may work for one MSP may not apply to the culture or workflow realities of another. For all the theory on IT PM, I learned during my master’s degree program, all these years later I’ve concluded that one size absolutely doesn’t fit all in this industry.

Molding a methodology on projects that is sustainable & scalable for your team can open the doors to larger opportunities without the pitfalls and cost overruns (sadly) too many MSPs become accustomed to.

About The Author

Derrick Wlodarz is President and Founder of Des Plaines, IL (USA) based Managed IT Service firm FireLogic. He has 15+ years of IT industry experience spanning both the private and public sectors. His firm specializes in providing SMB clients with managed IT support, consulting, and training. Derrick is a long-serving member of CompTIA's Subject Matter Expert Technical Advisory Council that shapes the future of CompTIA exams across the world. In addition to being an IT industry speaker and author, his work has been academically published in The Journal For Social Era Knowledge. He is a court-approved technical expert witness in the State of Illinois. You can reach him via email at derrick@wlodarz.net.