Introducing RESQ – A service targeted at software projects in distress

Software project rescue

In my earlier blog we had discussed about why software projects fail.Software or IT project failure is inherent because of nature of the process and industry itself. There are various reasons why Software projects fail whether your organization has outsourced it to a vendor or it is developed by an in-house team.

  • The requirements are not frozen and keep evolving because it has to meet expectations of various stakeholders
  • The team is not technically capable of delivering expectations and scale of the project.
  • The budget and timeline estimates were wrong and the project has failed to meet critical milestones resulting in lack of enthusiasm or support from the sponsors, and teams.
  • The project comes to a standstill because of commercial disagreement or dragged into a legal dispute.
  • There is a lack of communication and transparency between the project sponsors and development team.

If your software project is stuck in limbo because of any one of the above reasons it is prudent to take a step back and reconsider your options. Because projects in limbo can take up significant time, resources and cost but provide no value whatsoever to the organization. It is in your organizations best interests to do a thorough root cause analysis and consider any one of the following options.

  • Scrap the project and hope that it will not have an adverse effect on your operations and business.
  • Engage an outside Project Management consultancy or professional who will help you restart the project with the same set of vendors.
  • Scrap the current vendor or IT team, get the requisite knowledge transfer from the team and engage a different vendor which specializes in Software Project rescue and re-engineering.

If you opt for the third option, it is where RESQ  from Maestro Technology services Pvt.Ltd.  and similar vendors come in.

How to rescue software development projects?

We at Maestro have a 3 step process, broken down into multiple steps:

  • Project Assessment
  • Project Re-Engineering and Completion
  • Communication and Support

In detail,

Project Assessment

In this phase we do a due diligence of the current status of the project, redefine objectives and deliverables of the project, because a long time has passed since initiation and requirements may have changed or waned. We take these learning and create a back to track plan with clear objectives and cost.

Project Re-Engineering and Completion

In this phase, we take a look at the code, re-engineer and clean up the code and then get into development and enhancement of the actual product while optimizing the infrastructure. We complete delivery of the project at this stage.

Communication and Support

Successful communication and updates are critical to the success of any project apart and also establishes relationships. On successful delivery, we provide ongoing support and maintenance for the project.

With over five years of experience in the industry, we have rescued various software projects from the brink by following the building bridges analogy and learning from failures, documenting them, following a clear plan, execution process and more importantly having a team that is empathetic to customer requirements.

If human history has thought us anything, it is that we should learn from failures and do course correction in due time. It is this very capability that has set mankind apart and contributed to human progress through centuries.

If you are an SME or Business that is in need of Software development rescue reach out to us

A Brand New Blog !

brand new blog

Today, at Maestro Technology Services we take on a new challenge. We enter the world of corporate blogging. With the 2 cents  weblog will primarily reflect on our Two Cents worth of…

1. Transparent functioning of a global IT services company.

2. Updates on clientele, partnerships and new launches.

3. News, views, opinions and reviews especially on emerging technologies.

4. Niche areas of software services that Maestro Technology services specialises in.

In today’s world, we look forward to a community-input driven alignment for our mutual growth and learning. We look forward to your involvement at every level possible and invite you to share your thoughts, or write a guest blog for us if you feel so inclined . 

Please sign up for our blog feed and reach out to us if you wanna write a guest blog .

Software Development and Building Bridges – An analogy

Software Development Rescue

“The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labor to perform the same task.”

– Tom Clancy (The Sum of All Fears)

In 1986 Alfred Spector then President of Transcorp and currently CTO at Two Sigma, Co-authored a paper which compared bridge building to software development. In the paper, he explains

“Bridges are normally built on time, on budget. Software never comes in on time or on budget. When a bridge falls down (or has technical and business difficulties) it is investigated, and a report is written on the cause of the failure. The resulting information is used to produce or refine the decision or decisions in an attempt to prevent recurrence of similar failures. This report becomes part of an architecture that is used to guide future decisions for successful bridge construction.However, in the computer industry failures are covered up, ignored, and or rationalized, which may be due to the absence of procedures for analyzing failures.

