Flexible or Not, I am for Requirements


I mentioned in my last post (six months ago) that I was taking a break and working with an NGO as part of my Masters in Public Administration program.

As it would have it, I ended up on a SharePoint Online / Office 365 project.  Of course, I could have taken on the development myself but decided that it made more sense for the NGO to take on a local company to impelement the custom SharePoint development.  I have managed many software development projects in the past and thought that this would be a breeze.

The NGO even had a formal RFP process that forced us to evaluate several companies before making a decision on which vendor to award the project.  I created a feature specification from the point of view of the NGO and provided it to the prospective vendors.  As a consultant myself, I anticipated and indeed expected the awarded vendor to create their own requirements specification detailing exactly how each and ever feature would work, would look, dependencies, etc.  But this never happened.


Each time we met with the vendor, there would be some discussion, some head nodding, some scribbling of notes, and then we waited.  When we met next to see the progress, they would provide some functionality which vaguely resembled the functionality that we requested.  Week after week this continued.  Each meeting becoming more tense and stressful as they were unable to deliver a feature to our satisfaction until after a dozen iterations.  A 4 week project quickly became 3 months and more.


Now, sitting back trying to understand the lesson in this experience, I come to the following conclusions.

  • A software vendor should always plan and insist on fully understanding your customer’s needs and documenting these needs so that there are no misunderstanding of what is expected.  If a customer does not want to spend the time or money on this, then there is bound be problems down the road.
  • A customer should always expect that a formal excercise of discovery and documentation is performed.  If it appears that the vendor has not allocated for this, question them.  Poor planning will only hurt you in the long run.
  • Developing a requirement specification is not free and should always be accounted for in an estimate, quote, or proposal.
  • Demand quality.  Just because the vendor did not understanding the customer’s needs, does not give them permission to cut corners.

In this case, I was the customer and am as much to blame as the vendor as I was not adament that they create a requirements specification before beginning work or fired them as soon as I realized that they were not going to take the time to understand and document our needs.  Let’s at least hope that I have learned from this iteration.

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