Home > Articles > Software Development & Management > Agile

  • Print
  • + Share This
From the author of The Purpose Alignment Model

The Purpose Alignment Model

The result was what I call the Purpose Alignment Model. Because I invented this model, I also call it the Nickolaisen Model (gaining some credit for my invention and leaving some miniscule legacy). Purpose alignment helps us to define the purpose of project scope. Knowing purpose, we can design the project to achieve this purpose.

Designing around purpose usually at least breaks the project management triangle, but sometimes shatters it. The Nickolaisen Model works like this. First, we measure our business processes and project requirements in two dimensions:

  • The extent to which the process or requirement will differentiate us in the marketplace
  • The extent to which the process or requirement is mission-critical

These measurements yield the 4-Box Model shown in Figure 1.

Figure 1 Purpose alignment with the Nickolaisen Model.

The four boxes describe the purpose of our various processes and requirements:

  • Differentiating. A few of our processes and requirements are both market-differentiating and mission-critical. The purpose of these Differentiating processes and requirements is to win customers and gain market share.
  • We need to be better than our competitors at these processes and their functionality. To sustain our competitive advantage, we must constantly innovate how we perform these processes and deliver this functionality.

  • Parity. The vast majority of our processes and requirements are mission-critical but not market-differentiating. The purpose of these Parity processes and requirements is to keep us at parity with the marketplace.
  • There's no benefit in performing or delivering Parity processes and functionality better than anyone else does. In fact, treating Parity processes and functionality as if they were Differentiating processes and functionality has very high costs:

    • Direct costs. Resources we spend to make these processes and functionality better than they have to be.
    • Indirect costs. Complexity we add in order to make these processes or functions unique, interesting, or innovative.

    We should design these parity processes and functions in a best-practices, simplified, streamlined, and standardized way.

    The example that inspired me to invent the Nickolaisen Model—how the company performed drop shipments—is a perfect example of a parity requirement. Because store replenishment was a mission-critical activity, we had to do it well (otherwise, we would be below parity), but we didn't need to handle drop shipments in a unique way. We could accept—and, because it was a Parity activity, needed to embrace—the standard way of processing drop shipments.

  • Partner. Some processes or requirements might be differentiating but not mission-critical for us. To exploit this opportunity to differentiate ourselves in the marketplace, we would choose a Partner to deliver this process or functionality.
  • For example, suppose we differentiate ourselves with our engineering design, which requires incredibly precise manufacturing. Rather than building our own precision manufacturing capabilities, we might choose a partner that differentiates itself with its precision manufacturing. (Notice that we partner with this company, rather than outsourcing to the company.)

  • Who Cares? Finally, some processes or requirements might be neither differentiating nor mission-critical. For these, who cares what we do?
  • + Share This
  • 🔖 Save To Your Account