Seven (Plus One) Suggestions for Software Success

Does the painting above evoke painful memories of your experiences working on software projects? If you’re in corporate IT, or more specifically if you’re involved in a marketing technology initiative, the scene might feel familiar.

Turns out it’s more than a feeling. Studies show that all too often technology projects, particularly software projects, do in fact result in a proverbial descent into hell.

For example, consider the findings published August 2015 by Genpact Research Institute:

• Of nearly $600 billion spent on digital projects, almost $400 billion was invested in projects that fall short of expectations and ROI
• Speaking to CNBC, the study’s leader Gianni Giacomelli mused “at least 67 percent of those efforts are either scrapped, or end up being underwhelming”

Or, consider the May 2015 article by Boston Consulting Group which references a pair landmark Standish Group reports from 2011 and 2013:

• The odds of delivering a large IT project successfully are roughly 1 in 10
• Over the past 10 years, some 18-24% of projects fail outright, while another 40-55% are either functionally incomplete, over budget or over time
• The risk is significantly higher for large projects: 27% of projects under $750k in budget fail, while up to 66% of projects budgeted between $750k and $3 million ultimately fail

And to beat the horse one more time for good measure, consider the October 2012 study by McKinsey & Company:

• On average large IT projects (both hardware and software) run 45% over budget and 7% over time, while delivering 56% less value than predicted.
• Software projects run the highest risk of cost and schedule overruns, with 66% over budget, 33% over time, delivering 17% less value than predicted

These are staggering numbers. And these are not just academic exercises.  I can personally attest to these conclusions with examples I know of firsthand.  In fact, I think anyone who’s been involved in technology projects will have no trouble offering up their own horror show of corroborating evidence.

We Need to Get Better

Does this mean should we resign ourselves to the seemingly inevitable? Should we just call it the new dismal science (the old one being economics) and attribute it all to the devil’s handiwork?

I don’t think so, and frankly I don’t think we can afford it. For one simple reason:  each day technology engulfs a greater share of our professional lives.

Whether we like it or not, business and technology can’t be compartmentalized any more. There was a time when business school professors would tag us as either Poets or Gearheads.  But today those two camps are bleeding into one.  As the WordPress team likes to say, “code is poetry”.  The crucial point right now, however, is actually the reverse:  poetry requires code.

I’m not going to claim to have the magic formula. Many really smart people have tried, yet time after time the scorecards come in with similarly abysmal results.  If it was easy it would already be solved.

Instead I’ll offer an approach that’s hopefully intuitive, pragmatic and at a minimum asks us to be brutally honest with ourselves. So for starters let’s stand up, state our names, and admit we have a problem.  Only then might these suggestions stand a chance.

Note:  the following focuses on software projects, particularly marketing software projects, although it may have applicability in other kinds of technology initiatives as well.

Introducing The 7S+1 Framework

Long ago McKinsey introduced the original 7S framework. This has nothing to do with that, other than the idea of finding 7 words beginning with S that convey an approach to a problem.  That would be the poetry.  Let’s talk about the code:

The +1 Part: Skepticism

Maybe I should have called this 8S, but 7S sounds much better. Besides, this +1 part isn’t really a discrete item but rather an overarching theme or state of mind.

I’m suggesting this extra part because when results are as poor as they’ve been, it’s time we admit that it’s not just that we aren’t doing the right things or doing them well. It’s also that we aren’t asking the right questions.

So if you’re contemplating a software initiative, I urge you to follow this guiding principle: infuse every aspect of your project – before, during and after – with a serious dose of skepticism.  Question everything and always demand clear answers.

Should you embark on the project in the first place? Will a cheaper alternative suffice?  Do you have the right people and capabilities on the team?  Is now the right time?  Can you get by with less?  Or the opposite, should you build beyond the current needs? Is your team ready to support it?  Are other teams willing to use it?

It’s your right and obligation to be skeptical about anything anyone says or recommends.  Take nothing for granted, and don’t be shy about repeating questions over and over like an impertinent child.  Because asking a million questions and insisting on clear answers isn’t childish, it’s smart and shrewd.  As a general rule:

#1: Skills

Skills, meaning technical expertise and problem solving ability, are the beating heart of software success. Unfortunately, these skills are often underrepresented in software projects, particularly in marketing software projects.  Basically, if you have Poets running projects with key elements of Gearhead in them, you’re asking for trouble.  That’s because, as I noted earlier, business and technology are now inseparable.

If your VP of Marketing isn’t thoroughly versed on the details of SEO, e.g. they have no idea where Google search results come from or how they’re ranked, they probably shouldn’t be your VP of Marketing. If a Project Manager doesn’t know the subtleties around segmentation, nurturing and lead scoring, they probably shouldn’t be managing a marketing automation project.  If your E-Commerce Leader doesn’t viscerally understand the implications of payment gateways and online catalogs, they probably shouldn’t be involved in those decisions.

Yet mismatches like these happen all the time.

