Choosing an Engagement Model

Thanks everyone for coming out to my session on Project Epistemology a couple months ago at the Project Conference.  As I discussed in that session, there are often two conflicting views of any Project Server deployment – and I would contend that most conflict within a consulting engagement typically is driven by the conflict between these views.

Put more succinctly, when both parties in a consulting arrangement are operating from a different engagement model, bad things happen.

The first model is simple.  It is based on the following points:

  1. The problem is simple.
  2. The focus is the solution.
  3. The solution is technical.

What this means is that we have a discrete, defined problem.  We can easily place boundaries around it, and the consultant’s job is to come in, design the solution, train a couple of end users, drop an invoice on the desk and run.

The second model is more complex.  It is based on the following points:

  1. The problem is wicked.
  2. The focus is the problem.
  3. The solution is adaptive.

The challenge in the second model is that we never assume that everyone agrees as to what the fundamental problem actually is.  In fact, we don’t even acknowledge that everyone agrees a problem exists.  The first step in an engagement of that nature is to work on defining a common consensus as to the problems faced and the priority of those problems.  Often times, this requires covering ground that may have been covered already long before the consultant walked in the door.

That’s the fundamental building block upon which to continue the engagement.  Once that is completed, we don’t acknowledge that there is such a thing as a solution.  Instead, we acknowledge the concept of progress towards a solution, insofar as we can work towards a better future, one where we better understand what the problem is and better provide value to the organization.

What does this mean in the context of a simple reporting engagement?  Reporting, more than pretty much any other topic, lends itself to the adaptive consulting model.  In reporting, you are typically tying multiple data sets into a single reporting tool, and then presenting that data to your stakeholders.  Once they see the data, and they see how it can be manipulated, the questions start.  “Can I see it this way?” they ask.  “Can we add additional data to the mix to see how it impacts things?”

What that means is that a reporting effort never ends.  It just begins.  It’s an adaptive exercise continued ad infinitum until the stakeholders have iteratively identified what reports are actually required.

How does one consult in a situation like that?  You don’t focus on the steady state solution, which is arguably a myth.  Instead, you focus on building a capability.  Our job as consultants is to build the capability of developing and modifying reports within the client organization.  Once we’ve built that capability and the technology platform to support it, we have done our job well.

For more reading on problem framing as part of enterprise tool deployments, take a look at Kailash Awati and Paul Culmsee’s book, The Heretic’s Guide to Best Practices.

Choosing an Engagement Model

2 thoughts on “Choosing an Engagement Model

  1. Good article.. I have recently begun reading the same book …

    The only problem with the adaptive consulting engagements is that, once you build the capability, then you start looking at the ‘maturity’ of that capability. As a consultant you can never let go off the desire to improve the maturity and hence will never have the satisfaction of “completion”.. :).. it is a vicious cycle..

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s