This is an overview of the main changes you will have to address if you decide to switch to a product-centric organization.

This article introduces product-based development as an alternative to traditional software project-based development that is still dominant, mostly at the IT departments of companies that have several years in the industry.

The text will not focus on the methodology (Agile vs. traditional) but on the company’s organizational structure and therefore, the needed change in the management’s mindset in order to make the required transformation. Although this will give us some clues about why one paradigm works best than the other, it is not intended to present the advantages of product-based development but to give an overview of the main changes you will have to address if you decide to switch to a product-centric organization.

Project-centric development

In one of my previous articles, I dug into the tasks and responsibilities involved in management and leadership, trying to demonstrate how different they are. I also argued that if you are committed to a large complex project, a good Project Manager (PM) is not someone you can replace easily with just another good Project Leader.

The necessity of having a good PM and a good Leader relies on one single premise: building software to commit and deliver a project plan. However, it is largely proven that most software projects are very complex, with so many variables to take into account that most of them need to continuously adapt their execution plan based on the feedback obtained from the stakeholders as often as possible.

A good PM would help to adapt the plan and track the project properly but mostly would manage the client’s expectations. But even with the greatest PM and Project Leader commanding the development, following this continuous adaptation process of a project plan represents a huge effort.

In most cases, it does not pay off with the actual value that the project was meant to produce. In other words, a software project where a PM needs to adapt the traced plan continuously – no matter how good this PM is at planning and risk management – would be doomed from the beginning. The expectation that the PM should be able to answer if it is on track, or when a given feature will be done, would not be met.

Content related: Five of the most effective software projects leadership tactics

Before moving forward, let me define what I mean by project success (and therefore what would be a failure). It does not matter if a project is delivered on time or within scope and estimated budget; what really matters is the added value perceived and measured by its stakeholders once the project finishes (i.e., the actual gain that the company obtained from the project delivery). If you Google “software project fail”, you will find plenty of surveys and articles describing how a vast majority of software projects fail (under this definition of actual real value delivered to stakeholders).

So, what can we do under these circumstances? How can we save the project and achieve the expected results? The answer is simple: We won’t save the project at all. Instead, let’s shift the software building paradigm from project delivery to product development.

Product-based development

Thinking about developing products – not projects – tends to be associated only with a change of methodology and paradigm, constrained only by the internal works of the IT department. After all, products instead of projects, is actually one of the pillars of Agile methodologies. In reality, many companies around the world that call themselves Agile continue with the annual goals based on objectives organized around projects: At the highest level of the organizational chart, they manage projects, while at the bottom, the Project Leaders and IT managers attempt to turn the high level project plan into a product-based development.

As a word of caution, not every organization can successfully switch from project delivery to product-based development. Only a few companies really understand that the real gain in productivity and performance boost comes when you change the entire company mindset from one approach to another. That implies much more than just the IT department.

For companies with several years in the field, it may represent a huge shift in the organizational structure and even in the cultural mindset of their members. The company must evaluate the required effort and decide if they are willing to carry it out. When it can be done correctly, most companies indicate it surpasses the project-based development.

Having said this, let’s go a bit deeper into what we really mean by working on product-based development and how it compares to the traditional approach based on projects.

Funding

Product-based development implies the organization needs to fund the development and maintenance of a product, mainly without a time-framed set of features to be implemented. It also implies that what needs to be funded is the work that will be done during the year. For a software project (as for any other intellectual work), it means funding the team that is assigned to the product. Note that not funding based on objectives does not mean you will not have goals to achieve. That is another part of the story involved in how you will measure the development and the added value of the product.

Generally, when a project ends on a project-based development, the team working on it is dismantled and members become part of different new projects based on their skills and expertise. Instead, working on products and funding teams imply they become the product experts, and they have to continue with the same product across the entire product lifecycle.

Organization

Typically, a company organizes its capabilities in separate departments: finance, risk, marketing, sales, etc. When a software is needed, the company tends to mimic the organizational structure creating independent units of work specialized in different stages of the development: management, databases, web, and even testing and QA, all of them with their own isolated area with formal communication channels and separate objectives (this is known as Conway’s Law). But the software being built, in general, includes tasks that have high interaction and dependencies across all these areas, including clarification of requirements from non-IT departments like finance and marketing. On the contrary, working with a strict separation of departments tends to slow down the development process, making it hard to understand what is really needed for a given requirement to move from one department to another via an email or any other kind of communication.

Product-based development demands having the development team all united under a single department (note that as I said above, the organization funds the team). Besides facilitating the interactions needed among the different layers of a software, one of the main reasons we need this type of organization is to allow the team to be as autonomous as possible. Bear in mind that a big company may have dozens and even hundreds of different software products, and each of them would need its own development team. Therefore, keeping dependencies among the teams as low as possible and providing the team with the autonomy to adapt their own product are fundamental.

Goals achievement

You have teams that are funded for the products they are building and maintaining, and there are no predefined goals in terms of a detailed feature to be built. So then how do you measure success and performance during the year?

First, you have to figure out the metric that fits best to your company’s interests. The metric should be based on outcomes (real gain in the business, i.e., business KPI) instead of outputs (specific artifacts produced because of a project delivery).

When you work on a project-based development, the benefits are estimated at the beginning of the project, thus, delivering the project successfully means the benefits were met successfully. In practice, this rarely occurs. The project has many changes during its execution and the original estimated benefits tend to not be accurate at all. It is hard to define a method or measure that really works for validating the obtained benefits once the project ends.

Do not miss this: Software estimation, planning, and forecasting

Product-based development implies the product owner must periodically demonstrate the current performance of its product. It can involve A/B testing, user surveys, or sales indicators, among others. The tasks a Project Manager is involved in (as part of the project plan) evolve into defining success indicators, to be continuously monitored during the product lifecycle. Achieving the determined KPI values allows for the continuity of the product and therefore the continuity of the team working on it.

In terms of people working on a project-based organization, the team is evaluated based on whether it delivers the project on time but it does not mean the delivered project adds the expected value to the organization. Product-based development forces the team to commit and align with the organizational goals and strategies in a much stronger manner. If you work on a product, since your product success depends directly on the success of the organization, there is a real commitment to delivering true value with each new version of such a product. Any feature that does not contribute to these measured added values would lose priority and will be dismissed.

Don’t leave without reading this: What a PM should do to succeed in software development

To sum up

Shifting the paradigm from planning and delivering a project to continuously working on building and improving a product is not an easy task, especially for big companies with many years in the market. Such a change implies a major cultural change and the classic definitions of management and their roles need to change drastically.

However, taking into account the real success ratio of most software projects regardless their industry, it is an endeavor that should be considered seriously by any organization.

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.