Successful project managers present realistic expectations for completing any effort. Managing expectations for delivery is crucial to the perception of success, especially with business intelligence and analytics projects.
Many data warehouse, business intelligence and analytics projects would have been labeled as successful by any outside expert observer. Within the organization, however, the projects were considered failures because management and users had much higher expectations than what was actually achieved. There is nothing more critical to the success of a data warehouse or BI effort than managing the expectations of users and management.
There are five major areas of expectations: schedule, cost, function/usability, service level agreements (for performance and availability), and expandability.
Management has expectations concerning project completion. Statements such as “putting a stake in the ground” with a specific date attached is a management technique designed, ostensibly, to give the project team motivation and incentives for working hard. Usually, these dates are developed in a vacuum without any understanding of the tasks involved and the duration of those tasks. The data warehouse project manager often will accept those dates because there is no basis to refute the schedule. If the project manager had a project plan, there would be a basis for discussion and negotiation.
Having a basis for the project’s duration provides the project manager with a set of alternatives. In no case should the unrealistic schedule be accepted with a “let’s give it our best shot” attitude. The results are predictable. The project will slip, functions eventually will be deleted, the quality of deliverables will be below standard, or there may a horrible combination of all three alternatives. In any case, the project will be considered a failure.
There are alternatives, some more acceptable than others.
Alternative #1: Cut the Scope
The first alternative is to stay with management’s schedule and deliver the first phase on time but deliver only a subset of the initial functions. This assumes that the deferred functions will be delivered in subsequent phases and that a phased approach is acceptable to management.
The project manager must be careful to assure that, even with the reduced function, the first phase can be completed on time and that the functions delivered have real and measurable value. Two areas in particular must be examined very carefully: training needs and dirty data. These areas are chronically underestimated.
Alternative #2: Renegotiate
The second alternative is to negotiate for a more realistic schedule. Some schedules are hard and fast (a merger or acquisition, governmental reporting requirements,…) but others are without any underlying real requirement (a fast-track manager may want to demonstrate quick results). Determine the underlying reason for the imposed schedule and let it determine the negotiating strategy.
Alternative #3: Add Resources
The third alternative, throwing more resources at the problem has perils and inherent costs. Adding more people, employees, contractors, or consultants, often will delay a project, since the new people must become part of the team, trained and managed. This can mean that valuable resources are distracted from productive activities. In certain cases, however, the right resources, if they are trained, experienced and familiar with the project, can be of significant help.
Another type of resources to add could be software that would improve the productivity of key activities. An example would be data quality software that would help automate the process of cleansing and transforming the source data and software to facilitate prototyping. The project manager should be careful not to accept the vendors’ claim of improved productivity but should check these claims with reliable references. Be aware that new software requires time to install, it requires time to train the employees who will be devoted to the software, and requires time before the product is fully functional. The learning curve for a functionally rich ETL tool can be as high as three to four months.
A word of caution, the project manager should be careful about accepting new resources and should not accept a shortened schedule as a compromise unless the resources are the right ones and can truly support the timeline.
Alternative #4: Taking Shortcuts
The next alternative is not really an alternative, but is often an inevitable sequence of actions that result from the pressures of arbitrary and unrealistic deadlines. Often, in the name of expediency, quality can suffer. Shortcuts can occur:
- There was not enough time allocated to recruit a competent team and there was not enough time allowed for training the data warehouse team. Therefore, tasks were performed poorly or had to be redone.
- There was not enough time allowed to develop a project plan or to manage the development effort.
- The time to understand user requirements were severely shortened or the requirements gathering activity just given a cursory effort. The users did not get what they wanted and walked away from the warehouse.
- The effort to determine what source data to migrate to the data warehouse was eliminated. All the production data was dropped into the data warehouse. The result was a bloated data warehouse with poor performance. It was accompanied by poor documentation and with users who did not know the meaning of the data they were accessing.
- The time-consuming and labor-intensive task of cleansing the data was bypassed. This resulted in user dissatisfaction with their queries and reports and ultimately in the failure of the project.
- A data model was not created. Subsequent projects were not integrated and the result was disparate data marts with redundant and inconsistent data. It became almost impossible to create a query that accessed more than one data mart.
- Metadata was neither created nor maintained. It was not clear what the reports meant, their timeliness, or the source of the data. Since, in this process, transformation and cleansing were performed without the benefit of metadata, it meant the users were not even able to find or recognize their legacy data which was now stored in the data warehouse.
- There was not enough time allocated to develop and carry out user training. Users had more problems and become frustrated.
- Not enough time was dedicated to testing the system.
- There was no effort exerted to tune the system. Performance was poor.
It should be obvious that the effect of an unrealistic schedule on quality will have a devastating impact and should not be considered as an acceptable alternative.
Alternative #5: Major Overtime
The final alternative should not be considered seriously. There are managers who plan schedules to include employees working weekends and very long hours during the week. These managers have been known to ask the team to defer vacation, holidays and needed dental work. While the team may put in the hours, their productivity and the quality of their work will always suffer, not to mention their morale. In other words, the managers get the time but not the results. The now disgruntled employees often transfer during or shortly after the project is complete, or leave the company entirely.
If management is aware of the obstacles to insisting on unrealistic schedules, they are likely to accept either alternative one or two and may be willing to spend the extra money for alternative three but should be careful to avoid alternatives four and five. Project managers should become adept at managing schedule expectations by developing and presenting realistic project plans and offering valid, usable alternatives that will ensure a successful completion.