What's Wrong With a Tridion Project Plan?

Technology supports your business. Not the other way around. No matter what system you're implementing, focus on your project goals and objects with the business opportunity (challenge) in mind.

Vendor Projects

The most visible and trackable results in anything project-related are the deliverables. These take the form of those "zero-length items" in your plan (MS Project and some Gantt chart tools use diamond shapes) that mean some objective has been met. Vendors might refer to them as toll gates but your project managers might opt for objectives or milestones. Bonus if you know the difference. I don't care what they're called, someone needs to keep track of them.
Your vendor will understand the deliverables they're responsible for very well; any professional services type organization does this type of work over and over again. What they can't replace, however is understanding your business opportunity or challenge. Vendors can help guide you in discovering your business requirements, especially if in a new domain. But customers are still responsible for the results of their project.

What's a Tridion Project?

Unless you're in the business of enterprise systems (specifically on the R&D side), hopefully you don't run into projects with "<insert product name>" in the title. For example, the following CMS-related names would be better than a "Tridion Project:"

• Web Content Management Project
• Intranet Redesign
• Social Media Campaign
• Web 3.0 Alignment
• Some-Other-Objective-You-Want-to-Achieve

An idea from  Real Business of IT (Richard Hunter and George Westerman) should make this clear. You don't run a "Treadmill Project," you run an exercise program. There's a significant difference. You might even measure weight loss, but that would be a criteria or metric; not the project itself.

Even if the project name focuses on the product, you can still have a successful implementation when working towards a shared goal.

Win-Win

The best relationships are built on trust. The customer-vendor relationship that worked best from my perspective (with me as the customer) had the following characteristics. Your results may vary.

• Sales helps potential customer understand how they differed from the competition
• Customer provides clear business requirements, allowing vendors to showcase their strengths while being transparent on their challenges
• Both know the difference between features and benefits. Not all features are benefits.
• Both sides focused on a well-fitted solution, not just on profit or costs-savings

Tip: Buy a good fit with room to grow because it's not about the most fully-featured software package nor even the cheapest. It's all about a well-fitted solution. (from my  post on software licenses)

• Everyone understands the importance of training, it's in the budget, the statement of work (SOW), and the internal stakeholder or project sponsor understood this
• The right amount of services and training are included
• Deadlines, schedules, and resources are planned in advance and respected

Industry-wide software licenses include customer support, typically at a percentage of the purchased solution. Considering your total cost of ownership may dwarf initial resources and even deadline, it makes sense to get the right amount of implementation services up front. Yes, I'm biased being part of a professional services organization, but I've seen the difference when training and services are done sooner than later.

Preparation, documentation, and testing will help you met requirements, but don't skip training. In addition to easing the significant change a CMS brings, it can help you confirm user expectations and fine tune the system and services as needed. General content author training shouldn't be your only chance to vet the system design; but don't pass up on the chance to collect general feedback from your end users and possibly a well-versed trainer. ;-)

Okay, enough with the self-promotion. As a former-project, I wish you a successful project!