A project is a wave in a product structure

If you build your organisation out of projects you are building out of blocks that evaporate. A project is a transitory phenomenon, not a structural component. You probably know of one or more organisations whose BAU is whatever was left when the projects vanished. Building a business out of projects' droppings is a bad idea. We should build our organisation out of products, with standing product teams which are a permanent function for the lifetime of the product. Our operating model is based on product not project. I've blogged about this before.

ImageThe #noprojects hashtag is as silly as the #noOps or #noestimates hashtags. "Product not project" doesn't mean we don't have projects anymore. Projects still exist - they are just no longer the primary building component of the organisation. Projects are a transitory wave which passes through the product structure. A project is a surge in work, to deliver a defined outcome, a step-change in a product or products. So therefore it is a surge in the number of people in the team(s) and in the velocity of the team(s) as we deliver the wave of change required by the project.

We still have project managers too. But they perform a logistical support function. Project managers no longer stride like gods, commanding everything: hiring and firing, making product decisions, and driving the priorities and structure of our organisation. Instead PMs provide services to the product teams, to organise timeline, money and resources. You know, what project management used to do before it got out of hand.

Some additional thoughts:

  • Standing teams make sense. Project teams are a terrible idea: just when they have got through Forming-Storming-Norming-Performing and are actually starting to function as a team, the project ends and we disband them. People may come and go from a standing team, but as an entity it matures and improves.
  • Ideally, standing product teams should be Agile teams: small, autonomous, self-organising. If we swell the capacity we should never grow a team beyond say nine people maximum ("never double digits", "the two pizza rule"), or 12 if you must. So we may be able to double or at most triple capacity depending on the initial size, but any more than that, or if our teams are too big initially, requires splitting teams to stay agile. So keep the permanent standing teams small, say 5.
  • If we do scale to extra teams, make sure we either
    - split existing teams and embed fulltime staff into each team, or...
    - redeploy an underutilised team from another value stream
  • When we bring in people to provide a wave in velocity, put the full-time staff on the interesting new work and back-fill the BAU with contractors, so that the new IP doesn't walk out the door when the team shrinks again. Besides, why should contractors have all the fun?
    Image
  • When we organise IT as standing product teams, we can mature to an operating model where we perform work for business projects, not IT projects. We no longer have a project within IT, we no longer sell project outcomes. We sell capacity to build user stories under direction of the business project. IT is a factory. This is as it should always have been. Why have PM, Design, BA, UAT, or User Training ever been IT functions? We should never have been running projects for business change.
  • Sure IT will still run our own projects. Upgrading all the desktops to Windows 12 is a project. Replacing a worn out SAN is a project. But they too will be waves through our teams.

[Update:]And we still need project managers, to manage the budget, timeline/milestones/gantt, and people numbers, (I.e. what they used to do before they got out of hand) for the surge across the product teams. They can also track benefits realisation, and maybe project feature backlog.

It looks like this:
Image

I'm not sure I've seen the "project as a wave" model elsewhere. i may have picked it up subconsciously, or it may be an original idea. What do you think? Have at it.

Syndicate content