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.
   

8 comments:

  1. Anonymous10:17 AM

    Great thoughts agree on the approach to move from projects to programs. It is a tough sell in organizations that are so project oriented, that require "end dates" to move forward. It probably takes a lot of leg work to get the buy in from all across the organization, finance included.

    Looking forward to the next post!

    ReplyDelete
  2. Agree completely! Good post and to the point. Am about to attempt this [at least the beginnings of] with your California cousins...

    ReplyDelete
  3. Rob - Thanks for the comments. Hitesh - "Leg work" - I'm still working at it.

    ReplyDelete
  4. I agree with your view on programs, but I would argue that at the lowest level, you are still doing projects. Maybe you are calling it a release, but you still have to set a target date for V1.0 of your product, even if you have a program with V2 etc down the road.

    ReplyDelete
  5. Bob - Thanks for the comment. I will cover this in more detail in my next post or two, but the language I like to use in product development is Programs->Deliverables->Releases

    I use projects when there is a definitive end. So an IT project may be to move to new infrastructure, or upgrade a version of a database or operating system, or to migrate a process.

    ReplyDelete
  6. I have been looking for a way to present this approach to management. I would be so much better to get have 2 or 3 three functioning pieces instead of just a lot of documentation half the way through a project. This article will be a perfect tool in preparing my presentation.

    ReplyDelete
  7. I have been looking for a way to present this approach to management. It would be so much better to have 2 or 3 three functioning pieces instead of just a lot of documentation half the way through a project. This article will be a perfect tool in preparing my presentation.

    ReplyDelete
  8. Take a look at http://projectleadermanifesto.0sites.net/ I put a preamble to this actually stating that project thinking is dangerous, but if you are going to do it at least follow the principle that says you will think beyond the end of the project and to the life of the product (or service).

    Some folks have stated that this is simply a rookie PM mistake, but I disagree. I believe the concept of projects most of the time is dangerous as it makes the organization think of disbanding and reforming teams and hand-offs that shouldn't exist. It's not the PMs necessarily making the mistake.

    Here's a couple of areas where project thinking may still be valid: A Marketing or Advertising campaign - after it is over, there isn't usually a product or service that is long lived. An environmental clean-up effort (where you are trying to restore the environment to as close to its original state as possible).

    ReplyDelete

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.