Category: Articles

Home Articles ()

Article: From small projects, large projects grow

acornThere’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:

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.


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.

Article: Can you make EPM from the sum of its parts?

Article: Can you make EPM from the sum of its parts?
There are a lot of aspects of EPM. Do you have to go to one big integrated EPM system to accomplish them?  Of course not.  There are solutions to each of the main EPM challenges that are simple to deploy and quick to return results.  Here are a few hot tips on how to accomplish them.  Read more…

Article: Head for the Hills

Article: Head for the Hills
With a teenage daughter in the house, we end up watching MTV rather often.  The MTV hit “The Hills” has one of its cast fulfilling the role of project manager.  It makes you think how project management is perceived by people outside of the more classic scheduling expert.  Is project management becoming democratized?  And, is that a good thing for all of us?  Read more…

Article: The Electric PMO

Article: The Electric PMO
While at a local Project Management conference I was able to talk to project managers about the different kinds of Project Management Office (PMO).  I was struck by how choosing a different direction for the philosophy of the PMO would make for very different tools that should be selected by it for making the organization efficient.  Here are some of my thoughts from that confererence.  Read more…

Article: Third party project management tools – timekeeping

Article: Third party project management tools – timekeeping
Third party project management tools come in many different flavors but I have a soft spot for the timekeeping category.  Since my own firm, HMS Software, produces TimeControl, a project oriented timesheet system.  This article takes a look at why looking outside of your EPM system for a timesheet is worth thinking about.

Article: The project manager’s perspective

Article: The project manager’s perspective
So much of the project manager’s role involves communication.  But, how can you effectively communicate with someone if you’re not sure that they mean the same thing you do when you speak?  Common terminology from places like the PMBOK is a good start but do you take into account your own bias and your own perspective when you communicate?

Article: That elusive proof of concept

Article: That elusive proof of concept
Many organizations have purchasing policies that involve a proof of concept for enterprise software.  The problem is, it’s hard to evaluate the effectiveness of enterprise software until the company commits.  We’ll examine this Catch-22 of how to get around the proof-of-concept dilemma.

Article: Project Stage Gating

Article: Project Stage Gating
Stage gating is a concept that is known to many in the project management community. But, did you know it started as a study on what organizations were more effective than others and trying to find out why?  We’ll talk about the origins of ‘stage-gate’ and the reasons that the practice makes organizations effective.