Adopt over adapt: when your PPM tool has 'too many' customisations

At PMO Conference London, I spoke with several organisations trying to establish or strengthen their PMO. Some had people who had become project managers through experience rather than formal project management training.

What struck me was that they were not simply looking for a PPM tool to automate a mature, well-established process. They were also looking for something that could help them build the process itself: a common structure, a consistent way to report, clearer governance, and better visibility of resources, risks and progress.

It raised an interesting question: can a PPM tool help an organisation build its PMO process?

I think it can, but only if the organisation resists the temptation to redesign the platform around every habit, preference and exception it may have accumulated over time.

When the process is still taking shape

We often hear that organisations should define their processes fully before selecting or implementing technology. “Process first, tool second” sounds logical. I was certainly one of the people saying it a few years ago, coming from Thales, where I had experienced a very well-oiled process.

For a mature PMO with well-understood governance, clear ownership and consistent ways of working, that approach may be realistic. For organisations still developing their PMO capability, however, the advice can be too neat for reality.

For organisations still developing their PMO capability, however, the advice can be too neat for reality.

These organisations often know what is not working. Reporting takes too long, project information is inconsistent, resource conflicts appear too late, governance varies between teams, and leadership cannot see the complete portfolio. What they may not yet know is exactly what the future operating model should look like.

How many approval stages are genuinely needed? Should every project follow the same governance? Who should own portfolio information? What does “green” actually mean? Which information supports a decision, and which information is being collected simply because it has always been collected?

In these situations, the process and the tool often need to mature together. A PPM platform can provide a practical starting point through common definitions, repeatable workflows and clearer ownership. It can also make unresolved process questions much harder to avoid.

A workflow may reveal that nobody agrees who should approve a business case. A dashboard may reveal that every project manager has a different interpretation of “green”. A resource view may confirm that the organisation is very good at allocating the same person to three projects at once.

The tool does not answer these questions automatically. It gives the organisation something concrete to test, challenge and improve, which can be more useful than spending months designing a perfect process in theory.

One reasonable customisation at a time

At another conference I attended, after two days of discussion about technology, processes and adoption, one phrase kept returning: adopt over adapt.

The idea is simple. Start with what the platform already does well. Adapt it where the organisation has a genuine need, but avoid redesigning everything around current habits simply because they are familiar.

It reminds me of ordering in a restaurant. You choose a dish, then ask to change the sauce, swap the side, remove one ingredient, add something from another dish and serve part of it separately.

Each request may sound perfectly reasonable on its own, although my husband may disagree when I do it. But after enough changes, the final order can become difficult to understand and increasingly distant from the dish that was originally designed.

Today, for example, I ordered a four-cheese pizza and asked to replace the gorgonzola with goat’s cheese. Somehow, instead of a pizza, pasta arrived at the table.

I am still not entirely sure what happened, but it felt like a surprisingly accurate demonstration of what can happen during a highly customised implementation.

The same thing can happen during a PPM implementation. One team wants a different status definition. Another wants an additional approval. A third insists on retaining a field it has used for years. Someone remembers an unusual exception from several years ago and wants the new process designed around it permanently.

Before long, the new platform contains every preference, workaround and historic habit from the old way of working. Technically, the implementation may meet the requirements. Practically, the process becomes harder to understand, learn and use.

Complexity rarely arrives as one obviously bad decision. It arrives one reasonable customisation at a time.

This risk is particularly significant when the PMO is still developing. Processes may have grown informally over many years. Temporary workarounds may have become permanent habits, and local preferences may never have been tested against an organisation-wide model.

What people do today is useful input, but it is not necessarily the process they should build for tomorrow. If the platform is adapted to every existing variation, it does not create a common process. It simply makes the variation permanent. (1)

Deciding what is genuinely worth adapting

Adopt over adapt does not mean blindly accepting every standard process. Some organisations have genuine requirements that a standard configuration cannot meet. Regulation, security, contractual obligations, funding structures and specific operating models may all require adaptation.

The challenge is distinguishing a real requirement from a preference, and a genuine constraint from a habit.

Before adapting the platform or the standard process, organisations should test the request against four questions.

The first is whether the request reflects a genuine constraint. Is the change required because of regulation, security, contractual obligations or a material part of the operating model? Or is it mainly a local preference? “This is how we have always done it” is not automatically a requirement, nor is “our team uses a different status scale” or “this approval has existed for years”.

Each request may have a valid reason. The point is to understand that reason before turning it into permanent system complexity.

The second question is what outcome the change will improve. Will it improve a decision, reduce risk, remove effort or make the process clearer? What will someone be able to do better because the customisation exists?

If nobody can clearly explain the outcome, the request may need more examination. A more detailed process is not necessarily a more valuable one. A tool can make a process repeatable, but it cannot make a pointless process useful.

The third question is whether users will understand and follow the process. A design can be logically correct and still fail if the people expected to use it cannot easily understand it. The process needs to work for project managers, sponsors and contributors, not only for the people who attended the configuration workshops.

