Avoid slipping on banana peels in metadata projects

Let's be honest, implementing non business-critical web applications like metadata catalogues, business dictionaries, data dictionaries is not an easy task. It comes fraught with difficulties for the implementation team to negotiate.

And the larger the company the bigger the difficulties get. They vary from departmental responsibilities and compatibility issues to budget and cross company adoption. After years of deploying and running business dictionaries and metadata catalogues in various companies I've come face to face with many of these problems. Some of them are outside the control of the implementation team and are hard to negotiate. But there are many others that aren't. What can be done to avoid slipping on banana peels in metadata projects? Three tips.

Dont’t lose 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 comes 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) and let that experience define what you really need.

Avoid 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 an implementation 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 an implementation team that is 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 stakeholders 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 necessarily have to buy a license, you pay just for a few days (like less than 10) of consultancy. A server for you can be available in days. Then just start working.

Is there a term that you and your team couldn't agree on? Then use the 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.

David Vonka is Co-Owner at Semanta.

This blog was originally posted on the Semanta website.

Semanta wordt in Nederland vertegenwoordigd en gedistribueerd door IntoDQ.