Rescue Projects – What are the 3 Most Common Causes?

… and How to Avoid Them in the First Place

Most of our client projects have a positive start:

• • A company is about to develop an innovative new medical product, or perhaps is planning to enhance or upgrade an existing product line.
  • Syncro Medical has been engaged early in the process to help with project planning as well as architecture and design.
  • The program is well planned, and the key stakeholders feel enthusiastic and firmly in control.

However, other projects come to us with less positivity. These are referred to as “Rescue Projects”. There is a wide range of causes, but the symptoms are quite common:

• • The current deliverable is inadequate. The software doesn’t function as expected. Features are missing/ incomplete. The design won’t sustain product needs and expectations.
  • The project is now late. Key milestones have been missed, customer delivery commitments are in jeopardy, and the competition is about to take a leap ahead.
  • The development budget is compromised … a new infusion of funds may be needed to right the ship.

While we prefer projects with a positive start (who wouldn’t?), Syncro Medical has successfully taken on many Rescue Projects. With an eye toward how to avoid getting into these situations in the first place, I’ll discuss the three most common causes of Rescue Projects based on what we’ve encountered during our many years in this business. And I’ll conclude with a summary of how we approach a Rescue Effort in order to ensure the best possible outcome.

From our experience, here are the three most frequent causes of Rescue Projects:

Offshore Complications

Failures intrinsic to offshore development tend to be associated with the larger-scale Rescue Projects we encounter. Due to language/cultural hurdles, large time-zone differences, staff churning and differing product expectations, disconnects can happen resulting in deliverables that do not meet requirements. Often the degree of nonconformance isn’t discovered until quite a bit of the development budget and schedule have been expended. Sadly, we have encountered quite a few of these situations – the most extreme of which resulted in cancellation of the entire program because the additional cost/time to remediate was simply too high.

HOW TO AVOID THIS SITUATION

As discussed in an earlier blog, the ostensible appeal of the offshore option’s lower hourly rates seldom, if ever, offsets the consequences described above. At the end of the day, the potential cost savings can be far outweighed by the implications of missed expectations, delays, and rework. Ask yourself, “Is it worth the risk?” – Many of our clients would say, “No.”. Our advice is to very carefully assess the risks/trade-offs before sending your project offshore.

Oversold Capabilities

In recent years, particularly with mobile and web projects, we have seen the results of what I’d characterize as a capabilities mismatch. For example, firms that specialize primarily in consumer/business websites and/or mobile apps fall short when it comes to medical app development. Without a solid understanding and commitment to the defined quality systems and development processes necessary for medical software, the resulting code can’t stand up to regulatory scrutiny. Firms lacking medical product development experience often overlook HIPAA and PHI considerations. When it comes to the user experience, they don’t understand the nuances required for medical end-users.

HOW TO AVOID THIS SITUATION

When evaluating vendors, look for a balance of the necessary technical skills and medical software development experience. If you needed to have your knee replaced, would you have your general practitioner do the job simply because he/she went to medical school? Probably not. Similarly, having skills in the platforms/technologies you need is only part of the solution. Equally important is knowledge of regulatory process, and considerable experience developing software for medical use. Frankly, we know there aren’t many firms that offer this combination of capabilities. So it’s well worth taking the extra time to find the right outsourcing partner.

The Individual Contractor is No Longer Available

A common theme in the Rescue Projects we’ve seen is the “disappearance” of the contractor who started the project. The individual contractor was brought in to provide a particular skill/technology required for the project – competencies not readily available within the client’s internal software team. Then, during a break in the action while the client did some testing (or perhaps because something better came along), the contractor moved on to a new client/project or disappeared completely. The project is now stalled with nobody around to jump-start it.

HOW TO AVOID THIS SITUATION

Unfortunately, the “disappearance” risk is inherent in hiring individual contractors (or in some cases a tiny development firm) rather than using a development firm with a full team of engineers and project managers. A reputable development firm will swiftly redeploy resources to adjust for any staff departures, illnesses, etc., and keep consistent management in place. When using individual contractors, you’re left holding the bag to search for/interview a replacement, and hope it works out. As you’re thinking about staffing options for a new project, consider investing in a relationship with an established development firm – not only to ensure stability for the project at hand, but also to have a knowledgeable resource available for future needs.

How We Approach Rescue Projects

In many ways, Rescue Projects can be more challenging than de novo development projects. Code has already been written, often by somebody else who is no longer available to answer questions. Documentation may be incomplete, if available at all.

Our first step is to collect all available source code and documentation. We’ll do an initial review to get a better understanding of what the starting point is, if the design is usable, and whether the existing code set can be used.

If we determine that the existing code base is usable, we then perform a gap analysis in order to determine which requirements have yet to be implemented, which ones may be in progress, and identify those that need to be strengthened or can be used as is. If the documentation is lacking, we’ll also include plans to supplement documentation as needed.

Alternatively, we may conclude that the existing code base is not usable (factoring in the time required to undo and/or re-do the existing code, as well as the risks of a fragile, pieced-together end result.) In this case, we’d be up-front and recommend starting over from scratch.

Early project analysis also includes an assessment of the development processes and quality system used, and how compliant the results are. Depending on the circumstances, the rest of the project may be able to follow the approach already taken so that the results are consistent. In other cases, though, quality system compliance may be lacking, and part of the rescue effort will be to bring existing design and code into conformance.

We’ll discuss all of these options with the client and help decide the best course of action. Typically, we’ll have a solid recommendation and plan on how to best proceed to turn your rescue project into a success within a few weeks of initial contact.

We truly hope that you don’t find yourself with a project in need of rescue. Hopefully, this discussion of the three most common causes of Rescue Projects helps you steer clear of such situations.

However, if you do have such a project, Syncro Medical can help. In our 30+ years in this business, we’ve thrown out quite a few life preservers. And, to extend the analogy further, we have resuscitated and revived many at-risk projects with barely a heartbeat.

Think you have a project that needs rescuing?

Request a Consultation or Call Us at 215.359.9355