So there were a couple of good posts the other day by Johnny and the BMOC. The best thing is that they were about the same thing, yet not. Johnny wrote about how it was important to create a taxonomy, however superficial, and not put everything into one folder. BMOC looked at the same situation and talked about how it is important as consultants to guide clients away from the dark path onto the bright, safe path.

Building That Taxonomy

The theory is that you can put everything into one folder and it will work. Damn straight it will. That is until you navigate there, intentionally or not, using a client of some sort. That is where it all falls apart.

I had a client upgrade their system from 5.2.5 to 5.3. In Dev, all was well. In Test, it died. They were playing in Administrator, just poking around and looking when they realized that in the root of a cabinet, the installation owner’s cabinet no less, there were hundreds of thousands of test documents. The system locked-up trying to process the request to display the contents of that folder. A quick check determined that the problem was just as bad in Production.

The client had never had this problem before because nobody uses the Documentum interfaces for anything except Administration. They just expose what they need through a portal. I advised them that they may want to at the very least put all of that content into a sub-folder to reduce accidental browsing. They decided on a very simple taxonomy, not dissimilar in part from what Johnny shared with us.

For tips on building a decent taxonomy, just flash back to last August. I have a guideline for how deep to make a taxonomy in there. In a situation like the one that Johnny described, I might subtract one to two levels, taking the whole thing three total levels deep. Johnny’s design may get them where they need to go, depending on the time span for the documents. Getting over 1,000 items in one folder is starting to push it if users are going to navigate there. If not, Johnny’s rule of 2-3K isn’t a bad one.

Remember to pick your folder names carefully. There can be a steep price to changing them if you have a lot of things below in the hierarchy.

Monkey or Man?

Lee Dallas at BMOC focused on the business issue faced by Johnny (and reminded of the post by John Kominetz). When the client asks for something that you know is a bad decision, what do you do?

Before you answer that, there are a few things to remember:

• They are the experts in how they do business.
• You are expert in the technology (if you consult in one; say, just for example, Documentum).
• You are an expert in industry best practices (perhaps), but they may be as well.

Now, if you are just a contractor, brought on to build and do as instructed, then you may have no options. If you are brought in to consult on and/or design a system, then you need to work with the client as Johnny did. The trick is how.

The process is simple, even if the execution is not. Have the client explain their reasoning. If they want to check with others first, let them. It is important that the client fully understands their position. Ask questions to gain a deeper understanding to fully understand their point-of-view. Agreement is not the goal yet, just understanding.

After the client has confidence that you understand the why behind their position, pause to reflect if their explanation holds water. If not, then start sharing facts and posing scenarios showing why their approach may encounter difficulties. Remember, the client isn’t wrong or stupid (usually), they just may not have all the facts. That is why they hired a consultant.

If they become stubborn and refuse to shift, then you have to ask the hard question, Will this project succeed? If no, then you are left between a rock and an accountant. Some companies will inform the client that the project will fail if they proceed and may even withdraw from the project. This can hurt the pocketbook in the short term. Of course the alternative is deploying a system, having it fail, and having everyone blame the integrator and/or the software vendor.

The Hard Lesson

I once led a team to build an acquisition system. A RFP would be posted and companies could submit their questions and responses online. All communication was through the website with Documentum storing and driving the business processes. We were brought in 2 weeks into the project by the prime contractor after the schedule had been set with the client. Not seeing any written requirements, we worked with the prime and client to gather them while we started development to stay on track.

A few weeks later, we learned that the system as designed wasn’t going to meet the client’s needs. It wasn’t storing what was necessary, or storing what they had effectively. We had a neat and simple solution that would meet the requirements, but it would take a few more weeks to redo a lot of the work. The prime said make it work “as is” in order to meet the promised schedule.

We did the work and delivered on time. They had a system that “did” what was requested, but couldn’t perform any of the features that one might assume would come with such a system. The prime asked us to help them expand the system and move it forward, but they only wanted our developers, not any of our senior people that had dared to suggest a change in the plan. We said thanks, but no thanks.

Predictably, the system’s weaknesses started to show. The prime blamed us, repeatedly. Six months later, it became obvious where the real problem was and the prime was replaced at the client with a company that knew a little about Content Management.

Having a client that is wrong can be a tough and sometimes there are no right answers. Patience and understanding are critical, but they aren’t always enough. Experience helps. I learned quite a bit from that client, and very little of that was technical.