Requirements for a Project Management Mobile App

Imagine this case: You are a project management professional. You get a live as an Interim Project Manager, getting your clients’ projects done on time, on budget, using their resources. Your clients are projectized organizations. You are graded on goal achievements. Some of your customers sign fix priced with incentive fees contracts, that is, you get a fee if you finish early getting stakeholders’ expectations. Those customers are open to your advice on good practices, tools and techniques applicable to any other project. They need to improve project performance for their knowledge workers. When you are asked about one or some mobile apps to manage projects, what would they be?

When I am asked myself I don’t hesitate to recommend some mobile tools to manage teamwork. I propose managing conversations with Slack, tasks with Asana and documents with Google Drive. All of them works perfectly well in web and mobile. In order to plan and control project activities I use Microsoft Project, but not in a collaborative way. When doing project scheduling I don’t need any mobile app. What’s more, I think I will always prefer my computer to do this: I use Microsoft Project to centralize all scheduling data, when I need to communicate this I simply produce a report and store it in Google Drive.

However, for the time being, I’m not able to recommend any mobile app to manage project portfolios, meeting the needs of the 10 roles in Project Management. Most of the project portfolio management tools have a mobile version, but only as a supplementary channel, not as a primary one. In my last post Could you Manage Projects with a Mobile App? I’ve been directed to some mobile apps than honestly I don’t think are applicable to manage projects portfolios in a professional way.

In this post I want to elaborate an initial list of requirements I would love in a PPM mobile app. Any feedback is welcome, please.

1) Basic Data Model

Projectized organizations need their projects organized, if possible, in portfolios and programs. Organizations are structured on business units. We can call Functional Manager the person who is accountable for a business unit. We can also generalize that every project is leaded by only one business unit.

Projects may belong to a Program. Projects may belong to zero, one or more Portfolios. Programs may belong to zero, one or more Portfolios. Portfolios and Programs belong to the Organization.

2) Project–Request Duality

In my post the 10 roles in Project Management I tried to explain that every project admits two kind of management: one from the perspective of Requesters (demand management) and one from the perspective of Project Managers (supply management). Requesters’ perspective is shared with Stakeholders, Sponsors, Functional Managers and the PMO. Project Managers’ perspective is shared with Program Managers, Portfolio Managers, Team Members and Resource Managers.

From the demand management side, projects are proposed. If approved, progress is carefully followed until they are closed. From the supply management side, Project Managers have to deeply manage projects to get them done, meeting the management goals, what is fortunately very well standardized in the PMBOK® Guide by PMI®.

Interestingly, this guide tells us that projects need to be managed from the very beginning, when they are just ideas, not necessarily after approval –see the two processes in the initiating process group–.

In practice, from the demand management side, any project could be initiated by a Requester or by the PMO, and the assigned Project Manager should invite other Stakeholders. Then the Project Manger will update the project management information that will be accessed read only by the demand management roles. Projects can also be initiated from the supply management side, by the Project Manager, the Program Manager or the Portfolio Manager.

We can say that the Requester is accountable for the Request and the Project Manager is accountable for the Project, but I prefer to see this as two views of the same information. On a higher level, there have to be another person accountable for the program –the Program Manager– and other accountable for the portfolio –the Portfolio Manager–, managing not only the program or portfolio components but also the aggregated management information, which is again very well standardized in the respective guides by PMI®.

3) Multi-Role Access

In my humble opinion, the main value for a mobile PPM app will be the easy online collaboration among users, but strictly on the information they need to know according to their roles.

Any user could access the mobile app with one or several roles. For instance, Jose could access as Project Manager and Team Member, so that he can manage his projects and report expenses and time not only for the projects he is managing but for those projects he is working on.

He maybe wants to access as Stakeholder as well, to see the procurement projects he is managing as a client. Project Procurement Management is an interesting topic regarding mobile virality. Many projects outsource part of the work to third parties, and this work or part of it could be subcontracted again. These interrelationships among projects are sometimes so complex that is a real mess to follow the whole project tracking.

As you can see in the following figure, among the main entities of the data model should be those Procurement Projects.

