Let’s get this out of the way: EVERY PROJECT HAS ISSUES at one time or another. Sometimes a technical issue may need to be communicated to the project manager, escalated to gain resolution or just communicated within the project team. I seem to always hit issues during testing, and these issues never fail to keep me up at night. My issues usually revolve around:
- Source system data layouts or file definitions.
- Data quality that was overlooked in the source systems, and now must be resolved during conversion.
- Data volume – What? You mean 10 million records on an initial load is BAD?
- Data design for the target system is not optimal for query performance.
- Programs for the data extraction, transformation and load were not changed when the input data layout was changed, or just had a few translation issues.
I bet you figured it out by now – my life is surrounded by DATA. So, any planning and mitigation that we can do upfront to address these issues is totally worth it!
Usually early on, the project manager will create a communication plan for the project. This can be used for the following:
- Describes how to communicate with stakeholders and the project team (team meeting, management meetings, status reports, etc.).
- Describes how to escalate and resolve issues.
The second item listed above can also be described in an issue escalation plan. For BI projects, I usually just add a section to the communication plan. However, for large conversion projects, I recommend creating a separate document broken down by type of issue, such as when and when not to escalate. It should also include information about mitigation since it's usually required for a successful implementation.
What data errors have you experienced? Could better communication have helped resolve them? Share your thoughts below.
2 Comments
What to think of the requirement:
"The data, bi-report, must be approved first before it is allowed to be viewed/accessed by the operational business."
What you are hearing is an acceptance environment for reports on operational production data.
That is easily got confused with code management using words of "wich version", "wich release". Sometimes it is mitigated by a copy action without any documentation or statement.
Getting trapped by the confusion caused by those words can be even worse.
The code management is often done with mandatory guidelines. Ever tried to explain that the acceptance of production reports is not the same as acceptance of code (or machine or fixes)?
Good Point!
Thank you.