Rescuing Your Software Project

Rescuing Your Software Project

At zu, new client relationships can begin in a number of ways: sometimes it’s a call following an event where we presented, sometimes just a successful RFP bid, sometimes folks chatting over a pint or two. Or, it starts in a fashion we think of as: “Software Rescue”.

The situation

This is the situation where the client’s software team (internal, external or MIA) is on the verge of either failing to deliver a project that is important to the organization’s goals and milestones; or after far too long, the application must become fully operational NOW or else heads are going to roll. This may be software for internal use, external facing functionality or to do with the roll out of a new product.

To meet the important deadline, the client software team usually requires injections in some measure of development expertise, coding speed, or project coordination.

Why does this occur?

We are, nevertheless, happy to start as the tow truck driver, charging over the hill to pull the frazzled occupants out of the ditch so they can reach their wedding on time. Or hit their product release schedule.

• The project is late
  Predicting the completion date of software is near impossible. It is, however, far more likely for accurate predictions to be made by development teams that are practiced, have delivered many projects together, and have a process for building exactly what users actually need and expect. An experienced team ensures resources are spent moving forward, not retracing and redoing. In addition, successful dev teams have disciplined project management that protects the development plan from getting out of control with scope creep and injections.

• Project complexities beyond coding
  Client developers, though individually skilled and committed to their craft, might not actually be well-practiced in creating software, especially as a team. The businesses they work for are not focused on software development, though software is important to them. The client developers are eager to create a solution, but software projects require many non-coding practices associated with planning and running the project.

• Acceptance criteria undetermined
  Like the majority of software projects that fail, the team requiring a rescue was unknowingly building something bound to be late and that users would never find acceptable. Cross-functional contributions and key information came to light too late. User experience was only considered in final stages. Project management – in a gatekeeper sense – was non-existent, lost with the team’s willingness to please late requesters. Capabilities outside their job descriptions, information beyond their event horizon and simple lack of practice are ultimately what made the valiant efforts of the coders unsuccessful, and needing a little help.

• Loss of key person or vendor team
  Project directors are often aware of certain weaknesses in their internal capabilities and so hire temporary contractors with particular strengths to overcome specific knowledge gaps. This may succeed in getting or keeping the project rolling, for a while. But when the consultant flies home or the original vendors go bankrupt and the project hits the ditch once again, the wheels can really fall off the wagon. Desperation leads to rash decisions that undermine the long-term viability and reliability of what is being built.

• Loss of continuity
  Being under time pressure and then losing key skill sets can cause panic, hasty decisions and a flurry of band-aids being applied to the code. Without historical perspective on the decisions to this point, or memories of the technical dependencies things often get worse fast. When zu comes in for a rescue, we firstly bring calmness to the situation. Band-aid fixes must be removed and a little real surgery done to regain integrity in the code base. We are confident in our approach, our team and our ability to help. For many rescued clients, this relationship continues with zu supplying the missing and needed element of continuity.

Rescue is the second best way for zu to become involved

Our preferred engagement is to become involved in projects at the planning stage. Here we start with the ‘Why?’ of what’s going on. We engage users to identify pain points, opportunities and intended outcomes, and then layer in an understanding of the technical ecosystem.

We are, nevertheless, happy to start as the tow truck driver, charging over the hill to pull the frazzled occupants out of the ditch so they can reach their wedding on time. Or hit their product release schedule