23 signs your cloud project may be in trouble

All readers have their share of successful and failed software projects. Everyone has a favourite war story. But for software project managers, either in a company or in a consulting organisation, there's surprisingly little up-to-date information about what causes budget overruns and schedule slips.

Of course, management consultants worth their name will claim that their methodology will fix the problem - and they'll almost certainly have a two-dimensional graph showing how their expertise will take your organisation up and to the right.

Things aren't that simple. The Standish Group's Chaos Reports - a sort of CSI for IT murders - provide solid evidence that the success of software projects depends upon dozens of factors.

Having done these analyses for 16 years, Standish Group has been able to show depressing consistency in the problem areas and the project failure rates. This data works well for on-premises software implementation, both software package extension and bespoke application development.

Unfortunately, it's a little too early for solid data about cloud projects. So I'm going out on a limb here and characterising things from the 150 Salesforce systems that my firm has deployed. (If anyone has good data to add, please send it to me so I can improve upon this article.)

4 cloud project problems that are harmful but not fatal

Let's start with a list of the things that do contribute to success or failure but don't seem to dominate the cost/schedule/customer-sat outcome in cloud projects:

• Requirements that aren't worth the cost or effort. This is waste, pure and simple, but it rarely overwhelms a cloud project.
• Inadequate training on a particular system or tool. Learning curves are a pain, of course, but it's only a one-time cost if you've got the right people.
• Coding or configuration errors at the module or "feature-unit" level. These are a pain, but they're pretty easy to troubleshoot and repair, since they're not system-wide. You need a lot of these to really take a project off the rails.
• Unwillingness to cut losses. Fail-fast is an important optimisation, but holding on too long typically won't kill your budget.

7 cloud project problems that can be fixed mid-flight

Next is a range of issues that have a larger impact but can hopefully be detected - and corrected - before the project gets too far along.

• Team members who have issues with mathematical or data-model literacy. Fix this in the interview and selection process.
• Team members with written and verbal communication problems, particularly when it comes to problem solving. Root this out through testing.
• Overwhelmed team members who can't keep up with development, review and test commitments.
• Coding, configuration or integration errors that span several objects or multiple cloud services. Since these errors and omissions require cooperation and a common understanding across several team members, this can be helped with a shared-document system and agile development techniques.
• Having too many "B" players and not enough "A" players. This is brain surgery, not flipping burgers. There's no substitute for talent, attitude and domain knowledge. "B" players will drive up costs, no matter how small their paychecks.
• Spreading the team across time zones. Remember, distance is deadly.
• Bad assumptions or magical thinking about the way objects and RDBMSs work. (Believing that updates across objects just happen, for example, or thinking that deduping happens spontaneously.) This leads to the dreaded, "But of course the system will take care of me ... "

12 cloud project problems you must head off at the pass

This final category includes serious, pernicious issues that must be identified and corrected before the project beings. Many pertain to "soft issues," especially those surrounding communication, politics and business process.

• Lack of understanding about the quality and meaning of existing data sources. Since the cost of data cleansing, transformation and integration can easily swing by an order of magnitude or more, it's disastrous to do cost or schedule estimates without having access to some real data and people who can interpret it.
• Incorrect assumptions about access to external systems or data. This can get political (and costly) fast.
• An inability or unwillingness of security and other systems review committees to approve what you want. This adds to dithering, delay and, sometimes, nonsensical requirements.
• Management's unwillingness to involve the right users in the design, prototyping, implementation or deployment phases. This first-order no-no happens with surprising frequency - often accompanied by my-way-or-the-highway thinking.
• Weak or fake management championship. Executives tend to behave as if granting the budget is the end of their responsibility, when in fact it's just the beginning of a process spanning many quarters. An inattentive budget holder is about as dangerous as a distracted driver.
• An inability or unwillingness to face facts or communicate bad news early enough to make a difference. Say "Yes" or "No problem" too many times and you'll have a huge issue offshore.
• Expecting to manage a software project like a hardware deployment. That will just blow up.
• Maintaining long-running projects with large, interdependent teams and Big Bang deliverables. Keep things small, simple and separable.
• Writing ill-stated requirements or stating needs with false precision.
• Writing requirements that simply don't matter - often because they were added to a document out of expediency.
• Business process that evolve rapidly, particularly if there's a big organisational change. This goes double for M&A or divestitures; during such tumultuous times, only undertake projects for reconstitution, system survival and business continuity.
• Business processes that are unknown or incorrectly mandated. We've seen cases where executives stipulated business processes that haven't been true for years - or that never existed in the first place.

Look to Van Halen's brown M&Ms for problem-solving strategies

You probably think I'm going to harp on endlessly about agile. (Me? Never!) Instead, I'll take a tactic from, of all things, public relations.

As a project leader, you have to look for each of the 23 issues listed here. But you can't afford to nail them all. You've got to prioritise. Wargaming is a PR tool that gives the most actionable form of "sensitivity analysis" - the ultimate triage.

The first part of the exercise identifies the top five things that you know could kill your project and comes up with a contingency or corrective measure should it occur. The second part finds the top three things that might come out of the blue to hurt you.

With that second list, you set up some canaries in the coal mine to act as an early warning system. (For a non-IT example, think of Van Halen and brown M&Ms.)

A typical wargaming exercise shouldn't take more than an hour. It should be a cooperative exercise that involves both management and the team (either staff or consultant) and occurs at four critical junctures:

• While you finalise the statement of work, project schedule and budget;
• Just as the project starts;
• At the project's 50 per cent mark (in days or dollars, whichever comes first), and
• Before any "project get-well" or big go/no-go meeting.

David Taber is the author of the Prentice Hall book, Salesforce.com Secrets of Success, now in its second edition, and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel and India. Taber has more than 25 years of experience in high tech, including 10 years at the VP level or above.