Effective communication by BI teams creates better relationships with business users regardless of the development methodology employed. Providing:
- a clear picture of the team’s service offerings before the project,
- project insight during the project, and
- ongoing visibility after the project
are the triad of effective BI communication and are nearly always a significant part of my recommendations for the teams I assess.
Before the project, the BI team needs to market itself to its potential users. This involves defining the products the BI team provides both in terms of services (data integration, report development) and available data assets (customer data, product data, etc.) and creating a simple marketing plan for these services. The marketing plan includes such things as how to engage the BI team, what information is needed for BI to create an estimate, and guidelines for project scope. This serves a number of purposes including:
- Clearly defining and advertising the services offered by the BI allows users to brainstorm about their potential needs.
- “Customers” come to the BI team better prepared to engage the team.
- Estimates on well defined services become more and more accurate over time due to repeatable processes and comparability between projects.
Pre-project communication is generally best suited to some kind of web presence, probably an intranet site of some kind that should be short, sweet, and well maintained. One often updated page is more effective than dozens of pages from 2004.
JIRA Wallboard
During the project, communication is all about visibility. Here’s where the differences between traditional waterfall and iterative development really stick out.
The Future of Big Data
With some guidance, you can craft a data platform that is right for your organization’s needs and gets the most return from your data capital.
In any methodology, effectively communicating project status to stakeholders can mean the difference between disengaged, nervous stakeholders and engaged stakeholders. Stakeholders need to be able to visualize the big picture, determine at a glance where the project stands in that picture, and know where unaddressed issues can impact the outcome of their project.
All methodology flavors should publish these aspects frequently to a stakeholder accessible place, usually an intranet site. Ideally, there exists a project management dashboard for all of IT that consolidates relevant project statuses, but in most cases just having a picture on the project page will suffice. Note that I didn’t say just uploading the weekly status report to a document repository. This leads to stakeholders only checking status when they’re already nervous, defeating the goal of proactively identify risk.
In waterfall, status is percent complete on a variety of tasks, summarized on a gantt chart or the like. Keeping users apprised of the inevitable task level changes presents the biggest challenge for waterfall PMs, so having a status display generated directly from the working project plan is important.
In iterative projects, the essence of intra-project communication is more about backlog burn-down and velocity than task level percent complete. Stakeholders need a picture of how effectively the team is converting stories into product and where the stories they care about sit within the backlog. At Perficient, we lean heavily on the pre-built reports and information radiators available in JIRA to provide complete transparency into iterative project status. What’s great about this is that it’s pretty much free if we use the development management tool effectively.
Confluence with Gliffy
The other half of intra-project communication focuses on the design and testing aspects of the project – ensure that the project is going to deliver high-value, high-quality product. We’ve taken our game to the next level on this front by moving our design and testing activities from the desktop (Word, Visio, etc.) to the intranet with wiki based documentation and testing. For documentation, we’re using Confluence with Gliffy for visualizations.
On testing side we’re using DBFit and FitNesse, a wiki based implementation of the FIT acceptance testing framework. Moving to these collaborative-by-design tools has broken the cycle of passing overly formal design documents around via email (or document repository) and created an environment where design is collaboratively developed in a transparent fashion.
Combined, these methods allow our stakeholders to stay engaged, check up on their projects when they want, and improve the quality and effectiveness of the face to face meetings we do have as everyone is better informed before the meeting ever begins.
After the project, communication is focused on operational metrics for the system in question. We generally measure:
- Usage metrics to determine where future effort should be focused.
- Data quality performance, especially spikes in rejects or long downward slides in some aspect of quality.
- System performance, especially changes in the load window.
- Support requests through the helpdesk ticketing system and/or the IT issues management system (they may be one and the same).
Again, these metrics should be visible to stakeholders to encourage them to stay engaged with the BI team after the initial project. We’ve found that these measures, especially usage metrics, are often a factor in repeat internal business for the BI team as stakeholders become aware of the value the BI team is providing to their business units.
