Vendor ProjectsThe 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.
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
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-WinThe 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
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!