How to Kill Projects and Develop Agile Programs Part 1

Last post I covered why product development organizations need to kill projects and move to agile programs Here's how:

1) Embrace, but control projects

The first thing to realize is that there is an organizational dynamic around projects. So trying to "kill projects" in one step just isn't going to work and you'll get wrapped up in many change management challenges.

Instead, I suggest doing the opposite. Embrace them. Do this by creating a simple portfolio tool showing active projects and ones being considered. Create a review team to make decisions on new projects. In other words, build up a project portfolio and related processes (on boarding, stage gating, reporting) but keep this as easy and as light weight as possible.

2) Execute on projects / analyze the portfolio

This next stage can take some time; months or even a year. During that time you should focus on strong (agile) project execution. Get to done. Focus on process improvement.Capture metrics. Understand your team's strengths. Discover missing skills.

But most important is to discover two things

- Commonality around projects- commonality can come in several patterns. Demand for projects in some areas more than others. Needs for specific customer segments that are higher priority than others. Technical commonalities around skills or platforms. 
- Barriers and constraints in project execution especially regarding project on boarding and project completion.

Why?

Areas of commonality around projects are the basis for forming programs and teams. If you know that you had three business intelligence projects in 2010, chances are you'll have other BI related projects in 2011. 

Identifying barriers helps convey what problems you aim to solve in moving to programs. Is it speed to market (yes!), more efficient resource utilization (yes!), higher quality (maybe)? Knowing these challenges will help management understand the basis of transition and help teams home in on the program management structure.

Part two will go into more details.

Kill Projects and Develop Agile Programs

My last couple of posts covered the need to define markets before products as the first shift in transforming product delivery. The second issue to tackle is shifting from projects to programs.

Projects kill product development organizations. By definition, a project assumes a beginning and an end. The beginning requires deigning, justifying, and planning the project. The end assumes that deliverables and objectives are met and that resources can be disbanded or shifted to other projects.

This structure poses several issues to product development efforts

• My primary issue is project end. Software based products never truly end. Surely, you can put the product on fumes and not invest in it, but any product that has some business value should have a portion of revenue allocated for enhancements and innovation.
• The cost to start a project can often outweigh the value and benefits.
• There is additional risk on boarding and releasing resources

Let's contrast that with Programs. Programs imply a strategy and a number of efforts that align with the strategy. Efforts don't need to be managed as projects - they can be run concurrently with shifting priorities. Programs are very strong when they are coupled with an Agile Planning and Agile Development process. Programs typically have a base of resources with governance on adding/shifting resources, setting strategies, setting priorities, balancing efforts around strategies, and handling investment needs. Some advantages:

• It's a more fluid process to move efforts from strategy, to planning, to development.
• Continuity of resources reduces the overhead on resource allocation, complexity in knowledge transfer, and risk in quality.
• Light weight governance is more easily applied across multiple programs.
• Focuses teams on small incremental product improvements.

My next post will talk about shifting from a Project Management organization to Program Management.