Technology makes the existing design more permanent.
Organisations often begin a PPM transformation by comparing tools. The discussion quickly moves to features, integrations, licences and implementation dates.
That feels like progress because a system is tangible. But if teams use different processes, ownership is unclear and management information does not support a defined decision, the technology has nothing coherent to automate.
The likely result is an expensive version of the current inconsistency. Workarounds continue, data quality falls and leadership concludes that adoption is the problem.
First define the work, decisions and ownership. Then select the technology that makes them easier and more reliable.
Start with the commercial and operating purpose.
The practice exists to help the organisation win, mobilise, govern and deliver work. The operating model should begin with the outcomes the business and its clients require.
That means understanding the customer journey, the work being delivered, the capability needed and the decisions leadership must make. Only then can the practice determine which processes, controls and information are necessary.
Design around decisions, not reports.
Management information is valuable when it changes or confirms a decision. Reports that exist because they have always existed create activity without control.
For each information requirement, ask who uses it, what decision it supports, when it is needed, where the source data comes from and who owns its quality.
If those answers are unclear, adding a dashboard will improve presentation without improving management.
Standardise what must be shared.
A reliable practice does not require every engagement to behave identically. It requires clarity about what must be common and what may be tailored.
Decision rights, minimum governance, key data definitions and core controls may need consistency. Delivery methods, reporting detail and team routines may vary according to client, risk and complexity.
The operating model should make that boundary explicit. Otherwise standards become either too rigid to use or too vague to create reliability.
Only then select the system.
Once the practice has defined its processes, ownership, information and tailoring rules, technology selection becomes more disciplined. Requirements can be traced to real work and real decisions instead of a generic feature list.
The question changes from “What can this platform do?” to “How well does this platform enable the practice we have chosen to build?”
Questions before procurement
- What business and client outcomes must the practice enable?
- Which decisions must become faster or more reliable?
- Who owns each process and information requirement?
- What must be standard and what should be tailored?
- Which current workarounds reveal a design problem?
If these questions cannot be answered, the organisation is not ready to select a system. It is ready to design the practice.