Remember the Betamax? How about eight-track tapes? If you remember either of these tape formats, you understand the importance of standards. Adhere to the wrong ones and you find yourself with a closet full of useless junk.

Adhering to standards in the data integration framework (DIF) is just as important. DIF standards help ensure successful construction, implementation and deployment of your data integration projects. DIF standards aren’t just for formats ­– they’re really about best practices for deploying your entire project.

DIF Standards and Best Practices

DIF standards fall into the following areas:

• Project management: methodology, baselines, status, controls, scope, people management, team management
• Software development: tools, techniques, documentation, version control, release management
• Technology and products: company and project technology infrastructure and tools
• Architecture: the blueprint of what you’re going to build and how you’re going to build it
• Data: consistency, accuracy, integrity and validity are all crucial

There are many standards that should be common to any information technology (IT) project –­ not just data warehousing (DW) and business intelligence (BI). However, there are several areas to emphasize during a DW or BI project that are either unique or have a greater priority than other IT projects.

Project Management Standards

You can’t get around the fact that you must manage your project within the budget and time frame while producing tangible business benefits. Having a talented technical staff doesn’t mean you can avoid the up-front planning and tracking, nor does having tools that can be deployed really quickly (at least according to the software vendors). Some of the key standards or best practices for project management are:

Use a tried and true methodology. Select and use a project management methodology that has been successfully used in implementing similar projects. Choose a methodology that has been used in implementing DW/BI projects and can accommodate iterations (rather than just the standard “waterfall” project plan) and revisions as the project proceeds.

Take bite-sized pieces. Split the DW/BI objectives into manageable projects or iterations that progress in a stepwise manner toward your desired state. The “big bang” approach to IT projects is littered with failures: missed deadlines, endlessly extended deadlines and, most commonly, the “quick-hit” solution while the IT project lumbers along. You should have an overall high- level program plan with the first iteration, generally three to six months, being a detailed plan.

Communicate. Establish a communication process that involves the business users and management. A good approach is to have daily team progress meetings, weekly status meetings with IT and business project leaders with their immediate management, and biweekly milestone meetings with business and IT sponsors. Document all of these meetings and e-mail the summary and key issues to all parties. It is also a good idea to post the information on an internal Web site. Send the status to everyone. They can always ignore the e-mail if they are not interested, but at least they had the opportunity to be involved.

Manage the scope. Scope management and change control are the key project management disciplines that need to be applied in these projects, particularly if prototyping, pilots or rapid development techniques are used. Watch out for the pitfalls of dirty data, getting agreement on business rules and data definitions, and (surprise!) business users changing their minds or asking for more. You must be able to respond to adversity and change while documenting these changes, determining the impact on plan, making the agreed-upon project adjustments and adjusting the project baseline to reflect the revisions.

Obtain technical management. Have a technical architect or a senior technical person manage the day-to-day activities of the IT portion of the team if the project leader is not technical. Technical decisions and tradeoffs must be made often, and you need someone with the right technical background for this. More importantly, you need someone who can see the big picture of the architecture to keep the development team from going down technical ratholes or getting bogged down in some detailed items that could either be ignored or handled by other people.

The process of creating and executing a project plan is more predictable with other IT and business projects than with DW/BI projects. The latter always encounter data issues, even with newly implemented ERP systems, as the business expands the project and data scope.