Give More. Get More.

As SDL Tridion MVP Selection Panel chair, Nuno Linhares has called others in the Tridion community to action and has recently blogged about the the art of knowledge sharing . He offers some reasons he's had to not share (knowledge = organizational value, faster to solve than teach, and fear others will steal) and compelling reasons to share (recognition, ability to scale, job/career mobility). I've seen both sides and share my background with sharing below. I'd like to add that sharing can be scary, especially when you're not sure of how a message will be received or confident in what you know.

I've enjoyed everything from mentor roles to being seen as "the guy who does too much" to being called arrogant and immature, so take the following from the perspective that I've done okay so far, I believe in the value of sharing in your chosen interests and industry, and I have a lot more to learn and grow.

I've found career and personal satisfaction from creatively contributing in authentic ways (yes, I'm a fan of Seth Godin's Linchpin). In terms of knowledge transfer and sharing, I've been "rewarded" with bigger and better projects the more I gave old projects away.

As a Web-development-intern-turned-researcher, I've reported on everything from software development tools to industry news to competitive assessments. From screenreader software that read websites to blind users to enterprise-level content/workforce management systems, I received bigger and more interesting prompts the more I put into the research.

Gave away Roles. Got new Roles.

Also known as "I killed my previous job" through sharing or intentionally making myself obsolete.
I helped train other interns, explaining everything from laptop setup to who's the right person to ask what question. I eventually helped the development team select their Web Content Management System (WCMS). Fascinated by the chosen solution (Tridion R5.3) and eager to learn, I effectively killed my previous job of manual Web content updates, HTML edits, and SQL scripts; I still apply these skills but in somewhat more interesting situations.

I got a new role as a business analyst (BA) to support the WCMS and continued to help end users and developers. I learned from, and then contributed on, the Tridion forums (enough to win a nifty, sharp, and deadly-looking SDL MVP award).

I documented everything from user guides to system diagrams to requirements and encouraged others to update and share their own write-ups. I offered expertise when requested (and sometimes when it wasn't!). This coincided with another shift in responsibilities towards vendor/partner implementations and a promotion to a (cross-functional or "weak matrix"... just so you understand I wasn't directly leading teams) project manager (PM).

As a PM, I was able to leverage vendor evaluation skills learned from WCM in a WFM (workforce management) assessment and eventual implementation. I've enjoyed the role, but missed the collaboration with the solution and community that helped shape my career.

Sharing your way into New Ventures

In terms of that intersection of skill, will, and motivation I've found a sweet spot between these various "jack-of-all-trade" roles of BA, PM, and resident Tridion subject matter expert; I've applied for, and accepted a new position as a functional consultant with SDL Web Content Management Services (professional services) (My site disclaimer still applies; this blog does not reflect the views of my current/past/future employer unless otherwise stated. I've accepted an offer but don't start for a few days.).

I owe so much to my previous roles and will always have love for American Specialty Health, but I'm looking forward to learning, growing, and sharing with my new team and helping other SDL clients.

