Change management

For some time now, my colleagues and I have been struggling to optimize the change management process. We have already achieved some successes, but there is (first of all, project managers) a very strong feeling that all this is not enough.

Project: A platform product is being finalized by engineers to meet customer requirements. We have pieces of iron, so we have a production (assembly) of the numerous components that we order from third-party suppliers.

What is Change? Our product has a Platform: a basic device on which all the requirements of the buyer and his infrastructure are “hung” from above. When we come to the buyer with the price - it is for the Product. Product = Platform + Specificity. A product is what will be described in Specifications and TK. But then work begins on detailed design and preparation for production. And here Changes begin. Change is the Delta to the Product. That is, Sold_Product + Delta = Produced_Product.

We have different sources where changes are coming from:

Buyers demand
Customers use our devices in the existing infrastructure and sometimes it is simply impossible to find out all the details with which the device will have to work before the project begins. And as we are not trying to foresee everything at the stage of the ToR, all the same, “unaccounted factors” constantly come out. Sometimes buyers suddenly make changes in the middle of a project, but here we can at least figure it out and add to the bill, but when nothing has changed, but we only now understand something about the buyer's infrastructure - this is purely our cost.

Component Provider Change
We have a lot of a wide variety of components in the device, so if the supplier changes, you may need to adapt the design of the device to the components of the new supplier. Sometimes we ourselves change the supplier, because the other is cheaper / faster / better, and sometimes life makes us. To reduce the cost, we try to use catalog components, but sometimes because of this we have to “adjust the file” to other parts.

Optimization by engineers
In general, engineers play a leading role in our projects. If not they - there will be nothing for collectors to collect, and sellers to sell. But great strength comes with great responsibility - it is engineers who will run everything in a row, so that they think about the structure and make it cheaper / standard / modular / reliable / simple / ideal. And they do it. Therefore, from this source we have the most changes.

Production Optimization
The first wave of changes occurs at the Mock-up stage (this is when we make our product from clay and branches and show it to the customer, after which he is usually horrified and clarifies / removes / adds some requirements). At this stage, our colleagues from the production department and the buyer already give the first feedback to the engineers. The second wave of change is when the prototype is ready. A prototype is an assembly of the first Device. If everything has grown together the first time, then this will be just the first of a series. If something doesn’t work, then the second wave of change will come from here. The third wave - with the full start of mass production. Then it begins to become clear, for example, that something is faster to twist than to solder. The fourth wave is when the last devices have not been manufactured yet, and the first ones are already working and warranty cases begin to happen with them.

Lessons from other parallel projects A
lot of Products in different projects have already grown from our Platform. Some projects go simultaneously and those that go a little earlier already give feedback to both colleagues from the Platform (who also constantly refine our base product) and those who complete the design of current projects. This may be a lesson such as “do not use supplier X, its quality is not very good” or that some design changes were not accepted by customers or that something is then constantly returned under warranty to this other project, etc. We very closely monitor other projects of our company and worry about colleagues and try to take into account their mistakes to the maximum or adopt success stories. And those projects that are just starting now, in turn, receive information from us.

***

As you can see, with so many sources of changes and stages in the life of the product, changes are not only inevitable, but also numerous. And they can even be avalanche-like (for example, after mock-up). Moreover, each change may affect the chain and suppliers and other departments. Therefore, we implemented the process of managing these changes and appointed the person responsible for Change management in the project.

When someone wants / needs to change something, they first formulate the changes and present them to the Responsible for changes (in common parlance, he is a traitor at us, but not everyone likes this name). He looks at the change and then coordinates with each department (Engineers, Production, Purchasing, Sales), on the one hand, the technical meaningfulness of the change, and on the other, its value.

The cost of change consists of two parts: the cost of the change itself and the cost of its consequences.

For example, engineers say: it takes us 120 hours to make changes to the design, but we can buy a simpler component from suppliers (cheaper by X money) and we will save 5 hours during production.

And then from these costs of changes minus the consequences of changes, we get the economic feasibility of the changes. It also happens that we are not talking about subsequent savings, but about improving reliability and it seems that change only costs us more. In this case, you need to bring in the warranty department and calculate the savings on warranty service. Actually, the warranty department should always be involved. And sometimes it seems that you can simply remove one of the screws and now the savings, but in a year this savings will pour into us flying parts and every second device is returned under warranty. Below we will tell such a story.

