How To Buy
Skip to main content (Press Enter).
Skip auxiliary navigation (Press Enter).
Skip main navigation (Press Enter).
on this day
between these dates
Projects-to-Products: RC Product Budgeting vs Project Budgeting
02-07-2020 11:55 AM
Mark as Inappropriate
We have our second reader comment (RC) based post. In response to
my prior post about product managers
, James Ifill asked several good questions to which I immediately responded and suggested I would build on over time. I expanded on his first question in
. Now I'm tackling his second question: "How does finance - especially budgeting - differ between the 2 [projects vs products]?"
Product budgeting provides greater discretion to the product manager than project budgeting does to a project manager. In essence, when you choose to fund in a product model, the organization elects to fund the product itself (fund Product ABC for $100M for FY20) because the product as a whole has recognizable value that is worth investing in. The specific work that will be done for that $100M, however, is up to the discretion of the Product Manager. When the Product Manager (or Product Management team for larger products) decide which features will be included/enhanced throughout FY20, then are essentially allocating budget in making those decisions.
Some features may be highlighted at a high level in justifying the product's funding amount (what you might call marquee features -- see
my post on value elements
for more details), but you certainly would not breakout the work to the detailed level necessary for delivery. This is in contrast to typical project budgeting and business cases, where the entire scope of work is specified and estimated as part of the business case in order to justify the funding level.
A product model works better for agile organizations because it pushes decision authority down to a management level that can be reasonably expected to know all of the particulars that should go into making a decision about whether to invest as opposed to retaining that authority at a higher level with executives that are unlikely to have all of the proper data/details without consulting others, which then forces availability-challenged execs to convene hard-to-schedule meetings just to get up-to-speed and make necessary decisions.
Instead of funding specific business sponsored capabilities, you fund the release train and trust that the Product Manager will steer in the right capabilities. By "leaning out" the funding process and taking away detailed funding control of exactly what is to be built from the business, you will need to "over rotate" toward communication that what is being built is what they need. If you take away control and don't provide visibility and accountability, this whole model will fail quickly. This is where roadmapping comes in: Roadmapping is the process (and the resulting artifacts) by which product managers communicate the plan for evolution of the product and build consensus in support of that plan.
One related question you might ask centers around capitalization: How do you handle CapEx vs OpEx in a product model? If you are in a pure dedicated product model where individuals only work on one product or one related set of products, then you can generally use a percent allocation method for dividing between CapEx and OpEx -- usually grounded in historical time tracking data on what proportion of time has typically been spent in activities before and after technical feasibility and production launch.
Things get more complicated if you have individuals work across products, which means that a pure percent allocation may not capture the true nature of the work being performed. Sure, Product ABC may have a 60/40 split, but if the team member works on Product ABC half the time and Product DEF half the time -- and Product DEF has a 70/30 split -- now I have to know, at a minimum, how much time they spent on each product
-- more likely -- need to know what type of work they contributed to each product. In the aggregate across individuals, the splits may be what was estimated, but auditable records for how you got there will likely require time tracking or some other basis for allocation. This is part of the reason (although not the primary one) that dedicated teams make sense if you can afford to have them.
Reason for Moderation
Describe the reason this content should be moderated (required)
How To Buy
Copyright © 2005-2021 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries.
Hosted by Higher Logic, LLC on the behalf of Broadcom -
Supply Chain Transparency
Copyright 2019. All rights reserved.
Powered by Higher Logic