Semi-final, random thoughts on sharing

  • Though I've played various roles, there is nothing wrong with becoming an expert in any given role. I'm not advocating leaving your existing job and the intention shouldn't be to "jump ship" as quickly as possible, but to transform our roles to include More Great Work (Michael Bungay Stainer).
  • Think big! There are lots of after-school activities where a single coach or instructor will attempt to help an elementary school. But what about a program that teaches teachers instead of a single classroom? How can we scale from classroom to district? From one company to several?
  • I've helped a development team, an IT department, a medium-sized corporation, and a community of Web content management customers. My long-term knowledge sharing goals include either contributing to an industry or combining current and past interests to offer something new.
  • I didn't plan or think I'd be qualified to join SDL. I believe knowledge sharing works better when you're authentic and genuine ("white hat" sharing preferred--I don't believe my specific "path" and approach would work if I only shared for personal gain). Daniel Pink's Drive confirms that rewards and incentives are more effective as "now that (you've done something good)" surprises rather than "if (you do this) then (you'll get rewarded)." I agree with Nuno--it only took a kind word or encouraging email to feel appreciated for sharing.
  • If you give a man a fish he eats for a day. If you post fishing video on YouTube you can reach thousands of viewers.
We share, teach, or advocate because we love a product, solution, or idea. If we're lucky and find that right intersection of an appreciative audience and fascinating topic, we can feel like the bee girl at the end of Blind Melon's No Rain. Well, at least that's the closest popular-media-metaphor for how I feel when collaborating on interesting projects or talking Tridion with other consultants.

Well, that's what knowledge sharing, teaching, and contribution has meant, and continues to mean to me. I'd love to hear your successes and challenges with your own attempts and sharing, advocating, and being an ambassador for whatever fascinates you.

Key-Value Lookup Example (Tridion R5.3)

The following is adapted from a post of mine on the Tridion World Forum (an account required which is available to Tridion clients). Key-value "lookup tables" can be stored in xml files to manage Tridion-related information such as identifiers (tcm ids) or  other not-so-friendly key names and their corresponding friendly values. For example, rather than hard-coding unique Tridion identifiers for each environment, we can output a text-based configuration file. This simple example highlights re-use, separation of layers, and ease of content (re)creation.

1) Ordered Pair - embeddable schema Consisting of two items:
  • key (text)
  • value (text)
Description can be first and second item, with mention of "key" and a friendly name. This could even be localized to match the needs of a given publication and/or (end-user) language.

2) List of Ordered Pairs - schema Consists of one item: ordered pair (the embedded schema above, allowing multiple values) (also give this a useful namespace such as: 
http://www.example.com/schemas/listorderedpair)


3) Key Value XML Output - Component Template (XSLT)
(match the namespace above, the names space will differ in different versions of Tridion)

<xsl:stylesheet version="1.0"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 xmlns:tcm="http://www.tridion.com/ContentManager/5.0"
 xmlns:xlink="http://www.w3.org/1999/xlink"
 xmlns:tcmse="http://www.tridion.com/ContentManager/5.1/TcmScriptAssistant"
 xmlns:listorderedpair="http://www.example.com/schemas/listorderedpair"
 exclude-result-prefixes="xsl tcm xlink tcmse listorderedpair">
<xsl:output method="xml" indent="yes" omit-xml-declaration="no" />
<xsl:template match="/">
  <values>
    <xsl:apply-templates select="/tcm:Component/tcm:Data/tcm:Content/*" />
  </values>
</xsl:template>
<xsl:template match="*">
  <xsl:for-each select="//listorderedpair:orderedpair">
    <value>
      <xsl:attribute name="key">
       <xsl:value-of select="listorderedpair:key" />
      </xsl:attribute>
      <xsl:value-of select="listorderedpair:value" />
    </value>
  </xsl:for-each>
</xsl:template>
</xsl:stylesheet>

4) Ouput Generic XML - Page Template (VBScript, but any templating language can work)

[% 'this outputs a physical xml file
'component and corresponding component template that outputs actual xml via XSLT is required
 for each comp in page.componentpresentations
   writeout comp.content
 next

%]

To create the lookup XML file after setting up the embeddable schema, regular schema, and templates, first create a component based on List of Ordered Pairs. Then create the page, add the component (+ template = component presentation), and publish. The resulting file will look like:
<values>
 <value key="1">First Value</value>
 <value key="2">Second Value</value>
</values>
This example can relate  friendly names to their programatic equivalents. This can work in other scenarios and can serve as a general content-to-physical-xml file example.
If you've ever needed to make a quick and robust interface for this type of configuration data (or any content), a WCMS like Tridion can easily handle anything from the node and attributes values in an XML to rich-text, multimedia, and more complicated sets of content. 
Other use cases:
  • states and state abbreviation list
  • departments and abbreviations or codes
  • Tridion items and their tcm-ids (ids would be hardcoded, but example could be adapted to link to items directly)
  • other mappings for external databases or information
