Getting serious about portfolio and program management

It’s been 10 years since Johanna Rothman co-authored ‘Behind Closed Doors: Secrets of Great Management’ with Esther Derby. In the time since, Rothman has become known as the Pragmatic Manager, served as Program Chair of the Agile 2009 conference and wrote the Jolt Award-winning “Manage It!,” a guide to pragmatic management. Most recently, Rothman has been focused on dealing with management problems in larger organizations, which led to two books, “Manage Your Project Portfolio” in 2009, and, more recently, “Agile and Lean Program Management.”

Along the way she has consulted for, trained and managed at organizations as small as a dozen people and as large as the Fortune 5. Despite her busy schedule, Rothman found a few moments to answer some of our questions about where most organizations are with program management, where to start improvement – and what problems to look out for.

CIO.com: Talk to us about “Agile” and “Scaling.” What does a claim like “Agile doesn’t scale” really mean – and how do you overcome it?

Rothman: What works for one team does not scale to multiple teams. In that sense, nothing scales. All you get is bloat. However, we know how to do programs: a collection of projects where the value is in the overall deliverable. Program management helps organizations deliver the product (what the feature teams create) with the assistance of everyone necessary across the organization.

CIO.com: Your books imply two different approaches – project portfolio versus program management. Are these concepts different – and if they are, which is more relevant today?

Rothman: Project portfolio management is how you rank the work the organization does. Which project is No. 1, No. 2, etc.? Which project are you going to stop doing? Which project should you never do? Those are the questions of project portfolio management. When you ask the questions about the organizational work, you optimize the productivity or throughput of the entire organization.

Program management is “How do we collaborate across the organization to deliver this valuable product?” In a project, you can work inside the project. You have a cross-functional team, and you deliver. If you want to have multiple projects work together in concert, you need program management. In programs, you don’t care if the project teams are all technical or not. You might have a finance team, or a marketing team, in addition to technical feature teams. In a program, you need everyone to collaborate to help the product release.

[Related: How CIOs can create the voice of IT]

In a very large program, you may well have to trade off feature sets against one another for now. In that sense, there is a little feeling of project portfolio management inside some programs. However, for many programs, a feature team will continue to work on its feature set until the end of the program.

Both are relevant today. You will be more effective in your programs if you manage the project portfolio. When you ask people to work on one project at a time, everything goes faster.

CIO.com: Why “’Agile and Lean’ Program Management” – how do those pieces tie together?

Rothman: Agile is about the ability to change. Lean sees the whole and manages work in progress. When you use both, you take a holistic approach to seeing and completing the necessary work, and adapting to change. That’s what we need. Even programs of six to nine months need the ability to change the backlog for the next deliverable or milestone. Agile or Lean approaches help the teams get to done on a regular basis. When you couple that with Lean approaches to the program management, the collaboration across the organization, you have the best of both worlds.

Longer programs need to adapt to even more change. Very little is static in a longer program. Agile and Lean help the entire program adapt by reducing or eliminating work in progress. You can see the flow of features in a program which helps everyone see how the product is growing. The more flow of features you have, the more likely your program is to succeed.

CIO.com: Can you tell us more about program management?

Rothman: Back when I first learned how to manage programs, I knew I could not tell people what to do. They were smart about their feature sets. They were smart about what their area in the organization had to deliver. What I could do was: make sure we had a monthly deliverable so we could see progress; remove the obstacles from the people doing the work; and work with teams who had trouble delivering. Back in the pre-Agile days, I set that monthly deliverable with the help of the teams. I asked, “What can you deliver this month?” They told me, and I wove the story about the product from that. Of course, I worked with a product manager in those days. He or she explained how the product should evolve. I worked with the teams to deliver like that.

[Related: Top 10 project management certifications]

We weren’t Agile back in the 1980s and 1990s in the same way we are now. But, I insisted on continuous integration across the program, even for teams for whom that was a new idea. How else could we see what we were building? With deliverable-based milestones and frequent internal deliveries, we could see what we built, and we got the feedback.

Program management is about helping all the teams deliver their best. Program managers ease the way for teams to accomplish their work. The program manager “connects the dots” across the organization. Not by personally solving problems, but by creating small-world networks of people who do what they do best.

CIO.com: Where do you think most large organizations are today, and why?

Rothman: Many managers in large organizations have a difficult time trusting their people. They don’t realize the power of the small-world network. I often call that the rumor mill. Execs know how powerful the rumor mill is.

Too often, managers don’t ask for the results they want. They are so accustomed to surrogate measures, they ask for some surrogate behavior. Instead, imagine this scenario: you hire the best people you can. You tell them what you want. You provide them an environment in which they can accomplish their work. You trust them, with frequent enough deliveries for everyone to learn to trust each other. Because you, as a manager, can see the product grow, you can trust them.

