Skip to content

The Summit - December 2024

The newsletter for PS Managers & Executives!

Welcome to the December '24 edition of The Summit. To see the full archive of The Summit, please go to the Summit Index.

Falling into Passive Project Delivery

In my conversations with customers, it's rare to hear about a project management team that's over performing. More often than not, project management teams find themselves trapped in a cycle where the "business of project management" undermines its true purpose. At CirrusOne, we deliberately avoided this pitfall by designing an approach that addresses the root problem: Why are so many project managers overworked?

While the reasons vary, one issue stands out consistently: the selling of fractional project management.

When sales teams pitch products, implementation services inevitably enter the conversation. Unfortunately, many sales representatives struggle to articulate the value of professional services, particularly project management. This leaves them vulnerable when customers ask, "What's the value of all this project management?" Without a confident response, the conversation shifts to reducing costs.

As a result, project management is often sold in small increments—10% to 25% of full-time effort—even for enterprise-level projects worth $500,000 or more. This forces project managers to juggle multiple projects to meet their billable targets, often managing 6–10 projects simultaneously. While this approach may optimize billable hours, it comes with a hidden cost.

When project managers are stretched across multiple projects, they shift from proactive leadership to reactive maintenance. Instead of leading 2–3 enterprise clients effectively, they scramble to provide basic updates and meet reporting requirements. This diminishes their ability to guide the project strategically, reducing the value they bring to the table.

At CirrusOne, we committed to avoiding this trap. We established clear limits on the number of projects a manager could handle before their role shifted from proactive to passive. For enterprise projects, this meant assigning no more than 2–3 projects per manager; for smaller, mid-tier projects, the number was closer to 5.

While these numbers worked for us, every organization’s project profile is unique. The key is to determine the effort required for your specific projects and sell project management in a way that allows it to remain proactive.

To maintain proactive project management, start by mapping out how your organization should structure and sell project management. Then, create sales materials to justify this approach. Once you determine the minimum percentage of project management effort you're willing to sell, stick to it. Pricing below that threshold undermines your credibility and effectiveness.

Selling this model may seem challenging, but the real hurdle is commitment, not capability. When a customer asks, "What's the value of all this project management?" your answer should be clear:

"It ensures we lead your project proactively, keeping both organizations engaged and moving forward. If at any point you feel our project management isn’t delivering, you shouldn’t have to pay for it. Alternatively, we can offer staff augmentation, where we provide resources, and you take full ownership of the project—but this is far riskier."

With this approach, we rarely sell staff augmentation. Instead, customers value and invest in our proactive project management.

The project management problem is one we’ve created ourselves. By failing to believe in its value, we’ve sold it as a commodity—and that’s how it’s perceived. When we shift our mindset and sell project management as the proactive leadership of a risky journey, customers recognize its worth. More importantly, we begin to deliver it in a way that aligns with its true purpose.

By believing in its value, we can transform project management from a reactive burden into a proactive force for success.

PROJECT MANAGEMENT NEEDS TO CHANGE!

project-dynamics-front-cover-final-2024-thumbnailPrior to its release, Shane Anastasi's second book, Project Dynamics, is available for free to those who agree to provide an Amazon review on launch day.

Project Dynamics, challenges the theory that time, scope and budget adherence determine a project's success. Instead, replacing them the goal of achieving a customer reference, making the targeted project margin and not burning out the consultants who deliver the projects.

The book guides  customer-facing project managers to recognize the "dynamics" of a project and respond accordingly with corrective action before the dynamics create a reactive escalation. Learning to take action on these dynamics is the key to delivering successful customer projects repeatedly.

 

Collective Wisdom Map

For many years I've touted that if a professional services consultant is not billable, the next thing they can be doing is creating collective wisdom. Yet, in conversations with many organizations there is no structured approach to how collective wisdom is viewed or managed within the organization. While I appreciate the sheer complexity that some organizations face when trying to think about collecting their knowledge, there are some simple things that can be done rapidly advance the organization's ability to capture and reuse it.

Collective Wisdom Structure

In its simplest form we tend to get distracted by the many different ways in which documentation and knowledge can be collected within our organization. To help with this there is a simple architecture that can be deployed to help create a basic "map" of what it is we want to collect and where it can be found.

Methodology

Our methodology is the collection of best practices that we have determined should guide our project process. In fact, project should simply be managed as if it is a living instance of our methodology. Unfortunately, PSA tools do not share this philosophy, so most organizations that are serious about methodology find themselves trying to build customized "bolt ons" to try and bring it to the fore.

This is usually a worthwhile exercise but it is rarely as powerful as it could be simply because regardless of how the methodology says we should be implementing the project, the PSA still looks at it as though it is a financial vehicle (which it is). Still, I strongly recommend that all organizations have a methodology that acts as its central knowledge repository for how a project should be managed as it travels through its stages. 

Examples

