Skip to content

Why Transform – How leaders get to endorsing a nimble, team centric, organisational design

\<the point of this part is to get to the executive WIFFM\> "I want that nimbleness" – the Ability to rapidly pivot to higher priority work What this typically means

  • Need a joint understanding of priorities outcomes
  • Need to be able to flow people to these higher priorities; and understand what's being de-prioritised
  • People work in teams
  • Why: large outcomes broken into large pieces of work. Assigned to teams of teams. Assigned to teams. Worked on by individuals
  • Why: constraint is usually time. A few individuals could do the work of a larger group, but it would take time. Finding the sweet spot
  • Need to provide teams with the context of what they're doing, why, and how to measure success, understand completion
  • The area accountable for funding the outcomes will require governance on the investment

Most organisations can already do this. Regardless of their organisational structure and way of working. BAR 2021 showed this -\> when there's one strong clear focus, almost any org can respond quickly. Eg shift to remote working during pandemic. What we want is improved nibleness across an organisation's product portfolio. That is, when there are multiple prioritised outcomes – not just one. (Matrix org. An assumed "as is")

The Matrix Organisation

Take our typical matrix organisation. It has reporting lines, and executes work in projects which consume people from these reporting lines; typically with an added injection of external labour. TODO: links/citations to PMI research? Business units will have

  • a leadership team that has objectives across a few timeframes, often quarterly & yearly
  • view of work as existing/BAU, and new which is done with projects
  • an enterprise project management office (EPMO) tasked with running these projects

How projects are run

  • discovery or requirements gathering. Seeks to answer how the project's outcomes could be met. As this work will require people, it will receive an allocation of funding to account for itself, and "pay" for engagement time with the areas of the business it discovers that it needs to engage with
  • the requirements will be translated into a proposed project scope. AKA business requirement document (BRD), or product requirement document (PRD). Usually spells out what outcomes will be achieved, how, over what time frame, at what cost
  • approval of the project plan is likely tied to the budgeting cycle. In order to do work in (say) financial year 2023, the project plans and their executive supporters will need to be ready in financial year 2022.
  • With budget approved, the project can finally start. Now it needs to get people to do the work.
  • Internally: some individuals will be lined up from existing parts of the business, and those skills drawn in. Often we see related subject matter experts, business architects, technical architects, product managers, and a business partner from finance sourced internally.
  • Externally. The bulk of a project's people are likely drawn externally, from contracting, consultancy, or labour hire organisation.
  • While often described as a "tap" that can just be turned on or off, labour tends to take time to recruit and arrive. A simple case is waiting for someone to be done on their existing project. More complex cases mean going to market to recruit, or more complex labour hire vendor negotiations.
  • With people on hand, the project's actual work can start. Typical challenges in this phase are
  • Discovering interdependencies on other parts of the business or suppliers that had not come to light in the scoping phase. Getting access to these resources will face similar engagement sequencing as we've seen so far to get the project started, though likely accelerated due to executive attention. (see also, delays later in the project as people are pulled away)
  • Coping with changes. As the project builds, it will likely learned that reality isn't what had been scoped out. This is normal and expected, we're interested in how these changes are managed. Are changes substituted for other planned work of lower priority? Are changes built-in (and paid for as an add on or extension to scope)?
  • In the project teams, individuals are storming around the problem at hand. Learning about how to work with each other.
  • Milestone tradeoffs. Because new information is learnt and changes happen in-flight, previously committed objective delivery milestones are likely to be missed. Two approaches to these
  • Reduce the scope of delivery for the milestone. This can be positive, in the sense that "we learned we didn't need this other thing to get the outcome". Or negative, in the sense that a compromise is made that will need to be addressed later, like "instead of automating this process, we'll stand up a team for manual processing (at higher ongoing cost… for BAU)".
  • Extend the timelines – and costs associated with – the milestones.
  • In practice, we tend to see at least two of: reduction of scope, increases in cost, or increase of timelines.
  • In the project teams, individuals are now forming around their work practices. They've gotten through the storming phase.
  • Project completion
  • The agreed scope – now likely a reduction over the initial scope – is complete.
  • Benefits are likely to be booked as realised at this point; while it might be nice to assess benefits some time after completion (say 6, 12, and 24 month) there's rarely budget or executive support for this.
  • If required, operation of the project's output is transferred to a "business as usual" team for ongoing operation. A knowledge transfer will take place.
  • The project teams will be disbanded, and assigned to new projects. (or already leaking out to new, now higher priority, projects earlier in their start up/discovery/oops we missed something phase).
  • In the project teams, individuals have likely attained the norming phase, where they've established how they'll work, and the social norms between individuals, teams, and teams of teams. Unfortunately, as the project is being disbanded, this transitive memory will mostly be lost – outside of the sliver that can be transferred to the BAU operations team.
  • Outcomes for executive sponsors
  • Typically, less than originally scoped and promised. Due to reacting to changes and unknowns discovered during the project.
  • Higher cost, either in terms of funds or time or both, leads to a reduced benefits case.
  • The project structure, while generally reasonably efficient when running incurs a significant opportunity cost penalty due to the spin-up and spin-down/transfer to BAU time.
  • Generally less than satisfactory outcomes from a customer perspective. Because outcomes tend to be pre-determined and fixed, it's hard for a project structure to change scope and build "better" from a user lens. The project structure also as a tendency to obscure the view to the end customer, instead prioritising emphasis on the project's scope. It's not uncommon for project teams to not talk to the end users of their project during the project's lifespan.

