Projects AREN’T the best way to implement new practices

We need to improve the pick/pack/ship process for customer orders in the warehouse – let’s do a project. Our cycle times in manufacturing are too long; we need to shrink them – let’s do a project. Our forecast accuracy is terrible – let’s do a project. We need to reduce inventory – let’s do a project. And on and on. The project construct has become ubiquitous in the enterprise as a vehicle to implement something new. It is the preferred approach to change existing structures in the work environment and there is a vast industry of consulting businesses who live off the need to staff and manage these projects. In my experience, though, the project paradigm is not very successful at actually changing people and the work environment.

In order to focus this article let’s assume, for practical purposes, that we are speaking of projects in the context of the implementation of an IT system; or in the context of so-called continuous improvement projects, both of which most readers will be familiar with.

Projects are great at creating things, not at changing people

A project is a structure that entails a few things: there is a scope – something to accomplish; there is some methodology to achieve that scope – the work to be done; and there is a team with roles and reporting lines – the people who will do the work. And, there is a Project Manager. 

This structure was not invented to change work environments, the way people work and especially not culture. Projects as a structured approach began in Construction, Aerospace and the Military and are effective at producing infrastructure – that’s what they are good for. 

Here’s an example: an Enterprise kicked-off a project to improve the accuracy of Demand Forecasts. A piece of infrastructure was needed – a tool to automate statistical forecasting. The project was successful at configuring and installing the tool. But it failed at changing the way people work, other than the training on how to use the tool. For instance, one of the main problems in this situation was that multiple groups in Marketing and Sales didn’t share information amongst themselves and didn’t bring that information to Demand Planners. The great affliction called Silo-eeze got these various groups working in isolation from each other, information was not shared and so Demand Planners were isolated from the knowledge of Markete and Customer dynamics. The project team and the project process was incapable of changing this situation – and why? For two reasons:

• Projects such as these are not in the operation, they are external to the operation. 
• Projects are good to produce things that are well defined and that can be done by carrying out a limited number of activities over a limited period of time. Changing the way people work, the flow of work from one group to the other, how the organization reacts to market events – these are not things that can be defined clearly and the way to accomplish it can’t be neatly packaged in predictable activities.

I wrote in another article that the classical linear process where tasks flow in an established sequence only cover part of what happens in the real world. Handling the variety of exceptions that dominate day to day work life requires that individuals interact with one another in ways that improvise action pathways not established in prescribed process flows. Changing how these interactions occur relies on changing how people understand each other’s roles and quite often helping them move away from silo behaviour. That speaks to changing aspects of culture, something for which you can’t really establish a neat list of activities.

Another classical example, which I’ve recently witnessed in two organizations, is a project to implement an ERP. The project succeeded in that the ERP system is now in place. However, the practices surrounding that new infrastructure are still pretty much the same – no improvement. People are essentially doing what they were doing before but with new tools.

Projects not being successful at changing practices in the work environment happen even if there is no infrastructure involved. For instance, a Manufacturer started a project to reduce production cycle times. A team of people from the operation was established and proceeded to figure out how to shrink cycle times. It took forever but eventually they came up with some ideas. Some of them were implemented but the end result was a reduction in cycle time that was rather modest and the reason is simple: nothing fundamental really changed. By the most part, the work environment and underlying practices remained the same and only minor tweaks here and there were really implemented. 

In another project, a Manufacturer started an initiative to create streams of continuous flow in the operation. A team was created and began a pilot. It worked modestly but the rest of the operation remained the same. Eventually, the whole thing died because nobody figured out how to port what had been learned in the pilot to the general population.

But even if, in this latter case, for instance, you established a mechanism to port new practices learned in the pilot to the general manufacturing population, it’s still long, costly and burdensome because of the training and change management required. 

Thus, even if a project is able to accomplish change in the work environment, it takes long, it consumes a lot of energy and an enterprise will always have a hard time doing many projects that actually succeed. 
There is a better way

We call it immersed change. It says that you follow these principles when managing operations:

