【推荐原文】Lean Portfolio Management

namisang

原文地址：http://www.stickyminds.com/Bette ... fn=cifea&id=117
内容太长，请进连接查看
by Guy Beaver

Project Portfolios: Idea Inventories
An unintended outcome of project planning cycles is the deepening of the chasm between delivery organizations and their business clients. These planning efforts start with great intentions and tight development of business cases during the creation of project charters. Good communication typically occurs during project charter "season," as business organizations lead value-driven discussions about capabilities and features needed to respond to market opportunities or competitor threats. This high-bandwidth communication often degrades as technical organizations require analysis time for each technical silo—data, QA, mid-tier, UI, and any other tier organization that exists. Once the analysis in silos begins, a clear, lean anti-pattern [1] appears and integration is delayed until some point far in the future of the project lifecycle.

Project-driven organizations typically focus on minimizing cost while maximizing utilization of resources, instead of focusing on speed and realizing the value of incremental delivery capabilities that are prioritized by return on investment (ROI). The faulty thinking is that careful, up-front planning can substantially minimize risk. In fact, delays caused by excessive up-front planning are often the biggest project risk encountered. This article dispels the myth of up-front planning as a panacea and offers an approach to driving the enterprise by prioritized business features that are managed in a visible portfolio. This lean portfolio management hastens the delivery of value to the business’s customers—both internal and external.

Project Portfolio Management
Organizations that embrace classic project portfolio management (PPM) must exhibit administrative excellence in order to be successful. The sheer bulk of projects that must be estimated, planned, and staffed creates a resource-loading problem that is difficult to solve and that is only as strong as its weakest link—the first project that gets behind. A common approach to justify PPM is to create the illusion of rapid delivery by releasing twelve- to eighteen-month-long projects every quarter. To the business, this makes a predictable pattern of change, which is desirable as long as high-business-value solutions are being delivered. But therein lies the problem; IT projects that began twelve to eighteen months ago were valued at market conditions that may have long since disappeared.

Another feature of the PPM cycle is that it creates a nearly unsolvable problem of a resource-loaded plan. Once projects are selected, an IT organization must load balance its staff by shifting the projects around so that resource demand is steady. This resource-driven behavior sacrifices business value in two ways: It batches together features into projects, holding high-value features hostage to lower-value, lower-return features; and heavy administration is required, which is manifest as a task-based approach.

Once the organization begins to focus on decomposing software development into sub-processes defined by these tasks, the opportunity for creating a stream of products is compromised. Projects get larger as the process—assigning and tracking tasks and delivering handoffs—slows down the enterprise. This slowing makes it necessary to create large batches of requirements, so the organizational skill for quick release of high-value features becomes compromised. This approach has inherent risks insofar as there are many dependencies between these projects—when one is delayed, a cascading effect of changes to the others occurs.

Mary and Tom Poppendieck [2] have applied lean principles to software development and point out that twelve to eighteen months to deliver an idea from "concept to cash" is wasteful. IT organizations that utilize PPM administer large batches of requirements, which are inventories of ideas. Lean tells us that creating and managing large inventories is wasteful. These large inventories of requirements are managed by big planning efforts that result in long delivery cycles. Discoveries are treated as errors in the process and are managed by restrictive change control.