or, In Praise of Small Projects
Some projects are big… and there is just no getting away from it. And big usually means complex.
Other projects get big, not because it is inevitable, but because people keep throwing in more and more components. And we are all guilty of it; customers, clients, sponsors, senior users, suppliers, developers and yes, even project managers. We all succumb to ‘why don’t we just…’ from time to time.
And ‘just’ is such a sly, deceptive word. Because it implies such a little thing. And often the ‘why don’t we just…’ is a little thing, on its own. The problem is that, if we do just… then it adds to something bigger, and makes it significantly more complex.
Let’s look at why. with the simplest of possible models, a fully connected network. And we will start with the easiest of networks, with two, three, four and five components.
A project requires the co-ordination of many different components:
- material resources
- physical assets
Each needs to be co-ordinated with many – maybe even all – of the others, The simplest assumption (which is not going to be true in most cases) is that each component must co-ordinate with all others. In this case, the number of connections (a measure of the complexity of the network) can be calculated as:
c = n(n-1)/2
That is, the number of connections (c) is one half of the number of nodes (n) multiplied by one less than the number of nodes. To see why this is so, just look at the next example in our series:
If only our projects had such small numbers of components. As the number of nodes gets bigger, the number of connections becomes closer and closer to half of the the square of n. So, for:
- n=50, n2/2=1,250, c=1,225
- n=100, n2/2=5,000, c=4,950
- n=200, n2/2=20,000, c=19,900
- n=500, n2/2=125,000, c=124,750
- n=1,000, n2/2=500,000, c=499,500
Rapid Growth in Complexity
I should just address the challenge: ‘projects are not fully connected networks.’ No, they are not. But if a given project has a fill ratio of r, where r is between 0 and 1, then this does not change the shape of the curve. This is a simplified model that is broadly (but not universally) applicable.
So, now we can get to the crunch… simplifying a project. Consider a small project of 1,000 components. The complexity measure is approximately 500,000.
What if we could split it into two smaller projects of say 600 components. Then the complexity measure of each would be approximately 180,000 – giving a total complexity measure of 360,000. There will be interdependencies between the two, but nowhere near140,000 of them. We have simplified – and de-risked – our project considerably, by turning it into two smaller projects.
The ‘so what?’
Firstly: think hard before adding anything extra to your project. Don’t just evaluate the incremental cost, but consider the big impact it will have on the overall project complexity and therefore risk.
Secondly: where you can, split big projects into smaller ones, and avoid amalgamating small projects into one big one.