The ability to consistently develop new products and services that delight customers is the lifeblood of a company. Developing a product-based mindset and moving away from a project-based mindset is an important first step to creating a culture that is focused on the customer. This is a foundational difference between companies that just “practice agile” and those that truly are agile.
In many corporations that produce products and services that rely on software, the traditional unit of work is defined as a project. The Marketing or engineering teams typically create a project charter to describe a scope of work that the IT organization needs to deliver to create a product or service or enhance an existing product or service. Corporations use projects to define their accounting processes, drive forecasting and budgeting, and define the structure of organizations and teams. For accounting purposes, the development of new software is capitalized and the support of the software in production in expensed. Teams of people with various skills are formed to work on projects and then disbanded when the project is finished (or fails to deliver results and is cancelled). Teams are made up of people from various silo organizations matrixed together to perform various aspects of the development process. Budget is allocated to the project in large phases and not evaluated until al
l the scope for that phase is complete. The focus of a project manager is to minimize the critical path of the project to deliver 100% of the scope as fast as possible. All that sounds pretty good. The only problem is, as we have heard many times, most projects fail to deliver the planned results on schedule and on budget.
In contrast, many companies manage everything they do around the lifecycle of the products they sell. From a product management perspective, the company focuses on managing the lifecycle of a product to optimize customer satisfaction. Teams are assigned to develop various product capabilities and stay together as those capabilities are delivered to the market. A product owner has the responsibility to define the most valuable features of the product based on direct customer feedback. The product owner’s definition of the critical path is the minimum set of features that can be delivered as quickly as practical in the form of a minimum viable product (MVP) that delight the customer. The product owner continually evaluates the incremental improvements to the product based on the value they provide to the customer. Funding can be diverted to features that show high value and diverted away from features that deliver lower value at any time during the development process. The work that the team does can be systematically tracked by tasks completed in each sprint to differentiate capitalized development and expensed support. The team is motivated to produce a high-quality product because they will own the support of it long-term. If a new product development effort fails to produce the value expected, the work of the team can be quickly diverted to other, more valuable products or services. Calculated risks are accepted as the cost of innovation and sunk costs are minimized when ideas fail to deliver value. The team stays together and is not blamed for the failure.
Even though product management makes so much more sense than project management, making the shift from project management to product management seems to be one of the toughest paradigm shifts for large corporations to accomplish. The project concept has been so ingrained in the accounting and management structures of most corporations that making the shift can be very counter-culture. In traditional, project-based corporations, people judge their worth by how many important projects they are assigned at the same time. The heroics of people on blot-out-the-sun, do-or-die projects becomes part of the folklore of the company. The worth of mid-level managers is often judged by their ability to get project funding proposals approved. Projects inject new budget wealth into their organizations, justify hiring and expanding organization domains, and put leaders in the spotlight for those regular updates to the senior executives. The concept of doing away with projects strikes fear into the hearts of most middle management. Perhaps this is one of the reasons why “Company philosophy or culture at odds with core agile values” and “Lack of m
anagement support” continually shown up as 2 of the top inhibitors to the success in adopting Agile practices.
Making the transition to a product-based management paradigm is one of the foundational aspects of moving to a more agile business model. It’s not just semantics. IT’s about managing the lifecycle of products and services in a much more deliberate way. It will likely require a long-term structural change to the IT organization. Most IT development organizations have been born and raised around large projects. A product management approach will work more effectively if the development teams are aligned to developing and supporting functional capabilities fundamental to the corporation’s products or services. Capabilities, in this context, are defined as functions and competencies that are inherent to how your company delivers and supports its products or services. Scaled Agile refers to the processes that support capabilities as “value streams”. Capabilities and the value streams that support them can either deliver value directly to a customer or support internal business functions needed to operate the company like payroll or accounting.
Making the mindset shift to product lifecycle management will require getting your engineering, marketing, finance, HR and accounting peers on board with the benefits associated with that change. You’ll need to incorporate it into the plan for change that you lead with your peers.Leading the change to, and sustaining a product-focused business model, is one of the critical roles we have as an Agile leaders.
The Agile (IT) Organization 