Tag Archives: S.T.O.P. The Project Management Survival Plan

What’s the Difference Between a Project Manager and a Product Manager?

2 Replies
Two Sides of the Same Coin - Collaborating to Create Value

Two Sides of the Same Coin – Collaborating to Create Value

Several weeks ago Steven and I, along with David Heidt IIBA Chicagoland chapter president, were presenting to the Project Management Institute’s (PMI) Chicago chapter. After our presentation our hosts collected the questions that we were not able to address as the clock ran out. The question that was on everyone’s mind was “what is the difference between a project manager and a product manager?”

To understand the difference between the roles we need to look closely at two things. First, we need to understand the phases of the product management lifecycle.* We can then highlight the difference between these two critically important roles. So let’s start with the product management lifecycle.

Imagine for a moment a horizontal plane that has seven phases shoulder to shoulder. The seven phases are Conceive, Plan, Develop, Qualify, Launch, Deliver and Retire. All products universally, and without exception, move through each of these phases sequentially. The only difference is the amount of time it takes to move from one phase to the next.

With an understanding of the product management lifecycle in hand we can then look at the specific roles of project and product managers. Product managers are responsible for optimizing results throughout the entire product management lifecycle. In other words, to optimize the creation and maintenance of VALUE throughout each unique phase of the lifecycle.

This is different than project management where, rather than staying with the product from conception to ultimate retirement, project managers typically are involved from the Plan Phase of the product management lifecycle to the Launch Phase where they roll off and take part in the next project. |

Another way of thinking about this is to say that project managers have a defined span of vertical leadership (working closely with the product manager or owner) for a specific length of time (the project) with a focus on effectively managing the scope, schedule, and cost of the project. While product managers focus on optimizing the VALUE of the effort and lead horizontal activities (e.g. throughout the product management lifecycle).

Both of these roles enhance each other and the effectiveness of the overall product development team and are in fact separate and distinct functional roles with different focuses and objectives. However, the more tightly these two roles can be aligned around VALUE the more success the product development team and ultimately the product and the organization will enjoy. It’s important to point out that while effective collaboration between these two roles drives tremendous organizational benefit these two roles should not be co-mingled as this creates a conflict of interest.

You can learn more about how to effectively drive collaboration between these two roles and improve organizational effectiveness in our popular training course Creating Value Through Collaboration. This course was jointly developed with Lee Lambert of the Lambert Consulting Group and offered regularly by Actuation Consulting and the Association of International Product Marketing and Management. The course offers 16 PDU’s.

* See page two for an illustration of the product management  lifecycle

Share via email

Product Management Toolkits

Leave a reply
Actuation Consulting's Product Management Toolkits

Buy or Build? Product Management Toolkits

Four Points to Consider.

Several months ago we conducted an informal survey of product management toolkits. Hardly scientific, we were very interested in understanding perceptions of their value. Why? Because as authors Steven and I commonly get requests for “workable” templates from our books. Up until that point we tended to respond by sending a PDF of the tool in question to whomever asked. However, the frequency of these requests hinted at a larger market opportunity.

The polls we conducted spanned a variety of LinkedIn discussion groups since no single poll would give us sufficient information to generate a reasonable sample. As I said, less than scientific.

However, the findings were insightful if not statistically significant. To summarize, we found that approximately 60% of respondents were open to purchasing product management toolkits and may or may not have already done so. The other 40% were less inclined to do so favoring tools that they had created themselves (often based on Microsoft Office products).

Today’s product managers have largely had to develop their own tools and learn through “trial by fire” as our industry continues to be underdeveloped. Think about it, how many universities can you name that teach product management to undergraduates?

I’m an Adjunct Professor at DePaul University’s College of Computing and Digital Media and I’m told that there are only a couple other folks who actively teach undergrads in the US. Compare that to adjoining professions like engineering or project management. This single data point illustrates that we’re still early on the curve as a profession.

So we tend to rely heavily on our own ingenuity and creativity. Product managers by and large are resourceful people.

While self-reliance got us this far it’s pretty clear that 6o% of the respondents have looked beyond their own tools and are open to other options that can save both time and money. To me, that is one of the key benefits of incorporating thoughtful product management toolkits.

Several weeks ago Hakan Kilic related his experience implementing one of our product management toolkits. Hakan pointed out that toolkits, no matter how good, need to be localized based upon the needs of the business. I happen to agree with Hakan.

