Decision making - not decision braking

Let's be honest, installing and implementing non business-critical web applications like business dictionary, report catalogue etc is not easy. It comes fraught with difficulties for the BI team to negotiate and the difficulties get bigger, the larger the company. They range from departmental responsibilities and compatibility issues through to budget and cross company take-up. After more than 2 year's deploying and running our business dictionary and report catalogue in various companies I've come face to face with many of these problems. To be fair some of them are outside the control of BI and are hard to negotiate. But to be equally honest, there are many others that aren't. What can be done to avoid them?


Losing sight of the goal

Stage 1: Planning

Distractions. Right from the get go, even in the initial meetings it's easy to get sidetracked. Discussions start about the design of the home page, the personal page or another landing page. Three people, five opinions, 7 meetings, 1 implementation, 3 re-implementations. There's a lot of talk, but not much that can move things forward.

Then come a manager who immediately find out that the company cannot use a product unless some feature X or Y is delivered. Depending on the current position of Earth and Saturn, in this phase the project either gets hijacked by a crazy technical issue (it cannot be considered unless some "cross-forest single-sign on authentication has been implemented" and "passed performance tests") or an obscure feature request hits one of the applications.


  Don't:   Don't get distracted by small issues.

  Do:  Stay focused on the goal. Work hands-on with an existing application(s) on a 30 day trial basis and let that experience define what you need.


Too many cooks

Step 2: Deployment

Changes that can't be implemented or too big, too soon.

The system gets the green-light. A budget is set. A schedule for implementation, training and launch is drawn up. Things should be fixed and solid. Right? Wrong. Getting departments in large companies to keep to a schedule is like getting Dilbert to work in a factory. It's not in the contract. 20 people appear in training sessions, 18 of them with no time allocation to work with the system in this century, 16 of them with no time allocated to do homework! If that's not tough enough for a BI team to manage, it gets even harder. Stakeholders and interests groups have got their pens out and want to come to the party.



Meetings are organized about the company's policies on terms, the review process, the publishing process and what not. The abstracter, the better. And in between that, other meetings are organized for reasons beyond anybody's understanding.

At the heart of it, I'm afraid to say that most of this activity is futile. I've been in this business for years and have to admit it's surprisingly difficult to create a viable report catalogue or business dictionary application. We made a vast number of strategy changes over the years, before we reached the current state that kind of works. Bottom line and what gets lost in the minutes of the many meetings, is that however a company's stakeholders want to build a business dictionary, it's unlikely to improve it. 100 pages of detailed requests won't lead to a better app than the off-the-shelf product. The only result of all this activity is a BI team who are running at their fastest just to stay in place and your first business dictionary project drowning in abstract discussions started by people with no real experience of the product.


  Don't:   Define how people should work in a Power Point presentation.

  Do:   Create a tangible output using an application with a small team and then codify best practice for your company.


Sit down and start writing

Product deployment is difficult.The important thing is to stay focused on the goal and not get distracted. Explain to the various departments and stake holders in your company the need for the product; how it offers a collaborative work environment, a business dictionary, a report catalogue, a data dictionary etc. Don't give in to distractions and don't spend too much time brooding. Easier said than done, I admit. But a proof of concept project is cheap, you do not have to buy a license, you pay just for a few days (like less than 10) of consultancy. We'll start the server for you in days. Then just start working.

Is there a term that you and your team couldn't agree on? Then go to business dictionary and start working on the term and its definition. Scratch an itch, start tiny. Create a small team where the members have been allocated enough time to work on the project. Run them through a training session or two, and let them solve real issues. Later on, maybe you'll have to create a well-designed process of term review and publication, but let's not do it in the beginning. Do it when you need it.

  Do:   Sit down and start writing