Stop Doing the Work of the CMS! - Part 1

Picture this: you have a flat tire and you pull over to change it. To achieve your goal of changing the tire you perform the following tasks:

1. Put the jack under the car
2. Place the wrench on the lug nuts
3. Crank away with (on) the wrench and remove all of the nuts
4. Pull on the tire
5. Attempt to lift the entire car up by yourself
6. Step back and observe your conundrum

Did you notice the missing step? (Lifting the car with the jack, anyone?)

So what is the moral of this story? Don’t attempt to lift the car by yourself when you have a fully capable tool that can help you. The same can be said for content management systems – don’t attempt to “create” key activities of the information lifecycle on your own, let the tool do it for you.

In my previous post, E-mail is NOT a collaboration solution, I talked about why collaboration through email is a bad idea and offered some CMS alternatives to this [horrendous] practice. Today, I’m going to cover a few initial recommended practices with your new CMS so you’re not trying to lift the car without the help of a jack.

Note: the following recommendations are based on the assumption that your CMS has versioning capabilities and they’re enabled.

Recommendation 1: One instance, one file – period. Do not physically label versions of files that are stored in a CMS in the filename.

For example, let’s say we’re creating a new Product Manual for a VCR (remember those?). When the Manual document is created and loaded in a CMS it’s automatically assumed to be version 1.0 (or 0.1, 0.01, etc. depending on your CMS’ configuration). So, always leave the “ver X”, “vX” (where X is typically a number) out of the file name.

Why?

Because the CMS is controlling the versions internally behind the senses. For example, if you have “Product Manual v2” and it’s iterated on multiple times, you might have 10 versions of “Product Manual v2”. How do you explain that to your consumers?

“Mike, check version 10 of version 2 in document version 8.”

Mike is thoroughly confused at this point and doesn’t want to use your document at all. Instead, call the document “Product Manual”, let the CMS control the versioning. When it’s ready for public consumption publish “Product Manual” and let the incremental versions be contained behind the scenes.

Next Post: Recommendation 2: Communicate revisions inside of the document

E-mail is NOT a collaboration solution

How many times have you received this message in your Inbox?

“Good morning everyone - attached is the [insert adjective here] document – please review and send me your comments by COB Thursday.”

Before I say that these messages annoy me, let me add some context to it first. The following statements are all based on an assumption that you have some sort of document management tool available to you. (If you are reading this, and say that you do not have one available, I strongly recommend you check out Google Docs – it’s free!)

So, with that being said, if you just want to see what I have to say and I’ll never see your document again then I don’t mind the message (well, too much – intellectual property is another post). However, if you (sender) expect to take feedback, incorporate it into a new rendition/version of the document and republish it later, then I am super annoyed by your message.

Why does this practice me bother so much? Because I know that you’re (sender) going to send another message 5 days from now with a new version of the document. That means that I now have 2 messages in my Inbox, 2 versions of the document and a whole string of emails from other people whose opinions aren’t relevant to me or the subject at hand.

Despite my obvious annoyance with this practice, this isn’t the main reason to avoid this practice. Rather, it’s critical to capture all of this context in a way that is traceable, searchable and easy to access (have you ever tried this in your Inbox?). Remember, it’s all about the business value, not just the last version of a published document - business value is realized through the creation and lifecycle of a document (content).

What is the solution? Simply put – collaborative spaces with document management capabilities. Google, SharePoint, OnBase, Documentum, you pick – just make sure it has notification, check-in/check-out capabilities and the ability to publish multiple major/minor versions of the same material.

Here’s a simple questionnaire to look at when crafting an email. If you answer YES to any of these questions, please consider a collaborative solution instead of attaching that document to an email.

* Is there more than one recipient for this message (that has an attachment)?
* Do you expect to receive feedback on the content (document) attached to this message?
* Do you plan on publishing another version of this content (document)?
* Will this material be used in the future by anyone in the organization?
* Will the context of the content/feedback be lost entirely if the email is deleted?
* Is the material stored on a file share or someone’s independent machine?

A Valentine’s Delivery Story

Today, as I walked away from my most recent engagement, I was reminded of what makes IT solution architecture and delivery enjoyable for me. It’s hearing customers rant about:

* Reduced operational costs
* Improved service delivery
* More effective use of limited interactions with constituents

Right? No. Sure, all of those were present after the solution was delivered but those didn’t top the list. Instead, here’s the one that got me:

“I’m going to give you a valentine!” - as stated by the person who had the longest list of pain points just a few months ago.

It’s not always about the 1s and 0s, or the 1s + the number of 0s behind it. Today it was simply about delivering a technology solution for someone to make her life easier.

CIO.com and iPhone/iPod Support

I was very, very surprised to find that CIO.com, the flagship website for "Business Technology Leadership" (that's from their site), didn't automatically detect my iPod Touch and re-skin accordingly. Now, CNN, ESPN and most other "mainstream" sites do this automatically so I don't have to be inconvenienced with constant strolling, but not CIO.

Reread their tagline - it's interesting (and ironic).

Great Analysts Do Solution

“Just tell us what you want and we’ll tell you how” - the old adage of “what” vs. “how” in the IT mantra.

Today I was reminded that effective (great) solution analysts do both.

[I think the architects just threw something at my head from down the hall]

Let me clarify a bit…

I don’t think that solutions analysts need to know the extreme interworkings of a solution but they had better understand the conceptual aspect of the solution, and, most importantly, know what it can and cannot do. You must be cognizant!

Take for example a custom-development system vs. one that is available off the shelf (SaaS more specifically). When eliciting requirements it is critically important not to lead stakeholders down a path that will be impossible to fulfill with the defined solution. (read: you’re solutioning with the team) So, if the winner ends up being a pre-built package then it’s important to know the boundaries as you’re dance with the stakeholders. Otherwise, there’s a solid chance that you’ll never be able to fulfill requirements that you pulled out of the stakeholders.

[I think the PM just threw something at me – we wasted time and irritated the stakeholders because we’ll never be able to deliver this functionality]

So, in summary, understand the capabilities and constraints of a solution early in the game – even in the requirements phase.

New Gmail Look

Literally, 10 minutes ago, I walked away from my laptop and had Gmail loaded in my browser. After returning with my hoagie, Gmail had a weird look. All the sudden - Gmail throws a nice box up at the top of my screen that says "Our look has changed, check out the available themes".

Awesome!

Not the themes, per se (although I do like them), but the fact that Google can roll out a major enhancement like this without an explicit and direct communication to all members. Can you picture how much discussion (and scrutiny) this would go through in corporate America?

Not Google, that's the beauty of their products - they roll it, tell you about it and most importantly - give you the ability to go back to the same old if you desire too. Now that's usability...

Oracle SOA Suite Training: Day 5

Security, policies, securing policies with processes and policies. Information overload at this stage, I gotta leave this one up to the Ops guys to handle.

Again, as I mentioned before - NFRs play a big part in this one.