If you are managing software development efforts as projects, you are doing it wrong.  Instead of managing projects, organizations that sponsor and develop software solutions need to shift towards managing solutions as products.  A product management approach to software development aligns with modern software development and with Agile’s inherent product management bias.

Project Management vs. Product Management

In a nutshell, project management differs from product management in that the former is primarily concerned with managing people, schedules, and tasks while the latter focuses on managing the product and how it is created.

Traditional project management is misaligned with modern software development for two reasons:

1. An overemphasis on managing the triple constraints of the “Iron triangle” to the detriment of technical execution, product quality, and value delivery
2. An overemphasis on control to the detriment of speed and flexibility

The “Iron Triangle”

Traditional program management focuses on enforcing the triple constraints of the Iron Triangle:  cost, schedule, and scope (the amount of work done). The objective is to deliver expected value on time and on budget.  Unfortunately, fixing the three constraints leaves quality as the only variable, opening the door to sacrificing quality when things don’t go as planned.  Because no one can predict the future, most traditional projects fail to deliver on at least one of these constraints.  In other words, “I can get it to you cheap, fast, or good.  Pick any two.”

Traditional project managers manage against detailed plans that attempt to fix all three constraints for the life of the project.  They base plans on estimates of how long it will take a certain number of people, with specific skills, to accomplish a set amount of work at a certain cost.  As problems arise, managers work to keep the project as close to the original plan as possible.  If project reality strays too far from the plan, they develop a new project plan or scrap the project altogether.  Replanning is a risky and expensive proposition, so project managers work mightily to avoid it.

Fixing cost and schedule begins by fixing scope.  The more detailed project requirements are upfront, the more precise the cost and schedule estimates become.  However, these calculations are not necessarily more accurate because they are based on estimates and on requirements that will likely change the bigger and more complex project scope becomes.

How Enforcing the Iron Triangle Affects Software Development

The problem with applying traditional project management to software development is that development of non-trivial and/or large-scale software solutions is too complex for linear predictive planning.  As software solutions grow and evolve, their complexity increases, sometimes at a seemingly exponential rate.  Since we can develop and modify software solutions in infinite ways, they are often significantly more complex than physical systems of comparable cost.

Enforcement of the Iron Triangle in software development projects often leads to the following problems:

• Narrowing requirements and technical approaches too early – Predictive project planning typically forces teams to define what they will build and how before they really understand the business/mission and technology domains they will work in.  This often leads to developing things that customers and end users do not need or that do not adequately address their needs.
• Tendency to overengineer solutions – Specifying technical scope upfront often leads to overengineering.  Defining and developing features that few, if any, customers or end users will actually use is quite common.  Also, overengineering can lead to creating complex features or functionality where simpler versions could have satisfied requirements.  All those rarely-used or overly complex features cost money to develop and maintain.  They rob time and budget from developing and releasing features customers and end users truly value.
• Difficulty managing risks and taking advantage of opportunities – In the zeal to keep projects “on plan”, planners often identify emerging risks too late to keep them from becoming issues or forgo opportunities to improve the product and how it is developed.
• Forgoing opportunities to validate solutions – Projects based on predictive planning, such as Waterfall projects, often afford only one chance to validate what teams develop.  Typically, validation of the solution occurs towards the end of the project, when the time to address problems is most limited.
• Delaying delivery of business or mission value – With only one chance to deliver / release, sponsors, stakeholders, customers, and end users must wait until the end of the project to gain access to solution features.

Agile “Breaks” the Iron Triangle

Instead of attempting to fix all three constraints of the Iron Triangle, Agile fixes cost and schedule while allowing scope to “float”. In other words, Agile efforts are managed primarily by managing scope.

Under an Agile approach, there are no surprises. We have a certain amount of budget and time to spend developing software capabilities. We continuously verify (test) the solution as we build it to ensure we are building things right and demonstrate and release functionality often to ensure we built the right things. Since we build and deliver solutions iteratively and incrementally, customers and end users get valuable business or mission capabilities sooner.

