When deciding on selection criteria we have to look at our current situation or constraints and identify criteria that will make our decision fit within those constraints. One key about selection criteria is that they must be orthogonal, meaning independent, non-redundant, and non-overlapping. If they are not orthogonal you are inadvertently giving a criterion extra weighting. For instance, CPU clock rate and Whetstone performance are closely coupled computer parameters–do not use both. Things like, cost, effort, or complexity are typically used as criteria. Any one of these is fine, but if you use two or more you will probably have skewed results. When people do not have a hard cost number they usually estimate cost based on complexity or effort. When they try to estimate effort they typically look at how complex a project/feature/requirement is and then estimate effort. Sometimes the best way to ensure that this isn’t happening is take a set of stakeholders that are making the decisions and ask what they believe each criteria is measured, or how they will base their rankings. Unless clearly defined and given unique metrics that do not overlap these criteria will lead to over weighted selection criteria, that will deliver results not in line with your strategy or business objectives. In the next step of portfolio management we will address Identifying Ranking Metrics for each selection criteria.

“Dub” McNamara from F.L. McNamara Consulting gave a presentation entitled “Linking the PMO to the Organization’s Strategic Plan.”

He started off talking about the purpose and mission of the PMO office he currently works in, and then to a more general audience he did talk about how he perceived other peoples PMO offices to be. Here is a combination of what he said and what I thought as he was saying it.

A Project Management Office can manage projects in technology and process, sometimes they manage projects in sales, marketing, accounting etc.  So they are a group of project managers that manage projects regardless of content. They get involved more with high risk/high profile projects for hands on management. The PMO has project management skills that other departments may or may not have. A lot of times an executive team will create a PMO when “nothing is getting done.” Lots of great projects with nothing coming to completion.

So with all this insight I had to ask myself, and maybe you would to: Does the person in marketing have the project management skills to successfully complete the project that was just assigned to him, what about that critical sales project that John just took on, or the team in IT, accounting, etc? Cathy Liggett, @cathyliggett on twitter, referred to this recently as a persons performance readiness.

Another service of a PMO can be Project Portfolio Management. PPM here refereeing to selecting, evaluating, and ranking project proposals. One point someone made in the meeting was that it was hard to get the departments to get you the information that you need to make the decision, and not only can it be difficult to get, but even more difficult to get information that is comparable.  I had a good conversation about this with Mike Boudreaux, @mikeboureaux on twitter, during Product Camp Austin. His responsibilities at his company has him deal with similar issues.

“Dub” suggested that the PMO provide coaching and training to improve the performance readiness of managers and staffs to manage their own projects. I’ve seen other companies have a separate training department that might take this on. Or check out PMI’s website for info.

In a lot of processes one of the last steps is to review and learn, Stage Gate has a post launch review, and GOSPEL has Learning. Most would agree that having a review is valuable, but the consensus in the meeting was that it was pretty typical to have a hard time conducting the reviews. Besides, sometimes the reviews are planned when their is nothing that can be done about it. I think the trick would be to hold reviews when action can have impact, not when the opportunity is come and gone.

Getting into the meat of “Linking the PMO to the Organization’s Strategic Plan” “Dub” stresses the importance of asking the right questions. Here are some he suggests:

1. What are the right projects and how are they identified and selected?
2. What are the organization’s mission, vision, and strategic objectives/initiatives?

*The Anthropology of Product Management CoP would want me to make sure to identify culture, taboos, tribes, etc. Check them out on twitter #AoPM or their LinkedIn group.

3. Who determines the organization’s mission, vision, direction, and strategic objectives/initiatives?
4. What are the goals of the organization?
5. What is the process for determining the organization’s goals and objectives?
6. What are the components of a “good” strategic plan?

There was a lot of content in the meeting, and the next part was about one strategic planning process called the Balanced Score Card. I am sure that we will have lots of posts on the Balanced Score Card, cascading score cards, service balanced score cards, and just plain old score carding, so I am going to leave that for another day. I will say thought that one of the biggest differences between Balanced Score Card strategic planning and others is the more equal evaluation of projects across some form of four categories, Learning & Growth, Business Process, Customer, and Financial, not just Financial.

Because I didn’t get a chance to twitter about this meeting, I would love to pick up a conversation on this using the #PMI hashtag in twitter, and/or comments here.

I recently talked with a Product Marketing Manager whose role was among many things, to select which out of the hundreds of proposed projects (products, or roadmaps in this case) his company should sponsor. We spent the majority of time focusing on selection criteria discovery and definition, but eventually I would have lead him a little by asking who else on his team makes the final decision. I am sure that he would have said that his team works together on the selection, but ultimately it was decided by him.

When products and projects fail there are always many reasons. Often it easy to point out that a major reason for failure was that change adoption was not addressed. Change adoption within the company developing the product and change adoption within the market that product was influencing.

