Too many projects will bring you down
The odd one out
If you regularly drive to work, you’ll probably be all too familiar with roadworks. From your experience, which of the pictures below seems unusual?
![oddoneout.jpg 2348](http://www.planningplanet.com/sites/default/files/imagecache/wysiwyg_full_page/wysiwyg_imageupload/77079/oddoneout_0.jpg)
Picture 3? It’s rare to see activity. From my car window, most roadworks seem sat idle, not a worker in sight.
Why is this?
Parallel vs Serial planners
Imagine a company has a set of projects and a flexible team to deliver them. Which of the two scenarios is preferable?
![worlds.jpg 2349](http://www.planningplanet.com/sites/default/files/imagecache/wysiwyg_full_page/wysiwyg_imageupload/77079/worlds_0.jpg)
In Parallel World, we start everything as soon as possible. If there’s an opportunity, we get it going. The pipeline’s full and we’re all excited as we manage multiple, simultaneous projects.
In Serial World we start everything as late as possible. If there’s an opportunity, we postpone it until there’s nothing else to finish first. We prioritise projects and inevitably upset some people as they get pushed to the back of the queue.
Take a look at the distribution of project finishes in each scenario. Despite the contrasting internal perceptions, the Serial World gives customers a far better deal. Most projects planned in series would be delivered earlier than those planned in parallel. Even the lowest priority project would not be delivered any later!
In reality, Parallel World has even more downsides. As resources are typically shared across projects, projects end up standing idle until the appropriate team can be assembled.
![logjam.jpg 2350](http://www.planningplanet.com/sites/default/files/imagecache/wysiwyg_full_page/wysiwyg_imageupload/77079/logjam_0.jpg)
The more projects we manage in parallel, the more likely it is that they are all delayed. Managing transient resources becomes just too darn difficult.
Ironically, as Project Managers acknowledge general organisational slippages, they build in extra time buffer to compensate. ie. get it in the system even earlier! If there’s a logjam, throwing in another log is not going to help. No wonder we rarely see roadworks progressing. Perhaps most of our projects are like roadworks, just less visible?
To maximize customer benefit we should be striving towards a Serial World - doing fewer projects, faster and in a predetermined sequence.
Portfolio Management to the rescue
All too often project delays are put down to poor Project Management. I'm not convinced.
I’d like to argue that the predominant cause is more likely to be poor Portfolio Management. If there are too many projects in the system, there’s little a Project Manager can do. Of course the seasoned professional may be able to drag his / her project through on time, it’ll just be at the expense of the rest. Portfolio Management is the process of actively selecting which projects to resource now, which to put on hold and which to put down.
In my earlier blog post I urged anyone feeling the absence of a Portfolio Management process to first help justify its need.
If you followed the suggested steps you should now have a portfolio list of projects. Fantastic. My recommended justification is pretty simple. Just go and ask the senior managers how many projects they believe are active.
If your company’s Portfolio Management process is in control, they'll give you a consistent and correct answer. They'll also be able to tell you the total value, it's resource loading and strategic mix. I'm impressed. However, from my experience they probably won't even know how many projects there are. Their guesses will be widely inconsistent and far below the actual count, perhaps by a factor of 2 or more.
Your portfolio data coupled with the reasoning above should be enough to convince the senior management that they need to sit down together and start taking some decsions.
In next months post I'll outline what I'd recommend doing during the first portfolio management meeting.
Please feel free to connect with me at:
linkedin.com/in/mikebramworth
Printer-friendly version
- Login or register to post comments
Send to friend
Comments
Hi MichelleThanks for your
Hi Michelle
Thanks for your feedback - good question.
Specific answer
If there were interdependencies between projects then it would just add to the argument to tackle them sequentially. Just do them in the right order.
However, if projects were inextricability intertwined then it would make sense to consider them all as just one big project.
An example would be in Product Development when a company develops a range of products that must be delivered to the market as a single set, eg. a new range of Ready Meal foods. In this case, I’d investigate the market for the range as a single project. Once we get to the development stage, I’d fragment it into individual mini development projects to create the recipes - do these in series.
Once we’re beyond development, I’d treat the new range as a single project entity again to address the remaining deliverables such as producing promotional materials, creating supply chain…..
General answer
The point of the article is not to argue that we should always do one project at a time, but simply to try and change the thinking from:
” Projects make us richer so let’s start as many as we can!”
to
“Finished projects make us richer, so let’s finish as many as we can!”
I hope that this is one of those irrefutable bits of logic that is totally obvious once it’s pointed out. For those that get it, the repercussions are pretty instant without the need for any justification.
I was at mid-sized food company a couple of weeks ago. They have about 250 concurrent products in development across about 10 Project Managers. They’re stressed!
If they were to interject their growth ambition with the thought that becoming rich is about finishing projects, then I bet the number of parallel projects would fall to perhaps the 10-30 range, the total number of projects delivered in the year would increase and stress levels reduced.
Mike
Thanks for this post Mike -
Thanks for this post Mike - it is certanly true in my experience that trying to do several projects in parallel can result in slowing all of them down if they are not managed as part of a portfolio. Whereas in serial at least some project sponsors/stakeholders will get their final deliverables sooner and, as you point out, even the last delivered project could be delivered no later than it would have been if the projects were run in parallel. (Although convincing senior management of that would require some hard statistics)
But what about the question of interdependencies between projects?
If project 1 is completed and delivered standalone, then project 2 and 3 the same, but during the course of project 4 some new dependency is revealed which means you have to go back and change parts of your recently delivered projects 1, 2 or 3. How does that then affect the outcomes of all projects?