{"id":12847,"date":"2015-10-13T00:00:00","date_gmt":"2015-10-13T05:00:00","guid":{"rendered":"https:\/\/centricconsulting.com\/post\/chicago-five-ways-to-tell-if-your-project-needs-rescuing\/"},"modified":"2021-12-15T00:12:20","modified_gmt":"2021-12-15T05:12:20","slug":"chicago-five-ways-to-tell-if-your-project-needs-rescuing","status":"publish","type":"post","link":"https:\/\/centricconsulting.com\/blog\/chicago-five-ways-to-tell-if-your-project-needs-rescuing\/","title":{"rendered":"Five Ways to Tell If Your Project Needs Rescuing"},"content":{"rendered":"
There are plenty of other studies out there with their own figures, but the key message is this: Well over half\u2013 at the very least\u2013 of software development projects will face “challenges.”<\/p>\n
Obviously, you want your projects to not be on that list. And let’s generously say that your projects never have those sorts of problems. But other people’s projects do, and sometimes you’ll get asked to rescue those projects.<\/p>\n
Rescuing projects is clearly a common activity; too many projects need help, even more so because so few projects simply get killed when they have problems.<\/p>\n
Finally, there are the projects that truly in desperate shape. How can you tell if your project is one of these?<\/p>\n
The less emotional way to judge a project is by what the risks are compared to where the project is in it’s lifecycle.<\/p>\n
Early in the project, an indication that a rescue may eventually be needed is that the project has significant issues that are already indicated as “red,” with near-certain impacts on schedule, although no delivery dates may have been missed yet.<\/p>\n
In the middle phase of a project, the danger is suggested by significant issues indicated as “red,” preliminary delivery dates have been missed, and it\u2019s becoming apparent that deployment dates cannot be met.<\/p>\n
Late in the project – near when the project should be completing its deliverables – the need for rescue should be obvious: the project has missed delivery or deployment dates, and not by a week or two.<\/p>\n
Those are the unemotional answers. However, if you’re using words like “rescue,” you’ve probably already got a pretty emotional situation.<\/p>\n
That sort of situation looks like this:<\/p>\n
In short, something has gone terribly wrong, and incremental change will not work. The project is drowning and needs to be rescued.<\/p>\n
Given the dreadful situation the project finds itself in, it should be no surprise that the remedy will be uncomfortable.<\/p>\n
Making the Decision<\/strong><\/p>\n A project cannot be rescued without significant changes to its structure, scope, resources, approach or objective. If all it took were a minor tweak, you wouldn’t be talking about rescuing it.<\/p>\n So when we talk about rescuing a project, all of those things have to be on the table. If anything is kept off, you’re restricting your ability to make the changes necessary for success.<\/p>\n