120 Minute Waltz: Running A GCDOCS Architecture Meeting

I have previously blogged about GCDOCS planning, information architecture, and metadata modelling. 

I think it’s time to confront one of the most interesting and tricky parts of a GCDOCS implementation: the process and dynamics of actually meeting with clients in order to model out their GCDOCS environment. 

The outcomes of a GCDOCS architecture meeting might be fairly apparent: get folders, get metadata, align with information architecture/records management, smile nicely, and make sure to shut off the projector when you leave (if you need a budget projector, learn more here). But like any encounter with real humans, GCDOCS meetings offer plenty of opportunity for a number of strange deviations, rabbit holes or tangents…

Here are some tips I have formulated based on real experiences trying to design a GCDOCS/EDRMS environment for a wide variety of departmental business lines. 

“What is this meeting about?”

Ideally, your clients will have been made familiar with the system, have had some elementary orientation or training, and will been made aware of the architectural goals of the meeting before entering the room for your first session. Ensuring this type of preparation on their part is a fundamental principle of Change Management. But one must always prepare for the worst: people with no idea what’s going on, what they are being asked, or what GCDOCS even entails. 

Inconsistent attendance and unexpected personnel substitutions will also make for a disorienting experience. As a contingency plan, you should always be prepared to discuss the following, as quickly as humanly possible: 

  • What GCDOCS is, and what goes in it 
  • Why their business will be better once they use GCDOCS 
  • Why there are constraints to the folders/metadata 
  • What they are responsible for providing 
  • How you expect people to work in it 

Address three fears first 

I have found three fears tend to manifest themselves whenever somebody is first encountering a GCDOCS project. Be prepared to address: 

  • The fear of Open Permissions – people generally think you are making all of their material available at a departmental level (It won’t be). 
  • The fear of Impending Migration – people are terrified by the idea of migrating their files, and how difficult it will be (It’s feasible to propose a day forward approach). 
  • The fear of Disposition – people generally feel a lot of their material should be kept much longer than the retention periods dictate (Not everything can be kept forever). 

Don’t start with the model – Ask what the meeting participants DO

As tempting as it may be to hit the mind map immediately and starting building Babylonian towers of metadata and folders, you risk confusing yourself and everybody in the room if you do not have a good grasp of the business processes which need to be at the heart of the model. Ask them to explain what they do in their own words and talk out the process before pointing them to this or that prescribed structure. 

Don’t gloss over the small things 

GCDOCS, like any system, has its common pitfalls. Things like the user-experience for inputting metadata, or the navigation of deep folder structures are often glossed over in meetings. It’s easy to let your design sessions ignore these difficulties to expedite the meeting: don’t. If the discussion turns onto user-input metadata, highlight its problematic areas, and suggest alternatives (inheritance). If clients are suggesting deep level folders for single or small groups of documents, suggest that they might not need them for so few objects. 

Keep them talking 

An old precept of Freudian psychoanalysis is to keep the patient talking, no matter what, and about anything, no matter how seemingly irrelevant: eventually something will emerge that will enlighten their symptoms. An analogous situation could crop up in an architecture meeting that seems to be going in circles. 

When in doubt, ask questions or shut up, let them look at the structure, and see where they go with it. While we don’t want a rant session, sometimes it’s impossible to get at what you are looking for directly; the client needs to talk through it themselves. Remember, they may be very new to ideas that you are well accustomed to. 

Problematize easy cases 

Very often, the struggle between building a structure that suits clients as well as information management requirements results in tension. Sometimes, however, everything falls into place ridiculously fast. It is very possible that the clients can be too agreeable; they accept your logic without question, trust you entirely and don’t think about any problematic scenarios.

As tempting as it might be to move forward, you are not doing them any favours going too quickly, and it is likely that problems will start to manifest after implementation. Make sure the debates occur where and when they need to; if the transformation is going to truly have an impact, there will have to be friction. 

Leverage enthusiasts 

Very often, certain subject-matter experts will be far more enthusiastic or willing to help build the folder structure. It’s also very likely that these individuals have a very sympathetic understanding of the opportunities provided by a good information architecture. It would be silly not to leverage such individuals where possible. Do not ignore their advice! Allow them to serve as a coordinating role within an organization. Be flexible with their requests, and they will pay you back with buy-in from their entire organization. 

If you shortcut it, they will come 

There will inevitably be requirements that will grate on the users – usually regarding the location or structure of folders. While it is not always possible to give them the exact model they are looking for, a lot of resistance can be neutralized by extrapolating on the power of shortcuts and favorites to get users to their personalized destination folders as fast as possible. 

Know when to bow out

You can solve a lot of problems with your GCDOCS implementation, but you can’t fix a broken business model. In cases where organizational flux or poor design are causing contradictions to appear in the model, the best you can do is to highlight, not gloss over, the tricky parts. A functional approach to building folders is especially conducive to revealing redundancies and idiosyncratic methods that make little sense when seen from a non-organizational view. Know when you can’t fix something, underline the issue, and leave it to the group to confront their own problems. 

Finally, offer a flexible model 

GCDOCS meetings are very interesting events; one gets to plumb the depths of current business practices while at the same time looking towards the future. Almost everything under the sun can come out – it’s important that the pragmatic goals of building an environment balance with the forward-looking discussion. Above all, a flexible model enables debate and thinking about the future – which is much more useful than simply delivering a closed, monolithic environment. 


Leave us a comment: * Your information is never shared