The problem with Projects: Temporary Organisations

Charlton Ogburn, an Officer during World War II wrote this in 1957:

We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganized. Presumably the plans for our employment were being changed. I was to learn later in life that, perhaps because we are so good at organizing, we tend as a nation to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency and demoralization.

That it takes time for teams to “form up” is hardly a new phenomenon. Tuckman in 1965 proposed his, now popular: Forming–> Storming–> Norming–> Performing model to describe the stages of group development. In Tuckman’s view, each of these distinct stages were necessary and inevitable for a team to deliver results.

Whether these are, in fact, the stages of attaining group coherence and reaching a point where a team is “performing” I don’t know. The part I am more sure about is that it takes time. I know of no teams that have fulfilled their potential (or even the sum of their parts) immediately. I have also observed lots of teams that get significantly better over time as they learn how to work with each other, the technology they are working with and the problem space they are playing in.

How sad then, to observe organisations performing “Teamicide” on the teams they have spent so much time and money developing. These teams are sliced up and discarded, not because the type of work the team is capable of is no longer needed, but because the project has simply come to an end. Sometimes the parts are put through the blender and assigned onto other projects. Other times, the “parts” simply walk out the door. Demoralising, indeed.

Unfortunately, according to the Project view of the world, this is how it is meant to be – it’s a feature, not a bug. Temporary organisations aren’t an aberration, they are a fundamental part of the project paradigm. This is part of why the project paradigm makes little sense when it comes to the work of developing, maintaining and the ongoing improvement of products that are based predominantly on software. It’s like using a ferry to cross a waterway, when what’s really needed is a bridge – and then burning the ferry after the first trip.

Investing in the development of a high performing software development team should be seen as orthogonal to the work that team does. It is a worthwhile investment in and of itself because it provides an organisation with the capacity to deliver change quickly. As industry after industry is disrupted and eaten by software this is increasingly becoming a key competitive advantage.

Build the capacity and then bring the work to the team. Don’t form the team around the flawed project paradigm. That would really be a waste.

You can find more on the problem with projects here, and a summary/history of #NoProjects here.

