Select Page

Categories

The Product Roadmap is Not the Project Portfolio

The Product Roadmap is Not the Project Portfolio
By Johanna Rothman

I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management.

Several potential teams affect each project (or program).

Teams and Value

Figure 1: Centers and Value

Starting at the right side of this image, the project portfolio team decides which projects to do and when for the organization.

The product owner value team decides which features/feature sets to do when for a given product. That team may well split feature sets into releases, which provides the project portfolio team opportunities to change the project the cross-functional team works on.

The product development team (the agile/lean cross-functional team) decides how to design, implement, and test the current backlog of work.

When the portfolio team gets in the middle of the product roadmap planning, the product manager does not have the flexibility to manage the product backlog or the capabilities of the product over time. Read the Complete Article

Becoming a Leading Manager

Becoming a Leading Manager
By Johanna Rothman

My most recent article, We Cannot Choose Between Management And Leadership, has struck a chord. That’s the good news. The bad news is I have not defined enough terms. Okay, I’ll attempt that now. And, thank you, gentle readers, for hanging in there with me, waiting for my crazy travel schedule this spring.

I see these managers in the organization:

  • Project managers, people who articulate the vision of the project. They may not be the people who actually set the vision of the project, but they carry the vision forward. When I have been a project manager, I have been the one to articulate the vision. I have often tried to do that with the project team. If you can’t create the vision with the team, write the vision as a strawman and present it to the team as a draft and ask for help revising it, so that the vision becomes theirs.
Read the Complete Article

Estimating the Unknown: Dates or Budgets – Part 1

Estimating the Unknown: Dates or Budgets – Part 1
By Johanna Rothman

Almost every manager I know wants to know when a project will be done. Some managers decree when a project will be done. Some managers think they can decree both the date and the feature set. There is one other tiny small subset, those managers who ask, “When can you finish this set of ranked features?”

And, some managers want you to estimate the budget as well as the date. And now, you’re off into la-la land. Look, if you had any predictive power, you’d be off somewhere gambling, making a ton of money. But, you do have options. All of them require iterating on the estimates and the project.

First, a couple of cautions:

  1. Never, ever, ever provide a single date for a project or a single point for a budget without a range or a confidence level.
Read the Complete Article

Which Program Team Are You Managing?

Which Program Team Are You Managing?
By Johanna Rothman

Some program managers whose organizations are transitioning to agile are not always clear on which program team they are managing. Sometimes, that’s because the organization doesn’t always realize they need more than one program team.

Core Program Team

Figure 1: Core Program Team

If you are coordinating and collaborating across the entire organization, you are part of the core program team. If you take a look at the Core Program Team image above, you can see that there are plenty of potential participants on this program team. Aside from the program manager, there is the software program manager, the potential hardware program manager, the Program Product Owner, the Sales, Deployment, Legal, Marketing, Finance, HR, Investor Relations project managers. And those are only the people I could imagine. There might be other or different people in your organization.

Notice that the Software program manager is a delegate to the core program team. Read the Complete Article

When You Have No Product Owner At All

When You Have No Product Owner At All
By Johanna Rothman

What happens when you have no product owner at all? How does a team know what features to develop in what order?

Several teams I know encountered this. They all had product managers. Most of them had BAs. All of them had a technical manager who was willing to be their product owner, but they had no real product owner. They called themselves Scrum-but.

I used to think this was ok. I now think Scrum-but is a bad label.

That’s because agile needs a responsible person who is not part of the cross-functional technical team to rank the backlog so the team knows the order of the work. Without that person, the team does not know what to do.

So why is it so bad for a team to call itself Scrum-but? Because it’s not Scrum-but. It’s not Scrum. It’s iterative and incremental, but it’s not even close to Scrum. Read the Complete Article

Choose an Appropriate Project Lifecycle

Choose an Appropriate Project Lifecycle
By Johanna Rothman

