Concurrent Projects: No Badge of Honor

Question: How many concurrent projects does it take to break the proverbial camel's back?

Answer: Less than you think.

I read in this month's PM Network magazine that project managers are lamenting the number of projects they're being asked to juggle, with the average number of concurrent active project at 8. I've actually consulted at some organizations where some project managers are loaded with 20 or more active projects (and these are real projects, some of them large-scale initiatives).

This is the surest way to guarantee project failure. Some managers might say that not every project requires conscious activity from the project manager at the same time (maybe that should be a new book, "The Unconscious Project Manager.") It's a poor excuse, and discounts the work that a project manager really should be doing. It virtually guarantees that the project manager will shortchange the communication (which should be 90% of a project manager's job), not to mention the appropriate risk management efforts and execution monitoring.

In most cases, here's what I feel the correct number of concurrent large projects should be for a given project manager:


Ready????


...calculating .... number crunching.....


And the answer is....


1


For each project added, reduce 20 to 25% of the project manager's effectiveness. It's possible to oversee a larger number if there are project managers reporting to you, but that's not project management; that's program management. And even then, only one program should be managed by a person at a time.

It's also possible to manage a few smaller initiatives, but much depends on the team members and their readiness level for delegation of work packages (without coaching, etc.). That should not be assumed without validating first. Having project administrators or coordinators can also help offload some of the administrative work.

There's no magic number for how many of the small-to-medium size efforts can be juggled, but project managers would be wise to seriously consider what it takes to manage each effort effectively (not to mention the readiness of their staff to own the work packages).

I've seen more project managers fail because they are unable to make a case for turning down additional projects than for any other reason (in some cases, it's because they themselves underestimate all the things they should really be doing during project execution). At the organizational level, lack of focus and a prioritization process is usually the root cause.

Not too long ago, I did a presentation to a room full of CIOs. During lunch, I asked them what they felt their biggest challenge was regarding project management. After some discussion, they agreed their #1 challenge was having to justify to the board why their organization should not take on additional projects (or why they should decrease their current project list). Even at the CIO level, this is an issue.

A few CIO's mentioned that they had some success by putting together a high-level graphical view of the top few initiatives, showing the major activities and groups that were involved. Apparently, this got the point across that there was more to the projects than the executives realized. Sometimes seeing is believing.

The lesson: Don't try to fight a battle on two fronts... and certainly not 20.

Project Forecasting: More Lessons from Driving

A while ago, I entered a post about the importance of staying tuned in, drawing an analogy to driving. Well, another driving analogy had occured to me, this time about the need to focus on remaining time.

Let's put it this way. If you're driving from Philadelphia to New York City and you're at the entrance to the New Jersey Turnpike, what percent complete are you on your trip?

Some of you may guess certain percentages based on distance, but that's as foolish as basing project percent complete on the percent of budget or time that's been spent, without regard for work accomplished.

The quick answer is: Who cares what percent complete we are? What we really should be concerned with is how much time is left, assuming we care about what time we arrive to begin with.

But let's say that we DO care (i.e. schedule is a priority for us, as opposed to some other success factor). How can we measure whether we'll be there on time?

Simply using a percent complete tells us nothing. It's too subjective. What we need to know how much time is remaining. And that will depend on how fast you're going, how many miles are left, what barriers may arise (i.e. road closings, flat tires, etc.), how many stops you make, and a number of other variables. It's no different for projects.

For project schedule control, capturing percent complete is too theoretical, so that's not of much use to us. And capturing time spent tells us very little, except perhaps how long it took us to do prior work, which may not be an accurate indicator of future work. Besides, we can probably determine future work estimates more accurately through expert opinion and/or statistical sampling (combined with good planning).

Of course, there's no harm in entering time spent as long as people are disciplined to always include time remaining. Then a percent-complete can be calculated based on that. But the percent-complete itself is not a leading indicator, so is still of questionable value.

If we focus instead on time remaining at the task level, and combine that with barrier removal, risk planning, and regular reforecasts, we'd have much better control over whether we "arrive on time."

We can improve our ability to estimate in the future by capturing lessons learned, doing spot checks, and using the information to create project schedule templates and checklists, so future projects can avoid running over the same potholes.

Some may say, "Oh, we still need the percent-complete for Earned Value calculations."

Do we really? By putting a dollar amount to the time remaining, we can solve the same problem in a simpler fashion, answering the question: How much is it going to cost us to complete this project and what's our estimated time to arrival?

Just some food for thought. See my followup post on Project Forecasting and Uncertainty as well.

Business Analyst Body of Knowledge: Help at Last

AllPM has a great theme going this month. It's all about the integration of business analysis and project management. As it points out, especially during the early phases of a project, the project manager often works very closely with business analysts.

Three years ago, an organization called the IIBA (International Institute of Business Analysts) was formed to do for business analysts what PMI has done for project managers. It has grown to 3,500 members in 62 countries. They now have a certification exam as well, plus their own "Body of Knowledge" (BABOK).

The article below from AllPM outlines the relationship to project management. Well worth reading...

Theme of the Month: From Project Management (PM) Certification to Business Analysis (BA) Certification By Greta Blash, PMP :: ALLPM Project Management :: Project Manager - Project Management - Information - Forum Manager- PM Tools - Ar

Is Project Management Relevant?

Over the years, I've had discussions with software developers who question the need for project management. I've heard everything from "The developers are the only ones who really know what's needed anyway!" to "All the project managers do is slow things down and add unnecessary bureaucracy!" to "Why can't the the developers just work with the customer to give them what they need and avoid the middleman?"

The fact is, given the right developer and a fairly isolated project, all of these are valid statements. But many projects are much more complex than that. They involve multiple stakeholders with conflicting needs, offshore resources, multiple vendors, complex interrelationships with other activities and departments, and more. They frequently involve managing all of this against budget and schedule constraints.

Leading, facilitating, and managing all of these elements is where a good project manager can help. An effective project manager removes barriers for a team rather than adding barriers. Any activities that may appear like "nuisance work" to technicians, such as reporting time or percent complete against milestones, are often necessary to meet the project's schedule or budget constraints.

A good project manager will work with developers to determine the appropriate project approach, depending on the constraints and the level of uncertainty involved. Perhaps an agile approach is warranted, with learnings applied incrementally. Perhaps piecemeal deliverables can be achieved for quick wins and earlier value. A good project manager will also prepare management reports, conduct presentations, and deal with vendor issues.

Most of all, a good project manager will communicate to all parties throughout the project. Although some developers do indeed have the expertise to do all this, it distracts from the work they need to do.

This is not just a nuance of the software industry. The same holds true in any industry where technical or subject matter experts question the need for project management. Project management is a completely different skill set, necessarily so. It's geared toward leading people to achieve objectives. An organization can of course put the project manager in a better position to be successful by providing adequate tools, general principles, and minimal bureaucracy.

The article below offers clear and simple evidence of the importance of project management. It begins with the results of a 1999 study that showed that the number one reason companies stopped working with Internet design firms was not about their lack of creativity or high costs---it was about their inability to effectively manage a project.

Here's the article...

MB Journal Article Archives