Serial Monogamy Project Participation

I've been writing a bunch of articles about project portfolio management, exploring the ideas about committing to projects. (See Serial Monogamy Project Management for some initial thoughts.)

But, as I've been working with clients and writing more, I've been realizing that not only do the decisi0n-makers have to commit to projects, but that the project staff also have to commit to a project–and only one project–at a time.

That can be challenging. People need some time to think about future work, and maybe act on it a little. People might have an interruption from another project, that is in the best interest of the organization to answer. (If Project #1 has a question for someone on project #2, it is in Project #2's staff's best interest to answer the question. Not the other way around.)

So, one of the ways to make sure people fully commit is to make sure they are not fully booked 100% of the time. If people have a little slack in their day, they can accommodate the organization interruptions, the stray thought that they want to write down and explore later. Exploring later works best if you have a structure such as “20% time”, where people can take 20% of their time to work on something else.

What I'm finding interesting in my work is that people who have some slack can commit to one project much more easily than people who are 100% “committed” to a project. The people who are 100% committed have no slack to provide other projects some consulting or provide future projects some thinking. The people who are only 80% committed to one project (and not committed to something else, slack is key) are more able to finish their work and accommodate the inevitable interruptions.

When people multitask, they are not committed to a project. They have no slack. They have no time to innovate. They are always behind.

If you are lucky enough to have a leadership team commit to projects in a rank order, take advantage of that ranking. Work on one project at a time–commit to it– giving yourself a little slack, just in case. You can always use the time on your project. But if a higher ranking project needs you to answer a question, you can. You have time to innovate.

It's not just serial monogamy project management; it's serial monogamy project participation.

4 Replies to “Serial Monogamy Project Participation”

  1. Pingback: TheoRadical » Blog Archive » One Thing at a Time
  2. I like the twist on your theme. Slack or “management reserve” is important. I guess you are talking about “personal reserve.” The ability to surge into something else is important.

  3. When I teach project management, I use something called a “Productivity Factor” developed by the Keane consulting organization. Only a certain percentage of an individual’s time is available for project work, whether they are dedicated to a single project (the ideal situation) or more that one project (not ideal). That factor in most organizations is significantly less that 80% in my experience, usually between 60-70%. So even if someone is assigned full time to a single project, we can expect that the person will devote 3 to 3 1/2 days per week of effort to that project. This is a realistic performance estimate, allows time for the other activities you suggest and avoids much of the schedule slippage and excessive overtime that plague many projects.

  4. I think this approach is ideal when developing products. However, what if you have an established product that you are selling externally? Clients need some basic understanding of when features will be completed. If you are asking them for 6 and 7 figure dollars, simply saying we are working on only one project now may cause them to take their business elsewhere. What about revenue forecasting? If I am going to my CEO and saying that we can not earn such and such revenue because the team needs slack time, I will get fired. Do not get me wrong, I am a believer in slack time and its benefits, many unplanned activities come up regularly and teams should be empowered. But as a head of a PMO, this puts resource planning and revenue forecasting at odds with one another. We are actively managing this by developing adaptive release plans based on team capacities. This allows us to make loose commitments based on a ever changing plan (which we are ok with) and engage with clients on a fix time and cost basis.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.