Subsequently, due to the lack of a rational explicit process, the same mistakes continue to occur and negatively impact the success of software development projects. Because of human failings, critical information is lost, decision making becomes difficult, and mistakes are repeated. It is the repetition of mistakes and the occurrence of new ones, because of improper decision making, that results in canceled projects, cost overruns, time overruns, and failure to provide expected features.”

A 2014 study by Standish Group claims that almost 48% of software projects are in a “Challenged” phase and 16% software projects “Fail”. While the study has its share of contestants, chances are if you are a software developer, project manager or a SME owner you would have come across software and IT development projects that failed for one reason or the other or projects that refuse to die, which are kept alive because of the critical need for the system or difficulties associated with admitting failure in large corporations although the initiative has lost momentum or gone out of control.

Apart from Alfred Spectors accusation that Software development failures are covered up or rationalized a huge problem today facing software development projects is frozen design and requirements are not always feasible because it does not accommodate changes in the business practices. Therefore, development teams, as well as project stakeholders, work on a flexible model. This leads to various issues and miscommunication and the end result is that the project ends up in the dumps. But in the case of building bridges this is rarely the case. No one wants to change the starting and ending points of bridges once the project has started, nor does the client expect a bridge designed for vehicular traffic to support trains. The design is frozen and the crew has little or no leeway in changing the specifications.

However, bridge building is not always foolproof as it seems. Over the course of human history bridges have overshot budgets, exceeded timeframes and some even collapsed. But today we have learned through failures and bridges are foolproof because of the extreme detail of the design.

Software Development Rescue
The Sanginotobel Bridge is a world renowned structure and International Historic Civil Engineering Landmark built by Robert Maillart .

So what are the learnings we can draw from this analogy and use it to build better software? The Standish Group study lists down top three reasons for successful projects.

  1. Stakeholder involvement,
  2. Support from executive management
  3. And a clear statement of requirements.

The key aspect that I believe determines success of the project is the statement of requirements or what we call a “Software Requirement Specification” (SRS) document. The SRS document should act as the gospel for all stakeholders not only during the entire duration and project from initiation to delivery but also beyond in testing and support phases. Whether you are a software development firm, an organization that has outsourced its Software requirement or working with an internal team, the SRS document is the first step in successful project completion.

Why is a Software Requirement Specification document necessary?

  • Customers are good in understanding their problems, but in understanding how it can be solved
  • Developers are good in solving problems but face difficulties in understanding customer needs.

A go to document that lays down all expectation and solutions in a tangible form will make it easier for every one sitting across the table.

Software Development Rescue
The widely circulated comic on social media. Its a jest on how software development is viewed by each of the stake holders

What makes a good Requirement document?

  • It describes a feasible project clearly and in detail
  • It reflects the needs and use cases of the customers
  • It gives a very picture of how the software will look, feel and work.
  • It gives a mutually agreed upon time line, cost and expected deliverables without ambiguity.

The Anatomy of a Software Requirement specification document

While there is no one right format or template to capture SRS, a widely accepted and used template can be downloaded for free from here. Different organizations and different professionals follow formats that suits them or they may be used to a particular format. But in general a good SRS document will have the following points:

Introduction

  • A brief outline and scope of the project
  • References

Project Description

  • Software functions
  • Types of users and characteristics
  • Environment
  • Assumptions and dependencies
  • Constraints

Interface Requirements

  • User Interface
  • Hardware interface
  • Software interface
  • Communication Interface

System Features

  • Functional Features
  • Performance Features
  • Security Features

Glossary of Terms

  • A review and explanation of all technical and scientific terms specific to the project covered in the document.

In certain instances, SRS documents do not live up to the expectation for the following reasons.

  • Missing or incomplete requirement gathering
  • Constraints not mapped thoroughly
  • Insufficient or poor quality of data and requirement analysis.

It is very critical that we follow established and strict process for requirement gathering and arrive at an iron clad SRS document. Understanding and drafting SRS documents is not a skill that cannot be mastered. With adequate time, training and intent every body can become adept at SRS and ultimately contribute towards a highly successful software project implementation.

We have come a long way from the time of Roman bridges.  We may argue that building bridges and building software is not the same but never the less, just as construction crews and engineers over time have perfected the art of stringent design adherence towards bridge construction, software developers and the industry should perfect the art of building effective software with documented requirements and specifications.