Don't Ask Me About Best Practice One Month Before Implementation
Updated: Mar 23, 2019
I was on a call recently and the project lead went through everything they had already done to set up their information system. They had gathered their business requirements. They had selected and purchased their vendor, and they were one month out from implementation. This last part bowled me over. "Oh no, it's a clean up job." I thought. "They've realized that they didn't select the right vendor and they need help from industry professionals to get it done right this time around." But then they explained that what they wanted from a professional was implementation support and a metadata model - both based on best practice. I was speechless. They were planning to go forward with the implementation and wanted metadata and system configurations designed based on "best practice" within a month. I was definitely that person on mute banging my head against the table.
Here's the thing with best practices; by their nature, they don't retrofit well. You certainly can apply them to an established practice to improve how processes are executed, but not without major changes to behaviors and even the configurations in the system. Best practice is an approach, not a band-aid. Making major changes to established behaviors with a change management plan is one thing. Trying to squeeze a "best practice" strategy into a month of activity alongside actually building a configuration model, is nigh on impossible.
Below are just a few reasons why I say that you cannot start thinking or talking about best practices any time later than right when you start on your Information System / Program journey:
Spend time on discovery I feel like my first detail here probably already has some project leads groaning. "There isn't time or budget." "We sort of already did discovery, that's how this came up." "We already know what the problem is." I promise you, you don't know. Sure, you know what business need you are trying to solve for. But there are many unknown unknowns when embarking on the set up and implementation of an information system. Trust me. This is best practice. You can't expect to jump into requirements and not uncover several new stakeholders who have data that you'll need to incorporate, numerous systems that will need to be evaluated as part of the overarching program, several other projects in the works that might overlap with yours... The possibilities are just endless. You don't want to find this out after you've begun to write user stories and have committed to a timeline that your director is going to hold you to.
Involve your business stakeholders from the start This is a key criterion to user adoption and overall program success. It is an established tenet of project management that stakeholder engagement is best done early and often.* And I'm not talking about paying lip service to their involvement. Stakeholders are more likely to adopt a system that was purchased based on their needs, and that they have had a hand in selecting and configuring. You can't exactly go back and apply this best practice after the fact, unless you actually start again, and project leaders are rarely willing to do that.
Understand your IT security officer's perspective This is probably a lot higher up on this list than you would have expected, but it's a hiccup that I see over and over. You want your creative and marketing agencies to be able to upload and/or download content from your system. You want data to be able to go to distributors or to receive it from them. And you build it into your requirements and select a system that supports it only to find out that your IT Security team would never let them into the firewall. Now what do you do? Again, this one is tough to retrofit. Bring IT (also a stakeholder!) in from the beginning and always take their perspective into account.
Know your metadata requirements early There are a lot of good reasons to have your metadata model defined before you even begin to select a vendor. This isn't just consultants trying to get more work, I promise. There is a reason why what they propose in terms of discovery, requirements gathering and definition, and configuration planning blows you away... It's because it is best practice... And best practice takes a lot of work up front. Metadata is the foundation of any information system. It is the management in your "information management." It's the type-ahead in your search bar. It's the filters for your results. And it should very much be the apple of your digital transformation strategy's eye. There really is an entire other blog on all of the "whys" for pre-vendor metadata definition, but to name a few: Various information systems handle metadata differently. You need to know if any metadata requirements will make or break your program before you select a vendor. Do you need to be able to apply an extensive number of custom fields? Are some of your controlled lists too long for a drop-down? Is type-ahead a very strong want? Do you need metadata to kick off a workflow? What different metadata schemas or elements do you need the tool to support? Reading EXIF or IPTC? Do you have naming conventions in place now? Will you need to in the future? Just because you're setting up a system in which you can apply metadata to content does not mean that you don't have use for naming conventions. They can be extremely useful in automating tagging on content upload (if your tool handles it) or in helping users know what the content is whenever it lives outside of its home storage system. And of course, these will all inform your ultimate metadata model.
Define your operating procedures before you implement I have begun to suspect that some project leads think that these mythical "best practices" that they hear of are a specific set of standard operating procedures (SOPs) that only industry professionals know and that we're only going to give them once we are signed on to a project. But that isn't it at all. The specific operating procedures for a given company's given system implementation is going to vary dramatically. And of course having operating procedures in place before people become entrenched in behaviors is the best practice. Can I repeat that? Having SOPs in place before people develop their bad behaviors is the best practice. If you find yourself too far down the road before you start thinking about how to apply best practice, then you're going to have a lot more work to do to change behavior.
Now that is a few reasons that I have rattled off quickly based on just a few best practices that I know of. But the funny thing about these best practices that I have named is that they're pretty easily searchable. Type in "best practice for information management" into any search engine and pretty high up in your search results you will find standards documentation from highly credible sources such as AIIM, as well as useful white papers from major players in the field. It's all out there.
My ultimate thesis here is that you have to think about best practices well before you are implementing your tool. Even if you do think that best practice is just operating procedures, many of these will still affect your system configurations. Lack of best practice is definitely a reason why your user adoption, and overall program success isn't going as well as you had expected. They simply aren't something that you can just tack on at the end and say you did the thing with "best practice". They require investment and time. You have to be willing to fit them into your timeline and your budget from the very beginning, or you just might miss the best practice target again.
*Pinches, Benedict. "Stakeholder Engagement." Accessed from: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=11&ved=2ahUKEwili4ylys3gAhXhm-AKHSQdDDMQFjAKegQICBAC&url=https%3A%2F%2Feponline.com%2F~%2Fmedia%2F8EBD01AE7E1C4A73900943E370C7CF4E.pdf&usg=AOvVaw0F7lWa7EaPO9iMzYh0Q3m4