Management Levers: An Engaging Engagement Model

I’ve been selling custom software projects for nearly a decade. In my opinion, the most important part of the sale is correctly setting the client’s expectations for the design and development journey that’s in front of them.

A key expectation to align on is the engagement model.

Over the past few years, I’ve been describing the engagement model for a project by using a modified version of the project management triangle. I’ve been referring to this tool as the project management levers.

During a sale, I commonly draw actual lever icons on the whiteboard to better express my point.

Three Simple Management Levers

  1. Scope – The work that needs to be done.
  2. Cost or Time – The cost involved. Because the main driver of cost for custom software projects is manpower, I’ve simplified the tool to represent cost and time as the same lever.
  3. Quality – The quality of the work. Quality is a conscious decision when building custom software. I almost always suggest fixing this lever.

Management lever rules

It’s impossible to fix all of the levers. Something always has to give.

Two levers can be fixed. The third can only be actively managed. The lever that’s managed should be the focal point of the project’s weekly status report.

There are three possible permutations for the levers.

Fixed: Cost and Quality; Managed: Scope

Strive to use this engagement model for any significant custom software project.

Fixing cost and quality means that scope must be managed. We have a lot of great tools to manage scope (backlogs, burn charts, etc.). Although it’s not always fun to do, managing the scope of a project is much better than managing the cost or dealing with poor quality.

Atomic refers to this engagement model as fixed budget, scope-controlled.

Providing the right tools and being able to manage the scope firmly puts the control of the project in the client’s hands.

Fixed: Scope and Quality; Managed: Cost

This engagement model presents management challenges.

I’ve observed that pure, big bang integration software rewrite projects naturally fall into this engagement model.

Good luck managing the scope of a software rewrite. The existence of a legacy system sets the expectations for the new software’s functionality. It’s really difficult to tell someone that they won’t have a feature they currently use in the next version of the software–even when you’re convinced that they won’t need it.

This implies that out of the gate, you can only really manage cost for a rewrite. In my experience, rewrites always take longer than anyone expected. In these situations, the cost is only managed up! This is a painful place for a business stakeholder.

To flip the engagement model, we’ve advised clients to run parallel systems and slowly depreciate functionally in the legacy system as the new system matures. Since the legacy system still exists, scope for the new software can be managed to the most important parts for the fixed budget. This transforms the engagement model from “it’s done when we finish” to “fixed budget, scope-controlled.” The business now has the cost controls that it needs to operate responsibly.

Fixed: Scope and Cost; Managed: Quality

This is the house of cards engagement model. It enables you to do small projects quickly and inexpensively. Dialing back the quality lever should only be used for “quick and dirty” prototypes that will be thrown away.

Building anything substantial or operationally important on top of suspect quality is a recipe for disaster. Only use this model if you’re disciplined enough to throw out the software and rebuild if the prototype provides value.


Using the management levers during a sale helps educate the client on the engagement model that the team is using. Making sure that everyone is on the same page with respect to the engagement model saves a lot of project grief.