23 Signs Your Cloud Project May Be in Trouble
On many an old map, unknown territories were marked, 'Here be dragons!' Sure, it's actionable, but it's not very informative. Centuries later, do we have the same problem with software project management? Here's how to slay the dragons that threaten to set your cloud projects aflame.
Wed, February 05, 2014
CIO — 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.