Nobody starts a database project with failure in mind. And yet, it would seem as if the majority of all such projects end up with some degree of failure.
Oh sure, some are small failures, like the design didn’t last the full seven years as promised. Other failures are more stunning in their glory; I’ve seen projects that get cancelled before they are deployed to production for even one day.
There are many factors involved in database project failures. In my experience they can usually be grouped into one of three things: scope creep, unmanaged requirements, and blamestorming.
1. Scope Creep
“Just one more thing”
It’s as if Detective Columbo came back from the grave and managed to add in every imaginable design feature possible.
“Can you have the reports run every six hours?”
“Can you change that datatype to be nvarchar(1), so it matches what we have in system X?”
“Can you make it colored blue?”
Scope creep is likely the number one reason for database projects to fail. It is often the result of poor communication between stakeholders, or the need for one group to serve another no matter the costs, or the lack of clearly defined project objectives. My experience tells me that scope creep is traced back to week project management and leadership. As I have written before, with the lack of good managers in IT today it is not a surprise that so many of us look back at database projects as failures.
2. Unmanaged Requirements
This one always drove me crazy. If the end user wants something added to teh project then a good manager will simply look at the list of requirements and ask for them to adjust one of the following:
- The priorities for the requirements (i.e., how important is this new thing)
- The currently allocated headcount
- The project deliverable date
3. Blamestorming
We’ve all been in that room, the room where All Good Projects Go To Die. The room where everyone sits around and blames each other for every possible reason why a project is going to fail, and nobody offers up any solution that could possibly lead everyone out of the rabbit hole upon which they have descended. Many people call such a room by different names, but I refer to it as a Blamestorming Session. I wish I could say I’ve only seen this happen a few times, but that wouldn’t be true. It would seem that this meeting happens with a stunning regularity, usually coinciding with the threat of layoffs right around the corner and everyone is doing what they can to let someone else know that the failure wasn’t their fault.
But it was their fault. It was also the other persons fault. They allowed scope creep to happen. They allowed for the unmanaged requirements. They sat there as the project dragged on and kept thinking “When this thing fails, I am going to make certain that everyone knows so-and-so was to blame, and *I* was the smart one.”
The end result? Failure. For everyone.
I’ve listed three common things that derail all database projects. Nobody ever starts a project thinking about how it will fail. Perhaps that is part of the problem, maybe people should approach a project thinking about the various pitfalls that lie in wait. Then again, perhaps we should consider giving people some basic project management skills and training so that the above issues can be minimized.
Well, if someone asked me to make a DB blue, I think I’d have to respond that Mauve has more RAM.
One thing that may fit under the unmanaged requirements is the desire to have the world in the first release. That could be a warehouse that holds every part of the system, a fully detailed model for everything we could potentially do int he next 2 years, or some other “start big” proposal. While that doesn’t necessarily doom a project to failure, it definitely invites scope creep and tends to lead to “one more thing”.
Peter,
Great point there, trying to build something based upon “what if” rather than trying to solve a problem, can lead to poor outcomes as well.
Ah, blamestorming. Been there many a time. The problem I have is being the one suggesting a solution, but because things are in the state they are, no one ever listens until it is too late.
I’m going through this right now with a 4 month deadline looming and rather than the developer team working with the data team as, we offered, they decided to go their own route. All I could do was document the issues we as a data team foresee, prepare ourselves, and see how it plays out. It gets very frustrating when you are trying to prevent the blamestorm from happening. Guess there is no real way to control the weather of a project eh?
Our company has a problem with “executive buy-in”. In project management class in college (20 years ago) one of the first things on the list was getting buy-in from the people at the top, the people paying for the project. If you don’t have that when the project completes, and its the IT group rolling it out instead of mandidated from the top down, you’re going to have a real problem getting everyone else to buy-in.