- Change for change’s sake is a mistake.
- Introduction of new processes, tools, technology, or methodologies into a project will blow any reasonable guess at a timeline.
- Throwing people at problems doesn’t solve them, it just makes it worse.
- Lack of change management is analogous to planned chaos.
- Process methodologies are philosophies, not standard operating procedures.
Change for Change’s Sake
Some old clichés come to mind. If it ain’t broke, don’t fix it. Why reinvent the wheel? It is okay to be the voice of reason and present the been there, done that in the face of change. New people tend not to be too excited to dig into corporate history to see what has been attempted and what learnings were produced. There is an oral history obtainable through discussions with the old timers that you won’t find in documented reviews, because failures tend to get less documented attention. It’s good to do a little research beforehand to discover if there is an audience for the change. I think of this as the counter to Einstein, who said crazy is doing the same thing and expecting a different result. In this case, crazy is doing something different and expecting the same result.
Injection of New Increases Uncertainty
We’ve all been here. We have a new project and we really want to try out the latest silver bullet trend. It is, after all, exciting to try new things. The only issue is that finding expertise on new is impossible. You learn by doing. You learn by making mistakes. And by that time, you’ve invested so much time in it, you wonder why you didn’t use something proven because you could have, in hindsight, done it in a fraction of the time. New things just haven’t had the burn in time, or the evolutionary filters to prove they have the survival stuff. So, if you are on a critical project, reject new like it was the plague.
Mythical Man Month
Sometimes we have tight schedules and we figure it is easy to throw resources at problems to get tasks done in parallel. We know there is a logistical overhead. But there is also a quality and consistency hit. With brief training, not all temporary workers will produce the same quality work. They likely have a different understanding of what the task is than their peers. So it makes sense that we have a quality control group. It makes sense to do a lot of level setting, and knowledge sharing, between project folks even when they’re on parallel tasks. Though it is super tempting to keep our heads down and focus, and maybe even entertain cutting out things like testing and quality control, it really is the worst decision we can make (because we put controls in place to reduce risk.)
Change Management Good
Change management is all about reducing risk. You don’t want feature creep. You don’t want interruptions. You don’t want to get hijacked by low value, high complexity, and quite likely pointless flavour of the day type distractions. They are distractions. Work the plan. If it isn’t documented, and signed/authorized by someone in authority, be prepared to defend yourself when things go south because the execution of unmanaged change is the fault of the execution team, and the originator of the change will choose not to remember the expensive, out-of-band change request. Even if they do remember, it will be your fault because you were never asked to foul the timeline.
Change needs to be communicated gently to all stakeholders. And too much change is a bad meal because an organization can only digest so much of it at a time.
Methodologies are Not Holy Scripture
Thou shalt not treat all problems as nails and methodologies as hammers. Methodologies are guidance. They are good philosophies that apply in certain contexts. If you try to regiment a philosophy, be prepared to waste time dealing with exceptions. For example, DMAIC is for process improvements where the process has a good level of maturity. DMADV is for new processes in organizations that have good understanding of maturity. PDCA is better for immature processes. Like living things, some ideas are only viable in certain environments. Know your environment. Pick fit for purpose and settle on just enough method to attain incremental improvements and/or consistent quality.
So this is my sage rambling of the day. Enjoy.
