« First Impressions: Vudu's "Vudu to Go" Beta Software | Main | How Has the Definition of "Scholarly Journal" Changed? »
Tuesday
Jan292013

Recouping “Big Data” Investment in One Year Mandates Serious Project Management

By Dennis D. McDonald, Ph.D.

Click or tap the image to download a .pdf of this article.I chuckled when I first read the title of John Weathington’s recent TechRepublic article, Recouping your big date investment in one year. Nevertheless, this short article provides useful food for thought about the importance of effective project management.

Let’s examine the main sections of Weathington’s article.

Focused team

This section’s main points include:

  1. The necessity of a clear statement of the desired outcome.
  2. Engagement of a focused team consisting of:
    1. Managers, analysts, and content experts.
    2. Senior and junior person in each of these areas.
    3. Plus an extra analytics or content expert.
  3. An explicit one year plan where:
    1. The team spends the first quarter on planning and set up.
    2. The last three quarters are devoted to implementation and regular releases of useful functionality based on an Agile or Scrum project management approach.
  4. Project management spends constant but flexible attention on technology, process, and group dynamics issues.
  5. The team maintains flexibility and switches directions as necessary.

Conclusion

The main points in this section include:

  1. Payback within one year is possible.
  2. Of overarching importance: strong leadership and a disciplined approach.

My Comments

Of all of Weathington’s points the ones I find most critical are:

  1. Strong leadership.
  2. Dedicated team with necessary skill.
  3. Early emphasis on planning and set up.
  4. Subsequent focus on monthly functional deliverables.

These success criteria are certainly not unique to “big data” analytics projects. They could be the basic tenets of successful Project Management for any  project that combines technology and process change.

I especially like the regular delivery of functionality. That’s basic Agile management philosophy. While there is a danger that focusing too closely on early deliverables with functionality can lead to risk-averse behavior we’re dealing here with the delivery of useful analytical functionality. Such incremental delivery can stimulate and encourage process change as users are helped to modify their behavior to take advantage of new releases. As all project managers know, process change can be significantly more challenging than technology change. Engaging with the customer or client “early and often” is thus good advice.

Here are two more thoughts about the realism of Weathington’s  approach:

  1. The one year recoupment period. Let’s be conservative and say that the direct costs to the organization of this seven person team working full-time for one year is $1 million. If you can’t recoup such a minimal investment in one year with a high quality dedicated team, are you doing something wrong? Perhaps. Actually, I’m less concerned about the recoupment than the fact that the author seems to be suggesting that the team establish its own targets, but I may be misunderstanding something here.
  2. The tightly focused team with a mix of managers, analysts, and content experts. The author points out, rightly, the difficulty of gaining access to dedicated content expertise for the duration. By “content” he means familiarity with the organization’s business. As a career long consultant and contract manager I know how difficult it is to get access to such expertise on a regular and consistent basis from busy clients. Such experts, especially the good ones, are in constant high demand in most organizations. Bringing in outside consultants as content experts is only partly a solution. Ensuring access to such expertise should be part of the project’s risk management plan.

Still, I like the author’s focus on targeting specific returns on investment. These may be difficult to quantify in areas such as government programs, which is where I have been researching the most lately.

Targeting specific ROI levels helps us go beyond the “if we make the data available someone will figure out how to generate something useful” attitude I hear about sometimes when improved data transparency is discussed in the context of government programs. Having focused much of my own career on information products and services such loose talk about outcomes doesn’t fill me with a great deal of confidence. Taxpayers spend a lot of on government programs. We owe them a decent return on investment – especially when we’re talking about “big data.”

All in all, a tightly focused and well managed project sounds like a good way to go, especially if early and regular useful analytical functionality can be delivered.

Copyright (c) 2013 by Dennis D. McDonald, Ph.D. Dennis is a Washington DC area consultant specializing in collaborative project management and new technology adoption. His clients have included the US Department of Veterans Affairs, the US Environmental Protection Agency, Jive Software, the National Library of Medicine, the National Academy of Engineering, Social Media Today and Oracle, and the World Bank Group. His experience includes government contract research, software and database product development, system integration and consolidation, and IT strategy consulting. Contact Dennis via email at ddmcd@yahoo.com or by phone at 703-402-7382.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (2)

Hey Dennis! howzit goin? A couple of thoughts:
1) Your PM notes are solid as always - Big Data, any project, can be more confident of measurable success with strong Project Management.
2) Possibly not enough emphasis on the need for non-technical stuff, like training / commitment to "insight" and "imagination - just becasue we aggregate all this Big Data won't automatically make the end-users "more curious" and "insightful
3) Must we really wait a full year for results? Why not lean on the Agile / Scrum mentality to design first and second iterations that deliver some value - even if "value" means "first and second Sprint will focus on _quick_ proof of concept for most difficult data request, or biggest assumption, or highest probability return, or biggest potential maintenance nightmare - anything that might signal a need to cancel the project in month 1 or two.
I don't know of many projects that would allow 12 months of waiting before any sense of Return would be seen (in many orgs, run the risk of losing exec sponsors in that kind of timeline)
February 6, 2013 | Unregistered CommenterJames MacLennan
Jim -- I agree you have to start delivering value sooner, though I'm questioning whether you can really "recoup" everything the first year. It will depend on the project of course.
February 7, 2013 | Registered CommenterDennis D. McDonald

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.