A few of these could be handled via web services, custom code, or other Tridion integration points. However, a lot can be done with Tridion's out-of-the-box functionality. Please feel free to leave suggestions, clarification, or questions. I'll likely overhaul this with a Tridion 2011 treatment as well.

Lessons Learned from WFM

In a previous role, I helped work research, purchase, and implement a call center scheduling "Workforce Management" (WFM) solution. WFM is software that helps call centers schedule their agents based on historical data as well as monitor real-time adherence to the schedules. Like other software that brands itself "enterprise" it includes integration with other systems, key-performance indicator (KPI) reporting, and dashboards. The particular package from Verint systems included shift-bidding and ELearning features.

Playing the role of cross-functional (weak matrix) project manager on the client-side, we compared vendors, used Gartner research, did several demos, and completed procurement (including the paperwork trifecta of order form, master services agreement, and statement of work or SOW) over a few months.

Here are a few things that validated concepts I've learned from PMBOK, school, and personal experience with other software purchasing situations.

During research, it's important to focus on the business needs over technical benefits, but make sure the solution is supportable and approved by IT.

A vendor may present a list of deliverables (SOW), but keep your own milestones, schedule, and success criteria. Though supported externally, it's still your project so it must meet your own objectives.

Technical issues need to be addressed and prioritized with the business owners, technical team, and third-party vendors. Large issue affect multiple stakeholders differently. When in doubt, ask!

Managing expectations and getting the right (amount of) information to the right people is a large part of the project management and purchase evaluation process. I don't envy line managers in the amount of data they have to handle.

Try to separate the technical issues from project progress; but don't hesitate to hold your vendors ("sellers" in PMBOK parlance) accountable to project goals.

Above-all, a positive focus on how to make the project work has seemed to be more productive than keeping tally only to blame someone later. Definitely track issues, but approach them with the vendor and other parties cooperatively.

Whatever the service or software, it makes sense to focus on the mission and work with the other team while still holding your partner accountable.

Good luck with your next implementation!

Tridion BluePrinting Use Case

I prefer the acronym WCMS. Coming from a Web development and IT background in a healthcare-related company, "CMS" means something completely different.

Here's a use case for Blueprinting and localization for websites that need to be reviewed by external reviewers such as Centers for Medicare & Medicaid Services (CMS). I had a chance to run the scenario by Tory Johnson, a Tridion Professional Services consultant (who earlier identified better ways to use the Tridion 2011 Criteria Objects). He gave me the impression that my following setup might work (or at least confirmed I know a little bit about BluePrinting technology), but do see caveats below before trying this at home... er work.

But first some background and terminology.

Tridion BluePrinting

The Tridion BluePrint model allows developers, designers, and content owners the ability to create publications (collections of content, templates, and functionality) that share (think inheritance... sort of) content, style, or behavior. The BluePrint consists of parent and child publications where content is shared down from parent to child. BluePrinting may mean different things to technical audiences versus the business.

The Tridion localization feature is very important to BluePrinting.

Content Localization

Localization is a Tridion feature that lets you create a "one-off" version of an item, that is then shared down the BluePrint hierarchy. This item will have (almost*) the same Tridion content management identifier (tcmid), will be linked from the same components, but will no longer (automatically) share the same content from its parent publication. After localization, the item will keep its own history and can be updated independent of its parent item.

*The publication part of the 3-part ID will differ between the shared item's tcmid in different publications.

BluePrinting plus localization makes Tridion a strong fit for scenarios where you need to deliver content in multiple languages or targeted to different regions. But it's more than that, a well-designed BluePrint lets teams take the "component + component template = component presentation" concept all the way up to the publication level, where "Content Publication + Template Publication = Website Publication." Read on for an idea I worked on for a colleague (and yes, he gave me that "what?" look after we set it up).

Review Scenario

If you maintain a near-duplicate website for internal or external review, a simple solution is to simply publish content to the site. When it is approved, you can then publish this to the live site.

There's a problem, however, if you have a site that needs to be more than just website preview or user acceptance testing.

For Medicare (CMS) reviewed websites, there are restrictions on what content can be released. In this type of controlled scenario, only minor typos and select non-reviewed content are published to the Live site without CMS approval (from the technical side I'm not really sure what needs to be reviewed--the business side knows more, but this setup lets them pick-and-choose what and how things get updated).

Rather than having editors use versioning or edit history to control what gets published, a separate publication, higher in the blueprint can be used to separate the new yet-to-be-approved changes for the next iteration from the current live site.

Assuming a year-long iteration that begins in the New Year ("1/1 as a date is a hard deadline for many health or benefit-driven programs"), we start off with two publications:
  • Review Website Publication, which is a parent of...
  • Live Website Publication
In actuality we wouldn't use "Live" for the publication name since it might be confused with the live www. website or with the "Live" publication target (which publishes to the live www. website). Since the BluePrint is listed alphabetically, you might have names like "0035 MySuperMedicareProgram (CMS-Review)" and "040 MySuperMedicareProgram."

When the blueprint is first set up both sites are exactly the same. Review (this is not Preview) and Live have the same content shared down through the BluePrint.
  1. To create the CMS Review site, everything is set up the same as the Live site and all currently Live content is published.
  2. To make changes for approval for the next year, content owners determine the type of change:
  3. New

    Proposed content, new layout, and major changes can be made by first creating the proposed change (or localizing the Live Website version first if the items exist) and then publishing the changes. These new items shouldn't be published to the Live Website until approved and any localized items will keep their old approved versions unchanged regardless of how many revisions the Review Website goes through.

    Fix in Both

    A "must fix immediately" minor typo can be updated in the Review publication and published from Review and again in its child publication. If this typo fix applies to something that has been localized, content editors would update the Live Website localized item, then manually make the same correction to the Preview Website "proposed" item as needed.

    Year-End or Approved

    When CMS (Medicare) approves a change for the Review Website Publication, the content owners and their developers would:
    1. publish new items that don't have shared localized versions
    2. unlocalize items in the Live Website Publication, which will wipe out any localized edits and replace the items with their Medicare-approved versions
    3. publish the now-matching (unlocalized) components to Live and start over with both sites matching
    A content clean-up and a review of which items never received approval might also be helpful after the go-live date. :-)

    Issues and Caveats

    I helped set this BluePrint change in a production environment, but have not seen how it works in practical use (I've since changed teams a few times and haven't heard any issues--which strongly suggests it's not being used). The concept is sound, but I suspect there would be issues with the following.
    1. Training -- when should you localize (probably everything in the Live Site at the start of the year or iteration, but always before an edit)?
    2. Troubleshooting -- with content coming from two or more places, the ability to localize at different levels, and the fact that content owners sometimes forget to publish, I can imagine a few "hey, my page doesn't match my last change" type emails.
    3. Support -- a Tridion BluePrint really needs to match the needs of the content. Apparently some organizations want to set up a BluePrint to match an org chart (really?), which is friendly fodder for another blog post. Like any other powerful and flexible technology, BluePrinting shouldn't be underestimated and it isn't something typical business analysts, programmers, or other support roles would understand right away. It's not quite inheritance, nor do the terms "share" and "localize" do it justice.
    Watch out for confusion or misunderstandings around:
    • Preview vs Review
    • Tridion Publication versus Website
    • The word "Publish" (component? page? .NET site?), but this isn't unique to BluePrinting!
      Terminology (feel free to point out any inconsistencies above)
    If you have internal content owners publishing content for Review's Preview before it gets published to Preview's Live for CMS review of the WCMS-enabled content before it ever goes out to Live's Preview and Live's Live site, someone is bound to become confused.