To be clear, I’m not suggesting these are bad people or bad actors. In fact they’re probably good actors, just not for the particular role they’ve been cast in today’s movie, that’s all.  Without hands-on domain expertise in technology it will be very difficult for them to provide thought leadership and to visualize the ramifications of key decisions three steps removed.  And they certainly won’t be able to call bullshit when clever vendors stretch claims into reality distortion, as they often do.

Depth and breadth of skills, anchored in technical knowledge and problem solving ability, are today’s critical factors for success. These are necessary across the board, especially in leadership roles.

If you don’t believe me, consider the advice that Bill Gates once deadpanned to John Sculley, the former Pepsi marketing guy that ousted Steve Jobs from Apple: “Learn how to program.”

Or better yet, take to heart the words of Steve Jobs himself:

Software is infiltrating everything we do these days. Software is going to be a major enabler in our society… I think everyone should learn how to program a computer, because it teaches you how to think. I view computer science as a liberal art, something everyone should learn to do.

#2: Semantics

Words matter. They matter a lot.  Historically people have waged war because of words.  And currently, software projects often fail because of words.

The danger lies in the potential gap between features as stated, and their usage or interpretation in a real business context. For example, just because a vendor claims their product includes “document versioning” or “online annotation” doesn’t mean their versioning and markup features are what you’d expect based on your experience with competing products.  And they’re probably not what you’d expect based on your organization’s business context.

Remember that software companies, sales persons and consultants are genetically programmed to reply “Absolutely!” whenever you inquire “Does this have feature X?”  Technically they may even be right.  They do in fact have something in there that addresses X.

But when you peel back the cover to understand exactly what they mean by “Our X Feature” you often discover it isn’t what you thought. If you need proof, try comparing the high-level feature sets of directly competing platforms:  they invariably check all the boxes.  Dig deeper and you may find their particular implementation is incomplete, idiosyncratic, or simply unintuitive.

The result is not one colossal gotcha, but rather an expanding array of unexpected nits, annoyances and workarounds that eventually adds up to cause real damage. I often refer to this as “death by a thousand cuts.”  Truly an ignominious way to go.

Software success involves closing the semantic gap between the literal and the implied substance of words. It should be done empirically.  And even more important, it should be framed within the context of your organization’s needs.

Getting to the bottom of words involves detective work. Now ask yourself, is your team equipped to do that?  Check that beating heart (skills).

#3: Scope

Scope, and it’s promiscuous cousin Scope Creep, are among the most often cited reasons why software projects fail. For example, Boston Consulting Group and McKinsey both mention scope in the research linked above.  Trouble usually arises when any of three things is misunderstood or misjudged:

• Difficulty: a decision is made to include certain capabilities in the project, which prove to be far more costly, complex or time consuming than planned (blown budgets)
• Completeness: capabilities are built into the project, only to discover they require additional features in order to be fully operational or fully embraced by users (creep)
• Usefulness: capabilities are successfully implemented and released…and met with thunderous indifference (shelfware)

Project Scope is a key decision you normally define early on that points your fate toward success or failure the very moment it’s set. It’s a high-stakes game.  Fortunately there are a lot of great suggestions out there that should help.  In addition to those, here’s what I always tell my clients:

• Define Explicit Boundaries. Just as important as “what’s in” is a comprehensive list of “what’s out.” Make sure everyone knows, up-front and in gory detail, what is not part of the project.
• Consider Effort vs. Impact. Take the usual cost vs. benefit analysis a step further. Consider the Effort in terms of total cost (money, time, resources, distraction, disruption). Weigh that against Impact in terms of tangible and intangible benefits (capability, revenue, goodwill, adoption, excitement, political capital).
• Focus on Lowest Common Denominators. You can’t build everything for everybody (unless you’re into creep). But you can build a smaller footprint that’s helpful across the board. Distinguish between common needs across teams vs. specific needs for a particular group. Focus on the former and don’t let the tail wag the dog.

#4: Sequence

The order in which you execute (sequence) can be almost as important as what you execute (scope). You’d be surprised how often this gets ignored during software projects.

Here’s a little trick for you: always try to implement one of the easier, showier, funner and more visible capabilities early on.  Pick one that’s low Effort vs. medium-to-high Impact.  Also pick one that’s self-contained, meaning few points of integration with other systems or processes.  A quick hit often goes a long way to paving the road to future success.  It buys credibility and stimulates momentum.  But an opening fumble is hard to overcome and casts a pall that clouds future plans.

But sequence is about more than easy wins first. It’s really about dependencies.  So in order to define a winning sequence you’ll need to do two things:

• Identify All Prerequisites:  clearly identify both the necessary and sufficient conditions for success at each and every step
• Formulate a Comprehensive Roadmap:  arrange the steps into a roadmap that ensures all prerequisites – both endogenous (project) and exogenous (organizational) – are in place before kicking off any subsequent step or phase

Defining a Roadmap that identifies a viable sequence of steps, based on dependencies and prerequisites, requires a lot of organizational insight and technical understanding. It’s an effort inherently at the intersection of poetry and code.  Once again, check that beating heart (skills).

