Strategic CIO Advisors

Shifting the mindset from projects to products

A recent post on changing the language of IT is getting quite a bit of attention among CIOs. Continuing the theme around changing the language and culture of IT, we shift gears to the mindset of projects and products. For decades, the IT mantra has been to complete projects on-time and under budget. While this may have worked well in the past, moving forward it inhibits the very core of how we deliver solutions on many different levels. Let us take a look at this a bit deeper to appreciate the challenges in project thinking and opportunities that come from a mindset shift to product thinking.

THINKING LIKE A PROJECT

The very core of project thinking considers a discrete ‘thing’, which is represented as the project and has a specific start, end and deliverable. Project thinking brings significant focus to the deliverable and parameters that support the deliverable. That can be a good thing. However, in practice, it often means too much focus. Yes, there is such a thing as too much focus. Have you heard of the phrase “Can’t see the forest for the trees?” Some of the same principles apply here.

Part of the problem has to do with timeframes. Projects can last from weeks to years. The longer the project, the bigger the issue. Over a period of time, dynamics change. Companies change. Their needs change. Even the very reasons for starting a given project may change…or worse, disappear. Yet, many still get stuck in the mantra of delivering the project on-time and under budget. Even if that means that the deliverables are no longer relevant or the needs have changed.

It is not just the project thinking that needs to change. Projects do not happen in a vacuum. The way budgets are constructed, management is organized, and objectives are set all center around project based thinking. Like many things in the complex world of IT, projects are only one facet of a broader ball of yarn that needs to evolve.

THINKING LIKE A PRODUCT

A good alternative to project based thinking is product based thinking. Many of the same metrics for projects apply to products. The one stark difference is that products evolve over time. Put a different way, products are constantly evolving (or should be) to remain relevant. Projects are very different in this way.

The constant change of a product forces a shift in thinking around remaining relevant through the different phases of the product development and lifecycle. Even the terms shift to an evolutionary focus.

By changing the paradigm to a product based one, the thinking changes in two ways: 1) There is a constant awareness to remain relevant throughout the development and shifting gears as needed and 2) products have an ongoing lifecycle process versus the start/ end focus on a project. The product based thinking forces a whole new set of questions like: How long will the product be in use (lifecycle)? What choices are implemented now in anticipation of future versions of the product? These two questions have a dramatic impact on choices made in the current phase of the product.

MANAGING THE LIFECYCLE

The lifecycle of a product can be applied to any application or service within an IT organization and their portfolio. For example, take something as benign and simple as Microsoft Exchange email. If Microsoft updates Exchange every 18 months and it takes the IT organization six months to plan an evaluation and/or upgrade, then every 12 months an evaluation is started to determine if the service (email) is a) upgraded to the latest version of Exchange, b) migrated to a different solution or c) retired from service.

In project based thinking, one might only be focused on the upgrade of Exchange irrespective of the implications to the lifecycle. There are also implications to the IT application/ service portfolio, but that is a whole discussion on itself.

MISSING THE LOST OPPORTUNITY

Are projects bad? No. But they are missing a vital component that is a critical component of products: Context. Whether it is the time that resources are committed to a project or the cost to engage the project, there is a value component that comes with greater insight to context. A project might miss a significant opportunity while a product could seize the opportunity. One side benefit is that IT portfolio management becomes a whole lot easier using this methodology.

Shifting the mindset from project based to product based creates a significant shift in the IT culture and thinking that aligns more fully with business value. It creates agility and engagement in ways not possible with project based thinking. As business value shifts, so does the product. As customer needs change, so does the product.

Moving IT from a project based methodology to a product based methodology is yet another significant step in changing the language and culture of IT.