All Projects Great and Small

Projects come in all shapes and sizes. However there is a human tendency to begin to look for consistency in the way projects are run. If there is the possibility to make all the projects look the same and be approximately the same size, then we’ll force them to the same size. In my particular domain, software projects will aggregate sub projects until they get to a particular size that warrants an organization’s standard project methodology.  This has a number of possibly unintended consequences that bear consideration.

Projects as Boulders

This makes all projects like big boulders. They are heavyweight and take time to move and complete. Moving them around takes large amounts of effort and very rarely can you focus on moving two or finishing two at the same time.  In the diagram below, you can imagine that the blue area represents the total number of people (I’ll refer to them henceforth with the more abstract term resource).  The projects take a number of people from that pool and are represented by the yellow circles.   Although arbitrary, you can consider this as three projects being delivered sequentially.

We are now facing some real problems.

• Packing Density – Most project managers have a finite reach and ability to track and manage individuals. Experienced project managers may be able to extend further through delegation and decomposition, but that takes an experienced, strong hand and a lot of trust in those responsible for sub-projects, ongoing delegation and follow through. This leaves an organization as a whole having a level of un-monitored/unmanaged resources that won’t be assigned to a particular project.
• Manueverability – Given a finite number of resources, moving, reallocating or re-baselining the projects is very difficult to achieve without costs on the other projects.  Focusing on the diagram above, you can see that moving the around will require deforming the circles to move them around since each project takes up the majority of the resources at any given time.  You become effectively tied to the projects in more or less the same order until they are delivered or one project takes a considerable hit.  In concrete terms this you see that an organization can only carry one project as a focus with the other take a considerably further backseat.
• Variable Resourcing – Projects move through phases where there will be variable numbers of resources at any particular point in time, this creates slop in the organization that subscribes to the boulder style projects.  The project is running as quickly as it can, but until the project has active work for them to do, there is a higher likelihood of resources not being applied to any particular project.  In some contexts, the staff move through the technical debt that accrued during the previous peak time.

For the purposes of this article, I’ll be primarily focusing on the packing density as my illustrating point.  Other articles may delve into other areas.

Increasing Density by Adding Rocks and Pebbles

So to increase our packing density we begin to allow smaller projects to keep the resources active. This does increase our density. Great, but there is a cost. The diagram below shows smaller projects being packed into our resource pool to increase packing density.

If we apply the exact same methodology for all projects we end up with the project management overhead for the smaller projects beginning to outweigh the effort on the project. This creates a minimum size for a useful project. In the above diagram, we’ve increased the packing density for our resource usage by allowing smaller projects to run concurrently, but we have made a number of these projects ineffective – they are marked as red.

This is generally where most people who are anti-process find their first taste of something being wrong with process.  You do not need the full risk management, schedule oversight and coordination when there is a small project going over a month or two with only a few resources.

Scaling the Project Methodology

To address the inefficiency of these smaller projects we need to bring in a scalable project methodology. This allows us to tune the overhead of the project to be the size of the project. Small projects (which tend to carry less impact of failure) have a lightweight methodology, the larger projects have the full methodology, and the mid-size projects get something in between.

In a real sense, this becomes an effort in tailoring the project management oversight and cost within projects. Examining the artifacts within the larger more formal projects, you can begin to dissect these deliverables into those which communicate within the project and those that facilitate risk management and oversight.  Some of the artifacts that may not be needed for a small project, but are needed for a large project include Risk Management Worksheets, Milestone or Delivery Summaries, detailed Schedules, etc.

A second point to consider with scalable methodologies is the training and expertise of the leadership team for a project.  For the large projects, a certified or experienced project manager is usually needed.  For smaller projects you can normally get away with the people doing the work managing the projects, in particular for the smaller projects, the artifacts are more tactically focused on the deliverable details than the project management details.

I personally advise against doing away with artifacts or changing the artifacts considerably as this takes away from the consistency that the resources within projects need to experience to become scalable.  With the model outlined in this article, there will be many smaller projects moving through an organization than large ones.  Taking the opportunity to have the key deliverable related artifacts be extremely familiar to the resources through repeated application increases their ability to deliver with them in the large, more costly projects.

A Look at Releases & Projects in Software

Looking at my industry, there is a habit of making software releases be equivalent to the large projects identified above. This artificially limits the ability to run small projects – since they automatically get absorbed into the larger project. Even worse, the releases are projects model brings in unpredictability into the tempo of releases since they suffer with the same evils that projects have. That is, they get late, they become over or under-scoped, or they are under-resourced.

Looking at the Boulders, Rocks & Pebbles diagram above, we now have a considerably denser use of our resources. But we end up with lots of individual projects completing at random times. For software, you can’t just deliver in an ad-hoc fashion and still have a product that shows internal integrity and reliability. You need to cluster completion of projects together into releases.

Since at the beginning of this article, we supplemented the boulder sized projects with rock and pebble sized projects, thereby breaking the releases are projects model.   Now we want to rebuild a release cycle around these projects. If you begin to look at having a reliable release cadence, you can end up grouping the same projects described above into collections that are aggregated and released on a this release cadence. If you consider the project release cadence as a drum beating you can get imagine businesses finding a tempo of delivery in the same way that people exercising with headphones on will begin to match the beat of the music they are listening to.

This brings a lot more predictability to the release process, while dis-entangling the projects from these releases. The cadence or tempo that any particular organization can handle is relative to their maturity and organization predictability. I’ve seen organizations settle on a 4 week or monthly cadence, and others approach releases with trepidation for anything less than a six month cadence.  I’ll cover some concepts behind the problems with longer release cycles in another article.

My personal guidance here is that a drum beat over a long period doesn’t allow people to feel the tempo and start to move with the beat. My belief is that most organizations should look for a 1 to 3 month tempo. This fits nicely with other experienced cadences such as corporate quarters or seasons for the longer tempos, and simplifies quips and phrases such as “last month’s release” for shorter tempos.

Making it Real

I’ll admit that in this article I have simplified the resourcing model for projects to fit the points I am trying to make. To realize this in practice, you need to accept that large projects won’t fit into the one release beat, and that smaller projects will need to be ready no-later-than a date before the release mechanisms start. This final diagram shows a more realistic approach to the release cadence with more realistic projects.

Some important items to understand in this diagram.  You can have projects that span multiple releases, and it’s entirely a project’s decision if they want to have intermediate deliverables, keep the features latent and disabled, or to just have the code in another branch or repository.  This sort of model does support projects that that are delivered of 12 months as well as projects delivered in a day.  At the end of the cycle, the projects are integrated and validated as a whole and released.

There are lots more details and formalization that can come out of this on its way to realization, they will be communicated in other articles.