Examples should be stored separately from methodology as they need to be indexed differently. They need to be searched by things such as project size, solution type, solution components and industry. Once collected, this knowledge base becomes the go to repository whenever a project consultant begins a new task because it represents a possible head start.

Industry Specific Templates

As we reiterate our methodology, we also find specific nuances that are required by specific industries. These nuances provide us with an insight that can be used both in our sales process, but also in our execution as we implement these solutions into the same industry. We must, of course, be aware of intellectual property rights, but in most cases these industry examples just help us translate our actions into a vernacular that is more palatable to each industry.

Playbooks

Given our work in the Customer Success field, the concept of playbooks is one that I believe should also be adopted by professional services. The idea of a playbook is simply that if we individually face the same kinds of situations, and collected how we dealt with those situations in a common repository, then we would have a knowledge base that could other people through the same situations in the future with better results. I recently went to an offsite training with a customer who was avidly rolling out their playbooks and I was very pleased to see the amount of focus they were receiving. 

Technical "How To" Documents

While this might be something we share with the support organization, it is critical that we have access to a body of knowledge that can help us resolve technical issues. Without access to this knowledgebase it is possible that every time we encounter the same problem, we are resolving it from scratch rather than accelerating its resolution with a previously proven approach.

Collective Wisdom Map

The identification of where these repositories are located creates somewhat of a Collective Wisdom Map that can be shared with your organization as well as new hires to get them up to speed quickly. Such a map helps us achieve some of the benefits of a unified knowledge management solution while not actually requiring that there be one tool to rule them all. 

Rodina Transparent

Sponsor: Rodina Consulting (a PSA Implementer)

Rodina Consulting offers a full service range of Kantata SX and Certinia services. This includes: Full implementations, operational enhancements and ongoing administrative services. If you need help making your PSA sing, experience the Rodina difference.

PMO & Project Accountability

I have a number of clients that ask for help getting their PMO to "work". The usual problem is described as having a PMO that doesn't appear to help the PS executive identify and avoid escalations. This apparent lack of value from the PMO that tends to give the PMO a reputation of not providing as much value as was initially promised when the team was created. We find this to be true in most PMO instances. There are definitely exceptions and some organizations have a cracking PMO, but for those that don't the root causes of the "miss" are varied.

The first mistake that is made when establishing a PMO is misplacing the PMO's responsibilities and creating a divergent reporting line that removes (or weakens) the role of the PS Manager who is meant to have the accountability for the project's execution. The Project Managers are now asked to serve two masters. The PMO (who grills them on governance and process) and their direct reporting manager (who grills them on forecasting, revenue and resources). So many companies have this structure. The result is that nobody knows who is in charge and we leave the Project Managers field directives open to interpretation. "Should I go to the PMO or my PS Manager for with this issue?".

This mistake occurs because we incorrectly define the mission of the PMO. PS Executive and Managers get together to discuss project progress and status and are constantly being surprised by reactive project escalations. The PS Executive asks, "Why does this keep happening?" and the PS Managers or Directors respond, "Our projects aren't following the process." So, we create a PMO as a Process Governing Agency that is supposed to magically identify if a process is being followed, by only checking in with a project one a week or once a month and looking at its recorded data. NEWSFLASH: The issues that require addressing are not in the project data! By the time the project data reflects the issue, it will have already become a "reactive" escalation. This is because almost all project data is hindsight. A PMO that attempts to to assess a project at arm's length is always going to misread the situation until it is too late. The person who needs to be looking at the project's current situation is the project's sponsor (usually that is the project manager's manager - aka the PS Manager or PS Director).

PS organizations have set PMO's up in a way that attempts to replace proper project sponsorship with a cheaper version of it by using a centralized team who has less time to work directly with the project and whatever issues it might be having. Hence, the PMO becomes ineffective at identifying "proactive" escalations and so the ongoing "reactive" escalations persist. So, before we even begin to think about establishing a PMO we need to make sure that one key level of accountability is made clear within the PS organization. The PS Manager / Director must be the Project Sponsor and must be accountable for the assessment of the project's current status. For the PS P&L to work, the accountability chain must follow the profitability chain. Introducing a third party to check in on a project's profitability without being accountable for attaining it is pointless. Unfrotunately, the amount of training we give to PS Managers so that they can do this job well is sorely lacking. This is because the role of PS Manager / Director is incredibly difficult. You are responsible for the people, the forecast, the revenue, the profit, the customer satisfaction and the project execution. Welcome to owning a business ownership.    

With this in mind, we start to see a real purpose for the PMO. The mission of the PMO should be to help the PS Manager / Director  just as much as they help the Project Manager. The PMO should be asking the PS Manager if they have a good relationship with the customer's sponsor. They should be asking the PS Manager when they will be having the next Project Stakeholder Meeting and if one has not been set, helping that PS Manager to get it on the calendar, otherwise it will need escalation to the PS Executive. The most effective role for the PMO is to help the PS Managers and Directors lead their projects to success.