ground rules for success in a dynamic, new media environment

In the previous entry, I made the statement that many of us working in new media don’t have a clue about what’s going to be successful and what’s not. I wanted to expand on this topic with a few key points. At first glance, you could interpret these as being pet peeves. My intention, however, is to set some basic ground rules for success even in a space where tools, technologies and strategies change at the drop of a hat.

1. Stop pretending every new product is a panacea that’s going to change the world.

   Many so-called "Web 2.0" tools fall into this trap. I mean, since microblogging has never existed before, how are we to know that Twitter is going to either be useful or make money? Or, casting the net even wider, how do we know that users are going to want to comment on every single piece of content on the World Wide Web?

   By all means, let’s go ahead and try things as experiments, but we shouldn’t kid ourselves that many initiatives are anything but science projects. (For example, we’re beginning to see a backlash against what I term LGC – Luser Generated Content.)

2. Know what you mean when you choose an enterprise solution.

   "Enterprise solution" means different things to different people. To me, "enterprise" means that the software is stable, extensible, standards-compliant, has a large community using it in the specific business domain, and is scalable both in the content-delivery (audience-facing) and content-creation (internal-facing) sides. I don’t care if it’s a massive web farm of Drupal servers; if that works and it meets the foregoing requirements, I would call it enterprise-ready.

   Frequently, however, "enterprise" is interpreted as a proprietary solution that costs six-figures, is not easily extensible beyond what the vendor provides, does not adhere to any or many standards, and is backed by a large vendor that "we can sue if things go wrong".

   This isn’t a diatribe against such software, and I actually would consider some of it enterprise-ready, but not just because it’s big, costs a lot of money, and is backed by a large corporation.

3. Top-notch project management is an absolute requirement.

   Many new media projects are initiated without a clear project charter defining basics like stakeholders and project sponsor, the resource requirements and constraints, or even a basic scope. Secondly, scope change, and the impact of change on the project’s other basic constraints of time or budget, are frequently not managed properly. These are project management basics and without the basics, projects are almost guaranteed to fail, or at the very least, become death marches.

   Given that almost all new media projects are, in my view, high-risk (because they frequently operate under severe time, budget and scope pressures, using untested technologies), detailed project planning is a pre-requisite up front so you can determine if the project is even going to succeed before a single hour of implementation labour is wasted. If it’s not going to meet the agreed objectives, then why start the project? In the new media arena, there are always fifteen other candidate projects to be done instead of the one you decided to not do.

4. If in doubt about choosing a solution, adhere closely to standards.

   I’m not going to violate rule one and sell standards as a panacea, but standards bring another layer of order and discipline to an already chaotic world. They also ensure that others are going to be in the same boat, so you’re not alone if the standard changes. They also provide an exit strategy and a migration path out of systems. For example, I have previously advocated for a web content management system for news sites, built on storing articles as NewsML. This would maintain future compatibility, and makes data interchange (say, with partners) a cinch.

5. Speed is no excuse for disorganization.

   Time to market or a hard, fixed deadline does not justify a failure to approach problems in a rigorous, logical way. This rule is highly correlated with my point about project management, but I feel I must state it again. We don’t start civil engineering projects by pouring the concrete first and doing the design as we go along, so why should we do new media projects like that?

   Many managers abuse agile development methodologies, thinking that Agile obviates the need for proper planning. I would argue that agile methodologies can only be successful if you already have a good culture of planning; otherwise, they simply become an excuse to "whip the developers" into a free-for-all.

As I mentioned, one theme I keep returning to is that of project management in the new media arena. In a later post, I’ll delve more deeply into this topic with some lessons learned from my work experience as both a sysadmin and a developer (and with details sanitized so that readers won’t know if I’m talking about CBC projects or not!)