Every project, especially for complex initiatives in data warehousing / business intelligence / analytics, can fail because of poor project management practices. Following these bad practices lead to failure.
A project manager’s job is beset with worst practice traps just waiting for the unaware manager to fail. These traps can be avoided. Recognize and avoid these worst practices to implement any complex initiative successfully, such as a data warehouse / business intelligence / analytics project.
Worst Practice # 1 – Accepting an Unrealistic Schedule
Almost every 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 think that if they do not give a date the team will take forever and there will be nothing to show for the effort. The especially bad news is that management does not trust the project manager’s ability to plan and manage the project.
Many project managers have been saddled with an unrealistic schedule because their management already committed the schedule to their leadership. 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 of feathers in a five-pound bag – it does not fit. A project manager cannot 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, do not accept adding more people to satisfy an unrealistic schedule. The mitigation is a project plan with realistic efforts defined fully.
Worst Practice # 2 – Taking on a Failing Project
The organization knows that the project is in deep trouble and a new project manager has been given the mantle of hero or, much more likely, identified as 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, either have left the project or want nothing to do with it. The morale of the remaining team has been lost. Worst of all, management still expects the project to come in on time and with all the original function and a little more.
No project manager 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). The 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 to do is decline and wait for something more promising to come along.
Worst Practice # 3 – Attempting the Project with a Dysfunctional Team
Many organizations have poison people, the ones who no one else wants and, most projects have some. 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 do not respect each other and their dislike of each other is apparent. Project managers cannot succeed with poison team members. They will contribute nothing; they will only hurt compromise the integrity of the team and the success of the project.
Ask for the authority to choose the project 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.
Worst Practice # 4 – Choosing the Wrong Sponsor
Wise Uncle Herman once gave sage advice. He said, “Never get into bed with someone crazier than you are.” As a project manager, take this advice to heart and never attempt a project with a dysfunctional sponsor.
Some telltale signs of a dysfunctional sponsor include:
- A trail of bodies – this sponsor has caused the professional demise of multiple 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 the project will encounter, and pick a sponsor who will support the team and the project. The sponsor should believe that the 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 do not 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, and push the frontiers.” Pushing the frontier with a complex initiative such as business intelligence or analytics 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 later. This is usually 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
Scope creep happens; every project will have scope creep. The project manager must control it, not just document it. Good project managers are not 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 (do not forget this is a request, not a demand), “yes” and “no.” When a project manager agrees to the addition, he or she will always be known as someone who inflates schedules. In addition, he or she will be perceived by the team and management as either weak – unwilling to stand up to management – or naïve. If the project manager says “no” immediately, he or she 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, the response should be, “I’ll get back to you and let you know how badly this will affect our schedule.” Management should also know that scope creep analysis takes time and effort away from the original set of agreed-upon deliverables.
Worst Practice # 7 – Not Putting the Project Agreement in Writing
This assumes there is 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.
Many project managers feel they do not need a project agreement since they like and trust everyone involved with the project. They believe they do not need to agree upon and document a scope that will indicate what the team will deliver and when, including specifying responsibilities, service level agreements, levels of data quality, or acceptance criteria. Someone suggested there is no need to worry about or write down who will be paying for the project. Heed this advice and the project will encounter the scenario where the team thinks it succeeded only to discover that the users see it as a failure – e.g., it did not deliver 100% sub-second response time which they were expecting all along as part of their anticipated performance service level agreement.
A common mistake is to document a project agreement, have it signed by the sponsor and the project manager, file it away and to not look at it until the system is delivered and to then identify what was missed and also what was 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.”
Sometimes, project managers are reluctant to develop plans because they do not 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 should not 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. Do not 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.
Another project manager should review and validate those estimates. Experience has demonstrated that actual duration is at least double the effort time, and in companies that 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 manager was bragging about his data warehouse / business intelligence environment. 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 was not embarrassed when he responded that the users did not use the system. Were 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 and its BI capabilities. What had happened? IT developed the system with little or no input from the users, expecting them to embrace the environment as it was delivered. The users rejected the implementation in favor of their current reports. The new system did not meet their needs.
Every initiative should be driven by the business, although some BI and analytics projects may originate with Information Technology (IT) as a proof-of-concept. This is like the necessity to prove that manned flight is possible, and that analytics can be valuable to the business. The only way to secure user support and acceptance is for the project to be directed by the business. Every line of business has BI/analytics 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 DW/BI/analytics projects are under the total direction of a line of business. In many cases, the lines of business have no in-house DW/BI experience and will bring in an outside consultant to direct the project. In these cases, they may let an external consultant make the important decisions. This is not to imply that the consultant will make improper decisions, but those decisions can be driven by what the consultant knows and does not know.
Additionally, software vendors may have sold their entire package by convincing management that the only way to succeed is to use the vendor’s full range of integrated software and services. This approach prohibits use of software that would be better suited to the project, forcing the project team to use a second or third tier piece of software that would not have been selected if compared to their much better competitors.
Every organization has standards, including operating system, relational database management systems, and may include query tools, Extract, Transform, Load (ETL) tools and other related software. If such standards dictate software and tools appropriate for your project, fine. However, if those standards identify software that will not support the project, take control and select the right tools.
One of the first questions or assertions a project manager must demonstrate is the degree of authority to make important decisions. Consider the organization’s standards, gather input from outside consultants and software vendors, but reserve the final authority for making the decisions. In addition, prevent any consultant from trying to convince management or users that their opinion is superior, thereby undermining the project’s success.
Worst Practice # 11 – Marketing the Project Yourself
Project managers have credibility in their organization; however, others in management have more visibility and influence. Marketing the project is one of the primary responsibilities of the project’s sponsor.
Some excellent projects have been 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) have been touted as an overwhelming success. Why? The sponsor stood up and said the project was terrific and the project manager should receive the Nobel Prize for DW/BI/Analytics implementation.
In early discussions with the business sponsor, enlist support to promote the project and the noble team who will be building it. The business sponsor should deliver the testimonials, author the pieces describing the benefits of the system and speak about the wonders of the implementation to all who will listen. The project manager should give all the credit to the users of the system, to the team and to the sponsor. The project manager should take no credit directly – it will come indirectly; be patient.
Conclusion
Every complex initiative is fraught with challenges and ways to fail, and every project manager will encounter these and other obstacles on their journey to successful implementations. Avoid these worst practices and become a stellar project manager!
