Some years ago, a local builder here in Seattle was taking me through the project plan for my new house. This plan was a work of art, as its structure supported the conversation between client and project manager extremely well. I was fascinated by their approach and the clarity it brought to the process for three reasons. First, I actually understood all of the major steps in the project without needing a quick reference guide, color key or training. Roof, drywall, flooring were all readily understandable and verifiable steps. Second, the progression of work was crystal clear as is was structured around deliverables that I could see and where dependencies made sense. I knew that painting wasn\u2019t going to happen if the drywall wasn\u2019t finished. They didn\u2019t have to call that out for me in the meeting. Lastly, hard deadlines stood out and made sense as you understood the context. The last date for paint color changes preceded the day the paint was ordered. The other amazing aspect was that it was simple or at least it seemed that way.\nDesigning the project plan for your stakeholders\nCould any of these adjectives, simple, logical or effective be used to describe your project plans? If not, chances are the project plan was designed and standardized by the PMO for the PMO\u2019s needs. If the first task on your project plan says Phase 1 or Stage 1 or some other process step, you have a project plan designed for the PMO, not for the stakeholder, project manager or the project team.\nStakeholders usually don\u2019t care about your PMO process. They want to know when something that impacts them will be delivered, implemented or done. The project team needs to know where they are within the work plan so that they can adjust their efforts accordingly. The Project Manager needs the plan to support clear communication of progress. Project structure should be facilitating those conversations rather than simply supporting the PMO reporting needs.\nObscuring the truth with a process-centric project structure\nThe PMO isn\u2019t being intentionally evil. They are trying to solve their own legitimate information problem. However, encoding information into the structure of the project plan is inefficient and has bad side effects. Symptoms of this approach include process-centric tasks or instructions to project managers that \u201cthou shalt not change the structure of the project plan.\u201d It doesn\u2019t have to be this way.\nThere are two major issues with this structural encoding approach to projects. First, it creates significant impedance to the conversations that it should be supporting. It\u2019s a bit like asking your teenager about their current whereabouts and they give you their GPS coordinates. It\u2019s technically correct but not as clear or readily understood as Kayla\u2019s house. Second, it makes extracting information from the project plan for various uses much more difficult.\nData has interesting properties which you need for reporting. However those properties now depend on that data element\u2019s position within a hierarchy to derive the meaning. Obtaining meaning from the hierarchy is nearly impossible to extract efficiently. Explicit metadata tagging of data elements is much more effective.\nLearn from other technical areas\nIn the early days before search, you created long filenames in hopes that you would be able to locate the document later. You were encoding information into the file name, thus mixing data with structure. Some companies had elaborate naming schemes for all of their documents. There were people dedicated to ensuring the rules were followed.\nMetadata was later introduced, allowing separation of information from the document structure. You could tag a document with any tag for any purpose. Now, a single document can be part of multiple collections, without the wonky name.\nTagging for clarity\nThe project plan should follow a similar metadata focused approach, allowing it to be designed as a deliverable-centric plan rather than a process-centric one. Most PPM tools today support user defined fields at the task level or have metadata fields at the task level. Use these fields to tag a task with the SDLC stage or whatever property you need to track.\n Treb Gatte \nExample of a process-centric project plan.\n\n Treb Gatte \nExample of a deliverable-centric project plan.\n\nSee the progress clearly\nNotice that the deliverable project allows you to see the overall progress by outcome. I can clearly see that the Software task is almost complete while the Training Task has quite a bit of work left to do. With the process project, I can only see that executing is the current phase, but I can\u2019t see at a glance where the work stands.\nDeliverable-centric projects appear to better serve the purpose of supporting stakeholder and team communications. Using metadata allows the PMO to tag specific tasks as relevant for their reporting and enables easier and meaningful data extraction. Lastly, it frees the project manager to customize the plan to meet the specific needs of the project. Freedom, at last.\nPlease like this article if you liked the content. I look forward to reading your viewpoints and experiences in the comments below.