We sometimes learn our tools and trade from others or in formal training. For software systems we have services, documentation, support, and community-contributed online information. What happens when you inherit some system, though? For example, maybe you've been assigned as the SDL Tridion contact for either business or technical issues and you're not sure where to start.
Well, here's my list to someone stepping into such a role.
- Review the official materials. Software purchases include a license agreement and support details as well as the original purchase order and any statements of work. This gives you the official agreement between the vendor (SDL in this case) and your company. This is part due diligence, but you might be surprised to find potential benefits in features that weren't implemented in "Phase 1."
- Read your documentation. It's worth tracking down a few important pieces including:
- Functional Design (including the BluePrint diagram and design)
- Technical Design
- Architecture Design and related diagrams
- A (the) new developer for the platform?
- Vendor contact, handling questions down to tickets with the vendor?
- Serving a business or business analyst role
One final tip if you are part of the team managing the system:
I've taken for granted in setups where I was there from the start is I knew what we wanted to build. Coming into a new environment, you don't know what the challenges were or why a system was set up in a certain way. So you won't know what a specific field in Tridion does without checking simply because it depends on how the original team built it.
And that could be a surprise and possible opportunity for you with a change in "ownership" for something like Tridion. The forms, approach, architecture, and setup are meant to be managed as well as be flexible enough to meet your needs, back when it was first setup and now with you on board.
Welcome to the community, fellow Tridionaut. :-)