IT takes on a product mindset

When Steven Palmese moved into the CIO role at Presidio two years ago, he found an IT department delivering technologies through a project-based approach using waterfall development methods for some tasks and agile practices for others.

Palmese knew that wasn’t going to work moving forward.

“It’s not responsive. By the time you produce a solution, it could be irrelevant, so we had to adjust and find a way to function with the business to give them what they need more quickly,” he says.

He has been moving his IT department — and the rest of the company — toward a different way of working ever since.

Palmese partnered first with his company’s CFO, knowing that she shared his vision for working differently to get IT tools to her own team more quickly. He reorganized some of his IT staff into teams centered around those finance department tools, or products, and hired a product manager who had both a finance background and technical acumen.

He then put the new team into motion, tasking it to work collaboratively with the finance department to deliver technology features and functions quickly and iteratively so it can rapidly meet the department’s most immediate needs.

Bolstered by that successful launch of a product-based approach to IT delivery, Palmese continues to reorient more of his IT staff and company departments to this modern way of work.

Like so much else in business, he says this move to a product mentality in IT is a journey.

It’s also a commonly tread path.

CIOs have been shifting how their IT departments respond to business needs in recent years by finding ways to quickly create technology that addresses them. That has many IT chiefs now trying to get their staffers to work on products, not projects.

That may seem like semantics to some, but the difference between the two mindsets is significant and requires a lot of hard work to succeed.

Yet executive consultants, business advisors, and leading CIOs say the shift is necessary for organizations to remain competitive, where market demands and circumstances can and do change at lightning speed.

“This is ultimately essential for thriving today and in the future world, because firms in every industry are now required to do far more technology-enabled innovation to compete. It is an existential need for every organization today,” says Steve Berez, a partner at Bain & Co. and co-author of Doing Agile Right: Transformation Without Chaos.

Product, not project

CIOs as well as chief technology officers and others experienced in product delivery draw clear distinctions between project and product.

“A project is the realization of an idea that someone had yesterday — regardless as to whether it remains valuable today or tomorrow,” Data Conversion Laboratory CIO Tammy Bilitzky says, summarizing a commonly used phrasing for describing what a project is.

She cites the Project Management Institute’s definition of a project, which is “a temporary endeavor undertaken to create a unique project service or result.” A project has a definite beginning and end, she says, adding that, for a project, success means it’s completed on time and within budget.

But delivering projects can limit success in IT and, more importantly, business.

“We all know that by the time a project is completed, even if we successfully managed scope to keep within budget and schedule, the outcome may — or may not — be useful to its stakeholders. It may require several follow-up projects to produce a useful deliverable. Or it may never meet its business objective and, following the well-trodden path of countless projects that simply missed their mark, is trashed,” Bilitzky says.

She adds: “I am not implying that projects are no longer necessary. It’s the mindset of a project, its fixed duration and temporary team assignments, the thought that success is based on delivery to a pre-defined scope, on time, within budget — all those criteria are no longer the ingredients for success.”

In contrast, a product is an item or service — in IT’s case, a feature, functionality, application, or capability, with clear boundaries of what it is and what it is not. It has specific users (or stakeholders). And it is ongoing with continuous opportunities for improvement.

In simpler terms, if a project is meant to end, a product is meant to endure.

For IT, this means a team of technologists closely works with business colleagues to develop product improvements as soon as they’re identified.

‘Business-driven IT’

As such, proponents of the project approach see it as the best way to ensure IT continuously delivers what its business requires to compete.

“At the end of the day, it’s about the connection between business and technology and delivering value,” says Dave West, CEO of Scrum.org. “And it’s ideally not just an IT thing but it’s a business thing, because those products are ultimately business [tools].”

Chris Williams, senior vice president of technology for PrimeLending, a PlainsCapital Company, says he has seen how his IT team’s product orientation has delivered such benefits.

Williams’ IT department had already embarked on its shift to a product approach when he took on that top IT spot in August 2020, and he has been maturing that product mentality ever since. He has much of his workforce organized in either product teams (that each work on specific products) or teams that remain together as they work on short initiatives.

He describes the product teams as true agile teams that are self-sufficient and led by product owners and continually churning out new features and functionalities in response to business needs. “There’s always work for a product,” he notes.