For as long as we have enough budget and schedule, we have the option to continue developing functionality or stop after realizing enough value. We also have the option to pivot to a different solution approach or cancel the solution altogether. When budget and schedule run out, we can choose to invest more on the solution based on demonstrated functionality and customer and end-user feedback.

Overemphasizing Control

Enforcing the constraints of the Iron Triangle causes project management to implement heavyweight management and reporting processes.  These processes are attempts to lower risk by increasing control.  Overemphasizing control slows software development and decreases the flexibility necessary to tackle risks and challenges.  On the other hand, underemphasizing control can turn flexibility into chaos, robbing software development teams of both planning and process stability, thereby slowing progress.  An optimal balance between control, flexibility, and speed requires empowering technical contributors to plan their own work based on sponsor, stakeholder, customer, and end user needs and enterprise technical constraints.  The main reason for this is the inherent complexity of software systems.

High-performing teams are empowered teams.  They take on or participate in many duties traditionally left to project management:  Devising work plans, decomposing work and deliverables, monitoring task and reporting progress, and meeting commitments.

Software Development’s Inherent Product Management Bias

Software is never finished.  We’ve moved away from delivering discrete, standalone software package products (think Windows 95) to continual delivery of new software functionality and bug fixes via updates distributed over the internet.  Even in organizational IT and enterprise system integration efforts, development never truly finishes.  If any solution or product is to survive, it must adapt to meet changing customer needs while maintaining quality and performance.

Also, software is infinitely changeable.  Since software is abstract, we can add and modify it at will with much less effort and expense than physical solutions or products.  Thus, we don’t see the same level of resistance to updating software solutions as we see with physical products.  The very nature of software solutions makes them likely to continue changing and evolving long after initial development.

Thus, managing the development and evolution of software solutions as projects that start and stop does not make sense.  All software solutions go through the stages of the Product Lifecycle.

The Product Lifecycle

The Product Lifecycle includes the phases all products go through during their useful lives: from when they are first conceived, to when they are retired from the market or their mission domains.  This cycle focuses on the performance of the product in its intended market or mission domain.  All products, including software solutions, commercial or otherwise:

1. Start out as an idea developed into an initial version of a releasable product
2. Are introduced / released to their intended consumers or user bases
3. See their market or user base expand, if successful.  This phase tends to drive the most product changes that keep the product relevant and/or profitable
4. See an eventual stabilization or flattening in customer use, sales, or revenue growth as the product’s market or mission domain matures
5. See their market or mission domain decline as it becomes saturated or customers move on to new solutions
6. Are retired when they cease to be profitable, effective, or relevant

Projects Incur Wasteful Overhead

Traditional project management’s focus on projects is wasteful.  Starting and stopping projects incurs significant overhead.  Examples include:

• Contracting activities (and acquisition activities, for government projects) – Finding contractors / vendors, putting them on contract, monitoring performance, “Color of Money” concerns, etc.
• Ramping up new employees or vendors to be productive – Accesses, equipment, software tools, training (formal and on-the-job), etc.
• Ramping down employees or vendors as projects end – Removing accesses, returning equipment, managing software licenses, etc.
• Not having the flexibility to easily terminate failing projects or projects considered no longer necessary or desirable – It is much cheaper and easier to cancel a project after spending $10 million than after spending $100 million

Agile’s Inherent Product Management Bias

So, if we should manage software development as product development efforts, rather than as projects, what does that look like?  It looks like Agile software development.  Agile software development in general, and Scrum specifically, have an inherent product management bias.  Table 2 below shows how Scrum fulfills the product management duties listed in Table 1:

Conclusion

In my experience, the single biggest reason why so many Agile software development efforts fail to achieve the benefits of Agile is the conflict between traditional project management thinking and Agile’s inherent product management approach to software development.  This is not just my opinion, it is a growing realization Lean-Agile circles[i].

Today, business and mission requirements change too quickly for slow-moving predictive planning and management approaches.  To meet the challenges brought about by the quickening pace of technology, we must leverage flexibility and control to achieve speed while maintaining quality.  This requires a shift from a project management to a product management mindset.

[i] https://www.scaledagileframework.com/lean-portfolio-management/

---

Last Updated on April 17, 2022