The hidden cost of running two processes

Consultancies love process. It is easy to explain, it looks good in a pitch, and it makes an unfamiliar team feel safer to hire. In a project where the team works inside your company, it is also a cost quietly handed to your own engineers.

Who actually pays

Two processes in one project means two boards to keep in sync, two definitions of done and two sets of meetings. On top of that, someone has to translate between them. In practice that layer is staffed by whichever engineer on your side is the most conscientious. They will not send you an invoice for it, and they will burn out about five months in.

• Project status becomes a negotiation between two sources of truth, instead of a simple fact.
• Estimates drift, because the two systems measure work in different units.
• Your engineers stop trusting the external board and start keeping a private mental version. That version is now your real project plan.

Adopt it, do not argue about it

Our rule is that we give our opinion once, in writing, at the start. It is usually about testing or about keeping environments in sync, and occasionally about branching. After that we use the client's system as it is, including the parts we think are wrong, and we only revisit it if the data supports us after three months.

This costs us something. Our engineers sometimes work with tools they dislike, and our internal reporting has to pull together several different client systems instead of one of ours. That is the right place for the friction to sit — with the company that chose to be flexible, and that is being paid.

If your process improvements require the client to change first, they are not improvements. They are conditions.