Blueprints are one of the most useful features in Wrike. They are one of the things people set up once, build too much into, and then stop using if they become too complicated. The consistent theme across teams that use blueprints well is to keep them manageable and simple.
Location matters before anything else
The first decision with any blueprint is whether it stays at the account level or the space level. Account-level blueprints are available to everyone across the whole Wrike account. Space-level blueprints are only accessible within that space.
This determines who can use it and who can manage it. A blueprint relevant to only one team belongs at the space level. Account-level blueprints should be reserved for processes used across the organisation.
Organise your blueprint section with folders
Before creating any blueprints, organise the blueprint section with folders. Describe the folder structure clearly with separate folders for each sub-team, like Content, Creative, Digital, and Events.
That way, when someone needs to find or edit a blueprint for a specific team, they know exactly where to look.
You can create a separate folder for request form blueprints, named with a z_ prefix so it sorts to the bottom alphabetically. Inside it, have a subfolder for each request form named consistently. Blueprints tied to a specific request form are cross-tagged into both the team blueprint folder and the corresponding request form folder. A problem with a blueprint that a form is triggering can be found immediately without searching the whole account.
Wrike’s blueprint section has a text-based search function for looking up blueprints by name. This is useful, which makes consistent naming even more important. Blueprints not named something obvious will not surface in search.
Duplicate before you modify
Before making significant changes to any blueprint, duplicate it first. Modify the copy and test it. Delete the original only once the new version is confirmed to work correctly.
Blueprints are the source of truth for all the work launched from them. A mistake in a blueprint can create incorrect tasks across multiple projects before anyone notices. You are editing the main source of truth, so be sure before saving.
Do not make them too complicated
Blueprints can hold enormous complexity, but overly detailed blueprints create more work when launching projects if people have to delete tasks that do not apply.
Build blueprints with the essential, non-negotiable steps. The things that happen in every single instance of this type of project. Encourage teams to add their own tasks once the blueprint is deployed.
Design the process before you build the blueprint
Before opening Wrike, map out the ideal process using a diagramming tool or on a whiteboard. Define for each task the timeframe, the responsible person, task type, possible statuses, dependencies, and custom fields. Once the process is clearly mapped, build it in Wrike.
This prevents the situation of discovering halfway through building a blueprint that the process was not fully thought through, and then having to rebuild it. It produces cleaner blueprints since every decision made is intentional.
Review them regularly.
Blueprints can go stale. Processes, team structures, and tools change. Make it a practice to review blueprints regularly and work with the teams that get assigned tasks within them to make sure each blueprint still covers all the right action items.