The European Process Disease • Projekt.dk

Quotes from Marty Cagan on a visit to ProductTank in Oslo during a talk about pitfalls during the transformation towards a product-led organization:

Europe – especially Northern Europe – seems to be in love with process!

Process needs to serve us and not the other way around!

SAFe is just marketing (though very successful with CEOs wanting a quick way for their organization to become “Agile”)!

The desire for process is super dangerous!

Marty Cagan

Marty Cagan describes this as the “European Process Disease“. You’re most likely already familiar with the process-quotes from Jeff Bezos, Elon Musk and Steve Jobs just to name a few, but here we go:

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations.

Jeff Bezos

People get confused, companies get confused. When they start getting bigger, they want to replicate their initial success and a lot of them think there is somehow… There is this magic in the process of how that success was created. So they start to try and institutionalize process across the company. And before very long, people start to get confused that the process is the content. That’s ultimately the downfall to IBM. IBM has the best process people in the world. They just forgot about the content.

Steve Jobs, The Lost Interview

I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign. The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.

Elon Musk

I think is is fair to say that these industry icons are not exactly fans of “process people”.

Why are (some) European organizations caught in Process Bureaucracy?

It is though worth noting that Apple, Amazon and Tesla are all digital natives with entrepreneurial CEOs.

Knowing that it is both impossible and unfair trying to find a main cause behind this “European Process Disease”, I’ll give it a try anyway finding at least some of the fragments.

The CFO effect wanting predictability and control with an upfront Business Case

For some (e.g., big CAPEX) projects it makes perfect sense to build a Business Case before starting burning money. What too often happens is that this requiring an approved Business Case has become an auto-pilot reaction. You’ll find this hardwired in many organization’s project process as a mandatory gate-criteria. The funny / sad thing is that this demanding a Business Case also holds true even when the validity of the basis for the Business Case is very questionable.

Some de-facto project management models like PRINCE2© takes this Business Case fixation to a higher level. Everything in a PRINCE2© project is centered around the Business Case. Again – for some projects it makes perfect sense to have this strict Business Case focus in a stage/gate model like PRINCE2© … but probably not for high-tech product-led organizations.

PRINCE2© definitely is something European (British actually). Yes – I know the claim “PRINCE2© can be tailored from the smallest to the biggest project”, but it is still PRINC2©.

The Product Perspective

If we e.g., have decided that a given tough business problem has to be solved, it does not make much sense to demand a Business Case before allowing the product team(s) to do discovery work. How can we at this point in time provide cost estimates to the Business Case, if we’ve not yet discovered the best solution to the problem? And how can we estimate revenue effects, when we do not yet know what solution to serve the customers?

The alternative to requiring a big upfront Business Case covering the full project, is to apply a metered / VC-style funding model. And yes of course – the Product Team might at some point in time seek a major CAPEX budget for e.g., some production capacity. Here it’ll be fully understandable and expected to ask for an actual Business Case. At this point in time the team actually does have the foundation for building the Business Case.

“Are we then not doing any budgeting at all?“, you might ask. I’ve seen examples where budgets for the year are allocated, but the actual funding of the Product Teams are deferred to a metered funding. In contrast to the budget allocation on a project portfolio, this model provides the flexibility to fund what makes most value during the year. It might have been the case (many) years ago that you could plan a project portfolio a year ahead with a fair degree of confidence. That is definitely not the case anymore.

Process prescription

Having been around in many organizations, small to very big, I can confirm Marty Cagan’s observation that we in (northern) Europe have an affinity for processes, tools, templates and checklists.

The general rationale often falls into these categories:

shared and well-documented processes (and tools, templates and checklists) helps us increase efficiency and quality, and it helps us onboard new employees faster
having a strict process-compliance approach gives us control
applying pre-defined / de-facto models / frameworks (like PRINCE2, Scrum, SAFe, HalfDouble ..) frees us from "re-inventing the wheel" and it makes it easier for us hire external assistance
we've committed ourselves to some formal process certification scheme (e.g., ISO or CMMI) requiring us to enforce process compliance ... for us to keep the certification logo on our company website

The rationale is easy to follow. The approach to these categories are however very different across organizations. It seems to boil down to how employees are trusted / empowered … or not.

Low trust / mercenary culture

Here you’ll typically find a high degree of process prescription and even internal process policing, demanding formal signed waivers for you being allowed to divert from the mandatory processes. This cook-book type of culture also believes in checklists. The more and longer, the better.

In this type of culture you’ll often find a complex and very bureaucratic and multi-layered project governance.

Motto: the higher we score on the CMMI scale the better, making us a real efficient and lean feature factory, generating Output.

High trust / missionary culture

This type of culture also believes in working smart and using best practices. The core difference is the trust that the employees are able to pick & use relevant elements from the toolbox without having processes strictly prescribed … and being able continuously to develop this shared Pick & Use Toolbox.

Motto: the more we trust our teams and the less obstacles we lay in front of them, the better they serve our customers, creating great Outcome for our business.

Where is the balance in your organization?

Read about Missionaries and Mercenaries here.

The Product Perspective

We want and need a Product Team to be effective and efficient.

Being effective means (for a Product Team) to achieve Product / Market fit. The skilled Product Team will use a lot of methods, templates, good practices etc. in the Toolbox to achieve this. The team does not need to be told (prescribed processes) how to do its job.

Being efficient means (also for a Product Team) doing things the right way. Much of this is what I would label professional competences. It makes perfect sense to share / co-develop good professional practices and to have these structured in a shared Pick & Use Toolbox. You would e.g., not prescribe a software developer to do configuration/version management. You’ll expect that to be part of his/hers professional foundation. What on the other hand makes perfect sense is to share good practices on what works best in the given context.

Wrap-up

It makes perfect sense to develop and maintain a strong Pick & Use Toolbox, but think twice if you want to prescribe mandatory processes – and if you do, keep bureaucracy low.. Also consider a more flexible funding process.