For a broad range of executives, there’s emerging consensus that now is the time to make the move from a project- to a product-focused organization. There’s also another thing that many of these executives have in common: Their teams are struggling with how to get started. In this post, I’ll discuss some key factors that can help teams address their challenges and support their organizations’ successful transitions.
Within many organizations, a primary driver for moving to become a product-focused organization is to get to a model that encourages consideration of the total investment lifecycle and total cost of ownership of technology investments. However, have you ever wondered how we got to a place where the setup investment (that is, the project) got so disconnected from the operational spend? Historically, fixed assets were purchased based on justification around their entire cost—you wouldn't create a "setup asset" and an "operational asset."
So what happened?
It's probably difficult to pinpoint a specific set of circumstances that led us here, but I do have a story/urban legend to tell that sounds as good as any explanation I've heard for how we got to where we are today:
I once asked an industry analyst with longtime program management experience how we got to the point at which operational spend became so disconnected from project spend. The analyst surprised me with her response. She said that she and her past colleagues were probably to blame for that schism. You see, she was in the IT department at Intel in the early-to-mid-1980s—back when Intel was THE hot company. At the time, many of the best and the brightest technology minds from around the globe had migrated to Intel to be a part of the microcomputer revolution.
Very quickly, the executive management at Intel realized that they would benefit from centralizing their technology investment decisions. Since each division operated as its own business, there was bound to be duplication of effort as each of the talented division leaders committed to similar activities in response to industry trends. As a result, Intel established the first modern centralized IT department—one in which all technology investments would be executed.
Guiding the activities of this new centralized IT function was a steering committee that included leaders from each of the business divisions—all of whom were very strong technology program managers in their own right. As a result, there was general understanding and agreement on the long-range impacts of any particular technology investment and the team worked well together to move Intel forward.
Sounds great, right? So how did we end up separating project and operational spend
Well, remember that Intel was THE hot company at the time and everyone in Silicon Valley wanted to copy what they were doing. As such, Intel's "best practices" became the subject of many reports by consultants, industry analysts, and academics looking to instruct executives on how to run a successful technology business. Many of these analyses focused on the unique, centralized IT structure that Intel employed—without paying as much attention to the strength of the steering committee that guided the central IT group. Many replications later, the spirit of the change was lost, and what was left was largely the structural approach in which IT was centralized, and moved away from the business. The rest, as they say, is history.
Whether you believe this urban legend or have another explanation for how this disconnect came into being, it is clear that this disconnect prevails, and needs to be addressed. In speaking with customers attempting to become a product-focused organization, I'm often reminded of the early days of the expansion of project portfolio management (PPM). Back in those early days, we would often run into customers asking the key question: "What is a project for our organization?" They say history repeats itself, and sometimes it’s true: Today, a lot of customers are now asking "What is a product for us?"
Some practitioners ask the question out of confusion as they don't see their organizations delivering traditional "products." For example, a leader of a major government agency expressed concern that "we don't really have products." We then proceeded to have the following conversation:
ME: "Well, what do you fund?"
CUSTOMER: "Oh, we fund capabilities."
ME: "Do you also have capabilities managers who are responsible for the capability and its budget?"
CUSTOMER: "Yes, we do."
ME: "Sounds like that's a good start for the product discussion."
We may cover the lack of definitive terminology in a later blog entry, but suffice to say that the "product" concept is just that: A concept that could carry different names as organizations (or even parts of the organization) require.
With that said, it would probably be useful for us to agree on a common set of characteristics for a product. As a reminder, according to PMBOK (which stands for Project Management Body of Knowledge), here are the standard characteristics for a project:
Constitutes a set of related activities
Has a definite beginning and end
Creates a unique product, service, or result
Receives explicit funding in the form of money and/or people
Based on our research on hundreds of enterprises, we would propose the following characteristics for a product:
Represents a sustained asset
Has an indeterminate life (that is, an uncertain end date)
Delivers value that can be articulated in reasonable business terms (like outcomes)
Receives recurring, explicit funding in the form of money and/or people
This set of items appears to encompass the primary points that define a product-type investment and that would benefit from "product management" techniques. In conversations with customers, we've often found it useful to discuss an example of a "product" that illustrates how a product might be distinct from other investment types, such as applications or systems. Toward that end, here's one example of a possible product:
Product: Airline Check-In
Durable asset/sequence that receives recurring investment and has an indeterminate end date
Has a manager (or group of managers) responsible for the experience
In this case, the airline may use it "internally" to place people on their own planes or contract it for use "externally" with regional carriers (as an example)
The check-in process actually ties into several different systems (or potentially other products)
Flight-line operations (for example, whether status is on-time or delayed)
Seat selection (a process that may be contracted to a third party)
Baggage handling (such as number of bags, and whether overweight or not)
Booking (changes or cancellations)
Frequent traveler (in case traveler’s status affects seat availability, baggage charges, and so on)
Promotions/marketing (if we want to upsell additional flight features)
The high-level goal is to put people on planes as efficiently as possible
This system could have cross-management implications or dependencies with mobile apps, airport operations (for in-person kiosks or desk), and so on
The main point here is that "products" is not necessarily synonymous with "applications” or “systems." That might be the case, for example, if an application is significant enough or provides obvious business value on its own. However, you may also find it better to bundle several applications or systems into a product in order to articulate the business value.
Hopefully, this model will offer some useful food for thought as you navigate your transition to becoming a product-focused organization.
Brian Nathanson is a recovering certified Project Management Professional now serving as the Product Management Lead for Clarity at Broadcom. He is the host of several popular Clarity-related customer webcasts (Office Hours, Release Previews, and the End-to-End Modern UX Demos) and has conducted many hours of both project and product management training in various forums. Before joining the Product Management team, Brian helped dozens of large enterprise customers realize the value of project & portfolio management for over a decade as a Clarity Technical Sales Engineer. In his life before Clarity, he worked with state/local government customers on projects to integrate their mainframe financial systems to the World Wide Web (as it was known back then). Brian has his Masters' of Science in Engineering from the University of Pennsylvania, where he focused on the application of portfolio principles to making technology decisions -- a passion that he continues to pursue in his current Clarity role.