The Association of Change Management Professionals (ACMP) defines change management as the application of knowledge, skills, abilities, methodologies, processes, tools, and techniques to move an individual or group from a current state to a desired future state, so that intended outcomes and business objectives are met. For most companies, the clearest example is buying new software: the current state is how work gets done today, and the desired state is how it gets done once the software is live.
Two questions come up for almost every business owner who brings in software or starts a digital transformation. The first is which factors decide whether the change succeeds, and how to make sure all of them are covered. The second is where to look when the rollout is underway, or already finished, and the results are not what was expected. The People, Process, and Technology (PPT) framework helps with both. It splits a change into three parts that have to be considered together, people, process, and technology, and turns those parts into a checklist before the rollout and a set of places to check when results fall short.
What the PPT framework covers
PPT looks at a change through three factors that have to be considered at the same time. People are everyone in the organization, from the leaders who make decisions to the staff who do the daily work, along with their skills, attitudes, and motivation. Process is the workflow, procedures, and habits that shape how work gets done. Technology is the tools, systems, and software they use. This breakdown follows Prosci’s explanation of the framework; Prosci is a firm that specializes in change management. Take new software as an example: the software is technology, but it brings a new way of working, which is process, and people who have to learn it.
According to Prosci, the framework builds on Harold Leavitt’s diamond model from 1965. Leavitt saw an organization as four tightly linked elements: task, people, structure, and technology. His thinking drew on sociotechnical theory, which grew out of British coal mines around the Second World War and the 1950s. There, a group from the Tavistock Institute, including Eric Trist, Ken Bamforth, and Fred Emery, worked with miners. In 1951, Trist and Bamforth published a paper whose title says it all: some social and psychological consequences of the longwall method of coal-getting. At the time, the common belief was that technology decided everything and people were an extension of the machine. The Tavistock group argued the opposite: the social and technical sides should be designed together so they work well as a whole, an idea they called joint optimization.
Going from four elements to three takes one step: task and structure are merged into Process. Each of the two merged elements has its own content, though. Task covers what work is done and how, including the decision rights attached to it. Structure covers who reports to whom, spans of control, and coordination mechanisms such as meetings, forums, and policies. Meanwhile, the definition of Process only mentions workflows, procedures, and habits, and People only mentions leaders who make decisions, without saying where decision rights between departments sit.
So when you use the triangle to review a project, it helps to split Process into two groups: workflows and procedures, and decision rights and coordination between departments. That way the three PPT factors still cover all four of Leavitt’s elements.
Why people, process, and technology have to move together
When one factor changes, the effect spreads to the others. A clear example is IBM Credit, the IBM subsidiary that financed customers’ purchases of IBM computers, software, and services, described by Michael Hammer and James Champy in their 1993 book Reengineering the Corporation.
At IBM Credit, a financing request went through five steps, each handled by a different department. An operator logged the salesperson’s request on a form. The credit department checked whether the customer qualified. The business practices department approved any changes the customer wanted to the standard loan terms. The pricing department set the interest rate. The administration department turned everything into a quote letter for the salesperson. The whole process took six days on average, sometimes two weeks, and according to Hammer and Champy, that was long enough for the customer to find financing elsewhere.
Two senior managers decided to walk a single request through every department themselves. The actual work took only about 90 minutes in total. The rest of the time the form was waiting in a queue or moving from one desk to the next. Hammer and Champy point out that even if every person worked twice as fast, the total would only drop by about 45 minutes, because the problem was the way the work was split up, not the speed of any one person.
Looking more closely at each step, they found a second problem. The whole process rested on the assumption that every request was unique and difficult, so it needed four highly trained specialists. In reality, most requests were simple, and most of the specialists’ work was clerical: finding a credit rating in a database, plugging numbers into a standard model, and pulling standard clauses from a file.
The fix was to stop handing work off. Instead of four specialists each doing one step, one person, called a deal structurer, handled a request from start to finish. IBM Credit built a new, easy-to-use computer system that gave this person access to all the data and tools the specialists used. With it, one person could do the four jobs that used to be spread across four departments: check the customer’s credit, review requested changes to terms, price the deal with the standard model, and write the quote letter from standard clauses. In most cases the system gave enough guidance for the deal structurer to proceed alone. For genuinely hard cases, they could call on a small pool of real specialists in credit or pricing, and the two worked together as a team, so there were still no handoffs. Turnaround dropped from seven days to four hours, the number of deals handled rose a hundredfold, and headcount fell slightly.
Seen through the PPT framework, IBM Credit did not just change its software; it changed all three factors at once. On Process, five handoffs became one person working a request end to end. On Technology, the new system let a generalist handle most requests. On People, the role shifted from doing one step to owning the whole file, while the strongest specialists were saved for the difficult cases. Had IBM Credit only bought software to make each department faster while keeping the five handoffs, the 45-minute calculation above shows the result would have barely changed.
Three lessons follow. First, the factors have to fit together for a change to last; fixing one piece in isolation does not work. Descriptions of the model put it well: new tools should not be held back by old roles, and a new org chart should not be quietly undermined by old processes. IBM Credit also shows that speeding up each department is pointless when the work still has to pass through five of them.
Second, technology should enable a new way of working, not just speed up the old one. In a 1990 Harvard Business Review article, Hammer put it as “stop paving the cow paths.” A cow path is crooked because it was made by cows, and paving it gives you a crooked paved road. Old processes often live in unwritten rules, such as credit decisions belonging to the credit department, or forms having to be filled in completely and in a set order. Put all of those rules into software and you end up with a system that runs the old way of working faster. Lidl shows the cost of that choice: the company adapted SAP to fit its existing process and stopped the project after an estimated €500 million.
Third, people and technology have to be designed together. This is the core principle of sociotechnical theory from the coal mines: each side pursues its own goals while depending on the other. When people and technology do not fit, you cannot simply expect people to adapt to the machine.
Before the rollout: what to review
This is a checklist for business owners to work through before signing a digital transformation contract or starting a project. If the company has not yet decided which area to transform first, our article on digital transformation strategy offers a framework for setting priorities; come back to these questions after that. I wrote these questions myself, based on the definitions of the three PPT factors and the examples above; they are not a standard set from any source.
Technology
- When a few employees try it on a real piece of company work, can the software handle it from the first step to the last?
- Does it enable a new way of working, or only make the old way faster?
- What does the digital transformation quote cover beyond features, price, and the acceptance date? Is redesigning the process and training users included?
Process: workflows and procedures
- Does the way of working the software assumes actually exist in the company, or does every department do it differently?
- Have the unwritten rules been written down and reviewed?
- Which processes need fixing before any code is written, and has the company set aside time for that?
Process: decision rights and coordination
- When two departments disagree on a form or a way of working, who makes the call?
- Is a senior leader directly sponsoring the project, or is it relying on department heads to reach agreement among themselves?
- Once the software is in place, who reports to whom, and how do departments coordinate?
People
- Who will use the software every day, and how will their work change?
- Were they consulted when the software was chosen?
- Who is responsible when incorrect data is entered?
One point worth noting: the decision-rights questions are the ones most often left blank, because they are not in the vendor’s quote and do not belong to any single department.
When results fall short: where to look
Suppose the company is in the middle of a rollout, or has used the software for a while, and staff still avoid it or results are below expectations. The checklist above still applies, but it helps to work through it in order, starting with the factor that is easiest to check, one factor at a time.
First, Technology: does the software do the job people need? Ask a few employees to complete one real piece of work from start to finish in the software, and watch where they get stuck. If they get stuck because the software lacks a function they need, the cause is in Technology, and the fix is to change or replace the software.
Second, Process: does the way of working the software assumes actually exist in the company? This is the step most often skipped, and it is where my own project ran into trouble. I worked on a digital transformation project for a company that trains workers and places them in jobs in Japan: 20 years old, among the market leaders, with branches across Vietnam and in Japan. Before the survey, I assumed a company of that size would already have clean processes and my job was to build software on top. When we surveyed the business, almost everything ran on Excel, the same order was entered again in several places, and HR, training, and administration each kept their own data. The project paused for more than a year to build a shared process across departments before any code was written.
That seemed to settle it, but once we started building the software, forms for the same record still differed between departments, and none of them would give way. When two departments disagree, who decides? The three PPT factors do not answer that on their own, which is why decision rights get their own group of questions.
Third, People: are the people who use the software every day being heard? IBM Credit shows that users cannot be an afterthought, because the employees’ role changed from doing one step to owning the whole file. On the other hand, if the root cause is in Process, more training will not solve it.
Here is a hypothetical example, not taken from any real company. A company already has accounting software, but at the end of each month someone still rebuilds the reconciliation in Excel. Can the software produce the report that person needs? Do the reconciliation rules, meaning who checks what and against which template, live in the software or only in the head of a long-serving employee? Was the person rebuilding the spreadsheet consulted when the software was chosen? Three different answers lead to three different fixes, and only one of them is changing the software. There may also be more than one cause: two, or all three. The questions only narrow down where to look; going there and observing is still up to you.
Applying the PPT framework in your company
Before choosing software, describe the work that needs to change: how it is done today, how long it takes, whose hands it passes through, and how it should work after the change. IBM Credit only found its answer by following one real request through every department.
Once the change is clear, use the questions in the “Before the rollout” section to review all three PPT factors, and assign an owner to each: who is responsible for the process, who has the authority to decide when departments disagree, and who supports users day to day. The time and cost of redesigning processes and training should be in the plan from the start, because a digital transformation quote usually does not include them.
Before rolling out company-wide, run a pilot with a small group on a real piece of work, then use the three steps in the “When results fall short” section to fix what does not fit. After the rollout, pick a few metrics tied to the original goal, such as the time to process one request, and review the three PPT factors regularly, because, as Prosci notes, people easily slip back into old habits.
Frequently asked questions
What should business owners review before a digital transformation project?
All three factors together: technology, process (including decision rights and coordination between departments), and the people who will use the software. The article includes a set of questions for each group, written by the author from the framework’s definitions.
A digital transformation project is underway or finished, but results are disappointing. Where should I look?
Work in order: test a real task in the software (Technology), check whether the way of working the software assumes exists in the company (Process), then talk to daily users (People). The cause may sit in more than one factor.
What is the People, Process, and Technology (PPT) framework?
It is a way of looking at a change to processes and technology in a company through three factors that have to be considered together: people, process, and technology. Changing one factor affects the other two. According to Prosci, it builds on Harold Leavitt’s diamond model from the 1960s.
How is PPT different from Leavitt’s diamond?
Leavitt (1965) has four elements: task, people, structure, and technology. Later, task and structure were merged into process. The point to watch is that structure, meaning reporting lines, decision rights, and coordination, no longer has its own name in the PPT framework.
Do you have to go in order: people, then process, then technology?
No. The three PPT factors are a way to make the three factors fit each other, not three steps done one after another, and the original model does not require a fixed order. My project finished the process work before any code was written, but that was how that particular project was sequenced.
Two moments to remember the three PPT factors
When software fails to deliver, everyone has usually done their own part: the vendor delivered what was agreed, staff kept working the way they always have, and the person who paid ends up with a result nobody can explain. The three PPT factors give you three places to check, once before signing the digital transformation contract and once when results fall short. In my project, the factor that was most underestimated was Process.
Thank you for reading this far. In your company’s most recent project, when the technology did not deliver what you expected, which factor do you think the cause was in? I would love to hear your view in the comments.
Sources
- ACMP, Statement of Change Management (2012)
- Prosci, People, Process, Technology Framework
- Umbrex, Leavitt Diamond
- Newcastle University, Socio-Technical Theory
- Wikipedia, Sociotechnical system
- Michael Hammer, Reengineering Work: Don’t Automate, Obliterate (HBR, 1990)
- Lumen Learning, the IBM Credit case
Leave a Reply