★ Taking the Right Approach to Implementation

Lately we have struggled with a couple of our projects, and looking back it is clear that we need to refine our approach a bit.  Here is what we have currently done:

  1. On-Site discovery of processes and requirements
  2. Functional Design document based off of those requirements
  3. Technical Design document based off of the Functional design document

At this point, the customer is generally very happy.  They see that we have accurately captured their requirements and used those captured notes to design a robust system.  They see that we “get it”.

Then we hit the build phase.  We begin implementing the results of the technical design, sometimes in a vacuum.  Then, a few days before UAT we show them what is built (and it meets the documented design), and they say “That isn’t how I want it to work!  I assumed it would be a-b-c, not a-c-b.”  Now we have a problem.

Sure, we could go back and say “Well that’s not how we have it laid out in the Technical Design Document that you signed off on”, but that wouldn’t be fair to the customer.  When the customer sees a technical design doc, it might as well be in Greek.  In the case of Courion, they don’t understand Provisionee Communities, Provisioners, or the difference between User Success and Resource Success.  Nor should they.  They signed off trusting that we captured and reflected their process appropriately.

In our opinion, we did capture it properly, however there was a requirement here and a requirement there that didn’t make it in to the document.  There were some things that we interpreted one way, and they interpreted another.  There were cases where we would explain a functionality, and we didn’t do a good job of it so the customer misunderstood.  The customer didn’t have the knowledge to detect this, so they signed off anyways.  Now here we are.

In the end we end up giving in because we want the customer and the project to be successful.  We take pride in what we do, and if what we are doing is providing a solution that is of none to little value to the customer, what have we really done?

We’ve had discussions in-house about the waterfall vs. agile approach, or maybe a hybrid of the two.  We currently fall very much into the waterfall approach.  Which has worked for you?


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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