Prior to founding Actuation Consulting, I led product management for three separate organizations. While we developed many of our own tools I continued to evolve them over time and across different organizations. However, I also evaluated and purchased other tools that could enhance our efforts, streamline a manual task, solve a specific business problem, or help drive consistency. In these instances, it made sense to rely on others expertise. Why reinvent the wheel?

This brings me back to the point of the poll. We conducted the poll as a supplemental data point since we were being asked to make our project and product management tools available to folks that had purchased our books or taken our training courses. Before we took the plunge, and devoted production time to doing this, we wanted more information. The polls results helped nudge us down the path.

Things have turned out better than we had projected. In fact, we’re rather pleased with the outcome and will be expanding the set of tools we offer in the very near future.

I think the bottom line on product management toolkits is that while they’re not a panacea  for structural or organizational issues – they are very useful in the following instances:

  1. Solving specific business challenges that the team has not faced before - for example, clarifying roles, transition points (hand-offs), and responsibilities in your product’s production process or on your core product team
  2. Creating a standard terminology and common set of tools across the product management team
  3. Speeding implementation - assuming you buy into to the methodology that underlies the toolkit (some kits don’t actually have one)
  4. Focusing more of your time on creating value as a product management professional and less on developing tools

I have yet to meet a single product manager that professes to be an expert in all aspects of the product management life cycle (ranging from the conception of an idea to the products ultimate retirement). Product management toolkits have a roll to play in helping spread knowledge and best practices.

It’s good to see that 60% of the poll respondents are open to evaluating their options. In today’s environment of lean teams and limited time and resources inexpensive tools that improve product team performance can make a difference.

Share via email

Project Portfolio Management – A Different Perspective

2 Replies

A Better Way to do Project Portfolio Management: Heat Maps

Actuation Consulting - Product Management TrainingHow do executives, looking over a wide variety of products and projects in your company’s portfolio, know when to stop or kill one?

The decision to stop or kill a project amidst a sea of projects in a portfolio can seem almost impossible. Not only is there a question around how to kill it, but can enough information be gathered in a timely fashion to know when to kill it?

The decision to stop a project or product line can’t be made in isolation. The decision has to be made considering the entire context of the portfolio. Can we in the program management and project portfolio management community help our senior executives with this decision?

Let’s stop for a minute to think about that concept and then further dive into what the requirements / specification would be in creating such a view. What if there was a way for senior management in your organization to see, in a one page dashboard, updated in near real-time, how their portfolio of projects is performing? The dashboard would have to be simple and intuitive so that quick decisions could be made, but with enough data behind it to ensure the quick decision was a correct decision.

The following concept is inspired by the recent advancements in technology and information gathering used by the financial and stock portfolio management community. The concept is called a “heat map”.  A heat map is a visual aid used to track large amounts of information very quickly in order to see trends and make informed decisions.

For stock trading, the concept is pretty simple, as stocks go up; the heat map turns green and shows the percentage increase for the day. As stocks trade below where the stock closed on the previous day, the heat map for that stock turns to red, showing the % decline in overall value. Why can’t this same concept be applied to program and project portfolio management?

To use a heat map for program and project portfolio management, we would have to slightly tweak the concept. For instance, each project would need to be weighted differently based on the overall value it will bring to the organization.  That value could be applied universally across all projects in the portfolio based on typical business case metrics like return on investment (ROI) or initial rate of return (IRR). Each projects value would have to be displayed visually to provide the proper context regarding the relative size of a projects value.

In order to do that, each project would need to be represented by an individual box or square (illustrated below). The size of each project box is representative of its relative value. The bigger the box, the bigger its value. You probably will want to keep things simple by having only three sizes of boxes to represent value. A simple high, medium, and low value determination will suffice.  Value relative to size could then be kept in a legend at the bottom of the map.

High ROI = $20MM, Medium ROI = $10MM, Low ROI = $5MM

The benefit of this approach is that it visually represents in-flight projects with expected business value or ROI.

Next, we have to take our model and measure each projects progress along the way. To do that measurement, we have to understand that every project will be a balance of the infamous iron triangle – scope, schedule, and cost.  To truly measure value against these three constraints, we need a way to quantify and assess the value of the project and identify, if value has been decreased.  Measurement of how the value of the project progresses could be assigned to each project individually using the project management value equation:

Value = Scope / (Schedule + Cost)

Source: S.T.O.P. The Project Management Survival Plan ©2011

