Finding the optimal balance between process prescription and flexibility, is what all organizations are aiming for in their quest for excellence.
There is, however, no textbook-optimal balancing -point. What works best for you in your organizational context, will differ from other organizations having their unique context.
The aim for this post is to discuss some of the factors influencing such a balancing-point in a project-oriented organization.
In a hurry? Jump directly to the wrap-up.
Before diving-in, here is a couple of quotes to get us up from the chair.
- Process is a double-edged sward as expressed by Jeff Bezos:
Jeff Bezos
- This comment from Marty Cagan on “process people” also provides some input for reflection (note: what Cagan means by “maker” is a person doing the actual job – not just formulating processes for others to follow):
First, I can’t help but notice that so many of these process people have never performed either the maker role or the manager role in a strong product company. They have more enthusiasm than experience or knowledge. Not only does this put exactly the wrong people in control of how teams work, but these people are prime targets for the armies of consultants and vendors that have figured out that these people are their best path into your company.
Second, in many cases, these process people are hired because the managers are not willing or able to do their job – especially in terms of coaching and developing their makers. If that’s what’s really going on, then that is the problem that must be fixed. A process person is a very poor substitute for a strong manager with the necessary expertise.
Third, process is a lot like religion. People get fanatic about their favorite processes, and it’s very difficult to reason with a fanatic. (As a side observation, my theory is that since these process people aren’t makers or managers, they tend to have more free time than the rest of us, and many tend to spend a good portion of that time on social media preaching their particular religion).
No matter the specific organizational context, the same goal applies: We want happy customers and a viable business!
How we get to that goal, is what differentiates organizations.
The Balancing Act
Given your unique context, the challenge is to find the optimal balance between process prescriptions (telling people how to do stuff) and trust (people will figure-out how to do stuff).
Let’s discuss a few balancing scenarios.
Scenario #1 - (very) high CMMI level
In this scenario, the prerequisite for gaining access to the customers is a very high and durable CMMI assessment (above level 3). Being able consistently to follow (and being able to prove it) and continuously improve project processes is key for this type of organization. It needs to have a stringent waiver-mechanism making it transparent, if a project needs to deviate from the established processes. This is the lean-machine / feature-factory mindset.
Balance
Here the balance is heavily to the prescription-side. Such an organization will typically have a very big and complex process-universe (recipe cook-book).
In this type of scenario you’ll typically find a dedicated process-office with the purpose of developing and maintaining the process-universe – and do internal audits ensuring compliance to the processes.
Pros
Having and methodically following a prescriptive cookbook ensures a high degree of predictability and consistency across projects.
If the domain is stable (e.g., “only” digital) and the nature of the projects are fairly similar, then you can expect significant lean-effects … like optimizing a production line.
Cons
It takes a lot of time and effort to build, mature, implement and maintain such a complex cook-book.
For some people such a highly prescriptive universe can seem bureaucratic and even repulsive.
Failure is not really an option.
Scenario #2 - a strong project culture
In this scenario the customers are not having e.g., a formal CMMI level as a prerequisite.
What is important for the customers here, is the company’s project culture and history being able to meet expectations.
This project culture is based on a set of core principles and values:
- a trust in people, providing psychological safety, that they’ll do the right thing without having to be directed by a detailed cookbook
- a Minimum Viable process / governance prescription in exchange for a highly versatile Pick & Use Toolbox
- knowledge is a shared asset developed and maintained in facilitated Communities of Practice [CoP] by the doers – not in some central process office
We’ll return to this Pick & Use Toolbox later in this post.
Balance
More trust in people than prescriptions telling people what and how to do stuff.
Pros
This people-centric approach, showing trust in people vs dictating strict process rules, creates engagement and motivates innovation.
Cons
If you are having an unexperienced organization and/or a poorly designed Pick & Use Toolbox, then the risk is high loosing control over the projects.
Scenario #3 - PRINCE2 ©
The customers in this scenario are subscribing to the PRINCE2© model, done “according to the bible“. These are typically government customers. Being excellent in that specific project management model is thus a fundamental prerequisite for the business.
PRINCE2 is a very rigid and highly controlled methodology (hence the name PRojects IN Controlled Environments). It is a stage-gate model with a lot of processes, components, techniques etc. covering project management. It does not cover the actual delivery work. You’ll want to have a solid reason (like a prerequisite in the market) for investing in such a heavy model.
In all fairness – should you not find it relevant to invest in PRINCE2, then you’ll still be able to benefit from elements like e.g., the strong technique, Product-Based Planning.
Balance
The model is highly prescriptive on the project management level. How (delivery) work is actually done, is out-of-scope in PRINCE2.
Do not buy the argument “we’re not special – we can buy / adapt a general process”. The fact is that your organization is special with its unique context. No silver-bullet exists (not even PRINCE2).
Pros
If what your customers expect from you, is excellence using PRINCE2 the right way, then you have a strong sales argument. Go for it!
Cons
People agitating the use of PRINCE2 will down-play the size of the PRINCE2 manual with the argument “you can tailor PRINCE2 down to the very small project”. The fact is, that you need a deep PRINCE2 understanding for this.
Scenario #4 - SAFe ©
In this scenario we’re assuming classically thinking and classically organized companies. These companies have come to realize, that their modus operandi impedes their ability to innovate and stay relevant in the market. The CEOs have concluded “we have become too bureaucratic and slow – we need an effective detox cure making us Agile!”.
Many organizations in that situation choose the popular Scaled Agile Framework [SAFe ©] – introduced in 2011.
A word of warning: do not try to start a balanced discussion about SAFe on social media – unless you want to start an uncontrolled wildfire. With the risk of being flamed I’ll here give my take om Pros and Cons.
UPDATE #1: Talking about wildfire – see e.g., this LinkedIn post from John Cutler on SAFe.
Balance
SAFe is highly prescriptive with a lot of terms, roles, processes ..
Judge for yourself:
Pros
If your organization has deep bureaucratic roots with a classic mindset, then initiating the detox cure with SAFe can – for some organizations – be a relevant starting-point breaking the ice.
SAFe should thus be regarded as the initial dosage of the detox cure – not as the end-target … if the end-target is less bureaucracy and more agility.
Cons
Steve Denning characterizes SAFe this direct way:
Steve Denning
You may not 100% agree with Denning, but SAFe is overwhelming and not exactly characterized by a “Minimum Viable Process” mindset.
Scenario #5 - highly regulated context
Your company might live in a highly regulated context, say Medical Devices. In that case, you’ll need to comply to a number of international standards like ISO 13485:2016. Your products are literally about peoples life and death which is why a very rigid risk-management approach is required.
ISO.org
Balance
The balance is heavy on prescriptive processes, traceability and on documentation.
Pros
Being excellent meeting the formal quality requirements is a door-opener in your market – even a way for differentiation in the market.
Cons
If you’reorganization does solution projects for its customers in a variety of markets, it’ll be hard for you to meet and keep on top of the specifics in e.g., ISO 13485:2016. This is a specialized area, not ad-hoc adaptable when you get to run a new solution project.
Being in control
Before opening the Toolbox, let’s take a step back, asking “what is it that we want to achieve running projects in the first place?“
The answer is that we want to be in control of the core product / projects risks:
- valuable for the customer
- usable for the customer as intended
- feasible for us to build
- viable for our business
- we’re able to produce the product (in serial production)
Here it is important to distinguish between bureaucracy and control. Bureaucracy, dressed as prescribed processes, is one of the means to maintain control. In the other end of the spectrum, you’ll find a Minimum Viable set of mandatory processes combined with a highly versatile Pick & Use toolbox.
Being in control is thus not a matter of being “bureaucratic”. You have to act disciplined and be in control of your projects no matter where the pendulum swings. The alternative would be flipping a coin. How you get in and maintain control is a decision you have to make given your context, project culture and values.
Control balance
We’ll here assume two mature and equally successful organizations with fundamentally different cultures and value-sets.
One regarding its employees as gears in a lean-optimized machine.
The other organization only has a limited number of mandatory processes, but instead a trust that the employees can and will do the right things with support from a highly versatile Pick & Use Toolbox and a strong leadership.
Example: what is inside the boxes (here from an org. with a Minimum Viable Processes mindset)?
This organization has – carefully – chosen a set of rules of the game for all to comply to. The core purpose is to ensure always getting the basics right and ensuring transparency.
This organization, believing strongly in people, has reduced formal governance with decision boards / steering committees to an absolute minimum. Instead, the projects are empowered to do the right things, and be held accountable for the Outcome.
This is highly different from e.g., PRINCE2’s strong emphasis on the steering committee leading the project – not the project manager (“only” being responsible for the project execution on behalf of the steering committee – and especially the Project Executive owning the Business Case).
- Getting the basics right
Specific conditions must be established and peer-reviewed before formal commitment. - Transparency throughout execution
Having highly empowered projects, being accountable for the Outcome, the organization has implemented an Objectives and Key Results [OKR] IT-system and highly disciplined maintenance and review processes.
- Getting the basics right
This could sound like no leadership / management exist. This is far from the case. The difference to the classically thinking / organized companies, is that the leaders / managers here exercises a Servant Leadership mindset with the purpose of creating the best possible context for the projects to excel within. The point is to have better – not less leadership /management.
Make no mistake – the Minimum Viable Processes approach does not mean minimum viable expectations towards the organization (including project manager and team). Actually the direct opposite. For this to work, the organization needs to have highly skilled employees, engaged and motivated to do the right things the right way.
Knowledge-sharing and -development is of fundamental importance as materialized in the organizations Pick & Use Toolbox. Here you’ll “find it all” like
- Good Practices (hard to claim any “best” practices) like e.g., templates for how to sign-off a delivery with a customer
- Guidelines for how to use various tools
- Process for how to order xyz in the most efficient way
- And not at least the wealth of techniques used in project management and in the technical delivery activities
This organization has chosen to have facilitated Communities of Practices [CoP] as a way to accelerate knowledge sharing and -development. Large portions of the Pick & Use Toolbox is naturally owned by the network of CoPs (in sharp contrast to the central process office telling the doers how to “do”).
Yes – you’ll also find many of these elements in a high-prescriptive organization which is no surprise. It is just common sense to have e.g., your configuration under control.
Wrap-up
Your unique context is everything. It is hard work to find your balance here – and sorry – there is no “go and buy” easy fix model / framework.
Auto-pilot
Most organizations have a natural built-in auto-pilot set for the destination of increased bureaucracy. Some organizations have a high awareness of its existence, actively forcing another and less bureaucratic – more “agile” destination. Amazon and Tesla are two strong examples. The majority of organizations are willingly running on auto-pilot – even amplifying its effect with arguments like
- we need more process prescription / governance, rules, check-lists etc. for us to manage our growth
- it is a prerequisite for us to do business in the selected market
- our people are not smart enough / experienced enough and need to be told what to do and how to do it
- …
Adding new process prescription is the easy route to take in the response to scaling. The difficult route is stronger leadership / management (look at Amazon and Tesla). Marty Cagan formulates it this way:
Fundamentally, as organizations grow, there are two main ways today that organizations attempt to scale.
One is by scaling their leaders (the managers). The other is by scaling their process.
Detox
More and more organizations have come to realize the effect of the “auto-pilot”, now calling for a bureaucracy-detox cure.
A lot of such detox cures are being offered today. They are typically known as “Agile Transformation”, “Digitalization” or some Silver-Bullet framework.
Unless the organization fully appreciates the root-cause, being the auto-pilot, such detox cures will not last. Companies with classic roots are in for a challenge. Many have tried drinking the Green Stuff, didn’t like it, and back on auto-pilot.
E.g., Amazon and Tesla have a clear advantage both being digital-native companies driven by leaders with a strong start-up mindset. They do not need the detox cure in the first place.