Could a new project manager understand it without a two-hour explanation? Can someone tell which path to follow without checking a 40-page guide? Will it still make sense six months after go-live? If not, the design may be solving the wrong problem.

The final question is whether the benefit justifies the additional complexity. Every customisation creates an ongoing cost through more training, documentation, testing, maintenance and exceptions. It can also create more opportunities for people to work around the system.

The important question is therefore not only whether the tool can support the change. It is whether the change will make the process easier or harder for people to use.

The right advisor should challenge the process, not just configure it

This is where the choice of implementation advisor (or also called project management consulting) matters.

An advisor who simply records every request and configures it into the platform may produce a system that technically meets the documented requirements. They may also preserve every historic workaround, local preference and unnecessary exception that the organisation was hoping to leave behind.

A strong advisor does more than ask what the customer would like the system to do. They seek to understand the outcome behind each request and challenge whether the proposed solution is the simplest and most effective way to achieve it.

Why is this step required? Who uses this information? What decision does it support? What risk does this approval reduce? Is this a genuine organisational requirement, or simply the way one team happens to work today? Could the standard process meet the underlying need?

These questions can sometimes feel uncomfortable, particularly when people are attached to familiar ways of working. However, without that challenge, the implementation risks becoming a digital copy of the existing process, including all the complexity the organisation intended to improve.

The right advisor should bring experience from other implementations and help the organisation understand why the standard process was designed in a particular way. They should make the consequences of each customisation visible, including the impact on usability, training, maintenance and future upgrades.

They should also recognise when the organisation has a legitimate need that the standard approach cannot support. Adopt over adapt does not mean forcing every customer into an identical model. It means beginning with a tested foundation and only moving away from it for a clear and defensible reason.

Sometimes the right answer is to adapt the platform. Sometimes it is to test the standard process before changing it. Sometimes it is to simplify or remove a step before that step ever reaches the system.

That is not ignoring the customer’s requirements. It is helping the customer distinguish genuine needs from inherited complexity.

Adoption begins during design

Adoption is often treated as something that starts after go-live. The platform is configured, training is delivered, and then the organisation begins persuading people to use it.

In reality, adoption begins much earlier. It begins during design.

Every unnecessary field gives someone another reason to return to their spreadsheet. Every additional exception makes the process harder to explain. Every workflow that only its designer fully understands creates a future training problem.

This is why phased implementation can be more effective than trying to solve everything in the first release. Start with the visible pain points, introduce the simplest process that addresses them, test it with real users and real projects, then evolve it based on what the organisation learns. (2)

An organisation might begin with a common monthly status process, a standard risk register and basic portfolio visibility. Once those foundations are being used consistently, it can introduce more advanced resource planning, financial governance or strategic prioritisation.

This allows organisational capability to develop alongside the platform. A process existing in documentation is not the same as people understanding it and applying it consistently. Technology, process and capability need to mature together. (3)

This is also where an experienced implementation advisor adds value. Their role is not simply to record every request and configure it. A strong advisor listens, understands the context and asks difficult questions.

Why is this step required? Who uses this information? What risk does this approval reduce? Could the standard process meet the underlying need? What happens if we leave this out of the first release?

Sometimes the right answer is to adapt the platform. Sometimes it is to test the standard approach first. Sometimes it is to remove a step that no longer serves a useful purpose. (4)

That is not ignoring the customer. It is helping the customer separate genuine needs from inherited complexity.

The tool can help build the process, but it should not become the process

So, can a PPM tool provide useful structure for an organisation that is still developing its PMO process? Yes, I believe it can.

A good tool can provide a tested starting point through common definitions, repeatable workflows, clearer ownership and a consistent rhythm for managing projects. For organisations where project managers have learnt on the job, or where the PMO is still finding its feet, that structure can be extremely valuable. It means the organisation does not need to invent every part of its process from scratch.

The tool should still be treated as scaffolding, not as a complete operating model. The organisation needs to decide what the PMO exists to improve, which decisions it needs to support and which requirements are genuinely distinctive.

The practical approach is to begin with the standard process, test it against real scenarios and adapt where a clear need remains. This is not standardisation at all costs, nor is it customisation by default. It is a deliberate balance.

Adopt what is already well tested. Adapt what genuinely matters. Keep the process simple enough that people can understand it, use it and work with it rather than around it.

A few thoughtful customisations may make the dish fit the organisation. Too many, and nobody is quite sure what ended up being ordered.

Further insights referenced in the article, from experienced Altus advisors:

(1) Top 10 Mistakes Organizations Make When Modernizing Work Tools, Advisicon

(2) Making Your New PPM Tool Stick: What to Get Right from Day One, Sensei

(3) Why Capability Uplift Is the Missing Piece in PPM Transformations, Sensei

(4) Should We Rebuild, Migrate, or Retire Project Online Workflows?, Advisicon

‍