All readers have their share of successful and failed software projects. Everyone has a favorite war story. But for software project managers, either in a company or in a consulting organization, 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 organization up and to the right. Reductio ad Gartner Group.
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 characterizing 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 optimization, 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 getpolitical (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 justblow 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 organizational 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 prioritize.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 finalize the statement of work, project schedule and budget;
- Just as the project starts;
- At the project’s 50 percent mark (in days or dollars, whichever comes first), and
- Before any “project get-well” or big go/no-go meeting.