A good friend of mine switched from managing non-IT projects to managing a data integration and reporting project. The overall project management methodology is consistent at her company for IT versus non-IT projects. The templates, forms and checklist are all very similar. But as we got to talking, I started thinking about what makes IT project management, specifically of projects that contain data integration and reporting, different and difficult.
First, the Foundation
Successful projects have a useful project plan that helps the PM keep track of tasks, report status and percent complete. Dependencies on interfaces are key to data integration projects with a reporting component. Interfaces can be defined as both inputs and downstream feeds or reports. Proper lead times and contingency planning are important to avoid delays that can be caused when source data is not ready at the appropriate time in a project. Understand the options if a source system needs to push back a delivery date and examine other options to keep the team moving. For example, can source data be created by the development team for unit testing? Can other pieces of the project be shifted to keep resources busy while waiting on feeds? Integration and communication with downstream systems is important to project success as well. Feedback from those downstream systems about data quality and format should be addressed and the proper adjustments should be made. Expect these types of issues, and build time into the project for iterations. Report development is not dependent on data integration success, only on data model completion. Having reports built and tested with mocked-up data can help uncover potential data model issues before the coding for extract, transform and load is complete - which can be a huge benefit. Do not wait until data integration work is complete to start report development.
Another important document for a project manager to start with and maintain is a requirements/functionality matrix. The PM will need assistance from the technical staff assembling this document, but it can be used to validate in which parts of an application requirements are being addressed. The PM can pass this document from the technical development team to the testing team as an input to test plan creation. The PM can also reference this document when questions arise as to how a particular requirement is being met and to help ensure all requirements are addressed.
Make sure your project plan has adequate time allocated for one-time tasks, such as application back loading and initial performance tuning. These tasks often take significant calendar time, if not resource time.
Set checkpoints along the way. Weekly or even semi-weekly status meetings and reports are important to identify risks before they become issues. In data integration projects, common risks include delays in receiving source feeds, data quality issues, load performance issues and requirements change/scope issues.
It is easy for data quality issues to get lost if they are not causing a block, but they should be tracked and addressed. Potentially the resolution will be to do nothing, but that should be documented as well for future reference.
Utilizing the change control process is another key to success. Not only is it key to success, but it is fair. The project manager is responsible for ensuring the application being delivered is the application that was agreed to. When requirements are gathered, scope is agreed upon and resources are allocated, so any change to that scope should require a change to timeline or resources. If these changes are not properly tracked, the integrity of the application is at risk. Corners may be cut to stay on the set timeline, or other critical tasks may suffer.
Wrapping it Up
Prior to closing the door on a project PMs should consider the following two ideas. One is to follow up with key personnel that were part of the project and provide and request feedback. Recalling the parts of the project that went well and the parts that could have been better offers the opportunity for improvement all around. On large projects with multiple interfaces, it helps to keep notes on what made interactions with the other teams successful and what was challenging. If the interface was a data feed that was providing a file, how many iterations were required to effectively transfer the data? If the interface was a downstream application or report, how well were the requirements defined? How many iterations were required for the interface to be delivered successfully? This information will be valuable in cases where the interface with your application is being modified and you're working with those teams again. Reviewing the issues and having a reminder of the actual time and iterations that were required will make future estimates more accurate and will provide support for those estimates.
All projects have their challenges to manage. Data integration projects introduce special challenges with their dependence on source systems in terms of feeds timing and data quality. Project managers can help ensure success by identifying roadblocks and helping to remove them.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access