Williams sees a different mentality at work with these product teams than he has observed in IT departments focused on projects. He says his product teams have a synergy and a collective identity as they know that the team as a whole — and not any one individual — owns a product’s success or failure.

“They’re asking questions between testers, developers, the product owner, and you see a user story evolve among those conversations before the [development] work even starts. So by the time you start development, everyone is on the same page,” he says.

He adds: “They just gel with each other, you get into a flow and a rhythm. That’s a lot harder to get to when you have transient resources that come together for a while and then disband, as they do for a project.”

Williams’ observations come as no surprise to advocates and users of the product approach, who likewise see how putting IT specialists, the product owner, and business stakeholders onto a team together creates a level of collective accountability for delivering value that doesn’t exist in a project approach.

“It’s not asking about what’s the best infrastructure or the best architecture or network, which are all required, but instead it’s asking about what people need. It’s ensuring that your internal clients and your external clients are getting what they need,” says Mark Schelsinger, senior technical fellow at fintech company Broadridge and its former CIO. “At the end of the day it creates happy clients, happy users, by developing the right product at the right time for the business. It’s business-driven IT.”

Challenges to cultivating a product setup

Most CIOs understand the value of a product mindset, and many are embracing the approach, says Matt (MJ) Johnson, managing director of the Product and Experience Lab at the consulting firm West Monroe. Only a minority, though, have successfully made the full-scale shift to this new way of working; many more are still on their way.

“You can’t just say it and flip the switch,” Johnson says. “It’s a change of behavior, culture, the conditions that surround the product teams, and the funding.”

Indeed, the challenges to cultivating a product setup are significant in an established IT department.

CIOs need to reconfigure their departments and train staff to work in this new manner, all while continuing to maintain IT services without interruption, says Robert McNamara, a partner who leads the IT strategy practice at the professional services firm Guidehouse. That also requires redefining roles with the IT department while ensuring teams have the skills to be self-sufficient, that is, to do the all work required within their portfolio.

CIOs face further challenges when trying to do all that if they have legacy still in place, as their monolithic nature makes it harder (if not impossible) to break out products to assign to teams, according to multiple sources.

And they need to refocus their own and their teams’ idea of what constitutes success, as it’s not on-time, on-budget nor is it about optimizing services and systems. It’s now speed to value. That then requires agile development methodologies and conditioning the business to expect incremental improvements rather than issue a long list of requirements all at once.

“You need a new governance structure, and you have to rethink your entire IT operating model,” McNamara adds. “And they need to adjust customer expectations on how IT and customers will work together. So it’s the operating model/governance, and decision-making, and how you organize. Those are three areas that need to shift.”

Furthermore, in addition to a full complement of skills, teams need to be empowered to prioritize work and make decisions, and feel comfortable failing, as long as they fail fast and learn from it.

Berez notes, however, that some of the most difficult challenges to success when it comes to making the switch to a product-based approach reside outside of IT — and therefore outside the CIO’s direct control.

“The biggest challenge is getting senior leadership support for the model,” Berez adds.

CIOs must persuade their organizations to budget differently; there’s no longer a detailed accounting of total costs as there would be in a project scope but rather a bucket of money budgeted to maintain a product for a set time.

They must get business leaders as well as security, legal, and compliance departments to work as part of the product teams.

And they should work with human resources to structure incentives to reward team contributors and the teams themselves, rather than managers, and to help restructure the IT hierarchy as middle management is no longer needed when teams are empowered.

Balancing projects and products

Selling the C-suite on the importance of a product mindset should be easier once IT product teams demonstrate their ability to quickly, consistently, and continuously deliver value to business units — even if it’s only through small wins undertaken to curry widespread support.

“The most effective IT organizations are working in agile products, addressing the ongoing needs of the customers or the business, as opposed to a need at some point in time or a temporary need,” Berez says.

But don’t discount the notions of projects entirely, he and others say. IT still has and will continue to have some work for which a project approach makes sense: replacing an ERP system or integrating an acquired company, for example. But experts say that even such project work benefits from the product mindset by bringing temporary teams working in an agile fashion to the task.

Even so, leading IT organizations will know that those types of projects will be the exception, and they’ll undertake those projects very selectively.

“What is essential is to understand both [product and project] mindsets, the pros and cons of each — and make your choices wisely,” Bilitzky says. “Not everything is a product or should be treated as a product — but you should carefully evaluate its potential before reaching that conclusion.”