The Social Nature of Project Management

A successful configuration of Project Server is one that supports the conversations within the organization. Users have to go beyond use of the system and have concerns over the validity of the data entered. The Project instance captures the requisite information for the conversations and enables participant to synthesize additional outputs and insights. Therefore, an understanding of the work social environment is key to understanding the requirements for configuration and getting the necessary level of user engagement.

Projects: One of the Original Social Networks

Projects have been around for thousands of years as humans started working together to achieve common goals. We didn’t call them projects back then as most interaction was face to face and immediate. By PMI’s definition, these interactions were projects in that they were temporary endeavors undertaken to create a unique product, service or result. Feeding the tribe or building shelter for the family can be considered projects.

As projects got longer in duration and more people were involved, the need to capture the conversation between all parties became critical. The social networks involved in doing the work grew larger and longer. Project plans were born as a technique to keep track of the overall conversation. Thus, project plans represent the latest state of the conversation between everyone involved with the project.

Projects are Dynamic Social Networks

Projects today represent a temporary reorganization of your work social network. Within the project, the roles and importance of members change over the life of the project as information needs change to achieve work.

Tools such as RACI attempt to model the project’s social interactions. Communication plans also attempt to do this from a different perspective. However, RACI, communication plans and other tools of that sort represent a one-time, almost theoretical look, at how the project members and stakeholders interact. These models fall down as soon as the project starts and reality takes over.

Many social networks have different levels of access based on either whether you friend someone (Facebook) or through which contact you know them (LinkedIn’s Levels). Unlike Facebook and LinkedIn, your work social network can be defined and refined by the interaction level with others. The interaction level with a specific person or team represents mutual dependency as the interaction yields information needed to achieve work. A time aspect adds priority to the interaction as tasks that are due earlier require information sooner. Emails, meetings, IMs, tasks and break room discussions all represent types of interactions. As a result, today’s joint deadlines will prioritize a co-worker’s activities to a higher visibility than a co-worker with which you have a deadline 3 months from now.

Modeling the Work Social Network

Your work social network can be modeled as a hierarchy of social zones based on interaction and common experience. Each zone contains social group which morphs over time, depending on the level of immediate interaction. My basic model contains four zones. These are:

• Inner
• Shared
• Experience
• Public

Members of the Inner zone are those individuals with which I have immediate interactions. These would include:

• People with which I have joint dependencies
• My Project Managers
• My Direct Manager

By immediate, I mean there is a deadline within the three week window of activity that most focus. We look back to last week for status and forward to the next two weeks for planning. The immediate nature of the interaction means my attention to this group’s information and needs will be prioritized above other interactions.

The Shared zone members are people with which I have a current shared experience but do not have joint dependencies. This group’s information will be of interest but not priority. This group includes:

• Other project team members with which I’m not directly collaborating
• Other members of my work team with which I do not have project work
• Past direct collaboration partners on current projects
• Other interests or information to which I have subscribed

The Experience zone comprises the edge of your social work network. While the Inner and Shared zones tend to focus on interactions within your current work environment, the Experience zone extends beyond. The Experience zone is comprised of those individuals with which you’ve had past interactions. This can be:

• Former Work team members
• Former Project team members
• Past transitory interactions within and external to the work environment

Many may consider this to be the “LinkedIn” zone. Members of this zone can be a source of information as well as an external communication channel of activities and opportunities.

Last, the Public zone is attached to your public persona. This can include:

• All others in your company with which you have had no interaction but share a common identity
• Contacts based on public facing interactions

Example Scenario

I have a joint deadline with my DBA this week. The DBA has a family emergency and has to fly to the other coast immediately. Currently, they are within my inner zone and I would be very interested in this absence so that I can respond accordingly.

If my DBA was someone who is on my project but I don’t have shared tasks or deadlines, they would be in my Shared zone. I might be interested in this event but there may be no immediate action needed.

If we had worked together in the past but not currently working together, the DBA would be in my Experience zone. I’d probably regard it as informative.

If the DBA is in my fantasy football league and I email them frequently on the upcoming draft, I may have other social ties to this person, which could raise their level to Shared or Inner.

As you can see from this example, the challenge of implementing a social-centric project management system in the organization is incomplete information. Likely, you will not support interactions in the Experience or Public zones. Failure to support the Inner Zone interactions will slow or prevent adoption of the tool by users.

Inner Zone Support is Key

If projects are the latest state of the conversation, then Project Managers manage conversations rather than schedules. Schedules should be developed to support the conversations necessary to get the work complete. I’ve met many project managers who feel that their job is only about the project schedule. As they don’t see themselves as conversation managers, they tend to develop project plans that don’t support their conversations. Plans will either gather dust or worse, lead the team to improper conclusions.

Creating infrastructure to support the Inner Zone conversation is key to successful adoption of Project Server. Too many times, the system is configured from the perspective of the PMO. The PMO is happy but no one else will see anything of value. No value leads to a lack of engagement and the death spiral of apathy and bad data ensues.

To support the Inner Zone conversations, every configuration element has to be viewed from the perspective of the self and the Inner zone. A great place to start is to “make the system about me”. By this, little things like a My Projects view in Project Center, a Team Site home page that has my Active Issues and Risks and reports that show My Tasks make the system more about me. This raises engagement. Once this “me” need is satisfied, the ability to address the Inner Zone can be an extension of the self-views.

The goal is to turn Project Server into a source of information that drives people to want more, similar to honey in a beehive. By comparison, many customers of Project Server host a weekly cattle drive where we try to herd our user base to enter their time, update their projects and run their reports. Cattle drives aren’t satisfying and aren’t sustainable long term. We can and should look at the existing successful social platforms for ideas to improve the collection and use of data in Project Server. Honey may be easier to achieve than you think.