So, first a technical assessment, then an economic one. Now we need a temporary assessment: the planning department comes and says: guys, of course, you have come up with all this great, but if we do this, we stupidly according to the plan will not have time to finish and deliver all the devices in time. Then we connect sellers and buyers. Buyers go to suppliers and press for them to make / deliver components earlier (sometimes for money, sometimes for payment deadlines, sometimes out of love for working with us). Sales people go to the buyer and say: “we figured out how to make our device 0.1% more reliable, but we need a little more time. Can we deliver without fines a week later? ” With such an argument, you can usually agree. But when our device becomes cheaper, it is already very difficult to explain this to the buyer.

But, sorry, we ran a little ahead.

Each change, regardless of the source, is entered by the initiator into the registry. Notification of addition is received by the Modifier. He discusses the change with the initiator and pushes him further on a technical and economic assessment by department. When an assessment is received from each department, it is added to the total cost.

In practice, the changes that we have (these include changes in software, hardware, processes and suppliers) can be up to a thousand per project. Running around with every change is a waste of resources. Therefore, we have implemented certain threshold values ​​for some indicators: Cost of Change, Cost of Consequences, Change of Time. Relatively speaking, if the change does not lead to a change in time, it saves an hour during assembly and requires two hours from engineers and does not cause rejection in all departments, then we simply transfer it to the “Approved” status immediately.

Once a week we spend an hour discussing the registry of changes. This is a Change Board meeting. There is a project manager and a representative from each department.

If the change exceeds the thresholds, then we will discuss it in detail at the meeting and the change will not be approved until it has been approved by the Board. Small changes are simply summarized by the Changer at the same meeting. Yes, it so happened that the change, which at first seemed small and was casually mentioned on the board, suddenly caused a storm of unaccounted factors. Sometimes it is caught on a board, sometimes it just happens.

Stages:
“We came up with” - “We rated” - “We talked” - Approved or Rejected

The board may reject the change. In this case, the rationale is written and the change remains in the registry with the status Rejected. Engineers themselves, already separate from Traitors, sometimes get together and discuss rejected changes. Sometimes changes return from this status again to the status of “We came up with”, because the engineers figured out how to change it, so that it becomes more appropriate.

If the change was approved, then the work of the Changer does not end there. He coordinates the process so that all participants understand what, how and when to change and tracks real bones. Because it happens that the engineers say: we will do it in 50 hours, and then it suddenly turns out that it’s not so simple and real they spend 100 hours on it. Or the manufacturers say that this change will make the assembly faster by 20 minutes, but in practice nothing changes.

Once a month, the Board makes an extended meeting to discuss changes that have already taken place - as it turned out in practice. It happens that improvement leads in practice to additional costs. Sometimes engineers say that yes, sorry, a mistake has come out, it is somehow worse, but it might be better in a guarantee. To do this, we have to wait another year or two.

History: Once the consequences of change overtook us three years after the end of one project. A serious change came to the board. The boards of two projects, which were at about the same stage and generally very similar, came simultaneously. The change was expensive, in a serious component, but the engineers promised increased reliability and simplified assembly. Project A hesitated and approved. Project B hesitated and rejected. Project A laid out money to finalize the design. The estimate turned out to be very approximate and the total cost of changes exceeded the estimate by half. Project B giggled and rejoiced for himself. When assembling in Project A, it turned out that this wasn’t a simplification, but even vice versa. Project A with the mat was thinking about whether to roll back the change (it was already too late) and spent more money on the assembly. Project B was already laughing. Projects surrendered, delivered to customers on time. The first year - the flight is normal. Project A at lessons learned regrets the money spent, as the project’s profit in the end turned out to be more modest than expected. The second year - the flight is normal. The third year is the last year of the warranty. And here it exploded in Project B. The “serious component” rained down without any modifications. A third of the devices returned to almost complete reassembly. Costs ate all the profits. Thanks to Change, Project A devices survived this year in complete relaxation. Changes to the “serious component” suddenly paid off after three years. A third of the devices returned to almost complete reassembly. Costs ate all the profits. Thanks to Change, Project A devices survived this year in complete relaxation. Changes to the “serious component” suddenly paid off after three years. A third of the devices returned to almost complete reassembly. Costs ate all the profits. Thanks to Change, Project A devices survived this year in complete relaxation. Changes to the “serious component” suddenly paid off after three years.

