« Facilitating a Requirements Validation Meeting with Ease!
Improve Project Performance With Lessons Learned »

Defining Program Management and How Agile Helps

September 1, 2010 | Author: PM Hut | Filed under: Agile Project Management, Program Management

Defining Program Management and How Agile Helps
By Johanna Rothman

A program is a collection of projects, where the value is in the overall deliverable. Yes, each project may have a deliverable that’s valuable, but the value to the organization is when all the sub-projects get together and deliver their product. Here’s an example. Think of a cell phone. One sub-project might be the team(s) who create the features that allow the phone to make a call. There may be another sub-project for the features to answer calls. Another sub-project could be the features to manage/interface with voicemail. Another sub-project is the minute counting for administration/billing purposes. The texting features would be another sub-project.

Each of these sub-projects have teams that are as large as they need to be. So, working in smaller teams so each team can be agile does work. Yes, each sub-project works in parallel. The teams for sub-projects work in parallel. When I think of these sub-projects for a program, each sub-project has its own rhythm and staff and backlog. That’s why the program needs an overall backlog, because the sub-projects may have interdependencies and may uncover program risks as the program proceeds. In the example of a cell phone, you might not want to start the voicemail until after you know the phone can receive calls. Maybe you can, because maybe there’s a platform that supplies the services your project needs. What happens if you realize you need to change the minute-counting after the call-placing features are done, but before the billing features are complete? You work it out.

But the idea is that you have a program: deliver a cell phone. Each of the sub-projects has its own list of features and each of the sub-projects delivers a valuable result. But, you don’t have a cell phone unless you can make and receive calls and get voice mail. You may need more than that, but you don’t have a product that can succeed in the market without those minimum requirements.

Now, why we need program management? I’ve seen (and I bet you have too) programs where the software was all done except for one small piece. Or the software was done but the marketing was not. Or the hardware was done, the marketing was done, and the software was going nowhere. If you have agile approaches to programs, you get to see visible progress (or lack thereof) at the end of each iteration. You don’t have to wait until the predicted or desired end of the program to see the risk.

That’s one of the ways agile reduces technical and schedule risk. The iterations help you get to done across the entire program and help you see how things fit together. The demo at the end of an iteration shows you where you have technical risk, which reduces schedule risk. In general, incremental approaches reduce schedule risk and iterative approaches reduce technical risk. Because agile combines both, you reduce both kinds of risk.

Sow how does agile program management differ from “plain” program management? In non-agile program management, managers of sub-projects speak for their functional area, commit people, manage risks, and commit other resources. Notice that there is no program-specific view of the product or transparent coordination across the functional teams. There is not necessarily a ranked product backlog. You could have those things in a “plain” program. I haven’t seen them, but maybe that’s how your program management works.

In agile program management, you have coordination across the cross-functional teams. That’s a huge difference. You don’t have functional managers, you need cross-functional project managers (of some stripe) for each sub-project, and one for the program. Managers don’t commit; teams commit. The program team is all about managing the backlog and risks, the business value of the architecture, and the obstacles for the program.

The original article can be found at: http://jrothman.com/blog/mpd/2010/07/defining-program-management-and-how-agile-helps.html

Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Wednesday, September 1st, 2010 and is filed under Agile Project Management, Program Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories