www.ddmcd.com

View Original

Some Requirements for Using a Mobile Device to Interact with a Project Plan

By Dennis D. McDonald

Introduction

This continues my series on enterprise mobile technology strategy and collaborative project management.

Here I’m interested in how, in a project management situation, mobile devices such as smartphones and tablet computers can support project-related communication and collaboration. Specifically, I’m trying to figure  out how to use such devices to effectively share a synchronized view of complex project plans, especially in projects where teams are working from several different locations.

Accessing the Project Plan

I’m assuming  that project staff are already using their own mobile devices to communicate and share information with each other, with or without direct influence of project management. They may also be using the audio, video, and text messaging features these platforms provide and may already be familiar with how to download and use specialized “apps” tailored for a mobile device.

The question addressed here is how we want to use these devices to interact with some aspect or view of the project plan. There are many ways of looking at a project and all the tasks, timings, and resource considerations associated with running it.

Ideally any participant — a project manager, a team member, a PMO staff member, or other stakeholder — should in theory be able to use a smartphone or tablet computer to pick and choose how to view and interact with the project plan in a way that meets the needs of the moment and of the project. The question is, what are the costs and benefits associated with making this possible?

Many project, program, and portfolio management tools already exist and are available on standard network connected PCs and laptops. Some are PC based, some network based, and some are cloud-based or remotely hosted. They generally provide a variety of different views of a project and its planning information that can be accessed via a standard browser. 

  • How far do we need to go beyond attempting to duplicate the PC experience on a mobile device, especially when the browser experience is not optimized for a table or smartphone?

In some cases, tool providers are already providing specialized apps that accommodate the special features of mobile devices that include both display only as well as interactive features. So far so good. 

A question I’ve been exploring is whether the same types of services need to be available on mobile devices, or whether mobile devices are different enough to justify a different set of requirements.

  • Does it make sense to just consider mobile devices as extended parts of the network?
  • Are they capable of supporting different uses that we are only now beginning to explore as project managers, uses that may be somewhat different from how desktop based systems are being used?

Different Project Plan Views

The following are some ideas for the different views that a mobile device might provide of a project for a project manager, staff member, or other interested party. As you read keep in mind the small screen size, lack of full size keyboard, and connectivity issues common to many popular mobile devices:

  1. View Project Plan by Participant. Whether the participant is the project manager from IT, a business owner the project is supporting, a finance department representative overseeing project costs, or a temporary contractor assigned to support one of the project tasks on a part time basis, the mobile device needs to present information content about the project in a form recognizable and usable by that particular participant. 
    • How does the system know who the participant is and what the participant needs to know at that particular time? 
    • Are there location and context information available from the mobile device that could automatically be used to filter and shape what gets displayed? 
    • Can data or documentation that can be easily displayed on a desktop device also be displayed on a mobile device?
  2. View Project Plan by Resource. The rate at which project resources are consumed usually need to be tracked for both cost accounting and progress reporting. Each task or group leader may need to see the resource consumption or burn rate figures for the resources for which he or she is responsible. The project manager needs to be able to view overall resource consumption against budget while also having the ability to drill down in selected ways. 
    • Can a system working through both desktop and mobile devices provide such a potentially rich level of detail about resources? 
    • Given how important spreadsheet tables are in rendering trend data or multi-variable analyses, how can such displays be adapted to mobile devices if that’s what the project requires? 
    • Will graphical displays suffice for engaging with resource data?
  3. View Project Plan by Schedule. Project calendars are important management tools. They need to be shared, they impact what people are supposed to do and when they are supposed to do it. They also drive the definition of dependencies such as things that need to be done before or after a given task.
    • Should the mobile device display a project specific calendar?
    • Should that calendar be integrated in some way with the mobile device owner’s “personal” calendar?
    • Given how often projects change, should staff or managers be able to make changes to the project plan via a mobile device?
  4. View by Organization. Today’s communication and collaboration technologies can allow project participants to bypass traditional organizations and departmental boundaries. Names, titles, and affiliations can be bypassed in a communication network where immediacy and expertise can drive action at the expense of entitlement or formal authority. Still, there are situations where title, department, and job description are important factors to respect both during planning and project implementation. 
    • Can the mobile project management app answer basic questions like “Who is this guy?” when a name unknown to the participant crops up in a project related message on a smartphone?
    • Given how often such information changes, how can one ensure that updated organizational information will be available via a mobile device?
  5. View Project Plan by Team. By “team” I mean the people the project participant actually collaborates with. Some teams are formed as a natural byproduct of project planning, e.g., “Team X consisting of Mary, Susie and Sally will be responsible for Task Y.” Other teams will form on an ad hoc basis to address issues as they arise. 
    • Can membership and performance of both types of teams be visible via the mobile app to team members, non-team members, and project management? 
    • How — or should — such changeable information be managed via a mobile device?
  6. View Project Plan by Goal. At any time the project participant using the mobile collaboration app should be able to answer the question, “How does what I’m looking at now relate to the project’s goals?” On the one hand, it’s important for each project participant to understand what he or she is doing is contributing to the accomplishment of the project’s goals and objectives. On the other hand, it’s the job of project management to articulate what the participant is doing is connected to the accomplishment of the project’s objectives. Doing this is not only important for maintaining motivation, it’s also important so that each project participants makes decisions when options need to be weighed against goal related impacts. 
    • Is it realistic to expect a “tactical” tool such as a smartphone or tablet computer can be realistically expected to display strategic goals and business information to project rank and file in a form that can make a real difference?
  7. View Project Plan by Milestone. A milestone is an important event or deliverable that signifies accomplishment of an important body of project work. Often milestones are used as visible and understandable ways to track project performance both among project staff and in reporting to customers or management on progress. Users of the mobile application should be able to switch to a milestone view to see quickly where they stand on what they are responsible for accomplishing, what their team is responsible for, and how their milestone performance compares with other project teams. On the other hand, milestones have a way of slipping, and some team members may be reluctant to broadcast that they are falling behind via a device that can be easily accessed by all team members — as well as management.
    • How are data about milestones updated?
    • How are milestones displayed?
    • When milestones dates slipped who should get access to such data?

Discussion

One assumption I’m making is that a project plan exists in a form that can be referenced, updated, and used as the basis for project management and reporting. Experienced project managers know this is not always the case.  If the project plan does not exist, discussing which functionality should be transported to or created for a mobile device may not be a consideration.

Without getting into a discussion about “agile” versus “waterfall” project management techniques, I believe that a project plan is always needed in order to generate management buy in and to communicate expectations with project staff. The  physical form the plan takes, though,  is less important than whether the plan is shared, used, realistic, and updateable.

  • Is the “fit” of mobile devices less with attempting to duplicate the systems and applications already available via networked and desktop machines than with enabling project staff to create, update, and share the types of information mentioned above?
  • Are there situations where the lack of a detailed project plan can at least be partially overcome through the various types of communication and collaboration tha mobile devices are able to support?

Also, given the physical characteristics of the mobile device, it may be a good idea to focus on using clever symbolic, graphic, or auditory methods to communicate information that traditionally has been presented via page oriented displays and lists of text and numbers. Also, whatever a “view” from the above list is being considered, providing an easy way to move back and forth between summary “high level” views and detailed “in the weeds” views may also be valuable.

Finally, whatever the information being consumed from the mobile device, the user should have the ability to share that information with other project staff, e.g., with other staff who are part of the team, or with other staff who are waiting for an intermediate deliverable to be produced.

Copyright (c) 2012 by Dennis D. McDonald, Ph.D.