#5: Scale

Ever notice how software tends to look great in the demo? Snazzy, sexy and oozing with cool features.  The demo gods come at you like groupies inspiring your rock star ambitions.  Your users are going to love you.  Your promotion feels imminent.

Alas, the demo is not real life. Too often it’s all show and no go.  The reason is scale.

Basically, there’s a huge difference between 1 user doing 1 thing, and 10 users doing 10 things all at once, which only gets exponentially more challenging at 100 users. The obvious impact is on performance, but it’s much more pernicious than that.  Features that seemed simple and intuitive at quantity 1 have an uncanny ability to become onerous and prohibitive at quantity 10 or 100.

For example, 1 user electronically marking up a document is a vastly different proposition than 10 users sharing their online annotations in a collaborative review. Those 4 cool markups from the demo just transformed into a mess of 83 – all jammed into a laptop screen no less.  And later, when those users come crying for help, you’ll discover that tutoring the first user at their desk is nothing like responding to an entire fleet in a timely manner.

Software is like a drug in that it’s easy to get caught in the allure – and fallacy – of single digits. Those first hits might be fun, but you’re planting the seeds of your own destruction if you don’t watch out.  Beware the dangers of large numbers.

#6: Sales

I often shudder when consultants pitch clients on “Change Management.” Because to be perfectly blunt, it’s often pitched by individuals who don’t know jack about software (once again, check those skills).  They show up with a stack of glorious PowerPoints… and that’s about it.

Of course, you should definitely include change management as part of your project, just not in the form of slideware. The better notion is really about sales, specifically internal sales.

Done methodically and continually, sales is a great way to validate what you’re doing, to build consensus, to generate demand and to stimulate adoption.  In effect, sales greases the wheels of progress.  Here’s what I mean:

• Iterative Validation.  Some call it agile development, others rapid prototyping. Basically it’s a series of focus groups. Show progress, capture feedback, incorporate quickly, repeat often. It’s a mutually beneficial approach: you’re selling futures, they’re shaping it. Everyone wins.
• Consensus Building.  An iterative approach is by definition inclusive. It’s also a process of continual refinement. Drive toward a lowest common denominator that everyone can agree with. In effect, you’re building a base audience.
• Demand Generation.  Eventually, repeated exposure with continual feedback transforms the game from push (traditional sales) to pull (nirvana sales). As your audience “sees themselves” in the emerging solution they’ll get excited – they’ll even ask for it.
• User Adoption.  Your sales efforts also have an interesting side effect:  you’re effectively training and preparing users as you go along. Not only will they want the new solution, they’ll even get a jump-start on how to use it.

#7: Support

So you’re nearing the end of your long and (so far) successful software project, and you think you’re done. Well, not quite.  Software projects are like giving birth:  after 9 months you might think you’re done, but that’s when the puking and crapping starts.  Sometimes even worse.

Here’s the good news: many of the items previously discussed will contribute to your ability to support the solution going forward.  For example, testing, training and documentation will all benefit from the steps outlined above.  That’s a great start.  A few extra steps can help even more.

First, check those skills one more time

As the project transitions from development to rollout, make sure you retain technical expertise and problem solving skills on your side (e.g. the marketing or business team) rather than surrendering those entirely to the other side (corporate IT).  The reason is because retaining those skills ensures a high degree of self-sufficiency and control.

Specifically, designate an Application Administrator on your team, as opposed to a System Administrator on the IT team:

• Application Administrator (on business side): diagnoses “how-to and learning gaps” vs. “bugs and errors”, handles enhancement suggestions, makes configuration changes
• System Administrator (on IT side): handles environmental or platform-oriented issues, outages, bug escalations

Second, be prepared with protocols and procedures

No matter how polished and bug-free your solution may be, or how well trained your users are, the minute you go live is the minute phones light up and help desks gets flooded. Make sure you have a stack of diapers ready.  Also make sure you know what to do with them.  After all, first-time parents don’t know, and repeat parents don’t remember (traumatized by prior volume, perhaps?).

Successful support is about being rigorous, methodical and comprehensive.

Write down protocols and procedures. Make sure everyone knows what those are.  Train the trainers, train the users, train the support team.  Setup, test and deploy an issue tracking system.  Be prepared to develop and deploy critical enhancements and hot fixes.

Looking Forward

OK, I’ve covered a lot of ground here.  And, I’ll concede that sometimes when you dip a toe in the ocean you run the risk of getting all wet.  So let’s distill and recap.  A handful of key takeaways might be:

• Embrace those underlying skills
• Pick your battles carefully
• Work interactively
• Execute rigorously

But as they say… one more thing:

Remember, an unsuccessful project often spells the end of the road.  But a successful one begs a follow-up.  In short, you’re better off with a series of base hits than swinging for the fences.

So keep your projects small. You can include the extras in the next one.  Best of all, “small” even starts with an S.  In the end, maybe it’s really 7S+2.