Agile in Motion: The Process Purpose Model

In this interview for the Iterations newsletter, Heather Shanholtzer talks with Niel Nickolaisen about the Process Purpose Model, a tool to help identify which features you really need and which you can skip.

Niel Nickolaisen, CIO and director of strategic planning at Headwaters, Inc., has more than twenty-five years of experience helping organizations increase business value and deliver better products. He developed the Process Purpose Model as a means to identify those features that set a product apart from the competition so resources aren't wasted on making functionality better than it needs to be.

In an agile project, this model simplifies development and helps the team plan its iterations: Some iterations are finished when the product is up to parity. In other words, the Process Purpose Model helps agile teams define "when done is done."

Heather Shanholtzer: What is the Process Purpose Model and what was the impetus behind your developing it?

Niel Nickolaisen: The Process Purpose Model assesses a business process in two dimensions. First, the extent to which the process differentiates us in the marketplace, and second, the extent to which the process is mission critical for our organization. This assessment yields four different types of processes:

  1. Both differentiating and mission critical
  2. Mission critical but not differentiating
  3. Differentiating but not mission critical
  4. Neither mission critical nor differentiating

From a development perspective, the most interesting process types are those that are both differentiating and mission critical (I call these "differentiating") and those that are mission critical but not differentiating (I call these "parity").

We use the differentiating processes to gain market share and to wow and win customers. We need our differentiating processes to be better than those of our competition. We need to allocate our best thinking and creativity to the differentiating processes.

The parity processes keep us in business. They must be at parity with the marketplace, but they do not need to be better than what the market expects. If we make the parity processes better than they have to be, we have over-invested in these processes. This is not only a direct waste of resources it is also an opportunity cost, as thinking and creativity spent on parity processes is not being spent making our differentiating processes the best in our market. Using this model, we make process design decisions based on the purpose of the process. The purpose of our differentiating processes is to be better than our competitors, so we should design the process to achieve that purpose. The purpose of our parity activities is to be at parity, and so we can design these processes by adopting or mimicking best practices.

I developed this model out of frustration at managing IT projects that did not deliver the expected business value. What business value is there in developing software that attempts to make our billing process (which, for us is a parity process) unique, different, and capable of handling all known exceptions? I have found that by defining and using the Process Purpose Model, we make much better feature and functionality decisions and deliver much higher quality projects.

Heather Shanholtzer: Give an example of the Process Purpose Model in action.

Niel Nickolaisen: I have used this model to dramatically reduce the time and cost of ERP and CRM projects while significantly improving the business value of the projects. For example, most ERP functionality supports parity processes (Does our chart of accounts design differentiate us in the marketplace? Does the design of our purchasing module help us gain market share?). By linking ERP (or CRM, or BPM, or SFA, or whatever) functionality and features with purpose, we can simplify our software selection and implementation. Rather than have our development teams create unique and interesting customizations to the accounts payable or order entry modules, they work on improved functionality for customer segmentation (or whatever links to our differentiating processes). Companies that use this model experience 30 to 50 percent reductions in project timelines and budgets while delivering better products.

Heather Shanholtzer: How does the Process Purpose Model fit into the agile developer's toolbox?

Niel Nickolaisen: In my opinion, one of the most important and valuable agile methods is frequent, prioritized delivery of working software. According to a Standish Research report, 64 percent of the functionality and features we develop are either rarely or never used. Agile teams can use the Process Purpose Model to identify some of this 64 percent and treat it as it should be treated. This not only reduces the amount of work we do on functionality and features that will not make a difference in the product, it also frees up our brains and time to work on the features and functions that will result in a product that helps us win in the marketplace. Teams and developers can use this model as they plan and deliver their iterations. It is just common sense.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.