Hypothesis for improvement

From a teams and individuals standpoint, we observe that it tends to be similar people doing similar work within the matrix org.

  • Similar internal people are pulled into projects touching the same business unit or product domain. Similar contractors/consultants/labour hire are brought in.
  • The "lived experience" is poor from a team and individual in team standpoint; a lot of time is expended storming, forming, and norming. Re-learning social connections that solves the paradigm of understanding who else the project team needs to work with to get their work done.
  • Individuals tend to prefer working with stable teams, with a clear understanding of what they're doing, empowerment to do this work, and empowerment to improve their practices in the course of delivery (taking time out to chisel round wheels out of initial square ones). An observation for in-demand skills (software engineering, product management expertise, marketing specialist, human centred design, lawyer, …) is that these individuals tend to prefer working with stable teams. Making the project structure harder to recruit for.

From sponsoring executives' standpoint, we observe that there's a desire for

  • Better adaptation to change, when market opportunities arise or conditions shift
  • Clarity on the outcomes they've committed to, and the people that will execute on them. Today, and ongoing.
  • Governance, cost control
  • Improved certainty around the availability of the labour needed to deliver committed outcomes
  • Desire to reduce the cost of outcome delivery
  • Done well, this should allow the business to succeed, and hence the executives responsible to be rewarded. Sales will grow, valuations will rise, customer satisfaction will increase, remuneration incentives will be paid out.

What we've observed, is that even the best executed project is too slow for complex work with many unknown unknowns. This is usually the remit of larger enterprises and public service entities that have the breadth and depth to deliver complex financial, telecommunications, services, web**, infrastructure, logistics, etc products.

Team Hypothesis: Longer running teams perform better, delivering better value to the organisation that employs them, which delivers greater rewards to the executives that sponsor them.

\<@martin_f_foster to flesh out\> We say we need long running teams

  • These keep the learnings of the past. Transactional memory
  • Have an established way of working. Have stormed, formed, normed
  • Have a known labour cost basis. At individual or skill level
  • Are prepared and have practices to handle the inevitability of team member turnover.
  • Have built knowledge/practices/tools to support internal, inter-team, inter team-of-teams collaboration
  • Can collect all the skills needed for delivery, reducing handoffs. Handoffs have a time/queuing cost.
  • Can be given clearer view on the end customer that consumes (and pays for) the team's product
  • Understand the prioritised outcomes they're working to, and how this works up to the company's goals
  • Understand how success is measured – key metrics.
  • Delivers empowerment, stability, and just enough governance to allow the team to spend most of it's time on delivery.
  • Has support structures to clear impediments, improve processes, …

Because they know what local and overall outcomes they're working to, how success will be measured, teams can then mostly be left to delivering these outcomes. Practices like showcases, sprints help sponsors and other teams understand progress, the rhythm of collaboration between individuals and teams, and highlight challenges that need to be overcome or accepted.