Agile Tips

#58-The Risk of The Missing Stakeholder

Scott L. Bain

This episode will tell you a story about a time when missing a critical stakeholder caused a company to make a potentially disastrous mistake in their business automation.

The Risk of the Missing Stakeholder

This is a story about a boutique software company that does one-off development for small businesses.

Their customer was a small cable television outlet in a rural area of Montana.  They served a very small customer base the big players were not interested in: maybe about 250,000 households total for this cable provider.

They had a database in which they stored all their business information, accounts payable and receivable, customer billing information, all the stuff you would expect, but they also stored images of all their signed contracts and other critical documents, like customer level of service agreements.

The change requirement was:

“All images need to be deleted after seven years.”  

That’s the requirement, word for word.

Anyone want to guess what the reason for this was?  No reason was given, and the developers assumed they knew what the reason was.  

I’ll give you a moment to guess what reason the developers assumed.

They assumed it was space in the database, and perhaps performance.  This led them to a very simple solution, so they gave a pretty low cost estimate.  

All they would do is have a job run nightly, and have it look at the date stamp on every image, and delete it if it was seven years old or older.  That’s a very trivial programming task, so hence the low bid, and they got it done very quickly.

If fact was not performance that was driving this.  It was compliance with a state of Montana regulation that said you cannot keep an image of anyone’s signature for more than 7 years.  They didn’t know this because they didn’t realize the state governments was a stakeholder here.  They focused solely on their “customer” since that’s who pays them.

The developers eventually found this out and said: “no big deal, we got rid of them even if for the wrong reason.”

Then the systems operator said “oh no.”  

Can you guess why?  Again, I’ll give you a moment.

A database is someone’s responsibility.  If they want to keep their job, what is one thing they always do? They back it up.  So, the images were not deleted completely, they were also in all the incremental backups.  Those went into a secure location, and basically stayed there forever.  They were violating the law.

The requirement was not “delete them from the database after seven years” it was “don’t keep them anywhere for more than seven years.  Thy “why” was compliance.  

Getting them out of the backups proved to be a very difficult problem, until they asked the “why” of the backups.  It’s to make sure you don’t lose information.

So, they re-architected the entire thing.  They used a traditional, backed-up database for business records, and a separate image database that was not backed up, but rather used replication to ensure nothing was ever lost.  This was much more expensive and time-consuming than their original estimate, and it was all because nobody asked who the stakeholders were.

They didn’t think it was their business to ask, but it was.  I cannot tell you how often I have seen this as the primary source of errors.  

If you have not listened to my podcast on stakeholder identification, you might benefit from doing so.  The URL is in the transcript.

https://www.buzzsprout.com/2329657/episodes/15571371-25-enumerate-your-stakeholders