What’s this, Erik? Did you switch profession and go for the open seas? No, no, don’t worry, this is still very much a “help the PMO succeed” article. Let’s dig in, to a topic that comes up in a shape or form in every customer engagement.
My oldest draft article
I’ve had this topic in my draft section for many years already. And although an interesting topic, it never got past the general (draft) title. But then, last month, while attending the Projectum Energy Round Table event, the topic came up again while discussing a customer case.
It’s such a stubborn returning subject, that I’ve set my mind to finally write the whole thing. This is an article from a consultants perspective. I’ve assisted a large number of customers during my 15+ years of consultancy work. And I have seen my share of this phenomenon across the globe.
The executive summary: Don’t put too much effort and energy in implementing the perfect solution during the first engagement (with a software vendor/consultancy firm). Rather, accepting the company’s different perspectives on Project management and everything related to it, implement smaller but sturdy solutions that grow over time.
Never go big bang
There has only been one successful big bang (and maybe a successful tv serries). But implementing a new Project Management System company wide, at once, is certainly any project managers nightmare. Here are some reasons for this:
- Big difference in internal/external project sizes.
- Big difference in methodologies across departments (Agile IT vs Waterfall production department).
- Large group of stakeholders.
- Complex resource management structure across departments.
- Different reporting needs.
In my experience, implementing a company wide, all encompassing, project management system is the worst way to go. It’s a draconic effort, with so many stakeholders, and so many expectations, that there will always be saboteurs and missing features half way through the project. And with no finished product by that time, the project team isn’t very motivated to work on the solution before long.
The tender drama
But, if big bang is such an issue, why are there still big bang requests coming in?
Well, it’s just a hunch, but I believe it’s partially due to (European)tender drama. In Europe, any engagement above a certain price point needs to be tendered for. A process that involves a lot of documentation, time and effort from both the requestor as the 2 to 3 maybe more tender responders.
And because of this effort that goes into building a tender offer, I think some organizations go overboard (pun) with the requirements of the Project and Portfolio Management (PPM) solution. The general thought might be “Hey, we are already over the tender budget line, let’s cram as many features in the solution as we can think of.”.
But this automatically leads to a flagship solution request.
Aiming for the flagship
Let me tell you, a true flagship solution is beautiful. It delivers the value, it works across departments, it provides value to all layers of the workforce. And it’s maintained and operated by knowledgeable people.
So, is it wrong to want the flagship? Or, in ePMO terms, a solution that:
- Shows all projects in the organisation and their general status.
- Provides different project types for different departments that work differently, and have a different concept of what a project is. They might even want to call it an initiative instead of a project, because they work Agile.
- Provides a long list of metadata content for any project, related to the companies specific situation. Energy companies might want a MegaWatt numerical field. Shipping yards might want a global regions field to pinpoint regional offices and their productivity. Let’s call these our “company specials”.
- Provides a full blown risks, issues, changes, dependencies solution. Not only on projects, but also on programmes and portfolios, speaking of which:
- Has the option to build not only projects, but also programmes, and portfolios. With their own set of “company specials”.
- Has the option to build not only projects, but also the full project lifecycle, including ideation (before project life), a stage-gate visualisation and benefit management (after project life).
- Has a clear, and broad enough solution for strategy. Meaning in this sense, a ranking method to govern department specific and/or company wide prioritization of projects and ideas. And, the ability to kill or shelf the project if it’s below a budget or resourcing line, speaking of wich:
- Has the full workforce as a potential project resource, including skills, level of maturity, (geo)location, company RBS and different hourly rates and any “company specifics” we can think of.
- These resources can work full time, part time, take breaks, can be external, can be material, can be cost resources. They can, but are not bound by, a resource manager that owns their time (if applicable).
- Provides a time registration option, with the option to also include tasks outside the direct sphere of influence. Such as links to a ticket management system so that these tasks can also be registered on.
- Has integrations with: financial applications such as SAP, other task management solutions such as DevOps or Jira, other “company specials” such as the production line at factories across the globe.
- Is multi lingual (because we have English, Frensh and German speaking PM’s).
- Provides reports for all stakeholders regarding the projects, activities, risks, issues, specials, resources, financials, trend analysis on all.
That’s a long list right? And I bet there are some topics there that you thought, ooh I’d like me some of that! And that’s oke, obviously, because all of these topics are great to have in your enterprise PMO solution.
But,
What is your (real) need (,now)?
I don’t know if implementing a flagship solution from day 1 is possible, the Portfolio manager that was presenting at the Energy event said it perfectly “[we had too much on our plate,] we needed to simplify, simplify, simplify.”.
Look at your organisations direct, and near to direct, need. Maybe it would even be a good idea to have that singular by design. Focus on just 1 topic for the first phase. This focus will likely grow your understanding of the complex topic that is your organisations understanding of “Project and Portfolio Management” during the implementation.
And I’m writing this on purpose: “your organisations understanding”. This is not meant as a “you are wrong I am right” statement, but more an acknowledgement of different conceptual understanding of the topic. Does PPM mean we only do projects? Does it mean we need a rigorous structured stage gate model? Does it mean we have to have stand ups every Monday?
I really like the xPM approach we have in Projectum. Where there is freedom in the framework and we offer a option to do all. But no strict need to do all.
Different modes of complexity require different prerequisites.
What I mean with this, is that we should always remember where we came from, and where we are now, before we implement an xPM solution. Let’s take a look at “the rubber boat approach”.
Implement the rubber boat
Rather than complicating a new solution implementation, go for a phased approach. Phase 1 (the rubber boat) solves the 1 burning issue while keeping the door open for new functionality in the future.
Let’s take a look at different levels of org maturity. I’m oversimplifying the list here, but I hope you can find your spot on the list as well:
- Projects are managed in… “I think Excel?”
- We know what projects we have, but they are more schedules than real projects in the system.
- We have a list of projects, but can’t rank them/we don’t kill or postpone projects based on our strategy.
- We have a structured approach to projects, but don’t manage resources / finances in the system.
- We have projects, resources, finances covered in the system. But we want to integrate it with our other line of business applications to get a better “single source of truth”.
- We have a PMO across the organization. With specific department centred subPMO’s and a clear understanding of our strategy and where we are currently and the near future.
Number 6 obviously represents a organization that’s cruising in their flagship. But levels 1 to 4 can really still benefit with a rubber boat approach.
It shouldn’t surprise you to know that there are A LOT of organisations in levels 1 till 4.
For a level 1 organisation, that has projects scattered across and no clear overview, it wouldn’t work if you implement a fully integrated ePMO management system. Simply because they (likely) don’t even have a PMO. Rather, I would like to help this organisation by providing a full overview of all their projects, in one system.
This can still be a list that also contains metadata for each project. But it wouldn’t have much of a financial connection to SAP, or a complex change management solution, or a full blown resource management approach. That should come at a later stage with more maturity.
At level 1, there are just too many unknown-unknowns to be able to implement a level 6 scenario.
Some examples of (successful) rubber boat implementations
I’ll shy away from calling out real company names here for obvious reasons. But these are all real world examples of implementations I’ve been played a consulting part.
Company 1, a financial institute was preparing a merger. They identified 50 projects for the merger to be completed, but didn’t have a system to capture and manage them. With little more information available, we implemented Project Online for the customer. With a set of 10 meta data fields and a structured security model (you can imagine that mergers in financial sectors are sensitive topics).
This is a Level 1 example. Where the company grew later, by adopting this project approach to more departments during the years that followed. A PMO was established, and clear goals were set regarding the adoption of more metadata to supply the growing demand for additional information.
Company 2, A manufacturer of “products”, needed a better grip on their main bottleneck: the resources. This would mean a company that’s somewhere between level 1 and level 4. They knew that they couldn’t deliver more, because certain key players in the process were structurally overworked. But, with what?
This company benefitted from a Power PPM solution combined with Team Planner. And after a simple configuration of projects, not focussing on too much metadata, we already could establish a project stage schedule that provided enough information for more accurate resource allocation. The company saw an increase in product, as well as happier workforce because there was a direct visibility of overallocation before it happened. As a side note, under allocation was also quickly spotted and addressed.
Company 3, a municipality, had a group of mostly external project managers that worked with Microsoft Project. But, no central PMO, no central system to work with apart from a storage location where all PM’s were set to upload their schedules. This is an example of Type 2. A difficult scenario because of the large dependency on external PM’s, but one we tackled by providing a Power PPM solution that could read their MS Project files and let them keep that expertise.
The Power PPM solution gave 2 main benefits to the customer: a central repository of all schedules. Visually showcasing this in the portfolio overviews. And the option to slowly adopt a more Project Management minded mind set instead of only schedule management. With the PPM solution, management could address the need for specific metadata to be present as well. Thereby increasing the company reporting capabilities.
Company 3 is currently eying OKR’s as their next big win.
Final notes
Thank you for sticking around till the end! I hope you enjoyed reading this brainstorm article as much as I enjoyed writing it.
I think it’s crucial to know what need is being resolved by implementing any system (be it PPM or other). And there is a real risk over overestimating the organisations capacity for adoption to new systems.
People are resistant to change, organisations as a whole might not just be ready for a big change yet, so why force things? Take a close look at the current state of the org, and find the next 1 or 2 levels to improve on. I can guaranty you that this will be a quicker, easier, and in the end cheaper approach than forcing a flagship implementation from the ground up.
If you liked the article. Can I request a small favour? Will you share this on LinkedIn for others to see as well?
Have a great rest of your day, until next time,
Erik van Hurck