By assigning a value to each of these constraints we’re quantifying the value of the project. Increases to schedule and cost will decrease the value of the project if more scope is not being delivered to offset these changes. It’s important that you ensure that your scale for scope, schedule, and cost are the same. Assigning either a percentage value or using a 1-10 scale can work if each variable is quantified consistently. The idea being, at the start of the project, as you determine its overall value, Value should equal 100%.

As tradeoffs are made between each of the three variables, the project value will change. Change to the project value could then be given a color to represent how the project is doing. For example, if any project has decreased in value by 15%, that would equal the assignment of a Yellow color to that project and be represented as such in the heat map. This yellow representation would provide executives insight into projects that heading into trouble and where the fundamental underlying business case assumptions may be in jeopardy.

Projects decreasing in value by greater than 25% could be given a red color, meaning that the project is off the rails and the original business case or ROI no longer holds water and needs to be adjusted. That adjustment could lead to the project being killed or postponed.

Having the ability to see project data in this fashion relative to other projects would give executives better insight into how to balance their portfolios and manage resources more appropriately. Viewing data in this fashion also provides improved focus; focus on where the trouble is and how to manage through the trouble to maintain balance to the business and the portfolio.

Using a heat map helps ensure that the best projects stay on course and reduces the chance that the organization will be burned!

Share via email

Creative Disruption – Never Lose Your Edge!

Leave a reply
Product manager, project manager, product team

Creative Disruption: A Tool to Enhance Product Team Performance

How do you keep your product and product team fresh and creative throughout the product development lifecycle? What differentiates those project managers who seem to have a successful team no matter what group of individuals they’re working with — versus those who seem to always have a dysfunctional team and troubled projects?

The answer to this question was never very clear to me early in my career. In my search for clarity, I read “Surfing the Edge of Chaos,” an article by Richard T. Pascale from the book Strategic Thinking for the Next Economy.[1] In his article, Pascale wrote about “complex adaptive systems,” which I translated into meaning “products.” He noted, “What makes a system complex and adaptive is the ability to anticipate and be proactive.” Said another way, human beings are complex and adaptive, and it’s our ability to anticipate and be proactive that allows us to survive.

Pascale helped me connect a project team’s ability to survive and be successful with its ability to anticipate change and be proactive. Pascale also wrote, “Stable equilibrium equals death.” For any system to survive, it must cultivate variety into its inner workings. If it fails to do so, it will fail to adapt to change successfully when it comes externally. While equilibrium endangers living systems, it often wears the disguise of an attribute. Species (people) are innately drawn toward stability and equilibrium – and the further they drift toward this destination, the less likely they’re to adapt successfully when change is necessary.”

We see this in products that have been on the market for several years.  A once market leading product starts to show signs of aging, declining quality, and issues with customer retention. How do you cultivate a successful project team and prevent a once-functioning team from falling into the trap of complacency, unable to adapt to the new project?

The answer lies with something I like to call creative disruption. Creative disruption is the ability to periodically create a bit of disruption or change in the team to keep them fresh and functioning. It’s is a method to stop or disrupt the monotony of the everyday. Just because something worked for a team on a prior project doesn’t mean it will work on the next project. Keep the team on their toes and in a mode of constant, critical thinking. Your project results and team dynamics will dramatically improve as this technique prevents stagnation and complacency.

This change can be something as simple as co-locating team members or changing the development approach to the project. Implementing team change has got to be something that becomes natural and understood. Large, sweeping team changes rarely go well because the team isn’t used to and hasn’t recently experienced this type of change. The team has allowed itself to become stagnant, and big changes are perceived as completely disruptive. Small, steady streams of creative disruption in a project team can lead to better efficiency and productivity of its members and are better received than change introduced in a big-bang approach.

Creative disruption can also provide continuous improvement throughout the project. Often, project managers wait until conducting a lessons-learned exercise to identify opportunities for improvement, and then they don’t implement the lessons until the next project. By that time, the project is different, the team is different, and the lessons are old and may no longer apply.

Stop waiting and start addressing!

Continually evaluate the project and implement small changes to improve team efficiency and delivery during the project. Be creative if you have to. Creative disruption will have a very dramatic effect on building team bonds and furthering team integration as you strive to create that adaptive “ideal” team.

[1] Cusumano, M, A. and Markides, C. C. (Eds.) Strategic Thinking for the Next Economy. San Francisco, CA: Jossey-Bass, 2001.

Share via email