How to Rescue a Custom Software Project
We’ve established in another article that a failed software project has to be thoroughly assessed to determine if it can be rescued.If you’ve had an assessment done, and if the final report said it can be done and it’s affordable, then what?
Work with the Right People
It’s also best to have people doing the rescue that have done it before, and successfully, many times. They will be the software development group that can tell you endless stories of sad situations they’ve been handed, and how they’ve reached and exceeded expectations on those projects. Those software development groups won’t be cheap because it takes a lot of time, effort, and experience to perform a successful rescue. But it can be more than worth it. The cost issue goes back to whether the project was determined to have an ROI in the first place.
Have a Plan
To rescue a project, one needs a plan. This is true of creating new software from scratch, and it should also be true of rescuing a project.
The plan needs to be detailed, focused on the right goals and tasks, and reasonable in expectations of schedule and effort, among other things. The people creating the plan must understand why the project is necessary, what the client wants to accomplish as a business as well as what they want to accomplish with the rescued software.
Work the Plan
Once the plan is done, the team should be enabled by the client to do the right job. Doing the right job means following the plan.
We all know things don’t always go according to plan. When that happens, and it will, the team leadership and client will need to work together openly and honestly to assess the changing situations, determine the effect of changed conditions on the plan and project, and adjust accordingly to tack towards success.
This tacking doesn’t mean that the “captain” of the client’s team will say “get it all done in less time with fewer resources” and it will be so. That won’t happen. The client must understand what is reasonable. She or he must understand the project management triangle (https://en.wikipedia.org/wiki/Project_management_triangle) and take it to heart.
Instead, the client must be understanding and flexible. Don’t get me wrong, they can still be demanding. But they should think twice before attempting to bend reality to their will. Doing so will lead to another project failure.
Lastly, the team necessary to execute the rescue also needs to be top-notch. You don’t want a bunch of junior developers and a mid-developer with a PM because they’re available and less expensive. You also don’t want to hire a random set of people from a staffing firm, where those people don’t know one another, haven’t worked with one another, and don’t trust one another. The best team for a project like this is a tight-knit, trusting team of excellent software development people (developers, BA’s, QA’s, PM’s, dev ops, etc.) that follow best practices, communicate openly, collaborate willingly, and with strong leadership.
If you have all of the above, you’ve significantly enhanced your chances of success to rescue a software project. Yes, that’s a lot to do and have on hand…but if the custom software product is important enough, it will work out for the best in the end.