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

1) Embrace, but control projectsThe 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.