From Projects to Products
Most enterprises organize work as projects: temporary, budget-bound, deadline-driven. AME3 organizes work as products: long-lived, evolving, team-owned. The shift between these two worlds is one of the hardest transitions an organization can make.
Choose Your Own Game covered how to select and combine frameworks. This chapter applies that thinking to a specific situation: you have projects today, and you need a path from here to there. The Playbook shows how to set up Arenas and start the game. This chapter addresses the question that comes before: should you start, and if so, how do you decide at each step?
The following flowchart shows all decision points. The sections below walk through each one.
Project vs Product
“A project is a temporary endeavor undertaken to create a unique product, service, or result.” (Project Management Institute)
A project has a fixed time frame in which investments are made to achieve a result. A product does not. We constantly invest in products with the work of our employees. Even decommissioning a product requires investment. It is ultimately the last user who determines when a product no longer exists.
Products are significantly larger in scope than projects, and the targeted performance is anything but linear.
The blue curve represents the desired ROI development. From a company’s perspective, a project is an investment in the product for a certain period (red box). Scrum can be understood as a sequence of projects with a fixed period of one Sprint (in AME3: Match) (green boxes). Each Sprint generates knowledge about how the next investment can be improved, at much shorter intervals than before. In extreme cases, this knowledge can stop the investment completely at an early stage.
Is This Project Simple, Complicated, or Complex?
Short projects, completed within four weeks or less, do not need their own Scrum Team. Instead, include the work as items in an existing Arena Backlog and let a Team pull them into the next Match. The Team optimizes its work so that waiting times are minimized and a customer order can be completed within a single cycle.
For this to work, ask: what is the product that the employees are working on? In the case of a web agency, the product might be “the service for the development of web offerings.” Define the scope broadly. The agency owns the service and bears the associated obligations. Even if each individual order is only complicated, operating and improving the service as a whole can be very complex.
The same principle applies beyond software. A company that builds modular houses treats the turnkey houses as its product. Planners, manufacturers, fitters, and craftsmen in the Teams derive optimizations from experience gained in customer projects. I recommend using Wardley Maps to identify multi-team structure and potential for innovation.
In AME3, small projects are most likely one or a set of Improvements in the Arena Backlog
The majority of projects have significantly longer duration. A longer duration is an indicator of higher complexity: many unknown factors will influence the project that cannot be predicted at the start. This is the nature of product development, not a failure of the project team. As a guiding principle: if the question whether the project is complicated or complex needs to be discussed, then it is most likely complex. The Cynefin Framework can help: it distinguishes between complicated problems, where expert analysis yields answers, and complex problems, where only experimentation reveals the path forward.
Can You Afford to Start?
If the project is complex and the demand for innovation is high, we arrive at the standard case for Scrum. This is the birth of every Scrum environment, the pattern that The New New Product Development Game first documented. Form an initial team. A System Lead takes care of building the team. A manager with decision-making powers takes on the role of Arena Owner. This team, as autonomous as possible, can question existing rules and develop entirely new approaches.
But many enterprises fall into a trap here. Too many projects start simultaneously. Some companies have more active projects than employees. A complex project does not just affect one team. It influences the work of the entire organization. The fewer the number of active projects, the shorter the lead time. This generates value and feedback earlier, which benefits the next projects.
Before starting the next project team, check that the maximum reasonable number of active projects is not exceeded. If it is, the new project must be weighed against all active ones. If those are organized with Scrum, the Increment and the team’s experience provide the best data for the decision. A positive result can be canceling an active project in favor of a more attractive one.
A project can be considered as an entry in the company’s project backlog. In AME3, this is the Enterprise Backlog. With Goals or project profiles as entries, the Enterprise Backlog becomes the input for a Kanban system to make the flow from concept to cash transparent. Experiment with a work-in-progress limit (WIP limit) for Goals to discover how high the maximum parallel project load can be.
In AME3, the list of all Goals (projects) is the Enterprise Backlog, prioritized by the Enterprise Owner. Only the Arena Owner of an Arena can pull a Goal into focus.
Continue, Pivot, or Stop?
Whatever the innovation project was, the costs are most likely higher than expected. Scrum shows its full strength here, because progress is measured by the finished product Increment. It is the best source of data for making predictions about the future. Usually after three Sprints, at the latest after nine, a decision can be made whether to continue.
Three priorities at this stage:
- Stabilize the team. Do not expand unnecessarily. Keep social complexity to a minimum. Secure external talent on a permanent basis. The project team may become a new organizational unit.
- Focus on technical excellence. The Arena Owner should pay particular attention to the non-functional requirements of the product and focus the team on system architecture. More important than scaling employees is being able to scale the product in the market.
- Choose a scaling framework if needed. If the product team grows beyond 10 to 12 people, the System Lead should choose a lean framework for scaling. If done skillfully, scaling according to LeSS will happen naturally.
An early conclusion that the project will not succeed as expected is also a win. It clears the way for a project that opens up more opportunities.
In case A, you will probably continue to invest in the product. In case B, you will most likely cancel the project and product development.
In AME3, the Arena Owner and Enterprise Owner are responsible for deciding whether to continue working on a Goal or to change direction.
From Project Team to Arena
If the newly created organization can work independently of all other parts of the enterprise, there is much to be said for formalizing it as an Arena. The Playbook provides the detailed path: Entry Point 2.1 for new, independent products, Entry Point 2.2 for existing work systems with agile practices already in place.
If other Teams are also working on the same or related products, it makes more sense to incorporate the new expertise into an overall product organization. This means a reorganization of the teams and organizational units involved. The sub-product created initially by the project is further developed by all teams of an Arena. Such an organization then no longer speaks of projects but of Goals.
The Accountable Representatives of the Enterprise should now refine the strategy toward the next step in the evolution of the product and services. The result will be new Goals for innovation. An Arena can pull that Goal and a Team starts working on it.
Beyond These Foundations
These three chapters covered the practical foundations: how to plan when you cannot predict, how to choose the right framework, and how to transition from projects to products. They are starting points, not endpoints.
The Appendix provides extended guides on specific methods: Wardley Mapping for strategic terrain, Estuarine Mapping for constraint analysis, Stacey Matrix for complexity assessment, Visualizing Enterprise Goals for portfolio decisions, and scaling approaches like LeSS and Scrum@Scale. The Further Readings section grows continuously with new articles, practical how-tos, and hands-on guides. Visit ame3.ai for the latest additions.