5 Common Business Intelligence Project Mistakes #3
Third in a 5-part series
So far, I’ve discussed two of the 5 Common Business Intelligence Project Mistakes: not including operations/infrastructure colleagues on-board early in a new BI process, and not creating a proof-of-concept for your BI project. This post covers the third common BI project mistake.
You don’t establish a proper overall communication plan for the project.
Proper external and internal communication are key to the success of any project — not just IT. It is especially important on an Enterprise BI project, since a combination of factors, such as complex undocumented source data, ever changing business needs, and lack of familiarity with a chosen BI toolset require communication. Normally, project managers tend to focus communication with two key groups: management stakeholders and the business users driving the requirements.
Good project managers also hold regular status meetings; however, their potential drawback is that they may be formal and tend to focus on milestones. Other issues might arise that might be difficult to voice during such meetings since not all stakeholders are present. For example, a technical team might confuse business users with details; however, sometimes those details might be important. Sometimes, business users insist on having certain features which might not even be a part of the BI tool (or otherwise impossible to configure) and since they primarily interface with a project manager or business analysts, they might discover it too late.
To avoid misunderstandings like this, I suggest incorporating the following items into your overall communication plan:
- Initial communication to all project stakeholders with introduction as well as explanation of roles and responsibilities
- Regular communication on the data-modeling activities and progress
- Regular communication on the ETL activities and progress
- Regular communication on BI development activities and progress
- Regular communication regarding project status sent to all team members (could be the same as presented to management with financial numbers removed)
- Ad-hoc communication as necessary to business users about down-times, deployments schedule, and any other operational issues
- Regular meetings between technical BI developer or architect and business users to discuss desired functionality, requested features, and usage issues
- Periodic lessons-learned meetings to improve processes and procedures (post-deployment is always a good time for this)
- Ad-hoc workshop meetings, especially if using agile methodology.
You can utilize email, internal wikis, phone conferences – to communicate, depending on the team’s size and location. It is important to include even those team members who might not be involved with the project on a daily basis in order to cultivate goodwill, since you never know when you would need their expertise. A good communication plan as described above will help your BI project get on the right track reduce ambiguity among team members, and increase chances of success.