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.
User Rank: Petabyte Pathfinder 1/30/2013 | 6:12:23 PM
Re: blasted business There'e always some challenges in day first of implemention, Big data is going to change the rule of "data game", there's going to have some culture change, some clash within the company.
User Rank: Petabyte Pathfinder 1/30/2013 | 6:10:24 PM
Re: blasted business it's true! but IT professionals still have no idea on how to properly implement Big data stuff, they still addressing the issue in a piecemeal basis, they're not getting a good work.
User Rank: Petabyte Pathfinder 1/30/2013 | 5:29:42 PM
Re: blasted business Interesting topic! Big Data is gaining momemtum and buzz, I agree companies still don't know what exactly they can get with Big Data, they lack skills and experience. Even with tools and technologies companies still don't know how or when t use Big data.
User Rank: Exabyte Executive 1/30/2013 | 5:17:07 PM
Re: blasted business The initial challenge to a Big Data project is that the beneficiaries don't know what they don't know. We can ask them what they want to accomplish but with only a vague idea, or no idea at all of what Big Data is they can't respond. As CIOs our challenge is to wear the different hats of various departments and provide examples of value and ROI by using Big Data. And that means we need to understand more about how our respective businesses function.
User Rank: Blogger 1/30/2013 | 1:10:33 PM
Re: blasted business Hi Saul and Sara,
Thanks for these comments! My feeling is, it is really about negotiating a balancing act, and organizational clashes are to be avoided if at all possible. The IT group needs to serve multiple groups within the company -- Finance, Marketing, Sales, you name it. So the IT management is already dealing with how to prioritize projects for different groups given finite resources. Support from the business and measureable objectives will help as the PM attempts to garner additional resources to support a project that needs to be fast tracked.
The goal should be to set up win-wins, or at least acceptable compromises, amongst the stakeholders who include the business groups that are driving the project, the IT management who needs to allocate the resources amongst competing projects, and of course the developers themselves who have to go and execute the design really quickly.
User Rank: Blogger 1/30/2013 | 11:57:06 AM
Re: blasted business Very true @sarapeters! This is in opposition to a lot of c-level firms saying "we need big data, go and make this happen" with no definitions, no set goals. @Ben - is most of the struggle to get deployment up to speed involved in cultural clashes within the organization? (P.S looking forward to tomorrow's webinar!)
User Rank: Petabyte Pathfinder 1/30/2013 | 11:20:16 AM
blasted business Ben, of all the great advice you just gave this is the piece that will stick with me most: "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." So true, but it's one of those things that so many makes IT professionals either grumble because they disagree or blush because they know that it's true and know that they probably don't follow that good advice as much as they should.