Home > Software Engineering, Uncategorized > How to guarantee failure of a global software development project

How to guarantee failure of a global software development project

No one wants to witness a failure of a critical software development project.  The failure becomes even more painful if the project has been sponsored at the highest levels in organization to achieve critical business results, for example:  provide 360 degree view of the customer relationship, enable multi channel customer marketing campaigns.

Yet global, critical, “failure is not an option” software development projects fail all the time.

Before getting to the heart of the matter, it’s good to start with a small grain of truth.  History has a way of repeating itself.

Peter Drucker said, “The purpose of the customer is to create customers (implied in his words:  nurture and grow existing customers)”.   Considering that new customers may not profitable until Year 2 or even later, it becomes critical to give some thought to Customer Relationship Management, or CRM.

There are plenty of lessons learned from failed enterprise CRM implementation projects:

– CRM is :  first – a clear strategy, second – an approach to implement the chosen strategy, and third – technology (may be but most likely)
– CRM is comprehensive and requires participation from all functional areas:  sales, marketing, customer service, fulfillment, finance to name a few

The biggest lesson learned from failed enterprise CRM implementation projects:  strategy is not equal technology.   If business goals are not aligned with how technology may support and enable these goals, it’s rather obvious that any global software development projects will experience a guaranteed failure.

It’s essential to first develop a strategy how to structure the project and align the structure with a) what (milestones), b) who (people), c) where (locations), and d) every dependency which will either inhibit or enable your project.

For the moment, let’s assume that the goals are aligned and technology roadmap to success is clear.

What could one do to ensure that a global software development project would experience an almost guaranteed failure?

The top reasons are (I will focus on execution related topics as they relate to building great software):

– Do not spend any time thinking about a solution approach (or strategy) which will recognize all major drivers of complexity:  process changes, architecture changes (many hidden requirements here), competing projects, functional migration efforts, new development efforts, technology platform changes.

– Make every team across the globe operate in the same manner, whether they are migrating existing functionality or developing new features

– Ignore timezone differences

– Declare that one approach will work for every problem (instead of matching one or more approaches to the specific problem)

– Spend no time on thinking about how to componentize major software deliverables

– Discount the value of “design by contract” approach

– Spend very little time on creating the build / test infrastructure which will help teams to integrate code developed in multiple locations

– Spend equally little time on planning rigorous automated testing procedures

– Underestimate how much time may be needed to clarify requirements

– Discount the value of an integrated program plan where all stakeholders understand dependencies and critical milestones

– Discount increasing concerns from business owners, such as “I don’t understand when my customer support representatives will be trained”

Global software development projects do not need to fail.   Simply reverse above ‘suggestions’ to increase your chances of success.

  1. Amandeep
    March 9, 2010 at 1:40 am

    Thanks, this is very insightful

  2. Luis
    March 9, 2010 at 4:37 am

    Leon,

    Your points are good. Another thing very easy to ignore is that:

    1. Developers abroad may not have proper communications. This may sound stupid, but I have had cases where they didn’t have a ground or cell phone which I could use to contact them.
    2. Because many can’t afford to live from independent development/contracting, they overload themselves with projects.
    2.a. Corolarium: some have permanent jobs (that will not disclose) but they moonlight to survive. And, if there is a crisis, guess who has the highest priority, your project, or their permanent job abroad?

    And so on. Unless you are dealing with Canada, Ireland, or any other developed country, the most simple assumptions may not work in countries like Mexico or India.

    Luis

  3. Steve
    August 18, 2010 at 8:00 am

    Luis:
    I would add that manytimes offshore teams have no concept of a market different from their own. When it is acknowledged that creative ideas often flow upwards from the programmer, this becomes an important factor. Churning out code without being aware of the final goals is rarely the solution for any project and is often missed.
    Timezone differences cause mayhem, having worked with Russian and Indian teams I speak from experience working until 5AM and then going in the office at 9AM is no fun.
    I would be very wary of committing a large important project to offshore development teams unless as you say it is from a developed country.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: