Every organization I have been part of has grown, evolved, or shifted priorities. Some even entered new markets. With these changes, their processes needed to evolve as well. When the process doesn’t evolve it risks becoming disconnected from the organization. Conversely a process that changes too often has the same risk.

We had a process created by our project management office which required developers to track time against the activities required to complete projects. That data was then used for capacity planning for future projects. Finance saw this data and realized how it could help with capturing labor costs as operational or capital expenditures. When finance realized that salaried employees would often report more than forty hours in a week they added a control onto the process to limit what could be recorded. They also realized that several non-project related activities were not being captured (travel, training, etc) so they started adding those non-project items to the required tracking. All of this made sense for their purposes and was hard to argue against. The result was all salaried employees were now reporting between thirty-five and forty hours per week regardless of how much they actually worked. Within a few months, both team managers and project managers realized that they had lost the ability to see where people were actually spending their time. The original purpose was lost without anyone making a decision that the purpose was no longer needed by the organization.

I encountered a similar tension at another organization where I was the CTO. The CFO needed that same capex/opex data and was asking for the same changes. This time though we talked through the tradeoffs and agreed to keep the time tracking process focused on capacity and project planning. However, I would then transform the resulting data into what he needed. Had we decided that capacity and project planning was no longer required, I would have deliberately changed the intent of the process.

The same pattern appeared in an IT governance intake process. Teams started using the process for ideas which were not approved projects. In order to prevent unapproved projects from entering governance a project ID was added as a requirement to enter intake. This seemed like a reasonable response to the problem, however, we missed a major impact. The process that issued project IDs existed for only one business unit, so approximately one in three projects could no longer enter governance.

I don’t believe that adding a new requirement automatically changes or undermines the intent of the process. Adding new controls is often the right thing to do. Processes evolve and boundaries change, and the organization can decide that it requires the process to accomplish something different. Changes should be made deliberately. And with an understanding of their impact on the outcome.

The next time someone proposes another gate, approval, required field, or control don’t just ask if the change is justified. Ask what happens to the process’s intended outcome.