Partial Resources: It’s Always The “Other Project”

In a perfect world, we’d like all of our Scrum team members to be fully dedicated and committed to delivery on a project.  The reality is that scrum masters and product owners have to deal with less than perfect conditions under which they have to deliver high-quality software.  It’s always the “other project” that prevents our resources from executing on the project we are managing.  So, what do we do?  I think there’s a simple strategy that can help everyone involved.

I recommend deliberately and consistently scheduling project available time.  Let’s say you are 25% allocated to another project.  In a 40 hour (yeah, right!) work week, which equates to 10 hours of available time to work on that project.  That could be done 2 hours per day, or maybe one full day plus a couple of hours on another day.  What that means is that during those scheduled times, you are unavailable to do anything but work on the other project – no meetings or anything – like you are not even there.  Use your online calendar or team project management system to clearly lay out the schedule for the whole team to see.

It's always the "other project"...

Consistently following a schedule will help you time-box this effort, help with consistent planning and execution, plus it will help colleagues respect these boundaries such that everything can get done.  It will take a little discipline to respect these boundaries, but I believe it is what is necessary to mitigate the risk of partial resources being on the project.

Advertisements

Published by

bhackerson

I am a software lab manager in the Corporate Research Lab at 3M in St. Paul.

One thought on “Partial Resources: It’s Always The “Other Project””

  1. Brian,

    The thing is some resources try to deceive the Project Manager with this “Other Project” farce. Many times that other project consists of 2-3 hours/week, yet takes up to 50% of the developer’s time. The best thing to do is to discuss that other project with the person responsible for that project, and, from my experience, there’s a very good chance you’ll hear a totally different story. None of your tactics in your blog post will work in case the developer is lying.

    Additionally, sometimes, especially in a functional organization (see this article on organization structures in project management) the functional manager might very well take side with the developer (even if the latter is lying about his time), for no reason, other than to make the job of the Project Manger a living nightmare.

    Note that I’m not talking specifically about Scrum.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s