Do you think portfolio management tools should be integrated with requirements tools? If so, what are the integration...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
I think about portfolio management, specifically a portfolio of products, in the context of enabling a particular corporate strategy. The company has some specific goals (revenue growth/growth rate, market share, share of wallet; be the preeminent provider of X, etc.) Creation of a collection of products to serve various customers in their target markets is a business design decision -- people usually call this "corporate strategy." That design has (or should have) a rationale that reflects how each product will contribute to achieving those identified goals. This is a decomposition step that identifies the expectations that are placed on each product -- ideally described as quantified metrics that reflect how successful each product is in its contribution to the overall strategy. This also becomes a structure for management accounting -- allocating overhead and other costs to each product.
This is an analog of requirements traceability at the high level. The team evaluating the corporate strategy should evaluate two key factors of this traceability -- completeness and correctness. For completeness, the team will be asking a coverage question: "Is every aspect of our strategy addressed by one or more of the products in our portfolio?" Then any missing aspects have to be addressed. For correctness, the team will be asking a per-product question: "Do the goals for this product map back to overall corporate goals?" Then they will either update the product goals or the strategy when there isn't alignment.
The "goals per product" aspect of this analysis is where the transition from requirements management to portfolio management happens. This is the "top down" integration point.
Within a requirements management tool, you are starting with a "top level" that describes the goals for a product (and the metrics by which the team defines meeting those goals). Decomposition of those goals into particular requirements (defining personas & target markets, identifying use cases or user stories, applying constraints and non-functional requirements, etc.) is how this happens. The requirements management activities, as part of validating those requirements, will also perform completeness and correctness analysis. Are there requirements that don't support the goals for the product? Are there goals for the product that are not sufficiently supported by requirements? Are there reasons that "fixing" these broken alignments cannot happen?
The team then provides feedback "up the chain" about the viability (and timing) of their per-product plans at meeting the goals assigned to their product. This is the "bottoms up" integration point.
That feedback from the team is then incorporated into review of the overall corporate strategy. This is a recurring exercise -- as the strategy is updated over time, as well as the feedback from the individual teams.
Related Q&A from Scott Sehlhorst
Application performance monitoring fixes a system before it breaks. IT strategist Scott Sehlhorst offers insight into preventive performance testing.continue reading
'Continuous development' is still a relatively new and confusing term. Find out what it means beyond the hype.continue reading
Scott Sehlhorst offers strategic guidance on how to approach application portfolio management with a focused vision.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.