This article describes a reference example for how to use a project record in TeamDynamix, where the project is significant in size and needs “full” project management.
Preparatory Configuration
Types
Types generally correspond to the core work of the implementation: A “third-party integration” type, for example, vs. an “ERP upgrade.”
A type called “Other” would exist for projects that do not fit any other types. These projects are reviewed to consider whether new types need to be created.
Classifications
Used to set the level of project management overhead required. Consider having an additional classification for “non-project projects” for work that will be tracked as a project record.
For actual projects, here are two options for classification:
Classifications as Tiers
“Tier 1,” “Tier 2,” and “Tier 3” classifications that are documented to require different levels of project management. A “Tier 1” project might require communications plans, whereas a “Tier 3” project might not.
Classifications as RUN/GROW/TRANSFORM
“RUN,” “GROW,” and “TRANSFORM” classifications that correspond to the strategic purpose of the project. These classifications also identify the level of project management overhead: transformative projects typically require much more risk management, for example.
Statuses
When defining statuses, be careful about statuses that are more about the deliverables than the project itself. For example, sometimes one deliverable from a project is in Testing while another deliverable is still in Development.
Triggers/How the Project Record is Created:
Ideally the project record would be created from a project request that has been reviewed and staffed via the Portfolio Planning application.
Initial Project Setup
Project Fields
When the project record is first created/staffed from a project request, the below fields would be populated:
|
Field
|
Value
|
|
Project Name
|
Name that makes sense to end users/clients
|
|
Sponsor
|
Primary person authorizing the project, usually at a Director level or above.
|
|
Acct/Dept
|
Primary department requesting the project.
|
|
Type
|
See “Types,” above.
|
|
Portfolio(s)
|
Only used if the organization is practicing Program Management.
|
|
Classification
|
See “Classifications,” above.
|
|
Priority
|
Not used.
|
|
Start, End Dates
|
The absolute first and last days that any project work might be performed. Err on the side of too much time rather than too little—this affects the time windows when you can allocate resources, for example.
|
|
Health
|
Green = OK
|
|
Description
|
Description that makes sense to end users/clients.
|
|
Requirements
|
Key things that must be done for the project to be considered complete.
|
|
Total Estimated Hours
|
Use only if you are doing resource planning.
|
|
Time Budget
|
Use only if you are doing resource planning and billing for time.
|
|
Expenses Budget
|
Use if you want a top-line summary of project expenses.
|
|
My Total Hours
|
Set to 0
|
|
Mode
|
Standard project
|
|
Client portal visibility
|
Visible only to users on the project/listed as stakeholders (the default)
|
|
Time and expense approval
|
Approved by individual’s manager (the default)
|
|
Update Task Method
|
Users set % complete (the default)
|
|
Resource Management
|
Manage By Project (the default)
Only switch this to Manage By Plan if you are fastidious in your project plan updates.
|
|
Resource Schedule Editing
|
Do not allow resource pool managers to edit schedules (the default)
|
|
Update start/end date based on project plans
|
Set this if and only if you have set “Manage by plan”
|
|
Add all new project members to the project contact list
|
Yes (the default)
|
|
Allow project-level time entry
|
Yes
|
|
Notify me when assigned, estimated hours exceed
|
Yes (the default)
|
|
Resources
|
Set to all the people allocated to this project—anyone who might be assigned an issue, task, or risk for this project.
|
|
Components
|
Mark the components you will use. It’s OK to leave them all on.
|
“Manage” Sections to Use
For an active project, use the below sections:
|
Section
|
Description
|
|
Project Details
|
Use for regular project status updates as described below.
|
|
General
|
Use as described above.
|
|
Expenses, Time Types
|
Use only if you’re tracking time & expense.
|
|
Resources
|
Use this for people who need to interact with the full project (e.g. to see/update tasks, issues) in TDNext or TDClient.
|
|
Stakeholders
|
Use this for people who need to see the project summary in TDClient.
|
|
Components
|
Use this once as described above.
|
|
Status Chart
|
Use this if needed for historical reporting.
|
|
Baselines
|
Use this only if you are taking baselines.
|
All other sections may be useful, but they are either populated upstream in the portfolio planning process or they are duplicated by project components.
Apply Templates
Go to Manage > Project details > Apply a Project Template and apply any relevant template(s) for this project.
Components to Set Up
Briefcase
Set up any folders plus add any initial documents, e.g. if you have a signed project charter.
Contacts
Add any third-party vendors or other key contacts you know about.
Issues
Create/review issue categories. Common categories include “Question,” “Bug,” “Backlog.”
Risks Register
Create/review risk categories. Common categories include “IT risks,” “Institutional risks.” Load any risks from the project charter/etc.
Plans
Identify whether you’re going to use a waterfall plan, card wall plan, or a set of plans. There is no one right way to do this. As a couple of options:
One Waterfall Plan
This is the most traditional type. Create a waterfall plan, usually starting with building a work breakdown structure (WBS) and then defining and sequencing activities.
One Card Wall Plan
This is a very simple way to manage project tasks and can work well when team members have a good understanding of how to perform project tasks, there is a low degree of interconnected/dependent tasks, and/or it is less important to deliver an exact schedule for the project.
One Waterfall Plan + Card Walls
Here a waterfall plan has the summary view (e.g. with phases and high-level timelines). One card wall plan then exists for each phase/iteration.
Backlog Card Wall + Iteration Card Walls
Here a backlog card wall has lists for backlog definition, going from “idea” to “ready for scheduling.” Cards are moved into plans for each iteration as the iteration gets close to starting.
Key Project Activities
Project Team Expectation Setting
The project manager, perhaps as part of the kick-off meeting, sets expectations for the project team on how TeamDynamix will be used. Ideally this highlights the benefits of using TeamDynamix along with the expectations.
Project Updates
Once a week, the project manager reviews the project and writes a short summary update using Manage > Project Details > Update. This update includes an updated percent complete, updated health, project status, and update description.
Project Reviews
The project manager reviews the project plan and issues, looking for overdue or soon-to-be-overdue items. The project manager escalates these as needed, starting with using the item’s feed. For example, if Task 123 is not yet complete, the PM opens the task and adds a comment where they notify the owner of that task.
Project Closing
The project manager confirms that all work is complete, and the project is closed. The project manager goes to Manage > Actions > Close project and closes the project. The project manager leaves the project active, so that it can still be accessed for a few weeks. Later, the project manager (or someone else) deactivates the project.
See Also