20 Feb Worst Project Management Practices
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.
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.
Worst Practice # 3 – ATTEMPTING THE PROJECT WITH A DSYFUNCTIONAL 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.
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.
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.
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.
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.
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.
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.
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.
Author Sid Adelman – Sid Adelman & Associates
www.ewsolutions.com/worst-project-management-practices/