Any project can outsource zero, one or many other projects. Project Managers, Program Managers and Portfolio Managers should navigate easily from the client project to the sellers’ ones. If those projects are also managed inside the tool –even if they belong to other organizations–, these roles could see the updated management information accessing as Stakeholders. By default, P*M roles are also granted as Stakeholders of procurement projects automatically. Procurement is only a kind of relationship between projects. Other examples could be time precedence, funding precedence, sharing risks, etc.

4) Manage Control Accounts

The PMBOK® Guide defines Control Account:

“ A control account is a management control point where scope, budget, actual cost, and schedule are integrated and compared to earned value for performance measurement.”

This image shows how any project could be broke down into control accounts, work packages, activities and task:

I think mobile PPM apps should not manage the whole information to the deepest level because that could result quite unintelligible. My advice is to stop at the level of control account, and then integrate with other tools:

  • Task level should be managed with a task management tool such as Asana.
  • Activity level should be managed with a scheduling tool such as Microsoft Project.
  • Although there are many tools to manage WBS charts and keep the Work Packages information, I personally prefer to keep this information in the scheduling tool as well.

In order to manage a project with the smartphone, it should be enough to set up the control accounts (from 20–30 are typically enough for projects sized medium-large) and to plan and control dates, progress, deliverables, milestones, costs, baselines, global status, assignments, etc., at the control account level. There should be a special control account (CA number zero) for the project summary task. Via integration with the project scheduling tool, control account information can be two way integrated.

As you can see here, the central data entity could be the control account. Any project can have one or many (at least one for the summary task). Any control account can have several Deliverables and works assigned to several Team Members.

At this level of control account, you should be able to integrate information for activities, tasks, requirements, etc. But these are better managed in other specialized tools.

5) Integration with other Apps

With the rapid evolving of enterprise mobile applications and the fierce fight among the main players Microsoft, Google and Facebook –and even Amazon recently– to domain the market for the knowledge worker workplace applications, I think it is pointless a PPM application covering the whole spectrum for a PMIS. I think it is wiser if this app could integrate with others.

  • From the demand management side, we see a lot of customer relationship management tools –CRM–. Many organizations are using task management tools like Trello to manage the selling project lifecycle. For a Requester, a project can be in one of these states: lead, bid, contracting, in progress, closed, on hold or rejected. This information can be easily modeled with Trello cards:
  • Other integrable tools are those specialized in change control management. Trello could also be a simple mobile solution to perform project integrated change control.
  • From the supply management side, integrable tools could be those mentioned above. When I need to monitor and control any activity, I break it down in small tasks to be assigned to Team Members. I usually create an Asana workspace and there I have projects and sections to be traced back with activities in Microsoft Project. I create a Slack team with several channels to manage project conversations. I use Google Drive to manage project documents. These tools are easily integrable through API, and they also offer URL per channel, list, task, folder, etc., but they are not the only ones that could be integrated to cover these features.

The requirement here is that the mobile PPM app should be integrable, per project, with the more proper tool according to these 6 categories: CRM, CCM, Scheduling, Documents, Tasks and Communication.

6) Mobile Interface

For the time being, mobile representation constraints make it very difficult to visualize rich chart reports. Something so typical as Gantt charts, network diagrams, S curves, Work Breakdown Structures, resource histograms, etc., hardly fits on the mobile screen. Mobile user experience opens a new series of requirements, including:

  1. Mobile PPM tool must be centered on menus and data, it should not provide charts.
  2. Since the number of items could grow dramatically, persistent filtering and sorting mechanisms are needed. For instance, a PMO could see all of the open and closed projects of the organization, and this could be a very long list. The solution is to filter the list by the project states, and/or the requests states, and/or business unit, portfolio, program, project manager, semaphoric color, etc. Sorting is also important in the mobile: by subjective priority, the project value for the organization, size, risk rating, etc.
  3. It has to be a native iOS-Android app, since it has to be integrated seamlessly with other mobile apps, and it also need to produce mobile notifications when some stakeholder submit comments or change requests, for instance.
  4. It is also needed a kind of web application mirroring, that is a website with additional features for reporting, charts, data load and enterprise application integration. The typical use for the mobile app should be to consult information, and maybe to update some brief data. The intense work for project planning and activity tracking should be done more comfortably in the web or via integration with the scheduling tool. Users will see the updated information in their mobiles, but if they change something –a date, a progress, a color– this should be seen in the web and should be easily integrated to the scheduling tool.

This article is also available in Spanish.

Like what you read? Give PMPeople a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.