Project Management for Information Management Projects

Information management (IM), as a domain, presents traditional program and project managers with some subtle and not so subtle differences that need to be recognized before a project’s inception in order to have the best possible chance for success. The application of project management best practices and methodologies needs to be altered to account for these differences and measured accurately to understand their impact and the manner in which they are overcome. What follows is an examination of the differences between project management for IM projects and traditional IT projects. I will focus far more extensively on the major differences and provide suggestions for success.

Program and project managers that are assigned to IM projects or otherwise take on projects in the IM space can expect to face some or all of these differences.

• Information management projects often involve multiple technologies and competencies, far more wide-ranging than typical IT projects. Project managers are faced with integration challenges from the multiple technologies and the organizational change management component is extreme as a direct result of the complexity and scale of IM projects.
• The execution and success of IM projects often depends strongly on external technologies, people, processes, and data. The project also may have little control over some of these which necessitates a light and agile issue management methodology be put in place to manage the external factors without adversely affecting the scope, time, or cost of the project.
• Requirements often remain in a continuous state of revision as business users and leaders begin to understand what value is derived from these projects and how to best utilize the information being delivered as a result. Iterative approaches to requirements, development, and testing are a must for IM projects.
• Users and management should be involved at all stages of the project and not only at the beginning and at the end of it. The exploratory nature of IM projects requires constant review and validation of the data as well as of the requirements by the users. Assumptions and decisions will need to be made by management all the time. This is also a very good way to ensure the adoption of the new products when they are released. The project manager must ensure that all stakeholders and constituents are fully engaged by executing a more rigorous communication plan.

Let us take these differences in order and discuss them further. IM projects often involve products that span multiple layers in the enterprise requiring knowledge of database systems, ETL tools, data warehousing systems, reporting systems, and a host of visualization tools. There are plenty of other systems and tools that may also become part of an IM project. There are two solid approaches to handling this difference successfully. First, it is extremely beneficial to assign a project manager who is knowledgeable and conversant in these myriad technologies. Second, it is imperative that members of the business community and information technology with subject matter expertise in these technologies be found and made part of the project team. Projects such as these then run the risk of having very large teams, all with differing points of view and responsibilities. Communication is a cornerstone to any project but is even more critical for an IM project.

In any IM project there is a larger organizational change management impact on users and management alike. It is critical to plan for the change management aspects of the project by involving those who can affect change and evangelize the project’s benefits to the other stakeholders and constituents. Often an IM project will deliver new views of data, provide a need and mechanism for business process change, force evaluation of concepts and principles that are accepted and understood, or all of these. Engaging an organizational change management expert to help guide the project and its internal champions is a solid strategy for success.

The dependence on external technologies, people, processes, and data can be a confounding situation to manage. A project manager may find that the external factors are initially not part of the critical path but the very nature inherent to external forces, namely the limited control over them, ultimately force them to the forefront and place them on the critical path. Acknowledging this before a project is initiated and actively managing the risks associated with external factors can go a long way toward keeping scope, budget, and time in line. Employing a project manager familiar with vendor management techniques is very helpful for these projects. Another solid strategy is to include individuals on the project team with specific working relationships and knowledge of the external products and organizations involved in the project.

The often-changing nature of IM projects, specifically with respect to the requirements on which the project is based, can be especially troublesome for the project manager and project team. Projects in the IM space are, by their very nature, an evolutionary type of project. As progress is made toward any current set of requirements, new requirements are often uncovered and must be handled appropriately as part of the project. An iterative approach to executing IM projects is good strategy to manage the changing nature of requirements. This is not the same as an Agile methodology typically used in an application development world, rather this is a methodology that employs a repeatable set of steps to uncover requirement change to the project, develop new goals or objectives based on those changing requirements, and the incorporation of the new goals or objectives into the formal project plan. The risks in pursuing an iterative approach manifest themselves as increases to scope, budget, time, or more than one of those. A project manager needs to be adept at balancing the changes to the project as a result of changing requirements and managing business expectations and needs. Again, communication is the key to making sure that all stakeholders and constituents are informed.

Lastly, let me reiterate the need for outstanding communication by the project manager and project team with all of the stakeholders and constituents on the project. This includes internal and external resources alike. In order to manage the assumptions inherent to the project and elicit the decisions from project leaders as required, constant contact with those involved is necessary. This need transcends the typical status report focus of many projects and really necessitates the use of a more comprehensive communication plan. Several times weekly, if not daily, a project manager needs to review the communication plan and take appropriate action to ensure that anyone affected by the changing nature of the project is aware of the changes and able to participate as necessary. This particular aspect to IM projects cannot be overstated. Employ a project manager with exceptional communication skills or utilize an organizational change management expert to facilitate the execution of a rigorous communication plan.

In summary, IM projects differ from traditional IT projects in a number of ways. A successful approach to managing IM projects includes awareness, communication, liberal use of subject matter experts, and an iterative methodology for executing the project. It is important, even more for projects such as these, to place the right people in the right role. Additionally, most of the traditional tasks performed by a project manager on any type of project are also applicable to IM projects. What makes these projects more difficult to manage and more likely to fail have to do with the differences outlined above. Successfully combining fundamental project management techniques with strategies to address the differences experienced on IM projects will help a project manager to deliver the project successfully and provide value to the organization.