Change management

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

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

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

We have different sources from which changes are growing:
')
Buyer Requirement
Customers use our devices in the existing infrastructure and sometimes it’s just impossible to know all the details before the project starts, with which the device will have to work. And just as we do not even try to foresee everything at the TK stage, “unaccounted factors” constantly emerge. Sometimes buyers suddenly make changes in the middle of a project, but then we can at least calculate and add to the bill, but when nothing has changed, but we just now understand something about the buyer's infrastructure - this is purely our cost.

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

Engineer Optimization
In general, engineers play a leading role in our projects. If they are not, then there will be nothing for collectors to collect and salesmen to sell. But great power comes with great responsibility - it will be engineers who will run everything in order to think over the design 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 out of clay and branches and show it to the buyer, after which it is usually terrified and specifies / 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 it will be just the first of the series. If something did not work out, then the second wave of changes will come from here. The third wave - with the full start of mass production. Here it becomes clear, for example, that something is faster to twist than solder. The fourth wave is when the last devices have not yet been manufactured, and the first are already working and warranty cases begin to happen to them.

Lessons from other parallel projects
Quite a few Products have already grown out of our Platform in various projects. Some projects go at the same time and those that go a little earlier, already give feedback to colleagues from the Platform (who are also constantly refining our base product) and to those who are finishing the design of current projects. This may be a lesson like “do not use supplier X, his quality is not very good” or that some structural changes were not accepted by buyers or that something then constantly returns under warranty to this other project, etc. We very closely monitor other projects of our company and worry about our colleagues and try to take into account their mistakes to the maximum or adopt success stories. And those projects that are now just beginning, in turn, receive information from us.

***

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