• The current way of doing things is permanently in a ‘beta’ version. It’s never final and it’s not even static for very long. Organization, roles, processes, methods – everything is constantly evolving, it is never “the best way”.
• Changing processes is part of doing work. I.e., your job is not only to do the work but to change the way work is done. 
• Creating new ways of doing things is an integral part of the job. Not only are you expected to implement new approaches, you collaborate with colleagues at creating new approaches – it’s part of the job.

Thus, the things you would often find in projects are immersed in the work environment; they are not separate from the work environment.

The traditional paradigm is like this: the operation, in its current state, works in an established way – expressed by SOP’s and job descriptions. “This is how we do things”. Then, over there, there is a project team who is defining a new ‘version’ of how the operation will work. When they’re ready, they will train the people in the operation in the new way. 

In the immersed approach, when something doesn’t work, people in the operation and within the work enviornment, evolve a new approach and when they’re done, the new approach is already ‘live’. Since they were the ones defining the new way of doing the work and they are the ones who actually do the work, there is no need to train – they just start doing things the new way.
In a social model, the immersed approach is second nature

When people in a work environment operate in a social model – working through networks of dynamic collaboration – the immersed approach is almost a natural bi-product of the social model itself. People are already together in a virtual space, you don’t need to “bring them into a space”. They are constantly using pathways of action that are dynamically derived by the network, they don’t follow rigid process flows. Processes are actually multiple pathways of people combining their skills. If things don’t work well, new pathways  are invented.

I once worked at a CMO (Contract Manufacturer) and witnessed one such community network invent a new service that this CMO began offering to Clients. A Client asked them to perform a service that they could perform but didn’t know how to bill for. CMO’s typically work on materials and thus they ship and bill for materials. In this case, there was no material involved and the work was actually performed by external 3rd parties. So, the folks in the community started discussing the problem, one thing led to another and before long they had figured out how to configure the service so that they could bill for it even though no material was involved.

How do you combine projects with the immersed approach?

Projects are excellent at creating new infrastructure. So how do we go about handling a need where we have to bring in new technology but we also need to change the way people work?

I once carried out a project using the immersed approach and here’s how we did it:

• I brought in 3 consultants who were experts in the new technology and knew how to configure it. Only them, no Change Management people, no overhead, just the guys who actually set-up the technology.
• I didn’t create a team of dedicated resources from the operation; and I didn’t allow any workshops for these consultants  to “assess the As IS”, collect “requirements”, design a new “To Be” and then to train my people on the latter.
• Since the people in the operation were already working in a social model, I connected the consultants into the community and so the people who were doing the work were also defining new ways of doing the work, through conversations with these consultants; and the latter were figuring out how to configure the technology to suit new approaches; and, at the same time, they could validate their thinking with the people in the operation.
• Once the technology was ready, people in the operation were already prepared to use it, minus training in the use of actual software functionality. They didn’t need to go through ‘indoctrination’ in new ways of thinking, get used to new roles, etc. Since they were in a state of constant change and they were the ones defining the new way, they were ready to start. Thus, training took a short time and transition was not an issue.

The immersed approach is less costly

In the immersed approach, most of the work to design a new process is always done by people in the operation, fused into their day to day work. You only hire external expertise for the skills that you don’t have and don’t want to keep in house, rather than hiring consultants because you don’t have enough people.

In the project approach, not only there is a cost of designing new processes, there is also the cost of transferring the knowledge of the latter to the people in the operation. In the immersed approach, these two cost components are absent.

Thus, the approach isn’t just more effective, it costs less than a pure project approach.

In Summary

Our society is going through a phase of massive change and so is the Enterprise. A Project is a construct that fits well in a world dominated by Command and Control structures. But the Enterprise is evolving from a ‘military’ model to social models of great speed and adaptability. We are no longer limited to approaches that impose rigidity, formality and high costs. We can do things in a much simpler way.

In a “command and control” mentality, it makes sense to define changes in the operation outside of the operation; and then insert those changes into the latter. We clinically ‘package’ the future and then deliver it, as it were.

A much better approach – more effective, faster, less costly – is one where, if work needs to change, those who do the work change the way it’s done. Thus is the essence of the Immersed Approach.