More process doesn’t help
Over the last weeks, I’ve been to three different conferences where I heard presentations that were variations on a common theme: if we would just add more structure and more process to the topic at hand, if we would only introduce more steps, more checkpoints, involve more people, and so on, then all the problems we’re experiencing with this product road-mapping, these innovation initiatives, these business development activities, would magically disappear.
Although most would agree that this is obviously wrong, the fact is that in many companies, universities and government institutions, this is exactly what happens. The organization experiences some kind of problem, perhaps even one that may be exposed in the media and makes management look bad, resulting in a top-down order to “fix it”. The subsequent process is obvious for those that have been part of it. First, there’s an activity to describe the process that led up to the issue surfacing. This is followed by a review of all the actions and other factors, with the intent of identifying what went wrong. Finally, a new process is introduced or an existing process is updated to address the perceived limitations, holes or weaknesses in the current way of working.
Once introduced, the next step is to ensure enforcement of the new way of working. Obviously, the new or updated process adds overhead and makes it more difficult to perform the tasks efficiently. So, before you jump the gun and start to work on further complicating the existing processes in the organization, there are five factors I’d like you to consider.
First, one of the concerns that many ignore, but that’s obvious when you think about it, is that the future is fundamentally unknowable. Looking back, we have full knowledge of what has happened. Consequently, it’s obvious what the optimal way to address an issue would have been. However, when standing at the point when a decision needs to be taken, we’re doing so with significant uncertainty about the implications.
Second, depending on the organizational culture, it may be very difficult to point out that individuals have acted out of a fundamental lack of competence. It’s important to realize that incompetence cannot be cured by more process. Incompetence requires educating people or, if that proves unfeasible, replacing individuals with new people.
Third, the more process is introduced and the more enforcement of process takes place, the more people focus their attention on correctly following the process, rather than focusing on accomplishing the desired outcome. This leads to a fundamental lack of accountability in the organization, with everyone hiding behind having followed the process and failing to take responsibility for the desired results.
Fourth, too much process can cause more problems than it solves. As processes are created to be repeatable and to apply to a large variety of different situations, an overly detailed process definition is, by definition, ineffective in the majority of situations. Especially in organizations that place high value on following due process, the inefficiencies and harm done by blindly following process can become staggering, potentially even to the point of companies being disrupted.
Finally, in most organizations that I work with, processes and methods are developed by people that are outside the arena, meaning that they won’t be affected by the implications of the process and method definitions. Although not actually performing the job, there’s a strong tendency to act as “Monday morning quarterbacks”, a reference to the Monday water-cooler meetings in especially US companies where the flaws of a team’s quarterback are discussed. The interesting thing is that the criticism tends to come from people that would never ever qualify as quarterbacks themselves.
Concluding, before you fall into the ‘more process’ trap, please ask yourself whether it would help to predict the future better, whether your people perhaps lack competence, whether you promote accountability, whether the root cause is perhaps too much process and whether you’re listening to so-called experts that don’t actually have a sufficient understanding of the situation.
To get more insights earlier, sign up for my newsletter at [email protected] or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
Scrum Master | Agile Coach growing people, products and organizations. Increasing speed & quality through continuous improvents and lean agile mindset. Bottom line it’s about the people - Happy People make Happy Products
4 年Well, yes. This is the organisation maturity ladder speaking. I would dare to say most organisations are at maturity level 2-3 (of 5), where the most obvious thing would be to add processes to handle weaknesses within the organisation. Only at level 4-5, the organisation is receptive to what is described in this article. For more info on the maturity ladder, see: https://thefutureorganization.com/five-step-collaborative-organization-maturity-model/
Resulting vs Reporting "A nail is not discussed into the wall"
4 年10 years ago I read: Lean Brain Management.......seems that many people read that book without getting the ironic approach. Now lean brain gets established.......develop a safe process, get rid of high paid target oriented self-thinking professionals and restaff with uninspired cheap-to-get process followers. New problem today: many new people, hired for high workload phases, high people turnover, no time to even introduce on the main processes. Every subteam builds up own tools + use and abuse + communication.channels. Frame team needed with process know how and maintenance. Looks like an engineering cattle drive over the landscape of new technology. (Need fast horses for catching disoriented and escaped members of the herd).
Strategic Purchasing: energietransitie, aquathermie
4 年The more procecces , the less they are used. Some people think that more processes make the work better , but think the opposite is true.
Strategic Purchasing: energietransitie, aquathermie
4 年Lean and Mean. Today employees are mostly high educated people. Trust professionals doing what is right to do. Less processes helps. We should use our own brain (boerenverstand ) more then just follow processes. Avoid that people hide under processesbut take initiative and use their professonalism.
FORMATION CPTO | Experienced tech entrepreneur, (interim) CTO/CPO, strategy, and product consultant, hands-on troubleshooter and mentor.
4 年Exactly. Process is what we use to fix collaboration issues where people, for whatever reason, fail to work together effectively. In my experience, the dynamics of doing things with large groups of people can lead to complex processes whereas the the dynamics of doing those same things with multiple smaller groups of people allows getting rid of a lot of process. The key benchmark of developing large software projects is large open source projects that manage to maintain a high velocity of change and combine it with regular as clockwork releases despite having to orchestrate changes across many individuals working across multiple organizations. E.g? Mozilla is reducing their release cycle to 4 weeks. Linux releases a new version every 6-7 weeks. Eclipse releases every 3 months. The complexity and size of each of these projects dwarfs most corporate projects. Increasingly the way these OSS organizations have functioned for decades is also the way corporate large software projects are getting done. Getting rid of process bureaucracy becomes more urgent if you are building a distributed team with people in multiple locations or working from home/co-working spaces or if you have a lot of freelancers coming and going. This makes having a lot of meetings impractical and even less pleasant than they already are. In my experience, nobody actually enjoys having lots of process related meetings; especially busy engineers. In other words, distributed teams is where Scrum breaks down completely. I know of no OSS project that does scrum, sprints, retrospectives, estimation sessions, or any of that BS. This only works for small teams that are on site. Modern software development is all about asynchronous communication. Process is basically about introducing synchronization bottlenecks. E.g. Scrum typically has 2 week sprints. In many organizations this naturally leads to a "we release every 2 weeks notion". If you have multiple teams doing scrum depending on each other, you now have a bi weekly synchronization bottleneck where teams throw stuff over the fence. This does not scale and it causes a time to market that is inherently at least 4-6 weeks. The problems with this are obvious: why wait 2 weeks to find out about issues when you could be collaborating in real time to ensure these are resolved as they are discovered. The asynchronous alternative is doing CI and CD. Changes get CI'ed as soon as they get merged and CD automatically deploys any changes that pass automated test and deployment checks. Combined with Kanban style processes, this means you can drive a single change through in near real time. File a ticket, prioritize it, the work gets done, approved, merged, and deployed on a schedule that makes sense for that change. For bigger changes this may take months, for small changes minutes. The state transitions in this chain of event are asynchronous. At no point does it require having planned meetings. They are also supported by tools and it is important to have visibility in where things are in the process.