How do you manage Wrike governance in your organization?

We're almost a year into our transition to Wrike and have entered what we're calling a "Maturity Interval" while our teams get acclimated to the system, build the habits and practices of recording their work, and identify their additional training/support/reporting needs.

I am the primary Wrike admin now for our organization and I run a Wrike Governance practice as follows...

A weekly Wrike Governance meeting with all our project managers and interested team leads
A request form for major Wrike changes at the account level (like configuration changes, new org-wide processes/practices, etc.)
A recurring task for the weekly meeting that captures agenda items and notes.

Any requests for Wrike changes get run past the Governance group first and we schedule a breakout session if needed for deeper discussion.

Agenda sections, though I will switch up the order we discuss them as time requires:

Completed changes
In Progress changes
New change requests
Wrike Platform updates (yes, I include a link to the Weekly Update forum here)
Any other Wrike-related topics needing discussion by this group

How do you manage Wrike governance?

Find more posts tagged with

Comments

Anna Grigoryan

Thanks for sharing this! We have just formed a cross functional group to meet regularly and have best practices around maintaining and governing the account. Standing topics of discussions are

- Plan to clean up one of the configuration elements, such as request forms, workflows, spaces, CITs etc

- Discuss implementation of newly released features across the org.

Now based on your post I will also include a topic to discuss roll out of any new process in individual departments.

Thanks for sharing!

Cynthia Sperry

Oh, one more big component:

The Wrike Change request form creates a project item and that triggers a blueprint item to be created inside it: my Wrike Change Checklist. It takes me through the following stages (bold) more or less in sequence with checkboxes (individual bullet points below), which get expanded or struck-through as each stage generates new information.

1. Admins: Could this change be met by a field or function already in use?

Check the Custom Fields list
Check the Automations list

2. File a change request in the Request Form

3. Admins: Consider the implications of the change for…

User training
Communications
Retroactive changes (updating field contents etc.)
Request forms (refreshing custom field contents, mapping, branching logic, etc.)
Reporting
Permissions
Architecture

4. Review the change proposal with the Wrike Governance Team.

Decide whether sandbox testing is needed
Check assumptions
Seek external insights / reviews

5. Decide whether advance warning of the change is necessary. If so, make announcements as appropriate.

6. Actual Change Details (usually direct links to the tasks inside the project)

7. As the change is made, ensure that the following areas are updated (as necessary) to reflect it:

[internal channels] Announcement
Consider an email to all staff
User support materials
User trainings
Project Management Team training for user supports & reporting
Reporting (filters, fields, etc.)
Request forms
Retroactive content updates

8. Update project documentation and close work items relating to the change (including the change request project itself)