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
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
- 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.
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.
ReplyDeleteLooking forward to the next post!
Agree completely! Good post and to the point. Am about to attempt this [at least the beginnings of] with your California cousins...
ReplyDeleteRob - Thanks for the comments. Hitesh - "Leg work" - I'm still working at it.
ReplyDeleteI 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.
ReplyDeleteBob - 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
ReplyDeleteI 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.
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.
ReplyDeleteI 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.
ReplyDeleteTake 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).
ReplyDeleteSome 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).