Worst Practices of the Unsuccessful Data Warehouse Project Manager
By Sid Adelman
A data warehouse project manager’s job is beset with worst practice traps just waiting for the unwary project manager to fail. You don’t have to fall prey to these traps. We have seen them all, and a few more. We know where and what they are. Read on, recognize and avoid theseworst practices and you may be one of the clever few who will successfully implement a data warehouse.
Worst Practice # 1 – Accepting an Unrealistic Schedule
Almost every data warehouse project manager has been given a set delivery date. These dates usually have very little relationship to what can actually be accomplished. Management sometimes thinks that creating a scheduled end-date is part of their job description and only they have the innate ability to determine the delivery date. They may not know what they want but they do know exactly when they want it. They know that if they don’t give you a date you will take forever and have nothing to show for it. The especially bad news is that they don’t trust your ability to plan and manage the project.
We have seen situations where project managers have been saddled with an unrealistic schedule because their management already committed the schedule to their management. The appropriate response is “It’s best that we deliver the bad news right away. That way we don’t have to pretend to senior management, other stakeholders and to the team.”
The project manager’s job includes educating upper management on the four variables in a project: 1. Function, 2. Schedule, 3. Resource and 4. Quality. Fredrick Brook’s classic book, The Mythical Man Month, discusses trying to put ten pounds in a five-pound bag – it doesn’t fit – and likewise, you can’t fit ten pounds of function in a five-pound schedule. The book also suggests that adding more people to a project will slow it down. So don’t accept adding more people to satisfy an unrealistic schedule. The mitigation is a project plan with realistic efforts defined, deliveries, milestones, and schedules – and managers who don’t shoot from the hip.
Worst Practice # 2 – Taking on a Failing Project
The word is out. The project is in deep trouble and you have been given the mantle of the project manager who is either going to be the hero or, much more likely, the captain of a sinking project. The project is already far behind schedule. Milestones have been missed, and the architecture is unsuitable for a project of this magnitude. The key people, both IT and the business have either left the project or want nothing to do with it. The morale of the remaining team is in the dumper. Worst of all, management still expects the project to come in on time and with all the original function and a little more.
Don’t flatter yourself. Neither you nor anyone else can pull this project out of the ditch. The project cannot be salvaged without some major surgery (starting with a mind meld of senior management). Your only chance will be with a new scope, a new (not revised) schedule, a new team (not a reorganization of the old team), and, possibly, a new sponsor. Without major changes, these types of situations have no chance for rehabilitation. If major surgery cannot be performed, the best thing you can do is decline and wait for something more promising to come along.
Worst Practice # 3 – Attempting the Project with a Dysfunctional Team
You know who they are. They are the poison people in your organization, the ones who no one else wants and, lucky you, you’ve got them all. They are the ones with the bad attitudes, terrible work habits, poor social skills, obsolete technical knowledge, enemies throughout the organization, a side business, or a hobby or interest that takes 90% of their time. They don’t respect each other and their dislike of each other is apparent. You don’t have a chance with this sort of team.
Keep all these poison people off your team. They will contribute nothing; they will only hurt you and will compromise the integrity of your team and the success of the project.
Ask for the authority to choose your own team – the most effective models have been the small teams (five to eight people) who are smart, skilled, dedicated, motivated, who like and respect each other and who have a great project manager, i.e. you.
Worst Practice # 4 – Choosing the Wrong Sponsor
My Uncle Herman once gave me this sage advice. He said “Never get into bed with someone crazier than you are.” As a data warehouse project manager, you need to take this advice to heart and never attempt a project with a dysfunctional sponsor.
How do you recognize this sponsor? There will be some telltale signs such as:
- A trail of bodies – this sponsor has caused the professional demise of countless other project managers who have either failed or not lived up to the sponsor’s expectations.
- The sponsor is usually surrounded by one or more sycophants who do the sponsor’s dirty work, sing his/her praises and will invariably agree with the sponsor’s position.
- Initial flattery giving way to venomous outbursts for minor perceived offenses or deviations from the sponsor’s plan.
- A reputation for putting his or her interests above all others and definitely above the interests of the organization.
Try to sign on with a sponsor who is smart, well-connected, forgiving of the problems your project is sure to encounter and pick a sponsor who will support you, your team and your project. Your sponsor should believe that the data warehouse project will make a major contribution to the success of his or her department, and more importantly, to the organization as a whole.
Worst Practice # 5 – Accepting Expectations to go where no Man (or Project Manager) Has Gone Before
“You can’t always get what you want. But if you try some time, you just might find you get what you need.” (Rolling Stones) Users often have trouble making the distinction between what they want and what they need and the “want” will usually translate into unrealistic functional expectations. There is a feeling among some users that if they don’t ask for everything now, they will never get it and they want it all in the first release.
The other notion is “This is the time to stretch, don’t be timid, push the frontiers.” Pushing the frontier with the data warehouse is unwise. Stay with proven methodologies and technology.
Users suffer from “expectation inflation” unless they are constantly reminded of what they will be getting and when. Some project managers have made the mistake of not confronting incorrect expectations as they come up, believing they can deal with them better at a later time. This is almost always wrong. Expectations must be managed early and often. Never leave a meeting with a user without correcting invalid expectations. Follow-on notes or minutes of the meeting will reinforce the agreed-upon position. (See Worst Practice #7).
Worst Practice # 6 – Sitting Still for Scope Creep
Creep happens; every project will have scope creep. Your job as the project manager will be to control it, not just document it. You will be flattered with comments such as “We know you can do it.” “It shouldn’t take that much extra time or effort for someone with your skills (not to mention gullibility).”
There are two wrong answers to the request for additional function (don’t forget this a request, not a demand), “yes” and “no.” If you say, “yes,” in the very unlikely chance that you succeed, you will always be known as someone who inflates schedules. In addition, if you say “yes” you will be perceived by your team and management as either weak – unwilling to stand up to management – or naïve. If you say “no” immediately, you will be considered a naysayer, someone who is insensitive to the needs of the business.
Every initiation of scope creep should be met with an understanding of the new function’s importance to the business and to the project. If the business determines it is very important and of high priority, your response should be, “I’ll get back to you and let you know how badly this will impact our schedule.” Management should also know that scope creep analysis takes your time and effort away from the original set of agreed-upon deliverables.
Worst Practice # 7 – Not Putting the Project Agreement in Writing
This assumes you have a project agreement. Project agreements are sometimes looked upon as overhead and not real work. There are examples and templates of project agreements to use as a starting point in Data Warehouse Project Management.
Since you like and trust everyone involved with the project, you don’t really need to agree upon and document a scope that will indicate what you will deliver and when. You don’t need to specify responsibilities, service level agreements, levels of data quality, or acceptance criteria. One of the other guys on the turnip truck with you also suggested there is no need to worry about or write down who will be paying for the data warehouse. Heed this advice and you are doomed to the scenario where you think you succeeded only to discover that the users see you as a failure – e.g., you failed to deliver 100% sub-second response time which they were expecting all along as part of their mental performance service level agreement.
A common mistake is to document a project agreement, have it signed by the sponsor and you, the project manager, file it away and to not look at it until the system is delivered and to then identify what you missed and also what you delivered that was not agreed upon. The smart project manager will hand the project agreement to the team, use it as a base for comparison with what the team members are doing, and to make it clear that fulfilling the project agreement will be the team’s primary measure of success. A weekly rereading of the project agreement should be mandatory for each team member and especially for the project manager. The project agreement should always be carried into meetings with the sponsor to help remind the sponsor what was agreed upon and signed. In addition, if scope creep does happen, the project agreement should be changed to reflect a later schedule or other adjustments.
Worst Practice # 8 – Not Developing a Project Plan
Nike’s ads used to say, “Just Do It!” Many project managers have accepted this philosophy and they truly hate project planning. “We are all working hard and don’t have time to create a project plan. Besides, we can always do it later.” Similar to this reasoning is “We spent two weeks developing a project plan and nothing is working according to the plan. What a waste that was.”
Project managers are sometimes reluctant to develop plans because they don’t know where to start. There are a number of published examples of project plans with examples of work breakdown structures with tasks, deliverables and suggested resources (roles to carry out the task) so this shouldn’t be an excuse. Perhaps the most daunting challenge is assigning the efforts associated with each task. These effort estimates should come from those who will be performing the job. Ask them for the best case, worst case and most realistic case and use the most realistic estimate with a 20% allowance for unanticipated problems. Another approach suggested in MS Project 2000 Bible is to calculate the most likely effort by using the formula (best case + 4 times most realistic case + worst case divided by 6). Don’t forget to add time for other project related activities, non-project related activities, as well as for training, illness and personal time off and adjust for the person’s skill and job experience
Someone with data warehouse project experience should review and validate those estimates. Experience has demonstrated that actual duration is at least double the effort time, and in companies which thrive on meetings actual duration can be three times as long as effort time.
Worst Practice # 9 – Let the Project be Driven by IT
At a conference a few years ago, a manager was bragging about his data warehouse. It was around 500 gigabytes, running state-of-the-art software, with good response time and acceptable load times. When asked how the users liked the system, he wasn’t even embarrassed when he responded that the users didn’t use the system. We suggested that at least a few of the users were running some queries or reports. No, there were no users logging on; he dismissed the users as uneducated and unaware of the potential of the data warehouse. What had happened? IT developed the system with little or no input from the users expecting them to embrace the warehouse as it was delivered. The users rejected the implementation in favor of their old ways of reporting. The new system did not meet their needs.
It doesn’t matter where you report in the organization; the project should always be driven by the business. IT will sometimes initiate a data warehouse project and as a way to demonstrate the value of IT to the business. Some of these efforts are considered a proof-of-concept. This is like the necessity to prove that manned flight is possible. The data warehouse concept does not have to be proved. However, what does have to be proved is the value of the data warehouse to the business and the only way for that to happen is for the project to be directed by the business. Every line of business has data warehouse applications crying for implementation. If the business has not already done so, uncover those applications, solicit business partnership on the project and implement something that is of substantive value to your organization.
Worst Practice # 10 – Losing Control of Determining What Software to Use
Many data warehouse projects are under the total direction of a line of business. In many cases, the lines of business have no in-house data warehouse experience and will bring in an outside consultant to direct the project. In these cases they will often let an external consultant make the important decisions. This is not to imply that the consultant will make improper decisions but those decisions are sometimes driven by what the consultant knows and doesn’t know. The skills and expertise of the individuals slated for the engagement may color the consultant’s recommendations. In the marketing stage, consultants will represent their ability to work with any software on the market but when problems occur – they always do – the strong suggestion will be made that if we could use the consultant’s software of choice – you can always switch back later – the problems will be resolved. Just for the record, switching certain categories of software is as invasive as a heart transplant – try to avoid it.
Worse still, software vendors may have sold their entire package convincing management that the only way to succeed is to use the vendor’s full range of integrated software and services. This approach forecloses use of software that would be better suited to your project and you are forced to use a second or third tier piece of software that would stand no chance of being selected if compared to their much better competitors.
Your organization has standards. Some of those standards include operating system, relational database management systems (DB2, Oracle, SQL/Server, Teradata), and may include query tools, Extract, Transform, Load (ETL) tools and other data warehouse related software. If such standards dictate software and tools appropriate for your project, you are home free. However, if those standards lock you into any software that will not support your project, you need to take control and make sure you have the right tools.
One of the first questions or assertions you need to make as a project manager is your degree of authority to make important decisions. You will need to consider your organization’s standards, you will want input from the outside consultants and software vendors, but the final authority for making the decisions should be your own. Also, you do not want the consultant or vendor going over your head, trying to convince your management or your users of their position and undermining your own.
Worst Practice # 11 – Marketing the Project Yourself
It’s not that you have no credibility in your organization; it’s just that some others have a great deal more than you. Let’s face it; you don’t have the weight, position or the charisma of your sponsor – that’s how they rate their grossly inflated compensation package.
We have seen excellent projects rated “fair” while projects that should have been considered a failure e.g. 5% of the function, six months late, $1,000,000 over budget, user dissatisfaction (you get the picture) have been touted as an overwhelming success. Why you ask? The sponsor stood up and said the project was terrific and the project manager should receive the Nobel Prize for Data Warehousing – we understand the Academy is now considering such an award.
In early discussions with the business sponsor, enlist support to promote the project and the noble team who will be building it. You want the business sponsor to be delivering the testimonials, authoring the pieces describing the benefits of the system and speaking about the wonders of your data warehouse implementation to all who will listen. For your part, be sure to give all the credit to the users of the system, to your team and to your sponsor. Take no credit yourself – it will come to you indirectly; be patient.
About the Author
Sid Adelman is a principal consultant with Sid Adelman & Associates, an organization specializing in planning and implementing data warehouses, performing data warehouse and BI assessments, and in establishing effective data strategies. He is a regular speaker at “The Data Warehouse Institute” and IBM’s “DB2 and Data Warehouse Conference”. Sid chairs the “Ask the Experts” column on www.dmreview.com, and has had a bi-monthly column in DMReview. He is a frequent contributor to journals that focus on data warehousing. He co-authored one of the initial works in data warehousing, Data Warehousing, Practical Advice from the Experts, and is co-author of Data Warehouse Project Management with Larissa Moss. He is the principal author of Impossible Data Warehouse Situations with Solutions from the Experts and his newest book, Data Strategy, was co-authored by Larissa Moss and Majid Abai. He can be reached at 818 783 9634and email@example.com. His web site is www.sidadelman.com.
Data Warehouse Project Management, Sid Adelman & Larissa Moss, ISBN 0-201-61635-1
The Mythical Man Month, Fredrick Brooks, ISBN 0-201-83595-9
MS Project 2000 Bible, Elaine Marmel, ISBN 0-7645-3319-3