Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Anatomy of a cloud project cost overrun

David Taber | Feb. 7, 2017
A handful of areas in cloud integration projects produce cost ‘surprises’ with alarming regularity. Recognizing the pattern is the first step in solving the problem.

Solution strategy: Make the discovery phase longer, and when it’s complete have a signoff sheet for a strict feature and data freeze. Make the project team as small and tight as it can be, and do not hire more than one consulting company (to reduce finger-pointing).  Work to constantly improve trust among the team members. Kick people off the team who blame.  Keep executives and bean counters as far away from the project as you can, and limit big review meetings.  Focus everyone’s attention on business value rather than abstract or arbitrary metrics and project dashboards.

Why I’m an unabashed agile bigot

I’m currently reading the book “Being Wrong – Adventures in the Margin of Error” after having finished “Wrong!  Why Experts Keep Failing Us.”  So maybe I’m a little jaded, but it sure looks to me like cost overruns are the result of bad assumptions, fragmentary information, incomplete requirements and low trust. 

Interestingly, overruns are much less common for follow-on projects, where both sides have put the time in to develop good assumptions, a solid understanding of the real requirements and a trust relationship.  So for initial projects, we — clients and consultants — have to stop the pretend-certainty about our projects.

The truth is we don’t really know, and we’re not willing to spend the time and money to get sufficiently knowledgeable about, all the niggling details of a new project.  We run off and get a budget without knowing what the project will really entail.  And then we discover too many plot complications after we’ve reached the halfway mark in the project.  For those hoping that “hybrid agile” techniques will solve the problem, I haven’t seen much help there. 

In contrast, the real agile approach admits we don’t know, and simply scopes the project deliverables dynamically to fit within the budget and schedule.  The team discovers as they go, prioritizes as they go and focuses on maximizing business value instead of fixed (and possibly random) criteria.   When done right, agile makes the bean counters happy (they can claim “on time, on budget”) and gets the most important stuff out to the users as soon as it’s done.

 

Previous Page  1  2  3 

Sign up for CIO Asia eNewsletters.