Projects, Products, and the Project Portfolio: Part 1, Organize the Work

Projects, Products, and the Project Portfolio: Part 1, Organize the Work

By Discovery Lean Six Sigma

0/5 stars (0 votes)

I've been working with some clients who are trying to find the magic way to slice and dice their project portfolios. Their organizations treat the software people (IT or Engineering) as a shared service. That means the software people “service” the rest of the organization. While the organization might use products and product lines, the software people work in projects.

The big question these people have is: How do you assess all the projects?

Let me first discuss why organizing by projects makes sense for some of my clients.

Work in Projects to Minimize, Start, and Finish

https://www.jrothman.com/wp-content/uploads/2019/04/Manageproductcapabilitiesovertime-768x554.png 768w, https://www.jrothman.com/wp-content/uploads/2019/04/Manageproductcapabilitiesovertime-1024x739.png 1024w" sizes="(max-width: 300px) 100vw, 300px">Working in projects is not necessarily bad. I've said in the past that as soon as we have more work than teams to do the work, we need to switch from one product to another. I like the idea of using the project as a container for that switch.

I tried to show how that might work for one team with a primary product and “other” work in the image in this post, to manage product capabilities and value over time.

Imagine one product with three releases: Projects 1, 2, 3. For any number of reasons, the software people need a break before the next project for this product. (The software people need feedback. The users might need time to change how they work. Maybe the project was a series of experiments.)

The team works on Projects 1, 2, 3 for the duration of each of those projects. In between, the team works on “other” work. That work might be other projects for different products. It might be periodic work, such as quarterly reports. It might even be emergency projects, or ad hoc work. Not everything is a project.

Whatever the work is, the work offers value to the customers, and by extension, the organization.

Products vs Value Streams

I'm going to rant a little about the term “value stream.” I'm not sure why people use that word instead of products. Yes, I'm showing my ignorance, and asking for your help to educate me.

I think of the product and the value stream as the same thing:

  • Both products and the value stream create capabilities for the user. (At some point, there is a user, even if you sell to a distributor.)
  • Both products and the value stream need to release so that the user can use the work.

Any work that's done but not released is inventory.  (See Knowing When You Release Value.) Sofware inventory is not an asset. That's because software inventory tends to age and not be useful by the time you finally release it.

I happen to find it more useful to think about what's in the product that the customer can use vs. what's not in the product yet. (If you have other useful ways to think about this notion of product vs value stream, do let me know. I'd rather be embarrassed about something I didn't understand, instead of leading my clients astray.)

In my experience, the more people talk about value streams, the more they think the stream never gets interrupted. The stream is continuous.

But these clients of mine work in a “shared service,” centralized department. They must interrupt these streams so they have a shot of doing the work everyone needs. That's why I like thinking about products, with projects as a container for this work.

Flow Work Through Product-Based Teams

I don't use the words “epic” or “theme.” I talk about feature sets. That means the Reports module is a set of features. So is the Search product. So is the Email feature set. I don't differentiate between what they are, because they are all more than one small story.

If we can agree that a team can become expert on the Reports, Search, or  Email, then the team can finish the projects for their product/feature set.

By finish, I mean release something of value to the users. That's why I find the word “project” as a container for:

“Here's what/the value we want to release now, for these customers. We'll do another project, with other features/value for those customers, later. In the meantime, as the customers learn to use these features, we'll move to another product or other work.”

When we use projects as a container, we can:

  • Think about how little we can do, not how much.
  • Consider small, safe-to-fail experiments.
  • Think and work in MVE, MVP, Minimum whatevers.

Projects, as a container for work, tend to nudge the team to finish the work. In my experience, the project-as-container also nudges the user, managers, whomever to stop adding more work. The team finishes projects. They tie a bow on that work. They can move to other work.

When you have small projects, it's easier to assess the projects. I'll address assessing the various projects in Part 2.

The post Projects, Products, and the Project Portfolio: Part 1, Organize the Work appeared first on Johanna Rothman, Management Consultant.




Original: https://www.jrothman.com/mpd/2019/07/projects-products-and-the-project-portfolio-part-1-organize-the-work/
By: johanna
Posted: July 16, 2019, 4:57 pm

comments powered by Disqus

Discovery Lean Six Sigma

Dummy user for scooping articles

I'm a dummy user created for scooping  great articles in the network for the community.