What We Talk About When We Talk About Projects

by Mark Phillips, Lead Spokesperson, Vertabase

Sociology's concept of a boundary object can help project managers improve processes and communication on a project.

First, let me explain a boundary object. Simply put, a boundary object helps build bridges between different groups by facilitating communication. A boundary object is an object which different groups see and talk about differently, but whose underlying definition across those groups, has enough commonality that they can talk about that object.

It sits at the boundary between the two groups. And more specifically, it sits at the boundary between what the two groups talk about. To borrow an example from Peter Morville, "a dead bird can be a catalyst for communication between amateur bird watchers and professional epidemiologists." In this example, the dead bird is the boundary object. Even though both groups see the dead bird as something particular for their field and their interests, there is enough commonality between the way they see it that the groups can talk about the dead bird together.

When It Comes to Projects

Let's look at the status quo with most projects. For simplicity, let's talk about three groups: A client for whom the project is being done, a team that does the project and project manager between the two. What are these three groups most concerned about?

• The client is most concerned with the deliverables of the project.
• The team is most concerned with working on tasks.
• The project manager is most concerned with coordinating the team to deliver what the client wants.

Left on their own, the three groups often have trouble communicating. The project manager then has the sticky role of translating between the other two. Sometimes it works. Sometimes it doesn't. In particular, it doesn't work when the project manager has a special language of Gantt charts, work-breakdown-structures, constraints and dependencies.

Instead of clearly communicating, each group raises their voice louder and louder, pointing the finger and insisting that the subject of their language is the most important and demanding to know why it isn't getting the attention they want it to. And ultimately, it boils down to politics and hierarchy, which leaves the team in the lurch, the project manager scrambling and the client grumbling about the whole process and everyone involved.

The problem is, the groups have no single boundary object around which to have a meaningful discussion.

1. You have the client talking about deliverables.
2. The team is talking about tasks.
3. The project manager is talking about whatever they can to keep the ball rolling, or worse, he resorts to his own language of shift, lag, delays and schedule impact.

To solve this problem, the project manager needs to create a boundary object for the project. The most useful boundary object I've found is the simplified schedule. This is a schedule that has the key deliverables in bullet-point form, with their start dates and due dates. This schedule should be a roll-up of all the specific tasks that go into a deliverable. But the client doesn't need to see the tasks. They just need the deliverables.

You show this schedule to the client and use it to update the client on percent complete. You use it to show the impact of changes or problems. The client understands it because it is in their language — the language of deliverables.

You then drill down into this schedule and sort by team or team member to create the specific task lists for each person to work on. This then expresses the situation in the language of a team member, the language of tasks.

The team member marks items complete on the task list, or updates percent complete or requests changes to task because of problems. This is the list you talk about in meetings and use to manage your teams.

Here is an example of a simplified schedule:

This is how the drill-down would look to team members:

The project manager can manipulate the schedule to play with different scenarios, as long as he shows the simplified schedule to the client and the drill-down task list that results from it to the team.

Mark Phillips is the product manager and lead spokesperson at Vertabase project management solutions. Vertabase makes the world's leading ColdFusion based project management software. Mark has been the project manager and creative lead on numerous web-based and rich internet applications. He has presented to ColdFusion and Adobe User Groups in the U.S. and Canada on software design, usability, project and time management. He most recently spoke at CFUnited 2009 on project management. He hosted a Birds of the Feather Session at Adobe MAX 2008 on CFML Language Development.

• Subscribe
• RSS

• Editorial
• Specials
• Community
• News
• Tech and Tags
• Views
• Reviews
• Techniques
• Security
• Best of ColdFusion Talk
• Knowledge Base
• Blog Watch

• Tipical Charlie