Ten Signs of a Data Warehousing Project in Trouble
You can most easily tell that your data warehousing project is in trouble when you don’t have anything to show for your efforts when you thought you would. Try to get some indication that trouble’s brewing, however, before you reach that point. This list presents ten early warning signs.
The project’s scope phase ends with no general consensus
The allotted time for the scope phase of your data warehousing project ends (usually two or three weeks — a little longer for large projects), and the members of your constituency are unhappy.
They’re still grumbling and disagreeing about the project’s direction and its potential business value (or lack thereof), the relative priorities of capabilities and how they map to various project phases, and other points of contention.
The mission statement gets questioned after the scope phase ends
You’re three weeks into the design phase, following a four-week scope. You’re in an all-morning status meeting with the IT and business organization executive sponsors, as well as four key managers from the business groups who plan to use the data warehouse the most.
Just before a coffee break, one of the managers says, “You know that mission statement we talked about on the second day of the project? I want to talk about that some more because I have some problems with it.”
Tools are selected without adequate research
A project decision-maker looks around the room in disgust, sighs deeply, and says, “Look, we just don’t have time to check out these tools because the schedule is too tight. That vendor who was in here yesterday — what was that company’s name again? You know, the ones with the product that — I can’t remember all the details. Anyway, I liked their demo. We’ll buy that tool.”
People get pulled from your team for “Just a few days”
“I’m going to borrow Mary, John, and Sue Ellen for a couple of days because we have something important over in the shoelace plastic-tips division that must get done as soon as possible. Anyway, I think that it’ll be for only a few days. Try to stay on schedule.”
You’re in trouble.
You’re overruled when you attempt to handle scope creep
You’re in the last week of the design phase, and a business unit manager sits down across from you in the cafeteria. Between mouthfuls of Chef’s Daily Surprise, he tells you about “these one or two things I just thought of that would make this data warehouse thing work much better.”
You politely explain the concept of scope creep in the context of “Wait until the %$#^@ next phase of the data warehouse!” (except that you’re more diplomatic about it). Then, two days later, the manager’s boss (who also happens to be your boss) sends an e-mail message directing you to “add those one or two things to the features list, but don’t let them affect the schedule.”
Your executive sponsor leaves the company
You’ve done a fantastic job of selling the business value of your data warehousing project to executive management, and everything is rolling along nicely. Suddenly, two days after a stunning announcement of disappointing quarterly sales and earnings, the executive sponsor from the business side of the organization resigns. Now, your project doesn’t have an executive sponsor.
You might be in trouble: Work fast and don’t look back.
You overhear, “This will never work, but I’m not saying anything”
Everyone in the company is supportive of your data warehousing project. You’re pushing the cutting edge of technology, and everyone on your team is enthused. Their weekly status reports even reflect the progress they’re making. The project’s chief architect assures you that the more you get into the project, the more everyone is convinced that you’ve made sound technical decisions.
Then, in the cafeteria, you overhear two of the more senior developers discussing the project. One says, “There’s no way that this thing can work. Performance is terrible, and half the time the same query against the same data returns different results! But I’m not going to be the one to bring it up!”
You find a major “Uh-Oh” in one of the products you’re using
Despite your best efforts at product evaluation, something has slipped through the cracks, and a major feature simply doesn’t work. Although you can use one work-around, that work-around really negatively affects performance.
The vendor’s representatives slyly say, “Well, we had heard that it might be a problem. Our development organization is looking into it and will probably make a patch available in the next month or so.”
The IT organization responsible for supporting the project pulls its support
Your development group is in charge of most of the data warehousing development, including the business intelligence tools and the database definitions. The IT organization, though, is responsible for creating the databases and performing the loading routines, performing the backup and restore procedures, and taking care of many of the project’s other infrastructure elements.
Because of higher priorities, the IT organization pulls the people responsible for supporting your project, and their manager promises to “look into another answer.” She says, “Maybe we’ll hire a couple of contractors, but I won’t be able to look into that until next week.”
Resignations are a sure sign that major problems lie ahead. Even people who are unhappy with a company often give in to loyalty or a sense of duty, and they stick around until the completion of a project. (Or maybe they just want the résumé fodder.)
When a number of people resign in the middle of a project, however, you’re in trouble.