If you haven’t thought about lifecycles, consider the differences between these kinds of lifecycles:

  • Linear: Waterfall and waterfall with feedback
  • Iterative: Spiral, where the whole product is up for grabs each time
  • Incremental: Where you add to the product in pieces
  • Agile: cycles (iterations) of chunks (increments): Add to the product in pieces, where each iteration you can deal with the whole product.
  • Random: code and fix

If you’re building a tangible product, you can use linear or an iterative lifecycle. In an iterative lifecycle, you’d iterate on prototypes, and then engineer the entire product at the end. If you’re building a software-only product, iterative lifecycles can be difficult to complete. Too often, sponsors or management pressures the project team into releasing before they’ve engineered the whole product.

Incremental lifecycles are fabulous for software projects, and they are particularly wonderful for short projects. Read the Complete Article

The People Factor in Software Projects

The People Factor in Software Projects
By Johanna Rothman

The two most important factors for successful software projects are the ability of the managers to manage and the people to understand the domain of the software in which they are working. Capers Jones claims1 that reuse of high quality components is significantly higher than those two factors, but to be honest, I haven’t seen enough reuse to apply that factor to most projects.

What that means is that people matter. And managers matter.

So what do I mean by people matter?

I’m not a people person by nature. I originally decided on a career in software because I thought I’d be able to interact with machines all day and rarely talk to other people. After all, that’s how I went through school, and didn’t school prepare me for life?

Well, unsurprisingly to us now, I soon realized I spent close to half my time talking with other people: discussing the designs, how we would integrate, who would get computer time, which module would do what thing, and who would manage the work in software that the hardware guys couldn’t do. Read the Complete Article

Characteristics of Great Project Managers

Characteristics of Great Project Managers
By Johanna Rothman

I’ve had the pleasure of meeting great project managers, and some not-so-great project managers. Here’s my list of necessary skills for great project managers:

Non-technical qualities, preferences, skills

  • Listening skills.
  • Negotiation skills. PMs need to ask for resources, trade resources and information…
  • Writing skills. PMs need to be able to write down a plan, so that everyone understands the plan and the tradeoffs
  • Oriented towards a goal. PMs need to be able to finish a project and keep people focused on the goal
  • Interested in the people who work on the project. The PM doesn’t have to be everyone’s friend, but the PM has to be able to see when people are struggling, when something isn’t working, as well as when things are working
  • Able to manage ambiguity — to live with the ambiguity and make decisions. So far, every project I’ve managed, not just the software projects, has had periods of ambiguity.
Read the Complete Article

Breaking Free of Legacy Projects

Breaking Free of Legacy Projects
By Johanna Rothman

If you’ve never been a victim of medieval software project management, wow, I’m impressed. You don’t have to read the rest of this article. But if you’ve ever tried to break free of a legacy product/project, and haven’t been able to, you are not alone.

The problem is we can’t create a knowledge management system that can copy everything in a developer’s head. So we attempt to keep the developer chained to that product, only to break free if he or she leaves the company. I left a job, and the company asked me to keep a listing of all of the files for that product. I explained I had a limited short-term memory, once I started with other things. “But what if I need you?” the manager wailed. “How else will I know what’s in the code?”

Uh, read the code. That doesn’t always work–some people like to make complex code. Read the Complete Article

Why Your Senior Managers Like Serial Lifecycles

Why Your Senior Managers Like Serial Lifecycles
By Johanna Rothman

Serial lifecycles have lots of downsides. They don’t manage technical, schedule, or cost risk, they increase the duration of the project, and they don’t provide feedback early enough for the project team. One might ask, “If waterfall or phase-gate lifecycles are so bad, why do senior managers like them?”

Because the serial lifecycles are a simplification of what we do. They make more sense for a product with a physical component, because you do have to do some testing (certainly not all), once the product is built. But, especially for software, where we don’t have to wait until the end to get feedback–and should not wait until the end of the project to get feedback – serial lifecycles make sense only under certain circumstances. My general rule of thumb is to consider a serial lifecycle only if you have two or three people for no more than 1 month of work. Read the Complete Article

Recommended PM App

Recommended PM App

Categories