If you need big data solutions, chances are you need them now, not after a three-year development cycle. Big data business analytics solutions are big undertakings, but the right strategy will cut down on wasted time and take you from conception to early-stage ROI in the shortest time possible.
The main thing to remember at the outset of a big data analytics project is that it is only as successful as the business says it is. This is why forming a strong relationship with your business stakeholders is so important at the start of your project. Identifying a key stakeholder from the business with a vested interest in the project's success will help in a number of ways: coordinating active participation in the project from the business, defining the project and the metrics for its success, and managing expectations about what can and can't be delivered during a given timeframe.
How can you leverage big data in the shortest time?
With agreement from the business as to what the project should entail and what success will look like, you are prepared to establish a regular cadence of weekly sync-up meetings between the IT team and the business stakeholders to share progress, demonstrate new capabilities, and address any issues that may have arisen over the last week.
Quantifying the ROI on analytics projects can be a difficult challenge, but it's important to be able to identify and measure a set of ROI metrics for your project. We often say that big data infrastructures enable better decision making by business users, but these are hard to quantify. It may work best to define key use cases that your business stakeholders buy into; they will function as the measuring stick for your project. These might include:
User adoption: Did we achieve a certain penetration rate for a new analytical tool throughout our user base?
New operational capability: Did a certain capability, feature, or campaign launch on time?
Instrumentation for key corporate objectives: Can we measure how many users have migrated upward within our user segments this month?
A lot depends on the type of system you are building, whether it is a data collection project, aggregation and summary tables, new dashboards, etc. But no matter what type of project you are working on, it's a good idea to look around at the analytical infrastructure and see what's already available that could be extended or repurposed. If it's possible to bolt a new set of tables on to a system, and the required dimensions are all there, this could be a good way to save time and prevent redundant data storage.
But it's also important to assess quickly whether reusing infrastructure will work. If the original system needs significant modifications to support new requirements, you will probably be better off leaving it alone and building your system in parallel, rather than trying to negotiate the needed changes with whoever owns the original system.
For core infrastructure projects such as tracking or building the core ETL design, focusing on speed is usually not the best idea. Instead, focus on accuracy, completeness, and scalability. These elements will be foundational for the rest of your projects. When these core elements are in place and available, it makes sense to turn your attention to speed of ROI on analytical projects. Take the time to be sure your business stakeholders understand and agree with this emphasis.
Plan and build
Now that your stakeholders have bought in and you've assessed the landscape of systems, you are in the driver's seat, and it's time to hit the accelerator.
The first thing to do is dedicate your team's best resources to the project. If you must, negotiate with other teams to borrow their rock stars. You will go only as fast as your developers can take you. Get your management to agree on the priority of your project, so you can build a team of all-stars. To avoid unnecessary rampup time, find the people with domain knowledge in the subject area.
Now determine the bandwidth of your team. Given the scope of the project, how fast could it be done? Since you have assembled a great development team, you'll need to be open to their inputs about how long things will take and what is realistic to achieve in a given timeframe. Take what they say seriously, but don't be afraid to challenge them to exceed expectations, given the criticality of your project to the company's goals.
You will find that developers can go supernova for about two months at the most before it becomes too much, and you'll need to dial things back. You want to be clear that this is a temporary turbo boost, and that the work-life balance will return to normal after the mission-critical requirements have been delivered. Once that's said, it's critical to follow through on that, so that your best developers will trust you and be ready for the next supernova after some recharge time.
Be sure to reward your team for a job well done. Provide whatever rewards your organization can support. It's so important to remember that the success of big data projects is entirely due to the skill of your development team. You'll only get as far as these folks can take you, so embrace that, and let them know that they are valued.
Re: Big Data Partnering @saul I love the idea of the speed matrix. Never come across that before and could see it fitting in a number of areas I am working on now.
I see it working not only with the operating speed of the business but also the speed at which projects can be progressed.
Re: Big Data Partnering @Anna I'd look at that as a threat matrix... but adapt it into a speed matrix. What is the fastest route to take? As Ben discussed in yesterday's webinar, even bringin vendors in requires 'ramp up' time - so you need to know what you would benefit from (as usual) - but also envision how it will impact your overall speed. Will it deccelerate you in the short term but result in an overall higher top speed?
User Rank: Exabyte Executive 1/31/2013 | 8:12:07 AM
Big Data Partnering When planning Big Data project, I suppose it's easier and more straightforward identifying and bringing in employees from the company but at what point in the project should an enterprise involve external stakeholders such as suppliers and joint venture partners? What are the likely concerns from the IP perspective and what's the best strategy for addressing those potential hiccups on the way?
Supernova Heights Interesting HR point from @Ben here, "You will find that developers can go supernova for about two months at the most before it becomes too much, and you'll need to dial things back."
I wonder if this is often the first consideration to go out the window when pressure comes from on high to get the data doing what it is supposed to. There must be a lot of great staff who burnt out and became disillusioned on the back of more than two months expending the brilliant white light of that supernova's energy.
Re: blasted business @legalcio and the next step is for this ill definition to result in the C level losing patience with the big data operation. What Ben's pragmatic advice here offers are ways to ensure that those first signs of ROI are seen as quickly as possible. Not just to the data team, but in a way that the proof can be shown up the chain - resulting in more patience, more investment, and bigger results (we all hope)!