Please Stop Using the Word Done

 In my years working as a data warehouse/analytics/BI professional, one of the words I've developed disdain for is the word done.  You hear it all the time from business users and EDW management teams about when will something be done.  I get that perspective, but I would argue that if the data warehouse is evolving and delivering business value, you're never truly done.  In many instances, I've asked people to stop using that word.

Here's my perspective...

Hopefully, your a data warehouse project has a somewhat specific set of goals beyond "we need reports" or "we just need access to the data".  When I hear those comments, my first response is "for what purpose?", but we'll save that for another blog entry.  You may also run into projects that have a "grand vision" as far as "if we do x, y, z...we'll have data nirvana", which is also a topic for another blog entry.  Back to the original thought.  Let's say you have a fairly well defined set of data that you want to look at, and the requirements are fairly well defined.  You start to scope it out, and the first thing people want to know is when it will be done.

Rather than use the word done, I prefer to say that the first iteration will happen on some date based on the scope.  In my experience, you can't really call it done for a couple of reasons.

The first reason has to do with users don't know what they don't know when it comes to the data.  I've been in many situations where a user will say "I know...about this data", but when the data is actually pulled, it shows something completely different.  That's not a bad thing, but it requires that you adjust along the way, so the concept of done can change right in the middle of the project.  Changing the scope and timeframe makes a whole lot more sense than pursuing the original purpose knowing the data won't fulfill that purpose.  

A good example was when I worked at Sequent (acquired by IBM).  I was working with the CFO pulling together sales and cost data to figure out why we were having a "margin problem".  Loosely defined, we were selling quite a few computer systems, but our margins to build and ship those systems seemed way lower than it should have been.  Initially, we were convinced it was a general problem with the sales force discounting sales, and we were prepared to look at the data to deal with that challenge.  The challenge was that as much as we thought that was the problem, there was a bigger problem beneath that.  When we started digging further, we realized that we didn't have a general "margin problem" across all product lines, but rather it was specific to one product line.  By doing some digging and changing our scope to go in a different direction, we were able to deal with the specific problem rather than trying to figure out how to re-work the entire sales and manufacturing processes.  Yep, it threw the schedule out the window, but ended up saving a lot of time and resources we would have spent pursuing the wrong question.  After that, more questions were asked about other product lines, and the scope changed.  Rather than one implementation with one goal, we ended up with about 5 different projects covering a lot of different areas of sales and manufacturing.  The more we learned, the more we wanted to know.  Even after I left Sequent, I'm not sure we would have ever called it done.  It just kept evolving as it should have.  The data warehouse was truly a living, breathing thing that evolved, so the concept of done was a long way off 

The next reason has to do with what I call the "oh sh*t" syndrome.  You build out the environment and the user looks at the data and says "oh sh*t...I didn't know that".  This may totally change the direction of the final deliverable, which again is fine to do.  It's better to have the "now that we see this, we need to go x direction rather than y direction".

My example of that scenario comes from my days at DecisionPoint (the company I founded and was Chief Technology Officer of).  We specialized in pre-packaged data warehouse environments for financial analytics.  90% of our customers started with high level financial analytics using budget versus actual data from the General Ledger to see where the gaps were.  Companies would often by additional components for areas where they assumed they had problems.  Things like expenses from accounts payable, purchase orders and order fulfillment from purchasing, revenue analysis from accounts receivable, etc.  In one case, a customer felt that in addition to budget versus actual analysis, they also needed to take a deeper dive into their purchasing process with purchase orders, deliveries, etc.  However, after we implemented the budget versus actual analysis, they had the "oh sh*t" moment.  They realized that they didn't have a purchasing problem, but rather a problem with the inventory they were stocking.  They had a bunch of write-offs for obsolete inventory related to products that weren't selling well or were obsolete.  So, we changed directions quickly and provided the data they needed to solve the problem with the inventory.

The last reason I'll talk about is how end users change their mind about what they need after they see the data.  Their thought process evolves, and after they see the first set of data, they realize that with a few tweaks to the environment, they can do what I call the next level analysis.  That next layer deep that gives more detail to find/solve additional business challenges.  They see more data, come up with more tweaks, they do more analysis, and answer more business questions.  You really can't and don't want to put a label of done on the environment.  You just don't know when that next tweak will come leading to more business value.  You can't interrupt that process.  There may be a time where the additional tweaks slow down, but you can't put a lid on it by calling it done.

When done properly, the data warehouse is a living, breathing thing that will continue to grow and evolve.  Putting a somewhat random label of done isn't very reasonable.  Do yourself a favor...don't use the word done, but rather the phrase "done for now".