Tips from first-hand experience on better business specs (BRS); the importance of teamwork; quality in development and how testing is no luxury
We hear about the game-changing promise of data science nearly every minute. As a Business Intelligence (BI) specialist, I’m fully on board. But having BI and analytics work well for you is harder than it looks. As per Gartner, many companies have a long way to go before being really mature in their BI projects. Now, I’ve been working in some pretty interesting analytics projects over the last years, so I wanted to share some insider tips. Some tips that can help anyone involved in BI – managers and their teams – save precious time and money. When followed, I’m hoping the promise of big data can be better fulfilled, elevate companies to new heights – and make my data scientist heart sing ;)
Some premises – strategy is set and processes are clear
Before going into the tips I want to add that there are a couple of premises that need to be right for any business project. These are that the BI strategy of the company is clearly set out and that the team is well briefed on this strategy. The second premise is that processes are clearly defined for each activity performed by your team (change/incident management). If these are muddy – I’m sorry my friend but we may be doomed from the beginning!
So now for the tips:
Tip 1 – Make sure the Business Requirement Specification (BRS) works for the BI team (and not just the business)
So, you’ve got the BRS from the business and it’s finalized and approved as far as they’re concerned, but is it? Has your BI functional analyst and architect checked them out? No? STOP!
To save time during design and development and to prevent bad surprises during User Acceptance Testing (UAT) – when real expectations are often discovered – make sure you:
- Provide a standard BRS template to the business that ensures they list what the BI team needs to do their work. This also avoids receiving bad or uncompleted documents that you’ll need to embarrassingly reject! In the template make sure you have the business define how the project:
- Provides value
- Provides results that will be interpreted correctly by end-users and really fit their needs – or are they misleading?
- Looks for the simplest solution over a more complex one.
- Plan in a validation step – I recommend that, at the project initiation phase, you book a BRS validation meeting with your business partner that gathers expert insights from your analyst and architect. Make it clear that their expertise at this stage is crucial for good project results.
Tip 2 – Work as a team – design together!
No man is an island, especially not in a company. Make sure your design is robust and that the solution is in line with the company’s BI strategy and then ‘leverage eyeballs’ and work as a team. While a BI functional analyst may have the lead on solution design, have the data modeler and the architect sit together, challenge each other, review each other’s work. Also, the architect should always review the functional analyst’s solution design.
Beyond this, make sure you exchange and share knowledge across your team as well as across all project sub-teams. This way you get fresh input from people who have maybe experienced similar issues. I know the technical architect is generally the person who should bridge the sub-teams but in my experience that person is often too busy to disseminate all the info to all the relevant people. I see two simple solutions to this:
- Set up and promote the use of a Knowledge Management platform (e.g. Confluence, SharePoint, Git wiki)
- Have regular meetings to share current sub-team challenges, brainstorm and get advice on how others may have solved similar challenges in the past
Tip 3 - Make sure it’s all about quality in the development phase
Put a quality assurance system in place that includes evolving development standards, peer reviews and a release coordinator who validates the delivery of all milestones.
And don’t EVER call the ‘testing phase’ a luxury! Otherwise you risk unleashing data terror onto your users, who will never forgive you… But I promise, stick to quality and your project will be blessed!
Tip 4 – Make sure your system is open for continuous improvement
Just remember these three easy words: Measure – Learn – Improve – and all will be well in BI land.
Here, I recommend the team use the reporting features of project management tools and code management tools to measure. They offer valuable insights into the system’s pain points that we can learn from to continuously improve quality and service to your business partners.
So there you have them four easy tips that I wanted to share with you and clarify for myself. Now back to work and trying to implement them (for me too). Good luck! If you have any tips of your own I’d love to hear from you – please share them with me.