This article covers the basic information you'll need to know about how your TeamDynamix implementation plan is built and used. Your team's Scope of Work is the primary reference doc for specifics about your implementation, but this will give you some high-level information about how the scope of work will be implemented.
Methodology
We use the Agile project management methodology for our implementation plans. Unlike more rigid methodologies that require each phase to be 100% complete before moving on to the next phase, Agile embraces change and continuous improvement through the project lifecycle. This allows our team to respond swiftly to things like shifting priorities, customer feedback, and emerging requirements during implementations.
High-Level Timeline
Implementation plans follow the general timelines below.
TDX Work Management Only
TDX Work Management & iPaaS
TDX Work Management & Conversational AI
TDX Work Management, iPaaS, & Conversational AI
Delivery Acceptance Criteria
At the start of the project, you'll determine who from your team will accept that TDX modules have been delivered as needed. They are usually one of the following or a combination of the following project members:
- Primary Administrator
- Project Manager
- Project Sponsor
Once those participants determine that the TDX modules have been delivered as needed, the deliverables will be accepted.
From there, we'll check off the deliverable from your TDX project cardwall.
Communication Rules/Tools
Communication about implementations will happen primarily thorough your TDX project portal on TDClient. You can log communication there via email.
- Normal Communications: TDX Project Portal (TDClient), Email
- Emergency Communications Only: Text/calls
Unless otherwise specified, no other communication tools should be used.
Resource Management
At the beginning of each Readiness session or week/sprint/iteration/cycle, work will be distributed from the backlog to the assigned individuals by the client’s project manager. That work is reviewed at the end of each week/sprint/iteration/cycle to decide if it can be checked off, added back into the backlog, or transitioned into the next week/sprint/iteration/cycle.
- If a resource can’t engage in a certain week/sprint/iteration/cycle, they will communicate that to the client AND TDX project manager with at least 2 week’s notice.
- TDX consultants will also communicate with at least 2 weeks notice if they are unavailable for more than 1 business day in a row.
Risk Management
Risks will be tracked inside of the TDX Risks Register by both the client project manager as well as the TDX consultant.
There are two types of risks:
- THREAT: A group’s culture is not always amenable to rapid change, which can make the adoption of new tools/processes difficult or even impossible.
- The strategy that we will employ is to engage in change enablement tactics to engage stakeholders as often as possible to maximize ownership and engagement
- OPPORTUNITY: Key processes can sometimes be changed more easily during a tool implementation because stakeholders are already open to the idea of change coming.
- The strategy will be to engage Executives/Sponsors to identify critical processes, and how they must be improved to meet the latest needs
Review these articles for other implementation risks to be aware of:
- List of Professional Services modules: For a description of the Professional Services modules and more information on them and the most important risks to consider.
- Implementation Gotchas: See this KB for TDX Work Management implementation wide risks that we have assembled from several other implementation closure calls over the years.