The world of PMI vs. MSP Reality of Project Management
Projects - and our inability to identify and manage them -are causing most of the disruptions of the IT Service Delivery at a Managed Service Provider, this, in turn, is causing a major problem: lost profits. If all we did were Incident response and remediation, life would be easy. Well...we don’t! We also manage Service Requests, Network Administration Visits, and Projects. It dawned on me quite recently that we start out focusing on Incident Remediation. We do quite well handling the reactive work, adding some small then larger Service Requests; and even can handle recurring visits without causing to much trouble. But it is projects that are the gorilla in the mix. Projects are causing us to lose focus on the economic engine – recurring revenue. I am convinced that Managed Service Delivery and Project Management do not play well together. If your MSP is trying to manage them in the same way, you’re setting yourself up for failure. So, where do we turn for help? PMI? Click here for a full Sales-Sales/Engineering-Project Management detailed step-by-step process that includes: -10 Sales opportunity stages, including 4 Sales/Engineering stages-15 Project steps
9 Project Planning steps
3 Execution steps
3 Closeout steps
-Along with 3 best practice policies and how to use the Opportunity Probability
Why should a Managed Service Provider care about PMI?
Who are they? What do they do? And how do they help you run your MSP business, improve Service Delivery, or (in general) make your life easier? Project Management Institute (PMI) is recognized as setting the standard for Project Management. Their Project Management Book of Knowledge (PMBOK)is the gold standard on how to manage a project.
What Should Your MSP Know about PMI?
They have been around since 1969; PMBOK since 1996.
They focus solely on Project Management and have developed the ultimate best practice guidelines (PMBOK) for managing projects.
They provide a base language which we can use to communicate internally, in Peer Groups, and with Customers.
Projects (and the lack of definition and management) are causing most of the IT Service delivery problems in a Managed Service Delivery operation. We can learn from PMI how to best improve our project management practices.
Note: PMBOK is based on the American National Standards Institute’s (ANSI) “Standard for Project Management.” PMBOK’s purpose is to provide more detail about key concepts, emerging trends, considerations for tailoring the project management processes, and information on how tools and techniques are applied to projects. PMBOK is a guide, not a set of standards or rules – whichmeans, while we cannot change or use ANSI’s standards differently, we can adjust what PMBOK is saying to meet our MSP needs and best practices. Note: All PMBOK definitions are from the Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Seventh Edition (p. 715). Project Management Institute. Kindle Edition..with permission from PMI.
PMBOK vs. MSP Reality
PMBOK High-level Definitions: Project: PMBOK: A temporary endeavor undertaken to create a unique product, service, or result. MSP: A project is a request that requires significant labor, risk, complexity, and cannot be completed using Incident remediation workflows. To say “a temporary endeavor” is not enough. A single PC install is a temporary endeavor and does not need Project Management methodology.
Program: PMBOK: Related projects, subsidiary programs, and program activities that are managed in a coordinated manner to obtain benefits not available from managing them individually.MSP: A series of projects done for a single Customer to bring their Network up to the current Standard Build or some other purpose.
Portfolio: PMBOK: is projects, programs, and operations managed as a group to achieve strategic objectives. MSP: The Portfolio’s strategic objective is to make more money for the company without disrupting the economic engine – therefore, it refers to all the open projects being managed at any one moment.
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.
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. Ex: PC rollout, physical server build, VMware installation, Citrix Net scaler, 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: Saying no to anything and walking away is if the Customer balks at the gap analysis and does not agree to upgrade their network to our Standard Build. Or, if presenting a Managed Service Agreement, it becomes clear the Customer is not interested in partnering with the MSP. These two examples have nothing to do with projects. Once the op closes, we are obligated to do the project. The closest we come to applying this to a project is in the Engineering Review process where we say we cannot do the work, and then we do it 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. Ex: 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 non-existent. However, as the MSP Project Management skillset grows and matures, these things are added on an “as-needed basis.” Once added, it becomes part of the Project Management Playbook. The 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: - An identified area of project management defined by its knowledge requirements and described in terms of its component processes, practices, inputs, outputs, tools, and techniques. (there are 9 of them to be compared).MSP: Of the 9, we think about 6 of them. My hope is - after reading this article, the other 3 will become a topic around your water cooler.
PMBOK Project Management Knowledge Area 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.
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: All the arguments that ensue when the project goes south and becomes unprofitable. Out of the pain comes a myriad of techniques, SoPs, and haphazard attempts at managing out of scope work. This is a future article in itself.
Project Schedule Management PMBOK: Includes the processes required to manage timely completion of the project. MSP: Project Scheduling trumps (think cards, not presidents, although the President analogy might work also) all other scheduling, which sets the groundwork for Project Disruptions, leading to project unprofitability. And yet, the biggest argument is: Can I use a Ticket, or do I have to use a Project Task?
Project Cost Management PMBOK: Includes the processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling costs so the project can be completed within the approved budget. MSP: The cost of the parts purchase, because we are not sure of the internal cost of labor. Besides, labor is billable - so why should we care what it costs or how efficient our Project Scheduling time is? The rest is just administrative overhead and the cost of doing Managed Service Provider business – right?
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: Is the Network, including all devices, working as expected. Quality is determined 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: Are we talking about ISP Bandwidth or People? And if People, why are our highly skilled Sr. Engineers referred to as People? And what is this management – we have Bob, and if we leave him alone – which we don’t – he does an outstanding job. Anyway, Customers love him, so that makes him worth his weight in gold.
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 Customer and keep them into the loop as to how we are doing. As far as internal communications...well, that is always a work in progress.
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: Aren’t these lessons learned? After the project is over, we look at what went wrong and try not to do it again. Sounds like a plan, doesn’t it?
Project Procurement Management PMBOK: Includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team. MSP: We’ve got this, after all - we came from the VAR world. We know how to create a BoM, verify all the part numbers are correct before ordering the parts needed for the project, communicate the estimated delivery dates to the Customer and Project Scheduling (Bob, who is going to fit the project into his schedule somehow), track when they are received, communicate (to Bob) when they are in, and bill the Customer respectively and properly.
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: Again, we’ve got this covered. When someone screams, we provide the information they need.
Wait! Before you walk away MAD...
Before you walk away MAD, the purpose of this comparison is to communicate how a well- established project management-focused only organization looks at projects. While 17% of MSPs have been in business for less than 5 years, most have been in business for less than 20 years. In 1996, there were very few MSPs (they were all VARS back then); my guess is, there is a lot we can learn from the way PMI looks at things. The challenge is that there isn’t a one-to-one correlation. By that I mean, we cannot take ANSI’s Standards and make them rules for us - 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. Project Management and improving the quality of work-life for Engineers is my passion and my life’s work. Let me know your thoughts and how I can help you. Note: All PMBOK definitions are from Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Seventh Edition (p. 715). Project Management Institute. Kindle Edition.. with permission from PMI. Click here for a full Sales-Sales/Engineering-Project Management detailed step-by-step process that includes: -10 Sales opportunity stages, including 4 Sales/Engineering stages-15 Project steps
9 Project Planning steps
3 Execution steps
3 Closeout steps
-Along with 3 best practice policies and how to use the Opportunity Probability
