Projects and Operations
A project is a temporary, unique effort to deliver a planned result. Operations are ongoing, repetitive work that usually delivers a service. Most product development happens in projects, even inside long-running products, and projects need different management than operations.
The Project Triangle
Every project is constrained by scope (features), schedule and cost (people’s time). Quality is what suffers when the three are stretched: if scope grows, schedule or cost must grow too, or quality drops.
Project sponsors want these constraints locked in before work starts, and you would too if you were paying, say, for a house remodel. In software you can never fully identify them in advance, so different kinds of projects fix different corners:
- Customer contracts usually fix scope and budget, with some flexibility in schedule.
- Internally funded work usually fixes schedule and budget, with flexible scope.
Knowing which corner is fixed tells you where you can negotiate. When a team aims for more scope than it can achieve, quality is usually what gets sacrificed.
Agile Still Has Limits
There is an extreme reading of Agile in which the sponsor happily commits unlimited money and an unlimited deadline in exchange for a completely unknown result. Reality is different: budgets and deadlines are always limited, and every project needs an initial goal.
Agile management works fine on a fixed budget. The main difference from traditional planning is that Agile plans to resolve some unknowns as you go, through iteration and close collaboration with stakeholders, instead of trying to identify every unknown up front. The secret is that the definition of “good enough” evolves over time.
That shifts how the triangle is read. In Agile, scope is the flexible goal, constrained by quality, schedule and cost, because sponsors have hard limits on budget and deadline, won’t pay for quality beyond what the industry expects, and can’t be satisfied without adjusting scope as they learn. Agile projects therefore need Agile design: iterative and built on stakeholder collaboration.
Scope Is Always in People’s Heads
The most important idea in this methodology. Individual techniques may or may not fit your project. This one always applies.
Different people hold different pictures of the same project, even after discussing it. Requirements are low-resolution images of the vision in someone’s head. A clearly defined, shared vision of scope means:
- The team can estimate the effort clearly
- Stakeholders can be negotiated with clearly
- The team doesn’t waste time building things nobody needs
- The team can cooperate on shared goals
This stays true even when scope is well defined. You have to keep re-communicating it to everyone, all the way to end users through documentation and discoverability.
This defines the designer’s primary contribution to a project: facilitate a clearly defined, shared vision of scope, using business analysis and UX techniques. The designer’s own vision matters less; it mostly fills in lower-level details. And in most organizations, many people hold a stake in that vision, not just the customer and the product owner.
Needs, Not Wants
What people want changes as a project progresses; Agile accepts that. Look past the stated want to the underlying need: ask why someone wants something, not just what.
A Feature Is Not an Objective
A common trap is writing objectives that are really features, such as “simulate the weapon’s firing procedure with correct symbology and timings.” Simulating something is never the goal. It is a tool for reaching a goal. Ask why the customer wants the feature, and the real objective appears, for example: “the crew learns when to pack up and move after firing, before the enemy can respond.”
The real objective also tells you how far to go. Don’t recreate what the real world already teaches better. If a crew can practice assembling a weapon on the real thing, a computer adds little; replicating every screw turn would cost a fortune and teach nothing new. But the time it takes to pack up and move matters, because the decision about when to move is what’s being trained. The right level of abstraction depends on the objective.
Agile or Waterfall?
It’s a spectrum, not an either/or. Lean toward up-front planning when small changes are very expensive, the system is complex and tightly interconnected, or people need to work independently. Lean toward Agile when prototypes are effective, teamwork is essential, the business environment changes fast, or there is a lot of uncertainty.