In Part 1 of this series, we looked at a few high-level differences between private sector and public sector project management work. Basically, we considered the differences between projects geared to make a buck vs. those that are trying to save the world!
We also looked at the framework of various configurations of private-public partnerships (PPPs), of which the chart below is just one scenario. It will be the one that we focus on today, though.
Figure 1. A simple PPP scenario (For more PPP scenarios, see Part 1 of this series.)
Let’s dive a bit deeper into this topic and examine specific differences between the private and the public worlds. In the following article, we’ll cover these important areas of project management:
- Nomenclature
- Tools
- Processes
- Standards
- Methodologies
Important to note is that making a buck and saving the world are not necessarily mutually exclusive. In fact, in the case of private-public partnerships, this is the point. Both can be done at the same time!
Differences in Nomenclature
I have found that the first obstacle for a project manager taking on a PPP project is terminology. After all, when teams from both sides of the aisle (those who strive to make a return on investment and those focused on changing human behavior) work together, the two sides have to communicate, right?
Here is a table of terms often confusing to project managers coming from the business world and from the world of human development – as they begin to sail in the same boat:
[table id=63 /]Figure 2. Terms of Confusion (with takes from business and development worlds)
[Feel free to add to this list in the comments below]
Now that some terms are out of the way, we can discuss some differences and similarities between how a business manager would approach project work vs. how a development manager would.
Misunderstandings between approaches usually fall within the four “spheres of influence” shown in Figure 3:
Figure 3. Common Approaches to Project Management (from Project Management Methodologies, Bonnie Biafore & John Riopel, 2/2018, MPUG.com).
What happens when the team accustomed to adhering to the PMBOK standard butts heads with the team adhering to PRINCE2? Nothing good, unless some reconciliation is done beforehand. Looking at each “sphere of influence” above. Of course, we find some differences, but let’s also hope we can gain some insight into how to reconcile those differences. No one wants their project to follow the script of “When Worlds Collide” or have their partnership dissolve due to irreconcilable disparities.
For example, let’s take a unicorn project, Project REFRESH, where a PPP is formed between a mid-sized I/NGO (think UNICEF or Save the Children) and a Silicon Valley startup to 1) raise awareness on the importance of drinking lots of water every day, and 2) create a software app that reminds kids-on-phones to drink more aqua every 45 minutes or so. Let’s circle their orbit for a bit…
The Differences in Tools
One would think that like a carpenter, a project manager’s tool belt would be consistent from one job to the next; not so with these two species of worker bees. Businesses tend to license nice big expensive tools like Microsoft Project Server w/ SharePoint and all the rest. Development agencies…well, not so much. They tend to grow their own (crazy) systems, make due with Excel spreadsheets, or cycle through SaaS solutions (think Wrike and Basecamp), trying to find one that fits (but winding up unhappy with everything they try).
In the case of our hypothetical Project REFRESH, synergy between the two IT departments of both orgs would most likely benefit the development agency. They are usually the ones struggling. An exception to this quasi-rule is when businesses partner with governments, and not with smaller-sized NGOs. In this case, the business may have to adapt to a PM tool that is mandated by policy, or is otherwise entrenched within the governmental bureaucracy.
Preferably, both partners in the PPP would use the same PM tool, whether that be MS Server, Project Plan 365, Wrike, Smartsheet.com, or whatever. It really doesn’t matter too much, as long as it works for both parties. But never try to merge two types of PM tools. Trying to work in both MS Project Pro and Primavera would likely be a nightmare. In this age of SaaS (Software as a Service), it’s cheaper—and lot easier—to just go out and rent some for everyone.
The Differences in Standards
There are only two standards generally recognized in the wild: PMI’s PMBOK and PRINCE2. Of course there are many thousands of nameless homegrown ones, but PMBOK and PRINCE2 are the biggest ones out there, and while your agency or business might not have any standard at all, the time was yesterday for your two partners to get together and agree on one. More on that under “Differences in Methodologies” section below.
The Differences in Processes
As far as PM methodology goes, one would expect all the players to be familiar with each other’s processes, as with common B2B collaborations between two business houses. This is not the case for our Project REFRESH, where software developers are managing the development of the app using the Agile process, while the behavior-change specialists are managing their work using the Waterfall/Rolling Wave process. How can the lead project manager handle both? Good question.
[There are a few PM tools that help handle both. For example, Project Plan 365 (a Microsoft Project look-alike) and MS Project are two that do both Agile (Kanban / Scrum) and Waterfall. More on tools and how-to adopt a MS Project plan that can handle both in Part 3 of this series]
Another example of a PM approach that may cause confusion is PRINCE2, as most software developers have never heard of it, or might have a hard time understanding it. It’s the same on the flip side for some PRINCE2 managers struggle with other standards).
Here are five process tips for those PMs planning to bounce between the two planets of Business and Human Development:
- Make sure both partners meet and discuss a project charter together. Do not consider the other partner as an “add on” to the project, even though you may be subcontracting the work to them. As in our case study, product development for REFRESH’s app is being funded from the NGO’s budget.
- Map out and break down the work together (not in isolation), so that collaboration becomes more than just a bullet point on a report to upper-management. You can mind map out a WBS online.
- Schedule the work together, meshing as much as possible any differences in the planning processes that each are accustomed to. Collaboration can be done–but allow extra time in the schedule to do just that. This step should be easy if #2 above is followed.
- Monitor and evaluate the work together, trying to be inclusive as possible in a single M&E/QA system (not two or three).
- Don’t let software tools define your process. Define your goals and processes in partnership, and then agree on a common PM tool.
The Differences in Methodologies
For most successful projects (such as our Project REFRESH), the overall arching methodology that should be considered is nothing standard or generic, like PRINCE2 or Ten Step. You have to come up with your own PPP methodology through hard thought and candid conversations between partners.
If it works well the first time, make it universal, and whether you are a business house doing some good in the world with a humanitarian agency, or you are a non-governmental agency partnering with AI geniuses from Silicon Valley, you’ve established a joint way of working with each other right from the start. That is a way to have partnerships enrich each other and society together and at the same time. The best of both worlds is our plan!
Recap
Here is what we found during the design of our mythical Project REFRESH. From the get-go, the private sector and public sector teams joined forces to agree on the following to be used for the life of the project:
- A PM tool
- The PM process
- A PM guideline
From that basis, emerges a modified-standard or brand-new methodology that allows both worlds to 1) break down the work together, 2) schedule the work together, and finally, 3) monitor and evaluate the project jointly, using a single process, tool, and guideline.
From this initial project activity, your PPP methodology is born! Now that you have this new baby, why not use her to establish a new template (call it the My PPP Project Plan Template). This can help replicate all of the above for future partnerships to come. I’ll show you how to do that in Saving the World Project Management (Part 3), so stay tuned…
