Fear and Loathing in Project Management

How to insulate your data warehouse project team from potentially devastating business decisions

By Michael L. Gonzales

Executive Summary

Michael L. Gonzales As a project leader, you may be faced with politically naive behavior from executives, the IT department, or users. How can you implement a complex IT project involving disparate data sources and processing requirements in such an environment? The Dysfunction, Impact, and Feasibility (DIF) matrix approach can help you define interrelated, overlapping requirements, prioritize iterations, and provide nonbiased decision-making.

When you have a large IT project to implement, everyone - your company's executives, IT personnel, and users - wants a successful project. But, it isn't unusual for politically naive behavior from these same individuals to compromise the success of a project and leave reasonable professionals caught in the crossfire. However, you can manage these difficult situations by accurately identifying and prioritizing your project iterations.

I've experienced my share of volatile situations. In one account, I vigorously tried to persuade the executive IT sponsor that building a data warehouse without involving end users wasn't the best approach. My argument was that the project team should build the data warehouse using business requirements based on user community feedback, not IT assumptions. The executive sponsor's response was,"It may not be the best way, but don't we have the right to be wrong?"

In another account, I was leading a politically challenging project for a company whose executives didn't trust the new IT director and often overwhelmed him with their aggressive actions and attitudes.

In both cases, it was important to remove - or at least insulate - the project team and myself from the potentially devastating behavior of misguided or inexperienced executives. To that end, I have implemented a modified version of the Dysfunction, Impact, and Feasibility (DIF) approach, providing a statistically valid method for quantifying and prioritizing the project's iterations. Although the technique's origins are in process redesign efforts, data warehouse projects exhibit similar characteristics with numerous potential starting points and iteration opportunities.

It is best to use the DIF approach when you need to recommend where to begin a project and what the order of subsequent iterations will be. This approach lets decision makers set the project direction based on empirical evidence rather than emotion or politics.

The Right Approach

You must first determine if your project has multiple starting points and iterations. For instance, in data warehousing you may have many projects queued and waiting to start. User communities often besiege warehouse teams with competing requests. Marketing might believe its project is more important than the sales project, and sales might argue for priority over manufacturing. Process redesign efforts are subject to rival interests as well. These types of projects will benefit from the DIF approach. However, single-iteration projects are less suitable, such as writing a report or adding a feature to an existing application.

I most recently applied the DIF approach in a process redesign effort. The goal of the project was to simplify the complexity of moving data from disparate applications within the organization. This client had been experiencing problems with its data infrastructure and exhibited symptoms such as:

• Difficult ad hoc reporting because of disparate data
• Increased system complexity caused by disparate data and technologies
• Timeconsuming manual rekeying of data between systems
• Lack of integrated and accurate data sources
• A heavy dependence on IT for any report requirements.

If you attempt to implement a point-to-point integration strategy as a means to address the disparity, you merely exacerbate the problem, resulting in classic interapplication spaghetti code, of which this client was a prime example.

No matter how good the programming team, the combined growth of integration points creates an unsustainable architecture. Point-to-point integration is simply not scalable and often easily broken with any change requirements. And, to make matters worse, point-to-point integration code often develops in a vacuum specific to the task at hand and is made with inconsistent tools.

As shown in Figure 1, the environment encompassed numerous applications, major external process feeds, and several "data warehouses," as IT sympathetically describes them. The real architecture is far worse, more complex and convoluted than I can portray here. Table 1 shows a hint of the severity.

Two formerly independent companies are now attempting to become one synchronized, competitive leviathan. Aside from the sheer magnitude of political issues that haunt such acquisitions, consider the challenge of integrating disparate, independently implemented systems from various vendors, with different code structures, nomenclatures, and technologies. How and where do you start? The challenge is daunting.