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’t going to happen if the drywall wasn’t finished. They didn’t 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.
Designing the project plan for your stakeholders
Could 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’s 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.
Stakeholders usually don’t 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.
Obscuring the truth with a process-centric project structure
The PMO isn’t 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 “thou shalt not change the structure of the project plan.” It doesn’t have to be this way.
There 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’s a bit like asking your teenager about their current whereabouts and they give you their GPS coordinates. It’s technically correct but not as clear or readily understood as Kayla’s house. Second, it makes extracting information from the project plan for various uses much more difficult.
Data has interesting properties which you need for reporting. However those properties now depend on that data element’s 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.
Learn from other technical areas
In 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.
Metadata 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.
Tagging for clarity
The 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.
See the progress clearly
Notice 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’t see at a glance where the work stands.
Deliverable-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.
Please like this article if you liked the content. I look forward to reading your viewpoints and experiences in the comments below.
This article is published as part of the IDG Contributor Network. Want to Join?