Comments 9

  1. If the world were a simple place then it is absolutely true that it makes little sense to continually build and then smash your software development teams to make them fit the project paradigm. But the world isn’t a simple place and what works for one organisation may not work for another. It is not that the project paradigm is wrong but that it is wrongly applied to all scenarios.

    Where there is sufficient work to support a multi-skilled team that can maintain, develop and enhance your products then it makes no sense to enforce continual churn on that team by enforcing the project model of mobilisation and “teamicide”. But where there isn’t that pipeline of work, having a “standing army” of developers may not be economically viable. In that case adopting a project model may be more appropriate. That way the required skills can be identified and acquired and then released once the work has completed…and that is why there is such a vibrant consulting industry.

    1. Post
      Author

      Completely agree that context is crucial. (I’ve previously argued essentially the same thing before.)

      Unfortunately, it seems that those organisations who need the project vehicle the least are the ones who are most addicted to it. This, despite how incredibly wasteful the project vehicle has proven. Not only is precious little value created, but to develop teams that are starting to work well together only to destroy that capacity! It’s so short-sighted.

      I’m also increasingly of the view that if you can’t afford to maintain the longer term “capacity to deliver change”, then you really shouldn’t be messing around with bespoke software. Go find some SAAS provider that gives you most of what you need. Buy it off the shelf and keep any customisation to a minimum. Bespoke software is not for Christmas.

      It’s not that projects are inherently wrong: it’s that software just doesn’t fit in it any more. In that context, what is needed in today’s world has gone way beyond what the project vehicle can handle. It’s time to stop building ferries for a one-time trip across a river that we all should know by now that we are gonna need to cross back and forth, many times – for the foreseeable future…

  2. In my humble opinion, I believe there should be differentiation between project vehicles to deliver re-platforming or a major technological shift and continuous improvement product iterations. Project vehicles are more appropriate for delivering these changes and arguably more measurable as it is either live or not yet live. ;) Continuous improvement product iterations should continue as they continue to deliver customer and business value.

    1. Post
      Author
      1. Looks like my opinion really was humble. ;)
        There really is a difference between re-platforming and technology shifts and continuous product improvements. The delivery methodology should adapt and cater for this. Attempts of trying to do both at the same time usually end in painful stakeholder discussions. I believe there should be a split of project based delivery teams and continuous improvement teams to cater for these two different delivery approaches.

        1. Tim,
          I couldn’t agree more. Attempting to apply the same methodology whether you are embarking on a major transformational change or to continuously improve and refine your products makes no sense. It creates unnecessary tension within organisations and generally achieves neither the major transformational shifts nor incremental steps required.

          But then that’s only my humble opinion … I’ll get back to work now too ;-)

        2. Post
          Author

          :) I just happened to be speaking with someone who was in the same office as you when your first comment came through, so I couldn’t resist! Was gonna come back and write a more meaningful reply after mulling your suggestion over…

          As I understand it, you’re saying that because it is easy to measure “live” vs “not yet live” that therefore re-platforming initiatives are well-suited to a traditional project approach. This might be true if it was the only uncertainty or complexity involved in re-platforming. Maybe I only get called in on the really messy ones, but I’ve definitely seen enough “replatforming” projects to know that this isn’t the case.

          I’ve also never seen a replatforming initiative where the requirements weren’t a significant extension of the current offering. It’s rarely a like for like replacement, even if the underlying tech is completely different. Those sort of project proposals never get funded in my experience – they always come with a long shopping list of additional improvements. Those improvements of course require a continuous improvement approach, which I think you already accept that the project vehicle handles poorly.

          Given that we have both seen the insides of a very wasteful replatforming project (which was seemingly being run with all the usual project controls by experienced senior project managers) I’m quite surprised you maintain this view. I’ve learned that the project approach is a recipe for getting royally fucked by the supplier. Of course, the suppliers love it – they make millions! Super-hero contractors like you also tend to do pretty well trying to rescue them from the resulting mess ;)

          There is a better way though: an iterative and incremental approach coupled to a streamlined Continuous Delivery pipeline gets you to “Live” and delivering value, learning what works and what doesn’t much faster. In the process, you are attacking head on the often painful integration risks that the typical project approach doesn’t address until far too late in the day. As you know I’m fond of saying, the only meaningful measure of progress is working software.

          You do have a valid point though: how should a company go about resourcing a replatforming effort? For this I recommend starting with developing the capacity and ability to deliver value of the smaller set of teams that you intend to keep for what you are calling “continuous improvement”. Give them a chance to get a “Walking Skeleton” MVP in place and starting to increment to the smallest (in effort terms) piece of business value. The point of this is to not only have them put an initial outline architecture in place, but also to make sure that quality is built in, with all the good CI and CD practices you know and love.

          These teams also set the scene of quality. Since they are going to have to live with this code base for the long term, their incentives are to produce and maintain clean code that has good unit test coverage and quality. THEN (and only then) once you are confident that these building blocks are in place should you even consider adding more teams to the effort. I suppose these teams can be ephemeral if the organisation can’t afford to carry the capacity for the long term, but the teams who are there long term should be given responsibility for choosing who to partner with. They should also be concerned with monitoring quality and how the ephemeral teams interface with the longer-lived teams.

          Anyway, I could go on, but I’m probably boring you. Thanks for stopping by and sharing.

          1. Post
            Author
  3. Of course I find your opinion interesting, hence reading the article in the first place. ;)
    Thanks for the link and the kinda compliment. ;) I had another look at this article as we at tried to cover this topic from a product and project reporting perspective. It is good to hear different poles of view.
    I’m sure your article will be useful going forward.

Leave a Reply to Joshua Arnold Cancel reply

Your email address will not be published. Required fields are marked *