4

Manage Interruptions with Defensive Project Portfolio Management

 2 years ago
source link: https://www.jrothman.com/mpd/2021/12/manage-interruptions-with-defensive-project-portfolio-management/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Manage Interruptions with Defensive Project Portfolio Management

Here's a scenario I see in all kinds of businesses. Your team has product-focused work. And, the team also has “fast” response-required, ad hoc work:

  • Production support, when something breaks. You need to fix this right away.
  • Provide technical support when people have questions. The team needs to answer these questions on a “timely” basis.
  • Answer questions about possibilities for new development from management and others. You also need to respond on a “timely” basis.

With all these interruptions, when are you supposed to finish your product work?

The longer you take to answer the “response-required” work and questions, the longer it takes for you to finish the product-focused work. (See Aging Fun with Drunk Agile.)

You need defensive project portfolio management so you have a chance to manage your interruptions.

Let's first talk about visualizing all the work.

Make the Work Transparent

If you have all kinds of interruptions, you might not realize what all the work is, nor the state of that work. (See Projects, Products, and the Project Portfolio: Part 2, Assess & Rank the Work for guidance about all the work.) Here are some ways of thinking about how to make this ad hoc work transparent:

  • I do recommend a ticketing system just for production support issues. The ticketing system would only have blockers, crashes, and other stop-the-presses kind of work.
  • Instead of a ticketing system for all the other ad hoc work, consider a different collection mechanism. That mechanism could be: an email list, a parking lot, a large board with stickies.

I recommend against a spreadsheet. It's too easy to hide large pieces of information in a small cell. I've seen people use an email list where one person transcribes each email to a card. I don't like that, because it's too easy for people to lob work onto that email list and not take the time to make a card.

Instead, I much prefer to use either a physical or virtual whiteboard. Make sure everyone uses a large-enough “card” so everyone can read the entire contents of the card. If your whiteboard does not allow variable-size cards, use a different whiteboard.

I'm a fan of physical boards when we can call see them. One of my clients uses a physical board in the CIO's home office with a permanent camera on that wall. A physical board limits the WIP just because of its physical-ness.

Whatever you do, make sure everyone can see the work. Now, decide when to assess the work.

Assess the Work at Regular Intervals

If you have a ton of requests, consider assessing the work every week. If the team can't finish enough work every week, why do people get to add more work to your queue? (Are other people trying to get the monkey off their backs?)

Instead, work on the problem of the team being able to finish something every week. You might need fewer projects in progress, and people collaborating on work together. (See Create Your Successful Agile Project for more ideas.)

The first assessment is the Zeroth question: “Should we do this project (or work) at all?” IME, the more often you receive requests, the fewer of them you need to fulfill. That's because the people throwing work over to you aren't thinking about their alternatives.

Then, consider the other ranking possibilities. (Start with Project Portfolio Problems Masquerade as Project Problems or read Manage Your Project Portfolio.) I suggest you use Cost of Delay to rank the work. (See the excerpt from Manage Your Project Portfolio.)

Now, stop considering the work that the team can't do. I've seen several alternatives here:

  • Manage the organizational WIP and product WIP by asking the team to commit to much less work at any time. (Fewer simultaneous projects and features. Focus on finishing.)
  • Ask people to integrate testing and review into their work. I like pairing, but you might prefer some other approach.
  • Stop supporting “older” products that you can now buy off the shelf. You created a unique product ten years ago. Chances are quite good someone created an app/product that will do more than 90% of your uniqueness now. Transition to a new off-the-shelf product and stop supporting it in-house.

You might need a parking lot to see what you will consider later.

Principles for Defensive Portfolio Management

Here are the principles I use for defensive portfolio management:

  1. Visualize all the work. If possible, differentiate the truly urgent from the important.
  2. Assess the work with all the people who want you to do work on a regular basis. The more interruptions you have, the more often I recommend you do this. Maybe start weekly.
  3. Use Cost of Delay to assess what you should do and when.
  4. Limit the total WIP, to finish work.

And, as you do this, consider helping these folks learn about how to manage the project portfolio themselves, so you don't have to use defense. Be aware of what's important and urgent. Whatever you do, manage the incoming requests so people work on what's important and possibly urgent. Don't let other people decide what you should do today.

Like this:

Loading...

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK