David Frederick's | iAIR BLOG

Consulting, Innovation, Strategy, Vision, Education, & Ideation

Archive for June 2011

World’s Data Will Grow By 50X In Next Decade.

Over the years I have worked with a lot of companies solving critical technology needs and helping them apply the right solution to their pressing challenges. The one area that seems to give most of my technology clients a major head ache is solving problems around information/content/data. How to store it, how to manage it, how to share it and how to optimize it. Particularly content and rich media.  So when I read this latest IDC research paper on how the world’s data will grow by 50X in the next decade, it only underscored the critical challenges around managing, protecting, accessing, and optimizing all of this data. Especially with the rise of cloud based infrastructure, applications and solutions.

What’s really astounding is that currently in 2011, the amount of data created and replicated will surpass 1.8 zettabytes (1.8 trillion gigabytes), growing by a factor of 9 in just five years. That’s a whole lot of data! I could write several books on the opportunities and challenges that this explosion in data will create, but for now lets look at some of the IDC data.

By 2020 the world will generate 50 times the amount of information and 75 times the number of “information containers” while IT staff to manage it will grow less than 1.5 times ( DF NOTE: Its a good time to get into IT Management Jobs!!)

In the next five years, these files will grow by a factor of 8, while the pool of IT staff available to manage them will grow only slightly. The IDC study predicts that overall data will grow by 50 times by 2020, and unstructured information — such as files, email and video — will account for 90% of all data created over the next decade. Astounding!

Topics: Computers/Infotech/UI


Written by David Frederick

June 29, 2011 at 10:44 AM

Rules For Finding The Right IT Vendor

As a consultant, I inevitably get asked questions about OR asked to help with the selection of software and IT vendors. The problem is, this is not a simple binary exercise. Selecting the right technology and IT vendor can be a very expensive proposition. Especially if it is done wrong or you don’t consider the many variables upstream and down. That’s why I found Robert Plant’s article “I broke all six rules for finding the right IT vendor” both amusing and spot on. When an IT project has enterprise-wide ramifications, you can’t afford to change vendors mid-stream, or worse, start over from scratch.

For those who are looking at enterprise or significant technology investments, I suggest you check out Roberts article, then call me.


I Broke All Six Rules for Finding the Right IT Vendor

-Robert Plant (Robert Plant (rplant@miami.edu) is an associate professor of computer information systems at the University of Miami School of Business Administration.)

Never underestimate a vendor’s willingness to say yes to a project that it knows it won’t be able to carry out. I’m entitled to give this advice because I did exactly that.

After the hurricane season ended last year, I decided it was time to upgrade the wood flooring in my house (people in South Florida don’t usually do major infrastructure renovations during hurricane season, figuring that if the roof blows off, insurance will help pay for upgrades). I called a vendor who had earned my trust and appreciation by rescuing an abandoned master-bathroom project (the previous vendor had demolished the original bathroom, never to be seen again) and had installed a set of fixtures from Hungary — an impressively difficult job, given that the instructions were in Hungarian. I made the fatal mistake of asking: Can you lay wood floors? Naturally, he said yes.

Things were fine while he was doing the easy stuff, but when he got to the steps and the curved walls, he started making it up as he went along. Eventually, the project needed significant rework, and floors needed to be ripped up.

Like many other difficult experiences in life, this immediately put me in mind of ERP. Implementations of enterprise resource planning systems, as anyone who has ever been involved with one knows, are often companies’ most complex IT projects. A CIO who has survived an ERP implementation can wear his wounds proudly for the rest of his life. I’ve been privy to many ERP battles as a board member of an ERP consulting practice, and I’ve heard many ERP war stories in my executive-education teaching.

That all-too-willing contractor who tried and failed to do my flooring has given me a new framework for thinking about vendor selection for ERP implementations, a critical success factor I’ve written about in my research. The lessons can be boiled down to six rules.

Rule 1: Don’t base your vendor choice on personal relationships. Those relationships can cloud your judgment. Objectivity should be the goal. To add further objectivity, use external consultants who will not be part of the ongoing project.

Rule 2: Don’t assume that a vendor with general skills can handle specialized projects. A generalist vendor may not have the requisite skills or access to the proprietary tools, source code, patches, and programmer-interface knowledge that are needed to modify other vendors’ software used in the system architecture — even if he’s smart enough to figure out instructions written in Hungarian.

Rule 2 gives rise to Rule 3: A vendor’s references to specialized solutions need to be subjected to high degrees of due diligence. The project team must satisfy itself of the vendor’s ability to perform the tasks required (legal recourse for poor workmanship or broken SLAs is neither a good solution nor a comfort to shareholders). One way to do this is to visit companies that have been on the receiving end of the vendor’s services. Many companies will spend millions on a software contract but won’t take the time to visit a vendor’s prior customers.

The next few rules apply after the vendor is in place. Rule 4: The formal specification should always be complete before work commences. Beware of methodologies that use prototyping, iteration, and other “specify as you go” models; they can add significant cost, delay the project, and create a design that is an endlessly moving target.

Rule 5: Payment should reward not just time but also the complexity of the task. This requires that a formal specification be complete prior to kickoff. Without such a plan, it’s impossible to predict the degree of complexity and allocate resources appropriately.

Rule 6: Insist that vendors be responsible for all aspects of system integration. It’s vital to ensure that third-party software works as specified, is delivered on time, and is maintainable over the life of the system.

Following those rules would have made my floor job go a lot more smoothly. But I broke them all. I was unduly influenced by my past relationship with the vendor, I assumed that general-contractor skills are transferable to specialized tasks, I didn’t check the contractor’s prior work in wood, I didn’t have a clear idea what the outcome should look like, the payment structure wasn’t weighted toward ensuring a flawless finished product, and I didn’t make sure the vendor was responsible for the totality of the project. Eventually, it all worked out, and I ended up with a very nice new floor. But it’s a good thing I didn’t have shareholders to hold me accountable for all the time and money that was squandered.

Written by David Frederick

June 7, 2011 at 4:04 PM