MMS • RSS
Carmen DeArdo, former DevOps technology director at Nationwide Insurance, and Nicole Bryan, vice-president of product management at Tasktop, recently spoke at the DevOps Enterprise Summit London on the importance of moving from a project-based to a product-based organization [PDF of slides]. Project-based planning and funding leads to a disconnect between IT and the business vision (where IT is seen as a cost center and a black box), tracking activities instead of outcomes, and rigid project budgets that do not accommodate today’s speed of change in strategy and direction.
Product orientation is challenging because it requires new approaches across the board in how we manage budgets, planning, teams, priorities, visibility and risk. InfoQ reached out to DeArdo to expand on these challenges.
InfoQ: Why do you recommend moving from projects to products? Can you give concrete examples of “projects gone wrong”?
Carmen DeArdo: At the beginning of our talk we mentioned the 5 challenges, many of which come from having a view of IT as a “cost center” rather than a key capability to generate profit. One reason for that is that IT seems disconnected from the Business vision and strategy. While companies map (endlessly) the relationships between business and IT objectives, the normal associate in either side often times doesn’t feel that connection. By having product teams consisting of both business and IT and working directly, not just on business functionality but also giving business insights into what else needs to be prioritized in terms of risk, defects and debt helps provide that direct alignment.
As far as projects gone wrong, I think it’s more about the fact that important items like risk mitigation are often not seen and prioritized, even though they can have significant impact on the business (e.g. Equifax). Having silos in Dev and Ops causes issues and the same holds true for Business and Dev. And a project structure tends to create the same type of silos between the different types of work and priorities that really needs to be addressed holistically.
InfoQ: Does that mean we should not use projects to plan our work anymore?
DeArdo: No. I think Jon Smart did a great job in his talk with the statement “The PMO is dead. Long live the PMO”. When I was at Bell Labs, we used projects to create new products. So I would never say there isn’t a need to ever have a project. But work needed to improve and support products is better done in a product structure.
InfoQ: In your experience, what are the top 3 obstacles to making such a change in approach to work management?
DeArdo: In our talk, we had 7 areas that needed to be addressed in moving from project to product. The top 3 are going to change given the current situations and culture at a given enterprise. For me, I see budgeting, success (seeing IT as cost center whose costs need to be reduced) and approach to teams (bringing work to teams instead of forming project teams) in the top 3. But the first challenge is to define the products from a business perspective that you can create teams around to support.
InfoQ: Could you point out specific approaches and benefits of product-orientation in terms of budgeting?
DeArdo: There’s a realization that having annual budgets may be necessary for some organizations, but instead of funding hundreds of initiatives – sometimes 18 months ahead of time – a company can instead fund product investment and then allow the product managers to prioritize the work. At Bell Labs, this was revisited every 3 months to determine if the product funding needed to be changed.
Jon Smart talked about having an agile approach to portfolio management. We can’t say that we are agile, if only a small portion of our value stream actually has any agility. To be truly agile, it has to begin with the budgeting and portfolio management processes.
InfoQ: What is your definition of a product?
DeArdo: There are both business products and IT products. A product is simply something that has a customer base that it delivers value to. I think in the past we have created problems by not treating IT products (e.g. our deployment pipeline) in the same way we treated business products.
InfoQ: You spoke about the drawbacks of considering people as a “resource pool” from where to pull a team to do a project. What’s a better alternative and how can product-orientation help?
DeArdo: Once it has been determined what the investment should be in a product, one can fund the primary team that supports that product. Note, however, that we also talked about the fact that it is a “fairy tale” that a single 2-pizza team can do all the work for a given product. But having cross-skilled resources associated with products is necessary. Then when funding changes, if we are truly agile, we can move people accordingly. I realize this is easier said than done, but it needs to be a goal.
Processes which require 30, 60 and 90 day views of “demand” and also fulfillment processes with long SLAs are not agile in any sense and do not support the increased need to be quickly responsive to business needs.
InfoQ: What is your definition of a value stream and why is it important to align work and teams with it?
DeArdo: A value stream is the set of activities and time spent focused on delivering “value” to a given customer. Value streams start and end with the customer.
The reason that it is important is because the focus of any business is to deliver value to its customers. Value streams are the mechanism in which this can be accomplished.
InfoQ: What are the possible relationships between value streams and business areas?
DeArdo: It’s important, as stated above, to align business products with product teams. A complexity that many areas deal with is that this is not clearly seen today which leads to local optimizations that do not actually improve the flow of value to these customers.
InfoQ: How does product-orientation help manage and mitigate risks better? Isn’t there more risk of “forgetting” about risks when they’re not mapped to a particular project?
DeArdo: Risks are inherently associated with a product. For example, there’s a risk that if I don’t change the oil or do other maintenance on my family cars, failures will occur. Because the risks for each car are different in terms of types and time frames, having this as part of a “Transportation” project would be more cumbersome than simply having each product used for Transportation having its own set of activities which included the risks (e.g. recalls) and maintenance (debt) activities and also perhaps “features” such as adding Sirus XM.
A product owner is best able to provide “system thinking” around what is best for that product. There is visibility across the different types of work that are being continuously prioritized and tracked.
Finally, many times project managers are rewarded on delivering business features at a minimum cost. Paying for a security fix for a system that is being changed in the release is not something that aligns to that goal. Having a product orientation gives that control to the product owner to manage without conflicting incentives.