From Project-Based to Product-Based Working: A New Era in IT

In the world of IT project management and decision making, companies need to be able to adapt to the ever-changing needs of their customers and stakeholders. To stay ahead of the curve and increase their flexibility, more and more companies are shifting from project-based to product-based working.  

As consultants of enterprise architecture, we’ve been at the forefront of this shift, helping our clients achieve success in this new era of IT. In this blog, we’ll explore the evolution from project-based to product-based working together with our Solution Architect Patrik Schrey, and explain why this approach is no longer a nice-to-have in today’s IT landscape. Let’s dive in! 

What is the difference between a project-based and product-based approach?

Companies have traditionally used a project-based approach for IT project management, where the focus is on completing a project within a limited timeframe and budget. However, this approach is becoming increasingly outdated. Enter product-based working: a new approach that is more adaptable to the ever-changing needs of customers and stakeholders.  

So, what are the differences between these approaches? We’ve identified five aspects: 

  1. The timeframe: In project-based working, the timeframe is limited to the duration of the project, whereas in product-based working, there is no end date for the product. Instead of going into maintenance mode after the project has been concluded, the team keeps working on the product throughout its entire lifecycle.
  2. The unit of work: In a project-based approach, the unit of work is a project with a defined start and end date. In contrast, a product-based approach involves defining a product that can be complex, or even a solution containing multiple products.
  3. The type of team: In project-based working, team members tend to not be always available and are often added or removed based on a specific task. There is a high degree of turnover, and team members leave when the project is done. In contrast, product-based working involves team members who keep working on the product throughout its lifecycle and provide a much more stable environment.
  4. The level of upfront definition: Project-based working tends to involve more upfront definition of the project, often using the waterfall methodology or a “sandwich model” where only certain phases of the projects are Agile. Product-based working defines the product in a more fluid way, making it possible to adjust the product as needed using Agile methodologies like Scrum or SAFe.
  5. The goal: In project-based working, the goal is to complete the project within the set timeframe and budget. In product-based working, the focus shifts to the added value for customers and stakeholder to increase satisfaction across the board. However, in some cases it’s still just about keeping the product running and adding some features. 

Why are companies changing their approach?

As the (business) world becomes increasingly volatile, uncertain, complex, and ambiguous (VUCA), companies are finding that the traditional plan-driven project-based approach is no longer sufficient. To keep with the rest of the industry, they simply need greater flexibility in responding to changes in variables. 

In the traditional project-based approach, requirements are defined upfront, often based on assumptions made by the project team. These requirements are then used to guide the development of the project, and any changes to the requirements would require a formal change request process, which can be slow and costly. 

In product-based working, the focus shifts to delivering value to customers and stakeholders by prioritising features based on what gives the maximum amount of value for each level of the scope: needs or initiatives, features, and stories. Usually, this is done by following the Pareto principle, also known as the 80/20 rule. In the context of product development, this means that roughly 80% of the value comes from 20% of the features. In other words: companies shouldn’t put 80% of the effort into 20% of the value, except for must-have requirements like conforming to legal regulations. 

This means that product-based teams can be more flexible and adaptive, as they can change features based on agreements rather than predefined requirements. This allows teams to respond more quickly to changes in the market, customer needs, or stakeholder expectations. As we’ve noticed many times, this results in a product that provides the most value with the least amount of frustration. 

What are the consequences for project management?

The shift towards a product-based approach has significant consequences for project management. To begin with, the team organisation will have to change, with internal team members contributing their domain knowledge and external consultants providing technical expertise and ways of working. Scaling Agile methodologies like SAFe can help manage large products by organising team interactions based on the level of collaboration needed. 

Moreover, companies will need to switch from project management to product management in response to the VUCA world. This requires coaching their project managers to become product owners or product managers. At Agile Architects, we prefer working with an internal product owner who has the domain knowledge and understanding of office politics necessary to make critical decisions. External consultants can play a temporary role in coaching these product owners at first. However, the product owner must have the authority to deny requests at a certain point, which should be specified in the contract if companies do decide to go with an external product owner. 

Another critical aspect is the need for clear contracts that define product management adequately. We have noticed that not defining product management appropriately is a common mistake when working with external consultants. To work product-based, contracts will have to list all requirements sorted by priority, with their added value explicitly described. The contract should also mention the starting position and explicitly state that changes can happen without a change request. Working product-based requires full cooperation of the company and trust in the executing party, even if this is an external consultant. 

Conclusion

The shift from project-based to product-based working is becoming increasingly popular in the IT landscape, as it offers greater flexibility and adaptability to the ever-changing needs of customers and stakeholders. Product-based working prioritises delivering value to customers and stakeholders, resulting in a more satisfying product.  

This shift has significant consequences for project management, including changes to team organisation, the need for clear contracts that define product management adequately, and coaching project managers to become product owners or product managers. Ultimately, embracing a product-based approach is essential for companies to stay ahead of the curve and succeed in the VUCA world. 

Looking for an expert in guiding enterprise architecture? At Agile Architects, we have a proven track record of consultancy in both project-based and product-based approaches.

Contact us to find our more.