PMI from an MSP Point of View
PMI is clearly the leader in setting Project Management Standards! So, why can’t MSPs just blindly follow their Project Management Book of Knowledge (PMBOK) guidelines. Well, there are several reasons:
MRR and the Managed Service Support requests that keep disrupting Project work
Pulling from the same pool of Techs, or what is worse is trying to shield the Project Engineers from the Managed Service Support
Dumping the Project Tickets into the Queue, and telling the Techs to figure it out
The solution: Project Management for MSPs that understands and pulls the best PMBOK concepts and modifies them for the MSP work environment. When done correctly, the MSPs work environment moves from Chaos to a Zen.
Here is where the comparison starts:
PMBOK Key Components:
Project Life Cycle:
PMBOK: "A series of phases that a project passes through from start to completion."
MSP: From the time a project opportunity closes until the MSP is paid the final bill.
Project Phase:
PMBOK: "A collection of logically related project activities that culminates in the completion of one or more deliverables (Initiation, Planning, Execution, Control, Close-Out)."
MSP: Planning different aspects of the implementation of a single closed opportunity. Examples include PC rollout, physical server build, VMware installation, Citrix Netscaler, Azure file storage, with Zerto backup.
Phase Gate:
PMBOK: "A review at the end of a phase in which a decision is made to continue to the next phase, to continue with modification, or to end a program or project."
MSP: Often equates to the Sales Engineering Review process where work is initially said to be unfeasible but gets done anyway.
Project Management Processes:
PMBOK: "A systematic series of activities directed toward causing an end result where one or more inputs will be acted upon to create one or more outputs."
MSP: Coordinating the interdependencies within the execution phase of a project. Examples: Ports open before standing up the server and adding it to the network or updating the PC OS to Win 10 before migrating to Off 365.
Project Management Process Group:
PMBOK: "A logical grouping of project management inputs, tools and techniques, and outputs".
MSP: For an MSP starting out managing projects, this is often non-existent. However, as the MSP Project Management skillset grows and matures, these elements are added on an "as-needed basis." Once added, it becomes part of the Project Management Playbook. This playbook allows the MSP to go from managing a few projects to as many as 30 with 12-15 in progress at any given time.
Project Management Knowledge Area: PMBOK outlines 9 knowledge areas. From an MSP perspective, typically 6 of these 9 areas are actively considered.
Project Integration Management:
PMBOK: Includes the processes and activities to identify, define, combine, unify, and coordinate the various processes and Project Management activities within the Project Management Process Groups.
MSP: "Hey Service Manager, by the way, we also want you to manage the projects." This highlights the frequent additional responsibility placed on Service Managers.
Project Scope Management:
PMBOK: Includes the processes required to ensure the project includes all (but no more than) the required work to complete the project successfully.
MSP: This is often seen in "all the arguments that ensue when the project goes south and becomes unprofitable." Out of such pain comes various techniques, SOPs, and attempts to manage out-of-scope work. Properly managed projects should track changes for out-of-scope work to adjust future templates.
Project Schedule Management:
PMBOK: Includes the processes required to manage timely completion of the project.
MSP: Project scheduling often takes precedence, which can lead to project disruptions and unprofitability. A common debate is whether to use a "Ticket" or a "Project Task." MSPs have the ability to control when projects start or end, and how many are sold, which allows for strategic staffing decisions.
Project Quality Management:
PMBOK: Includes the processes for incorporating the organization's quality policy regarding planning, managing, and controlling projects and product quality requirements in order to meet stakeholders’ expectations.
MSP: Quality is often determined by whether the network and all devices are working as expected, and it's measured by the number of break/fix tickets created due to the project.
Project Resource Management:
PMBOK: Includes the processes to identify, acquire, and manage the resources needed for the successful completion of the project.
MSP: The focus is often on "people" (skilled Senior Engineers), and the management involves ensuring these valuable resources can perform their outstanding work without constant disruption. Resource Planning techniques are used to balance project scheduling with team availability to minimize disruptions to high-value project time.
Project Communications Management:
PMBOK: Includes the processes required to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and ultimately, disposition of project information.
MSP: "One painful experience after another, we have learned that we need to talk to the Client and keep them in the loop as to how we are doing. As far as internal communications...well, that is always a work in progress". Effective communication is crucial before, during, and after a project.
Project Risk Management:
PMBOK: Includes the processes of conducting risk management planning, identification, analysis, response planning, response implementation, and monitoring risk on a project.
MSP: This is often seen as "lessons learned" after a project is over, where the team looks at what went wrong to avoid repeating it. The practice of capturing "Lessons Learned" is strongly recommended.
Project Procurement Management:
PMBOK: Includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team.
MSP: MSPs often have a strong grasp of this due to their background in the VAR (Value-Added Reseller) world, handling Bill of Materials (BoM), verifying part numbers, communicating delivery dates, tracking receipts, and proper billing.
Project Stakeholder Management:
PMBOK: Includes the processes required to identify the people, groups, or organizations that could impact or be impacted by the project, to analyze stakeholder expectations and their impact on the project, and to develop appropriate management strategies for effectively engaging stakeholders in project decisions and execution.
MSP: Often simplified to "When someone screams, we provide the information they need."
Wait! Before you walk away MAD...
The purpose of this comparison is to communicate how a well-established Project Management only focus organization looks at projects.
However, the challenge is that there isn’t a one-to-one correlation. We cannot take PMI’s Standards and make them rules for MSPs – it will not work. We cannot take a Project Management-only focus and incorporate it into a world where Managed Service Support takes precedence.
The best we can do is look at the guidelines PMBOK lays out as best practice, then look for ways to apply it to our world – without grounding the ship on the rocks (Incidents, Service Requests, Network Administration Visits) while we sail in the often-choppy project waters.
Conclusion:
However, there is a way to get Project and Service Delivery work to play nicely together. The solution is the 2nd Pillar in the 4-Pillars of Operational Optimization; that is Tech Allocation.
An even bigger problem is that in 2025 - due to Windows 10 EoL, Exchange 2016 EoL, additional Security is needed, and Ingram Breech - MSPs are underwater getting projects done.
What is the solution?
A fully Done For You Operational Improvement Program from Advanced Global – email [email protected] for more information.