The Detail-less Project Plan

Project plans are tried and true. For as long as people have been planning and executing projects, they’ve been tracking detail in a list, or (around 1910) using a bar-chart cousin called the Gantt Chart to illustrate start and end periods for critical and simple tasks! But regardless of the plan format it is that moment in a project status meeting, or planning meeting, when the PM presents the plan to their team for review when it feels we’re all being punished for an unknown transgression.

I’m not advocating that we get rid of project plans. The detail in our plans is as important to a project manager as Photoshop is to a designer, or Beanstalk is to a developer. The inter-dependencies of work tasks must be understood if proper project oversight is to be provided. I am suggesting that we create a new high-level, visual document, that allows a project manager to work with their project team to define their project approach collaboratively, and without so much focus on specific tasks as a group. Fleshing out specific tasks, if needed, can be done with individual team members, but not in group where meeting efficiency and resource effectiveness are stunted for an exercise that mostly benefits the PM.

Digital project management workshop or creative project plan proving ground?

In February 2014 I attended a Digital Project Management workshop in Austin hosted by Brett Harned (@brettharned). During one of the workshop scenarios, my table-mates and I were tasked with developing a project plan. Each of us developed a plan independently and then shared our ideas as a means for converging our thoughts into a plan that represented the best of our individual ideas.

As I began working on my individual plan I realized I didn’t want to create a traditional task list or gantt chart. I chose instead to create a weekly duration column that ran down the left side of my poster paper. I used the rest of the paper (think one thin swim lane and one really big swim lane) to illustrate the project approach using a workflow diagram. Workflow was broken down into project phases: project definition, information architecture/design, and development and then matched to the weekly durations in the left column. The end result was more process than project plan, but the visual served to show a project approach and its planned execution over a period of time. As part of the workshop we had to post our work to twitter for review by the workshop attendees. Here is the image I posted:

Scenario B #dpm2014 pic.twitter.com/nTb6Wrpo4P

— Dave DeRuchie (@dderuchie) February 22, 2014

The workflow diagram is very high level. Key objectives are categorized into phases, but specific tasks are not revealed. Identifying what we plan to do, not how we plan to do it, is the distinguishing trait of this exercise. It’s still too early in the project to prescribe specifics, but the project approach can be captured in workflow, as are dependencies that may exist between task categories, i.e., User Experience & Content informs UX/IA, design aesthetic, and CMS structure. I explored adding more detail around the boxes, like Design Aesthetic, which shows brand, typography as elements that will be addressed in this part of the project, but during the workshop exercise I didn’t have time to really drive that out.

Boxes, Arrows, & Swim lanes oh my!

Creating the “Detail-less project plan” is easy. I find this exercise really worthwhile during the sales cycle when we really don’t know enough to get specific about an approach, but the prospective client really wants some idea of what we plan to do. This pre-project opportunity allows you to gather would-be project team members and collaborate as a group on the approach you think will work best for this engagement. In addition to helping your sales person get a sense of scope, it generates excitement among your colleagues and creates a sense of contribution in the sales cycle. To illustrate how this plan works lets assume a project opportunity arises and is a good candidate for design sprints. Work with the meeting attendees to brainstorm ideas on a whiteboard. Using boxes and arrows you can capture the process in a “blackish” box format (there is detail provided so this isn’t a black box).

I like to use class diagram elements from the Unified Modeling Language Class Diagram for planning purposes. The Class element allows me to define a phase, then assign task categories to give a sense of what will get done, without saying exactly how the team will do it. Here’s an example:

Once the team has identified all project phases and associated task categories we connect them to show workflow, or identify a dependencies. We use swimlanes, both vertically and horizontally, to associate duration with classes, denote team member roles responsible for completing the actual tasks associated with the class. When all of the elements come together we have a high level overview of the project approach associated with time and project roles that is easy to speak to with your prospective client, or with your project team.

Conclusion

Since the DPM workshop I’ve been tinkering with the idea of how workflow elements may be used to create a high level project process document. A document that might follow your sales process, or a project kickoff meeting, and represents the approach that the team wants to use for the project. How are you adapting traditional project tools to work in today’s project environment?

Back to Top