Prologue

Here are some typical stories, often repeated in various settings:

  • The development team is completely frustrated. No matter how hard they try it, they are not able to satisfy the demands of the business team. The business team is frustrated as well. They do not know how to make the developers understand what they need, and have a feeling they are going in circles.
  • Developer A and Developer B cannot work together. The project is in jeopardy because of the friction.
  • The project is running for a while, the progress is being tracked on a daily basis. The team does not seem to make any headway with the functionality however. The work is clearly derailed.
  • New requirements are added while the project is in progress, as they are business-critical. The development team strives to accommodate them. When the project goes over budget or over schedule, it is the development team’s fault. “You never told us”, the business users complain. As the damage control, new deadlines are issued, which are completely unreasonable.
  • Different teams keep working merrily on work assigned to them. When they are asked to collaborate, suddenly there are problems found. Unattended work is found in the no-man’s-land. The project scheduled is pushed back by a few months.

These are all painful stories. Can they be resolved, or even better, avoided?

The Challenge

Statistically, 75% of software development projects fail. They go over budget, over time, and most of the times come to a screeching halt.

The failure is caused by various reasons, unique to every setting. We have seen that often, there is more than what meets the eye. In one outsourcing engagement, for instance, the developers were seen as a non-productive bunch. “Clearly, they have skill issues” the client felt, and felt that they were being overcharged. But the underlying cause was some technical constraints which left the developers blindfolded, so they just could not deliver.

The Value Proposition

As the challenges are unique to a project, so are the solutions. It is a lot like healthcare. The treatment is unique to every ailing patient. The best hope for a patient is finding a good doctor.

Acism has a rich experience in software project delivery. We have seen failed projects and we have seen successful projects. There is a thin line demarcating the two. Once you have an understanding of that line, it is possible to work on the failure indicators and turn around projects to propel them into a success trajectory.

As in healthcare, the most important factor is the right diagnosis of the problem. A US based company had a captive offshore team in India. Even after 6 months of development, the team had not progressed much beyond login functionality. On the request of the CEO, we met with the team once. During the first meeting itself, we deep dived into the code that they had written, and diagnosed the issue. The issue was a faulty design that came in the way of development, and also (although they did not feel it then) the application would have been heavy on the resources. We shared our findings with the CEO. He was so impressed that he literally took the next flight to India to discuss with us what course correction was needed.

After the diagnosis, the course has to be charted out and the team needs to be steered on the path. We have done this on multiple engagements of multiple clients. In most of our engagements, once the turnaround is complete and the project is set to go in the right direction, we came out of those engagements.

Summary

75% of software development projects fail. Acism can act as the doctor to your ailing projects. We diagnose the problems, chart out a recovery path, and also see through the implementation. A turnaround can propel these projects into a success trajectory.

Epilogue

One would ask, isn’t it possible to do what is needed upfront and get the ball rolling from the beginning itself? Why wait for the project to nose-dive and then turn it around? Wouldn’t that avoid all the headache?

The answer to that is affirmative. For one client, a software development house, we have helped them to start their engagements and then stepped out when the projects were on track. But the challenge is that these projects run so smoothly from the beginning that most companies do not appreciate the value of the contribution made. They are boring, uneventful and have no spice. “It was a simple project anyways!” everyone feels.