The most difficult thing to work with changes is their coordination after approval. The board approved, the engineers did their job, made changes to the design and are sleeping peacefully. But to make sure that all changes have reached the purchasers, from them to the suppliers of components, manufacturers and other participants - this is where the work of the Changer is best manifested. Especially if changes occur after the start of production. Because here it is extremely important, together with the person responsible for production, to understand in which devices changes have already taken place and in which there are none, to discuss with everyone what to do with the already assembled ones (to reassemble, use in another way or deliver as is), to have time to convey to the suppliers, that we need another component, when we have already placed an order for the entire batch, rewrite the instructions and drawings for the assembly. The cheater is not the one who does all this, but it is he who runs between everyone and kicks so that everything happens and no one forgets anything. In our memory, there were meetings when people sat down side by side and walked around the table with a pencil, ticking off what had been done and what wasn’t, and then signed this table. It's terrible that in our age of high technology in the production of high-tech devices, we still resort to checkmarks in the plates, but sometimes this is the only way. To track the life of the Change, we have implemented a series of different statuses of the change, so that it is clear what, for example, we have already discussed with purchases and what is not yet. Between the status of “Approved” and the status of “Fully Implemented” there are two dozen more statuses between which the change jumps. when people sat down side by side and walked around the table with a pencil, ticking what was done and what was not, and then signed this table. It's terrible that in our age of high technology in the production of high-tech devices, we still resort to checkmarks in the plates, but sometimes this is the only way. To track the life of the Change, we have implemented a series of different statuses of the change, so that it is clear what, for example, we have already discussed with purchases and what is not yet. Between the status of “Approved” and the status of “Fully Implemented” there are two dozen more statuses between which the change jumps. when people sat down side by side and walked around the table with a pencil, ticking what was done and what was not, and then signed this table. It's terrible that in our age of high technology in the production of high-tech devices, we still resort to checkmarks in the plates, but sometimes this is the only way. To track the life of the Change, we have implemented a series of different statuses of the change, so that it is clear what, for example, we have already discussed with purchases and what is not yet. Between the status of “Approved” and the status of “Fully Implemented” there are two dozen more statuses between which the change jumps. that in our age of high technology in the production of high-tech devices, we still resort to checkmarks in the plates, but sometimes this is the only way. To track the life of the Change, we have implemented a series of different statuses of the change, so that it is clear what, for example, we have already discussed with purchases and what is not yet. Between the status of “Approved” and the status of “Fully Implemented” there are two dozen more statuses between which the change jumps. that in our age of high technology in the production of high-tech devices, we still resort to checkmarks in the plates, but sometimes this is the only way. To track the life of the Change, we have implemented a series of different statuses of the change, so that it is clear what, for example, we have already discussed with purchases and what is not yet. Between the status of “Approved” and the status of “Fully Implemented” there are two dozen more statuses between which the change jumps.

“Fully implemented” is also not the end of the Change with the change. The change is still not just present in the registry, but departments also enter information on actual costs and the change is viewed on the Board in the general registry. After the end of the project (release of all devices and transferring them to the buyer), the registry of changes together with all the other project good is transferred to the warranty department. They will enter there information on how the change in the warranty phase behaved, whether it led to additional savings or costs.

How we track real costs: each change is assigned an identifier. When it comes time to distribute, for example, the hours of engineers, they distribute them between projects and inside the project between topics, and inside the topic: “Changes” between different changes using just identifiers. The price of components is more complicated - it comes in fact one apiece. Usually, in order to understand the changes, we ask suppliers two proposals: for the part with the change and for the part without the change. The difference between these two sentences is the material bones of our change. Manufacturers do the same.

It is worth noting another stage in the life cycle of change. It happens already outside the project in which it happened. Those changes that in the long run have proved that they deserve and bring real savings are brought to the change boards of current projects and to the platform change board. Remember, we told at the beginning that our Product is a modified Platform. So the platform also does not stand still. And changes in small projects often have an impact on the development of the Platform. Sometimes the Variations of the Platform budge from this, and sometimes they make changes to the database.

That's about how we work with changes. This, of course, is a brief introduction to the changes. Maybe we have not described any of the stages right now, not because they forgot about him, but because he seems to us to be taken for granted. We will be glad if you share with us

PS: We have already added this article and let our colleague see it. He sighed and said that there were too many words where three or four flowcharts could be added. But our experience shows that many people have difficulty reading flowcharts and narratives usually go easier. How about you?