Would anyone argue that when your team decides to go with your opinion you usually support it? Better yet, make sure it is successful, live it, defend it, go the extra mile with it? And when the team decides to go with something that you think is wrong how easy is it for you to give that same effort and focus? Depending on how much my Product Marketing Manager wants his team and company to be on board will really determine if he wants to come to a consensus or come to a vote.

A consensus is where the team looks at all of the rationale behind each position, and comes to an agreement on what the right approach is, because each person sees how one position is being selected, and agrees that that method of selection was the best method. A vote is where the arguments are given, and then the group with the most people in agreement wins. There is one thing that a vote will always create that a consensus will not… a minority. What are your thoughts? What are some more reasons and situations for consensus vs. vote?

However, the roadmap isn’t just a feature planning tool for an individual product; it can be used by senior management to communicate the strategy and desired direction of the organization to each individual product manager. In the book “Leading Product Development” by Wheelwright and Clark it talks about these roadmaps and the role senior management plays as Product Line Architect. In this role, senior management defines the types of products that will be in the product line, such as breakthrough products or platform products. Take into consideration what the product line looks like to today’s customer, what it should look like in the near future, and the long-term view. They also determine the revenue and growth desired from each type of new product development.

Using a roadmap, senior management can plot out all the new products and their relationships to each other in order to communicate the desired direction of the company and the strategic vision. Having lunch with a VP of product management a few months ago, we discussed this type of roadmap. We plotted out on a timeline the current and future products in the product line and lifecycle of each going forward. We determined how much revenue, market share, growth, etc. we expected from each of the products at different times in the roadmap. This helped us plan out the new product projects to be introduced and products planned for end of life as well.

This type of roadmap, that I refer to as a strategic roadmap does not include feature sets, it is focused only on the types of products or new product projects, when they should be rolled out, and their relationship to each other. When used in this way, the roadmap becomes a key tool for communicating the direction of product development and our overall strategy.

          A sub step to identifying alternatives is to segment them into sub-portfolios. This allows you to manage the alternatives in a much smaller group and will enable portfolio balancing later on. Sub-portfolios should be based on certain characteristics so that all elements of a sub-portfolio have those characteristics. These sub-portfolios create a hierarchy of aggregation for the entire portfolio. Characteristics for new business opportunities for example might include: investment risk, alignment to core-competencies, fit within existing product line, potential ROI, or market access. I would then create sub-portfolios for my organization that would use these characteristics to segment my portfolio of business opportunities.

          Let’s say I break it into 3 sub-portfolios and use typical ones from PPM called Maintenance & Utilities, Enhancements & Improvements, and Transformational. The Maintenance & Utilities sub-portfolio would include all business opportunities that had a low investment risk and ROI and small market size, but a very high fit with the existing product line and core-competencies. Thresholds would be setup for each characteristic to determine which of the 3 sub-portfolios a business opportunity should belong to. These sub-portfolios make it easier to perform the other 4 steps in portfolio management and to achieve one of the 3 goals of PPM: Balancing the portfolio.

 In the Robert Cooper’s book on product portfolio management, he states the three main goals of portfolio management very well. First is to maximize the value of the entire portfolio of x (products, features, market opportunities, family activities, whatever you’re managing).   The second is to balance conflicting factors in your portfolio such as risk vs. reward, attractiveness vs. ease of implementation, etc. The third is to align the portfolio to strategy (product, corporate, or personal). If you simplify portfolio management it consists of 5 steps:

1.       List Alternatives

2.       Identify Selection Criteria

3.       Identify Ranking Metrics for Alternatives

4.       Weight Selection Criteria

5.       Determine Execution Capability

The first thing to do is make a list and identify all of your options. Once that is done, a set of selection criteria needs to be defined so that the selection is defendable and repeatable. Ranking metrics for each criterion need to be identified so that the options or alternatives can be ranked. The selection criteria need to be weighted based on their relative importance to your organization. Often times these weightings will change and be impacted by the current business driver of your organization. (Ex: increase sustainability, reduce cost, increase revenue, etc.) When this step is completed you have a ranked set of alternatives (opportunities, features, products, etc.) based on weighted selection criteria. The last step is to determine the capability of executing on the alternatives. This looks at resource demand and availability information to help select and sequence preferred selection in context of feasibility. Each one of these steps has best practices and approaches to performing them. In the future Portfolio Management Blog Series I will address each step individually.  

In brainstorming we defined a roadmap view that would be helpful showing this information in a graphical format. This roadmap would identify the types of products into different categories: Maintenance & Utilities, Enhancements & Improvements, and Breakthrough or Transformational products. We then discussed using similar techniques at the release planning level.

Based on the roadmap we’d know what type of product we were trying to launch. We would categorize features or requirements into each type: maintenance & utility, enhancements & improvements, and transformational. By setting target percentages for each of these categories, we can ensure that the product release is in line with the strategy.

This allowed us to tie the roadmap strategy down to the requirements and features being worked on in a release. I’d be interested to know how others have gone about ensuring strategy execution in release planning.

It was a great conversation with lots of possibilities and an excellent meal.