This is the fifth article in a multi-part series:
Part one | Part two: | Step 1 | Step 2 | Step 3 | Step 4 | Steps 5 & 6 | Step 7
Step three: Identify and challenge constraints
The third step of the Operating Model Design process is to examine the things that will constrain our design. This is of critical importance. Far too often we’ve seen organisations try to implement patterns that are at odds with organisational constraints, which results in dissonance at the team level (e.g. scrum in an environment mandating high fidelity requirements specifications in business cases).
Information
We consider the information sources that we need to deliver value including any information security, regulatory, legislative or privacy concerns. e.g. What critical information needs to be available to our people offline? What information is highly sensitive and shouldn’t be openly available? What conversations can’t be had over VC? What do our people do in an emergency when they are offline?
Locations
We consider the locations that we provide value from and any constraints that they present to how we organise to deliver value. We consider the timezones in which we operate and the locations that are available/unavailable to us.
What parts of the workforce can’t work remotely: Do we have a physical plant that our people need to interact with? Do we have customer-facing locations where we need to have a presence? Do we need to be available at certain hours for operational requirements? For remote locations: What health / safety requirements do we have? How do we support people who can’t work from home?
We consider the flexibility in hours of work for each team. Despite asynchronous working enabling us to be a lot more flexible in terms of working hours, the hard won benefits in our employment contracts, enterprise agreements, legislation, etc may (somewhat ironically) place limits on that flexibility. A lot of labour agreements assume that codifying hours of work is good for workers but in the Work From Anywhere future this is often no longer the case.
We consider what floor space we have and what floor space we will need as a remote or hybrid workforce. This may create a constraint on how many people can be in the office at any one time in the future and inform our design.
Platforms
We consider the platforms that we use to deliver value. Do our software and hardware platforms constrain our operating model? e.g. Do we have one or more monolithic software platforms that may be a constraint preventing us from moving to fully independent teams? Do we have platforms that are only understood by a few?
We consider our collaboration tools and any constraints that they present. Are we tooled up for remote working? Do we have redundancy in our remote working infrastructure? Are our people trained to use remote working tools? Are we confident in platform security? Does our virtual infrastructure have licensing or scalability limits?
Funding Sources
Capital constrains the operating model. We consider the funding sources that are available, the volatility of our funding sources and any upwards or downwards trends / indicators:
- Direct operational budgets
- Capacity based funding for teams
- Indirect operational funding e.g. from other departmental budgets
- Funding from projects or business cases
- Metered funding for innovation
Unfortunately we don’t live in a time of endless abundance and sometimes funding conversations are challenging. We are open and transparent about downward trends or volatility because our people are adults who appreciate honesty, even when we may have difficult decisions on the horizon. We ensure that we take care when discussing these issues and provide support to those who need it.
Other constraints
We consider anything else that might constrain the way that we organise to deliver value to customers:
- Key person or knowledge constraints
- Process bottlenecks, overloaded systems
- Regulatory constraints
- Constraints imposed by the controls environment (e.g. segregation of duties)
- Contractual constraints between us and our vendors (e.g. contracts based on tight specifications and change control)
- Dark constraints (where we can see the effect of a constraint but the cause is covert / non obvious)
Consider enablers
Constraints are not always simply barriers, in some cases they may actually enable design. We run a pass over the constraints that we have captured:
Constraints as enablers
We review the constraints we've captured and reflect on whether we can fruitfully leverage some of those constraints to enable us to meet our design principles or effectively deliver on our objectives.
Other enablers
We consider whether there are any other aspects of our environment that enable us to more easily design to our principles or effectively deliver on our objectives?
Challenge Constraints
This is an opportunity to challenge the constraints that we have identified to create optionality in design. We explore the nature of the constraints in the system (Cynefin can be useful here: https://wiki.cynefin.net/index.php/Constraints) and whether they are contextually appropriate.
You’ll save a lot of time, employee goodwill and money by having hard conversations with executive leadership about whether some of the constraints you’ve identified can be relaxed. Some examples:
- Can we challenge the constraints imposed by the regulatory environment?
- Can we change the way we fund the operating model to reduce volatility?
- Can we change the way we contract our vendors to enable us to work more like a team rather than through contract managers?
- Can we hire capabilities that are missing or find ways to relieve key person constraints?
- Can we change the way that we measure and report on performance?
For the last couple of decades we’ve seen organisations try to adopt agility without changing the things that make agile really difficult. There is little benefit in putting scrum into an organisation in which the finance division demands detailed business cases before it will release funds and in which procurement contracts its vendors to detailed requirements specifications with fixed price terms.
By challenging constraints we inform the boundaries of design. This part of the process requires strong executive presence as it is far easier to add processes, policies and control than it is to remove them.
As we commit to altering the constraints of the system we capture our commitments and clarify ownership and deadlines.
Continue to:
