What to Implement in Tridion First?

In a case of role-reversal from Functional Consultant to Product Manager, I'll soon have opportunities to prioritize development tasks.

I've told customers they might (should) prioritize based on their market/product/content strategy. For example, a client asked how to prioritize their website redesign from a Tridion perspective. After giving my feedback, the client pointed out my advice differed from my project manager. Oops.

• My Project Manager said to prioritize by difficulty.
• Separately, I suggested prioritizing following content strategy.

I was saved by the fact we were both correct from a CMS perspective. Combine perspectives to get some sagely advice:

Implement the harder, complex, and critical parts early. Use content strategy and business value to choose between tasks of equal complexity.

Use a top-down/outside-in approach to manage buildable sets of work for your sprints focusing on the hard, critical parts first.

1. Global “page template” elements (global navigation, footer, etc.)
2. Main editorial content and your main page/content types
3. Shared functionality that are not on all pages

Without page templates, you don't have pages. Without content, you don't have content.

Your content strategy is aware of quantity as seen in a content matrix, inventory, and/or sitemaps. From a CMS perspective there's value in “templating” something used 100s of times.

Remember that business value and metrics aren’t necessarily the same. Focus on the popular parts and perhaps postpone elements that don’t help your customers. Convince business stakeholders using numbers, customer feedback, and research.

In practical terms:

• Gather the latest site map and content inventory information—reports or the previous spreadsheets.
• Find or get in touch with whoever owns analytics (“hey, is this page popular?”).
• Add this to an outline of the FDD or whatever document manages your deliverables (work breakdown structure, Gantt chart, or agile board).

In the end, the advice was simple if not necessarily easy: prioritize according to your strategy. The hard part now is that I'll have to take my own advice for a change. ;-)

Example SDL Tridion Sandbox Proposal

I've written about Custom Training, the "sixth" SDL Tridion environment. But I almost forgot that I created a mock plan for such an environment as part of a course project before joining SDL back in 2010.

See the document below for a modified submission for a Web Design class I took at University of Phoenix four years ago. We were encouraged to submit projects that reflected our jobs and this demonstrated things I knew (and didn't know) about Web development and SDL Tridion (R5.3 at the time). I got somethings right and others not quite right.

Got Right

I got some things right like project documentation basics including an informal project plan, problem statement, and objective. I had an informal concept of personas by describing developers and management as the "target audience" for this mock proposal.

I included a content inventory of sorts under a section called pages and suggest separating design, content, and functionality concerns.

There's both a simple wireframe and a sitemap documenting the example site and even some notes on accessiblity, copyright, and source control based on research projects and things I've learned as an "IT professional."

I described "page types" without actually calling them page types.

Four years later and it still looks like a typical wireframe. The example screenshots are a bit dated though.

Not Quite Right

Tridion and Technical Debt

When updating Web content management (WCM) systems, the implementation team has an opportunity of paying off technical debt.

How?

There are a few ways to improve an existing WCM, either by offering more structure, flexibility, or paradoxically a little of both. For example you can:

• Separate code from content
• Improve the author experience
• Improve the design experience
• Simplify maintenance
• Improve the user experience
• Improve scalability
• Offer more options while simplifying the default choices*

*For an excellent treatment on improving the user/human experience, see Nudge: Improving Decisions about Health, Wealth, and Hapiness. 

Technological debt refers to design or implementation choices that have a relatively low cost up front, but cause significant issues in the future.

Tridion as a Culprit?

Could Tridion itself cause such debt? Sure. It depends on the design choices and trade-offs.

For example, implementing a mismatched BluePrint, creating confusing schema, or skipping training can wreak all sorts of short and long-term havoc with a Tridion implementation. Also, upgrading too soon or too late with any system vendor has its own trade-offs. Btw, Tridion's complex because of customer's sophisticated needs. No, I'm not being sarcastic, stop grinning. Really.

Avoiding Technological Debt

As developers we refactor code, review approach, and evaluate better implementation methods. When working on business and system requirements we balance business wants with system needs and include both user and IT perspectives. At its core, we reduce debt by planning for, anticipating, and designing for the likely-to-change  parts of our systems. Though you might smell best practices, I see practical patterns.

Easy != Simple.

Just because something has a GUI doesn't mean you don't have to perform the same due diligence. For example, although schema creation is "easy," we should apply the same rigor to avoid technological debt.  Before creating schema, be sure to understand linking propagation, the importance of author-friendly schema names, what types of fields to use, how field order impacts authors, how to properly use Categories and Keywords, BluePrinting, templates, and the difference between page metadata and page-related components.

Organizational change is so hard, some call it change leadership. But while you're investing in Tridion or any other significant implementation, it's a good opportunity to pay down technical debt. If you choose to take on technical debt, do so conscientiously in a way your team can live with.