Before I start anything I want go give a disclaimer. I absolutely believe that the business should be involved in every stage of a project. When it comes down to it they are who we do the work for. That said, Introduction!

This is T-SQL Tuesday, the long-running blog party by Adam Machanic (b/t) and currently being run by Steve Jones (b/t). It’s a lot of fun to do and I highly recommend joining in. This month we are hosted by Jeff Mlakar (b/t) (Thanks Jeff!) and the topic is Death March based on a book by the same name. (Go to the invite link to find the link for the book.) The invite says to share a story about a project you worked on or were impacted by that went horribly wrong. The one I’m going to share was a good 10 years ago so I don’t remember a whole lot of details. I was brought in near the end but here is the way I saw it.

Friday around 4:30 I got a call. We needed to put in a big change into one of the ETL systems. Next thing I know it’s two weeks later and we are still trying to fix our data. Over that two weeks, we discussed what had gone wrong. Basically, the change wasn’t ready. There was scope creep and it hadn’t been fully been tested yet. So why would you possibly put in an important change that hadn’t been fully tested? The business said they had to. The developer was told by the manager This must go in this weekend. and when the developer told them it wasn’t ready they went to their manager. The development manager allowed themselves to be convinced and told the developer to do the install. Long story short, they should have listened and they should have waited.

It’s important when you are working on a project that you get everyone together who’s involved, and that you listen to all of them. Everyone has their specialty and you need to pay attention when they talk. In this case, the developer said This isn’t ready. and the business didn’t listen. I’ve also seen lots of cases where the developers didn’t listen to the business and built something that was completely useless to them. And of course not bringing the DBA in until the end of the project is kind of a tradition. I find it interesting that Dev Ops, Agile, two very popular methodologies both seem to be trying to solve the same problem. Communication. Of course, from what I’ve seen, lack of communication has caused more failed projects that just about anything else so it’s kind of a big deal.

This particular project did teach me something important though, that successful communication isn’t just talking, it’s also listening.