Conflict of interest is something we all try to avoid.  Both in our professional lives and our personal lives.  It can change opinions, skew results, and just generally wreak havoc on what you're trying to accomplish.  Results can get thrown out, work can have to be redone, and customers or project clients can lose all confidence in your ability to be impartial or objective if a conflict of interest comes to light.



Why then, is it so incredibly common that our project clients seem unprepared, unwilling, or uninterested in putting much if any effort into thoroughly testing the solutions we provide to them?



Well, since I'm opinionated, I definitely have my own thoughts on this.  I believe it boils down to, primarily, one or more of three reasons:

 

 





     
  •  
  • Lack of subject matter knowledge




    •  
  •  
  • Lack of available staff and time




    •  
  •  
  • Lack of interest because they want us to do all the work and hand them a finished solution




    •  
  •  

 


All of these are valid responses and all are very wrong.  No matter how you look at it and no matter how hard we may try to test objectively based on the original project client requirements, if we do the testing it's unquestionably a conflict of interest. And this conflict of interest will come back to haunt us in a very bad way if we ultimately deliver an end solution that the project client deems unacceptable or that misses the mark for the target end users.



So, how do we get around these customer issues?  How do we get past their lack of interest, expertise, or availability?  How do we put the onus for testing back on them so that we can be confident at the end of the day when they sign off on the project that they’re happy with it and know what they’re signing off on?  How can we be sure that our neck is covered and they won’t come back pointing the finger at us for a signed off and tested system that they are frustrated with.



Four key steps are what it takes.  By incorporating the following four key steps or processes into the engagement we can better ensure that the customer WILL be involved in testing and our neck WILL be covered when they sign off on the system and pay us for our efforts.  There’s no guarantee of course – anyone can sue anyone, right?  But at least following these steps will show due diligence and put the responsibility for testing and approving the system solidly into your project client’s hands and not yours.



Get formal approval on the requirements



It all starts with proper requirements.  And if you can’t get great requirements out of the customer, at least get the best that you can and have them formally sign off on the requirements you jointly document so there’s a mutual understanding going forward of what you’re building – and also ultimately testing – against.  Make sure that the formal signoff task is part of your project schedule as a milestone using a tool such as Seavus’ Project Viewer to track it.



Make test cases and test scenarios a customer deliverable to you



Tell your customer at kickoff time that the creation of test cases and test scenarios is their responsibility.  Prepare them as early in the engagement as possible for this responsibility so that they’re working on it.  Leave them no excuses.  Be sure to include it in the schedule and at the appropriate points in the project get status updates from them on it.  Include it as tasks to cover in the status meetings and discussions that you have on the engagement.  Be sure that they understand that this is solely their task to deliver on.  You can help them along the way, but make your involvement as minimal as possible.



Be available for testing – but don’t do it for them



Make yourself available to the project client during user acceptance testing, but be involved as little as possible.  Think of yourself as more of an advisor – definitely not a participant.  You don’t want any appearance of subjectiveness or conflict of interest that could cause you problems later on.



Get formal UAT signoff