There’s something compelling about the big project, the huge project, the significant project. There must be because almost everywhere I go, people take little projects and try to make them bigger.
It might start innocently enough, the project team brainstorms in the early planning stages and a mind-mapping exercise takes the little project and gives it branches from the main idea and the branches grow twigs and the twigs grow leaves and before you know it, it’s blocking out the sun!
Or, perhaps a consultant might have thrown in his two cents. “We should do something magnificent,” he might say (thinking of how many of his colleagues might be able to join him on the job.) “It’ll be a project that endures through the ages.”
Whatever the cause, before you know it the initial idea has now become a humongous idea and the size of the project carries its own risks. The more complex a project is, the more likely it is to fail. We talk a lot in here about being effective, about using our systems to make us as productive as possible, about using resources expeditiously. I’m pontificating all the time about how we can handle those big projects and tackle even bigger ones at the same time if only we could use our project systems most effectively. If we think of the 3 sides of the project management triangle: Scope, Time and Resources, we’re always talking about fixing the Time or Resource sides. The one we almost never talk about reducing is “Scope”.
So today: a few thoughts from the chain gain on turning big rocks into little rocks. Yes, that’s right, making a smaller project out of a larger project.
Let’s pause a moment. Doesn’t that go against the grain? Aren’t you having one of those uncomfortable nail-on-chalkboard kind of moments right this second? It’s a cultural thing. AS project managers, we embrace complexity. We take it as a challenge. After all, if the project is too simple, they won’t need us. No one wants to put on our resume, “Managed numerous really small, really simple, low-risk projects”. No! What we want is “Managed schedule for the space station” or “Managed 20 year project for Cure for Cancer”. We are pulled to the complex project and that may be part of the problem. It seems like heresy to even promote a simpler project but let’s suspend our disbelief for a moment and see if it makes sense.
First of all, almost every project can be broken into pieces. In almost every project there is a kernel of an idea; a base functionality or a core construction. Even in large complex projects, breaking the project into manageable pieces makes sense. No one wants a schedule with 100,000 tasks. But 20 projects with 5,000 each might just be manageable.
Even when you’re committed to a set list of functionality, releasing it in phases still makes sense. Yes, I know there are times when that’s just not possible. While it may be true, it’s the exception, rather than the rule.
“But wait,” you say, “if we do the whole project together, we’ll maintain the overall vision of the project.”
Yes, that’s also true but that benefit comes with a host of risks. Let’s take a look at some of the advantages and disadvantages of making projects smaller:
Advantages
On the good side, a smaller project almost always has less risk. It’s smaller, easier to understand, the finish line is that much closer than it would be in a smaller project and the whole team can drive towards the finish almost from the beginning.
A smaller project is also easier to schedule resources for. The key personnel in any organization are going to be easier to lock up for a short period for a smaller project than they are for a longer more complex project. Key resources (we’ve talked about them in here before) can’t be locked up in a single project for long. They’re key for a reason. So, the longer and more complex the project is, the more likely that you’ll only get partial attention from those kinds of folks. The shorter the project is, the more likely the chance that you can get key people dedicated to it.
A smaller project gives back some return on investment sooner. It’s true that the return will be lower than what you were hoping for from the entire vision of the bigger project, but it’s return coming in now rather than later and regardless of how you’re measuring that return, it’s always good to have some value coming back into the organization.
Finally a smaller project makes for faster successes and shorter, faster successes breed their own energy. The longer and more complex a project is, the more likely it is to suck the energy right out of a team.
Disadvantages
Ok, it’s not all grins and giggles. There are a few down sides to making your project smaller. First of all, there’s a significant risk that the initial vision for the project will never be realized. Often what happens is the 80/20 rule takes hold with a vengeance. The first 80% of the value gets delivered with 20% of the effort. The last 20% of the value takes another 80% of effort. So the problem becomes keeping the attention of management or the client when you’ve gotten the first 20% done. By the same token, going for funding piecemeal makes a significant risk that you’ll get funding for the early parts of the project but not the later parts.
Next, there’s a chance that we lose cohesion from the original vision. With the project now broken up into smaller pieces, it’s possible that the original idea will be lost as we deal with each tree rather than the forest.
If we think of taking an initial vision and breaking it into distinct smaller projects, one of the risks is that it ultimately costs more. While I think this is possible, you’ve got to temper the chance of this happening with the benefit of getting return on investment along the way with the completion of each smaller project that’s part of the whole.
So how do I do it?
Ok, so there are some drawbacks and some advantages to making smaller projects out of your larger projects. If you’ve decided you like the idea how do you do it?
Start with identifying the kernel of the idea within the larger project. If you can identify some kernel of functionality or core principles see if those can be crafted into a base project from which other parts of the project could evolve.
If you’re looking at technology, then phasing in functionality over time can be another way to articulate the various pieces of a larger vision.
We look at projects to see whether we can divide up their functionality by geography, functionality, people or source of funding. If you stop and look at the whole, there’s almost always a way to break it into pieces. Then you’ve got to decide if you absolutely need to maintain the original vision which you can do in a separate piece on its own. Call it the integration or supra-project if you like.
We talk about this concept in project management all the time when we train new project managers. “Break the project into smaller and smaller components until you’ve got something you can manage,” we tell people. Keep this in mind as you face the temptation of larger and larger projects.