For teams to trust managers, you have to stop asking people to work on multiple projects or programs at the same time. Multitasking is the fastest way to get nothing done. If you, as a management team, can stop the multitasking by managing the project portfolio, you have conditions which make it possible for a large program to succeed.

CIO.com: Most of the experts recommend that large organization should move to become a series of feature teams. Why is it so hard to get to happen?

Rothman: Back when we tried to use Waterfall, managers and many technical people loved the idea of specialists. We had subject matter experts (SMEs), experts in this area of the code, experts in that area. We thought it was “efficient” to have experts. We compensated people for their expertise. We now know that experts cause bottlenecks and incur a cost of delay. But, so many teams and people are still organized that way.

Even now, when I teach program management and have people run a simulation of a program, they first break the teams into functional silos. This is not for building with code – it’s building with pipe cleaners and other materials. People don’t have any expertise in the program they run in the workshop. The idea of specialists is so ingrained, people are not able to easily move from that specialist idea to cross-functional teams. Cross-functional teams who know how to work together appear to be able to learn together quickly, in my experience.

[Related: The dirty secrets of project management revealed]

It’s so hard for managers to trust teams. Partly it’s because managers love the Gantt chart. Even if it’s wrong, the Gantt is like a blanket. Partly it’s because too many teams believe they need to build infrastructure first, instead of doing the simplest possible thing and refactoring.

CIO.com: What can companies start to do to move toward program management?

Rothman: If you need more teams to work on a product, start with the smallest number of teams you think you need. Establish a core team to help with organizational business value and a software program team to manage the problems the teams can’t manage. Tell the teams what you want. I like, at minimum, a monthly deliverable. More often is better.

If at all possible, bring the program teams together to start their planning and perform retrospectives. Encourage “Communities of Practice” for the teams. If the teams are not feature teams, consider an experiment to help the teams learn how to create features. Look for demos at minimum, and releasable product at least once a month. Encourage teams to work together, where that makes sense. I could go on, but I’ll stop there.

CIO.com: What have you seen go wrong as companies try to go down this path? What are some common mistakes?

Rothman: One common mistake is to think you can have Agile and Waterfall teams on the same program, and it will all be good. No, it won’t be good! The Waterfall teams have to learn how to do monthly deliverables, a shock to their system. You can certainly have Waterfall teams on the program. They might not be happy.

I see another mistake, where people think it’s okay to not use the technical practices we know keep the code integrated and working. Some of those are: pairing or swarming to get the benefit of cross-training and code review, test-driven development to drive architectural and design decisions so you don’t need to do Architecture Up Front, and Continuous Integration across the program. Yes, for a large program, you need CI, all day every day.

I see another problem in very large organizations: The teams who are still Waterfall would like to transition to Agile. They have not had Agile training, so they adopt some practices as a cargo cult, without knowing what the practices mean. That’s a huge problem.

CIO.com: You’re certainly not the only person to see that problem. What can software leaders do about it? (Both from the VP level to the hands-on technical leaders?)

Rothman: As a leader, your job is to see the current situation and learn where your points of influence and leverage are. Then, fix it!

If you are a senior manager, don’t think you can scrimp on training if you want the cultural and project changes. Agile and Lean are culture changes, not a project management framework. If you want the organization to become Agile, you need to become Agile. More likely, as a senior manager, you need to adopt Lean. Consider the results you want. As for measurements that reflect those results, not surrogate measures. If you want finished projects and programs, measure the throughput of features over time for the project or program. That measure will provide you the potential end date and allow you to see earned value.

If you are a middle manager, you need to look for and remove obstacles for the teams in your area. Take a holistic view of your area and optimize so you are always optimizing at the corporate level. Ask for more training and coaching money. People need time to learn. They need to know how to learn to be Agile and Lean. Training and coaching can help.

If you are a technical leader – and I don’t mean someone with a title, but anyone who feels the call for leadership – show people your technical excellence. Show your commitment to reducing your work in progress. Show how you collaborate and ask for help. The more you do that, the safer it is for other people to do the same thing. Without technical excellence in the teams, you can’t take advantage of Agile’s ability to change. The more you show how you work in an Agile and Lean way, the more the people around you will want to work that way.

To learn more, the book, Agile and Lean Program Management: Scaling Collaboration Across the Organization, is available in beta now. As I finish it, I’ll be releasing more beta versions. Once the book is done, I’ll list all the places you can buy it on my website, where you can also find both of my blogs, Managing Product Development, and Hiring Technical People.