(This post is the fourth in a series of five)
In this post we discuss something that many collaborative software vendors don’t talk a lot about…how does the software support the needs of upper management and stakeholders?
Back in post one, we argued that for a social project management software product to be considered “social”, it should be integrated into the enterprise social platform, the “social fabric” of the organization. This is because so many of the operations of the project team, including issue resolution, expertise identification, status reporting, etc., are impacted by the social processes that are possible only when integrated into the wider social network of the organization.
This post focuses on another by-product of the software being socially embedded into the organization by asking the question: “Does your software support what management – outside the team – needs?”.
The core premise of social business applications and, of course, social project management is that they leverage the social network of the organization. For this reason social business applications must consider the needs of all of the types of users for whom social ties exist. Realistically, project teams’ have three key classes of social ties – team members (of many types), project management, and stakeholders.
Unfortunately, while many web collaboration systems provide a number of the features required by a project team, few think about the greater needs of the program and portfolio management team, to say nothing of director-level or executive-level management. In some cases, this is due to the ideological stance of the vendor – those seeking to “democratize” projects, or to make teams more “egalitarian” see little value in recognizing the reality of the large, hierarchical enterprise and the requirements that these organizations place on the project manager and team. In these cases, project managers are often left with the tedious task of converting the information stored in the web project management system into reporting and other templates necessary for communication with upper management.
Just as a social project management system must provide visibility and engagement for the project team, it must provide the same ability for visibility and engagement for stakeholders. It can do this in many ways, but most importantly it should:
- Promote engagement by allowing stakeholders to not only view, but participate in the social activity stream of the project.
- Promote visibility by providing project and portfolio-level reporting for stakeholders – in real-time – without requiring additional project team or project management overhead to provide it.
Unless the system expects stakeholders to directly interact in the social process of the project, and unless the system provides the functionality for the stakeholders to transparently see the progress of the project, it will fall down on this point. Why should project stakeholders not be part of the same “democratization” of project information that is properly recognized as being a key requirement for social business?
Project stakeholders often complain that their project teams are a “black box”, that they cannot see into. Interestingly, many project team members often are unaware of the power that they possess to keep information hidden from stakeholders (of course, others are far too aware of that power). Because of this, the ability for stakeholders to have constant, real-time, and transparent information regarding project progress is often an unrecognized need, or an intentionally neglected need, when evaluating project management systems.
So, a social project management system engages the social ties with stakeholders in the same fashion as it engages project team members. By providing the information that each person needs, when they need it, while minimizing the work necessary to provide that information.
