How Project Management Roles Impact Use of Mobile Technologies
My friend Michael Kaplan (@mkaplanpmp) suggested I discuss “roles” as a follow-up to What I’d like to see in a mobile project management app. I thought that was a good idea so here goes.
What do we mean by “role” in the context of project management? Role is not the same as “job title” but that’s a good place to start.
A project manager has a certain set of responsibilities and authorities, a project task leader has another, and a temporary member of a specific task team will have yet another. How individuals performing these roles interact with the project plan, with other project team members, and with project stakeholders and clients will influence — and be influenced by — how mobile technologies can support project management, communication, and collaboration.
Mobile technologies such as smartphones, tablets, and wearable devices, due to their portability and accessibility, can allow project staff to interact with project related data and with other team members in both traditional as well as innovative ways. The role a project team member is playing at a particular point in time should be able to drive or filter how a mobile device:
- Selects data for display;
- Displays the data;
- Enables the user to interact with the data; and
- Makes it possible to communicate with team members about the data.
We envision how a project management system, working in the background, will learn from the team member’s role profile (e.g., project manager vs. task support) and project related behavior (e.g., on site vs. on vacation) to display information in anticipation of need, just as Google Now presents selected data “cards” to the smartphone or Glass user based on behavioral data. One example: “Your project status meeting is scheduled for Friday and 3 required attendees have not yet confirmed their attendance. Do you want to contact them?”
We’re already accustomed to providing role-based information access and privilege levels to users in many networked environments. For example, when we set up a SharePoint site to support a project it’s common to provide different privilege and access levels to team members depending on what they need access to and how they need to interact with it. Conceptually, what we’re doing with mobile tech is to extend this concept to include any information that can be managed or coordinated by the project management system as it is interacted with via mobile devices.
A key feature introduced by mobile technologies is that we may have different sets of contextual data the project management system can draw upon to shape data for display, interaction types, and anticipated actions. One example is the physical location of the user. On projects taking place at multiple locations, for example, we may want to manage access to project data based on role and the level of access provided to that role regarding the location’s security controls.
Additional context information to be filtered by role might include a pre-listing of those authorized to (or responsible for) discussing specific project performance issues. In traditional organizations departmental hierarchies can drive who is authorized to talk about what and with whom. In a flatter and less hierarchical project environment, skills and actual responsibilities might take precedence. The last thing we want to happen when a team member needs help now is to be told by a smartphone, “You can’t talk with Mr. X without getting approval of Mr. X’s boss.”
Security issues aside, in most cases we will want the best and most appropriate person to be contactable via a context-sensitive “help me” function. Making such information available in real time as filtered both by context (e.g., location, what I’m working on now, etc.) and by role (e.g., by my responsibilities and my level of authority) could help both speed up and improve the quality of a response or a decision.
Finally, project roles change and the same person can perform multiple roles. That means that the mobile device may need to quickly and seamlessly be able to switch from role to role as, say, a project manager “makes the rounds” through an organization when he or she is running multiple projects. Similar context switching might be called for when an individual’s role changes from project manager to team leader to team member. As role and context change, so too should the data being displayed along with available actions change.
Copyright (c) 2013 by Dennis D. McDonald