When someone wants / needs to change something, they first formulate the changes and present them to the Responsible for the changes (in common parlance, we have it Perementior, but not everyone likes that 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 cost.

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

For example, engineers say: in order to make changes in the design, we need 120 hours, but then we will be able to buy components from suppliers easier (cheaper for X money) and we will save 5 hours during production.

And then from this cost of change, minus the consequences of change, we get the economic feasibility of change. It also happens that this is not about further savings, but about increasing reliability and it seems that the change only costs us more. In this case, it is necessary to attract the warranty department and calculate savings on warranty service. Actually, the warranty department should always be involved. And sometimes it seems that you can just remove one of the screws and now the savings, but this savings in a year will result in us flying off parts and every second device will be returned under warranty. Below we will tell this story.

So, first a technical assessment, then an economic one. Now we need a temporary assessment: the planning department comes and says: guys, you, of course, have come up with all this great, but if we do this, then we stupidly do not have time to complete and deliver all the devices in time. Then we connect salespeople and purchasers. The buyers go to the suppliers and pressure them to make / deliver the components earlier (sometimes for money, sometimes for payment terms, sometimes for the love of working with us). Salespeople 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 penalties a week later? ”With such an argument, you can usually agree. But when our device becomes cheaper, it is already very difficult to explain it to the buyer. Sometimes (if the savings from a change are directly very substantial), we can share with the buyer, sometimes we deliberately delay delivery (in this case, penalties for the delay become part of the cost of the effects of the change).

But, sorry, we ran a little ahead.

Each change, regardless of the source, is made by the initiator in the registry. Addition notice receives a Modifier. He discusses the change with the initiator and pushes him further on technical and economic evaluation by department. When an estimate is received from each department, it is added up to the total Cost.

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

Once a week we spend an hour discussing the registry of changes. This is a change board meeting. It is present and the project manager and a representative from each department.

If the change exceeds the thresholds, then we discuss it at the meeting in detail and the change will not be approved until it has been approved by the Board. Small changes are just briefly explained by the Non-negotiator 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 unrecorded factors. Sometimes it is caught on a board, sometimes it just happens.

Stages:
"We came up with" - "We appreciated" - "We talked" - Approved or Rejected

The board may reject the change. In this case, a justification is written and the change remains in the registry with the status Rejected. The engineers themselves, already separate from the Amendors, sometimes gather and discuss the rejected changes. Sometimes changes come back from this status back to “We invented” status, because the engineers have figured out how to change it so that it becomes more appropriate.

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

Once a month, Bord makes an extended meeting, where they discuss the changes that have already happened - as it turned out in practice. It happens that improvement leads to additional costs in practice. Sometimes engineers say yes, sorry, the error came out, some kind of deterioration, but it might be better in the guarantee. To do this, we will have to wait another year or two.

History: Once the consequences of a change overtook us three years after the end of one project. A major change has come to the board. It came simultaneously to the boards of the two projects, which were approximately at the same stage and generally very similar. The change was expensive, in a serious component, but the engineers promised to increase reliability and simplify assembly. Project A hesitated and approved. Project B hesitated and rejected. Project A laid out the money to refine the design. The estimate turned out to be very approximate and the total cost of the changes exceeded the estimate by half. Project B giggle and happy for myself. When assembling in Project A, it turned out that this was not a simplification, but quite the contrary. Project A with the mat thought about whether the change would be rolled back (it was too late) and spent more money on the assembly. Project B was already laughing. Projects surrendered, delivered to customers on time. The first year is normal flight. Project A on lessons learned regrets about the money spent, since the project’s profit turned out to be more modest than expected. The second year is normal flight. The third year is the last year of the guarantee. And here it exploded in Project B. “A serious component” fell down without any modifications. A third of the devices returned to almost complete reassembly. Costs ate all the profits. The Project A devices, thanks to Change, survived this year in complete relaxation. Changes in the “serious component” suddenly paid off after three years.

The most difficult thing about working with changes is their coordination after approval. Bord approved, the engineers did their work, made changes to the design and sleep well. But to make sure that all changes have reached the purchasers, from them to component suppliers, production workers and other participants - this is where the work of the Modifier is best manifested. Especially if changes occur after the start of production. Because here it is extremely important, together with the production manager, to understand which devices have already changed and which are not, discuss with everyone what to do with the already assembled ones (reassemble, use differently or deliver as is), 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 assembly. The changer is not the one who does all this, but it is he who runs between everyone and kicks so that everything happens and nobody has forgotten anything. We had meetings in our memory when people sat side by side and walked around the table with a pencil, ticking off what had already been done and what had not, and then signed the table. It's terrible that in our age of high technology in the production of high-tech devices, we still resort to ticks in the tablets, but sometimes this is the only way. To keep track of life changes, we have implemented a whole series of different change statuses, so that it is clear that, for example, we have already discussed with purchases and what have not yet. Between the “Approved” status and the “Fully implemented” status there are another two dozen statuses, between which the change jumps.

“Fully implemented” is also not the end of the Modifier’s work with change. The change is still not just present in the registry, but the departments also contribute information on actual costs and the change is viewed on the Board in the general registry. After the end of the project (the release of all devices and the transfer of them to the buyer), the register of changes along with all the rest of the good of the project is transferred to the warranty department. They will enter there information about 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 watches of engineers, they distribute them between projects and within the project between themes, and within the theme: “Changes” between different changes using just identifiers. With the price of the components more difficult - it comes in fact one apiece. Usually, in order to understand changes, we request two offers from suppliers: for a part with a change and for a part without change. The difference between these two sentences is the material bones of our change. The production workers do the same.

It is worth noting another stage in the life cycle of change. It happens already outside the project in which it took place. Those changes that have proved in the long term that they deserve and bring real savings are brought to the boards of changes to current projects and to the board of changes to the Platform. 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 influence the development of the Platform. Sometimes Platform Variations budge out of it, and sometimes make changes to the base.

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

PS: We have already finished this article and gave it to a colleague. He sighed and said that there are too many words where you can add three or four process flow diagrams. But our experience shows that many people hardly read flowcharts and the narrative is usually easier. How are you?