The Doneness Matrix: A Project Manager’s Perspective
Whether the project is large or small, having a single place where all team members can assess what is in-flight and what is next in queue is a powerful management tool.
At EightShapes, we use doneness matrices to define and report project status. In one screen, we can see a project’s status, determine who owns the next step, and accurately predict the next stage of deliverables.
Nathan provides a detailed description of its design and implementation on his blog post. In this article, I share some of my lessons learned in using this tool for tracking completion.
EightShapes recently worked on an initiative that had multiple types of final deliverables: wireframes, visual design comps, redlines (visual design specifications), and HTML code. Each asset was dependent on completing and securing approval for the preceding track of work. To measure the progress of deliverables, approvals and due dates, we used a doneness matrix.
Our project team adapted the matrix to become our source for daily design status meetings. Reviewing current status and updating the matrix during the daily meeting with the team’s input kept everyone in lock-step. Since the matrix was a shared Google document, everyone could remain apprised of the progress.
In managing projects through these spreadsheets, EightShapes follows these guidelines.
1. Establish Meaningful Milestones
Your matrix tracks completeness of an initiative, based on the greater project vision or scope of work. Keep this in mind as you create your milestones, as they should be referencing the project requirements used by the extended project team (including non-designers). Translate these requirements into easily defined milestones.
For example, your project must deliver: wireframes, visual design comps, specifications, HTML. Identify each of these deliverables as milestones within your matrix. Include a target completion date with each element as it becomes defined.
2. Use a Common Language
Align your project plan to use the same terminology as your doneness matrix: common language is pivotal to the success of this matrix. Where possible, use the same language found in the business requirements document as on the project manager’s project plan. For example, if your project manager refers to “visual design treatments”, use that vocabulary instead of “design comps” or “screen designs” as the milestone.
Ensure that you are marching towards the same goal: the phrase “visual design treatment” could mean the package delivery of comps + specifications + css code. Subsequently, if you are tracking the phrase “visual design comps”, you are only tracking delivery dates for one of the three expected elements. Aligning your phrasing is a must for setting expectations of what will be delivered and by when.
If you’ve successfully used common language, all project stakeholders can easily understand what the next steps are towards completion.
3. Clarify Ownership
Define ownership of the matrix the moment your project team decides to proceed with one, establishing who will be updating the matrix and how often. Also identify the editor-in-chief. If each person on the team is responsible for updating their own respective status, identify that, and confirm with your team so everyone has the same expectation. After you’ve identified editors, determine your audience. If you’re using a shared document format like google spreadsheets, identify who will have “read only” access.
On one project, the UX lead owned the matrix. Our team met daily to discuss design status, and the lead used the matrix as the recurring agenda. The design team would walk through status updates, updating the matrix in real time. We all understand of who owned the matrix and how frequently it would be updated. As a result, the matrix became the source of design status for everyone, even those not able to attend status meetings.
4. Update Constantly
Once you’ve set up a doneness matrix on your project, it must become a living document. The quality of the information presented is only as good as the quality of information that’s tracked. In other words, keep your project status up to date as often as possible. If the information is out of date or stagnant, the matrix quickly looses value.
Keep everyone aligned by scheduling a recurring 5-10 minute daily meeting with your team to ensure they’re up-to-date on project status. Using the matrix as the agenda will allow the matrix owner to make updates as the project progresses. Having the daily meeting on your calendar will serve as a reminder to refresh the matrix.
When working with your project stakeholders, regularly review the matrix with updated status. Encourage the greater project team to consult the matrix for status before and/or after they begin working on dependant tasks.
How I’ve Used the Matrix
The Doneness Matrix is only as useful as the information it’s tracking. Sometimes you need to modify the format slightly to account for individual project variations. For example, to accommodate varying priorities of different milestones, we included a priority column that helped us identify which elements were needed before others. While reviewing the prioritization column with our stakeholders, we were quickly able to align our expectations for which elements we would deliver, and in what order.
On a recent project, our team worked to redesign how page components re-size, depending on the browser size. Because this project was re-architecting the existing components that were in production, we updated the matrix to include a column for an inventory reference, comparing the new components to existing ones. As we completed the designs, the developers could align the redesigned component with the original elements.
Even with myriad approaches to reporting status, I come back to the matrix again and again. By focusing solely on doneness, the matrix avoids incorporating information that would distract from the essential message. It is easily accessible document that keeps the team moving toward the same goal: successful completion.