Seven critical success factors for BI projects

BNZ head of business intelligence shares his tips at Tech.Ed

Speaking at a session at Microsoft's Tech.Ed conference yesterday, BNZ head of Business Intelligence Dave Thompson shared seven tips for implementing a successful project.

Thompson, who reports to the bank’s chief financial officer, is part of a team that won Project Initiative of the Year at the New Zealand inaugural national CFO awards in March. The bank used business intelligence tools supported by Microsoft's SQL Server R2 database for two major web-based projects over the past 12 months. The reporting applications — online profit and loss (Online P&L) and customer portfolio management (CPM) — provide analysis of monthly historical data, drillable down to individual bankers and customer accounts.

Here are Thompson’s Seven Critical Success Factors:

1. Team Culture

“We all know that you need smart people to build cool software and most of us are aware of this important thing called team work. We all know this but in my experience it still remains an illusive attribute of most projects. It is the most important single factor in determining long term sustainable success.” He recommends the book The Five Dysfunctions of a Team by Patrick Lencioni.

2. Quality of Executive Sponsorship

“A lot of sponsors who fund your project don’t really have the time, or the interest, to spend with you in sufficient detail for you to build something that meets what they think they want. We are the eternally optimistic developers that let them off the hook from the start. If your sponsor only has peripheral involvement in the project this is an early warning sign of likely failure. Get them more involved or run away and find another project.”

3. Role of the architect

“Architects need to write code. This is a little bit controversial. We have, in my view, too many architects that are not hands-on technical enough and too many of them seem to operate in a parallel universe to developers and they tolerate each other but that’s about it. “

4. Test the architecture early

“You can’t test the architecture on a whiteboard. There’s no point in have a grandiose architecture if it’s not pragmatic. It needs to be pragmatic, supportable and it can’t drive the developers nuts trying to work around it. That’s why I think the architect needs to be able to write code although that’s not to say they are the main developer. I think a really good contribution early on when you’ve got the architect whose thinking through security, saleability, designability etc that they take a deep slice of the application that carves through all the different layers and builds some of that code. They should do that and test it and see that it’s not too cumbersome and that it does scale and is supportable and that it won’t take developers three years to build something because it’s too over-engineered.”

5. Agile? No substitute for experience

“I think Agile (method of delivering projects in a highly flexible and interactive manner) tends to be a better approach but there are a few caveats. Mostly because it’s unreasonable to expect that your customers and users know everything up front before you start building. You have to build something, pull data through and look at it before you can determine if something is even possible. But don’t let Agile become an excuse of no process and no documentation. More important is experience, I always take an experienced project manager regardless of their methodology because they usually have a sense of where the snakes are in the grass ready to bite you.”

6. Data quality can kill you

“If you’ve got a bank teller working on a customer record they might not think about the consequences of entry of like industry code. It might not be relevant to data entry because on that one record it doesn’t matter, but when you pull through millions of records and you start to slice and dice through those sorts of measurements then you’ve got a big issue. The key here is to try to ensure things are fixed at source. Data quality issues can severely tarnish the reputation of the data warehouse. Even though it isn’t not your fault, it tarnishes your magnificent project. It goes back to Number 2 – you’ve got to have that executive sponsorship so that they can ensure you’ve got frontline staff that understand in their KPIs that data is important.”

7. Post implementation reviews

“It is important to get someone independent who doesn’t have a fixed interest in the outcome.”

Join the newsletter!

Error: Please check your email address.

Tags managementMicrosoftsql serverTech.ed

Show Comments

Market Place

[]