Web development projects can sometimes fail. It happens for a variety of reasons, and your response to failure is what will determine if your project succeeds or doesn’t. The CHAOS report tells us that 71% of projects are doomed to fail at some level. It seems high, doesn’t it? But sadly, it’s true.
In this post, we’re going to dig into why projects fail, how to remedy a potential failure, and in the worst case, how to change web developers in the middle of your project. Let’s get started.
Why Projects Fail
Like anything else in life, projects can fail, and usually, it is for a variety of reasons and not due to any singular cause. The most common faults we see that eventually lead to project collapse include the following:
Bad planning: A project’s fate often depends on how well it was planned. All too often, clients or developers jump into a complex, custom web development project with little to no planning. They have an idea, a developer says they can do it, and work begins. But frequently, digital projects are agreed to even when they are 20% defined yet littered with 80% gray-area uncertainty. With this ratio, you’ll eventually run into trouble, especially when clients are trying to do everything for a fixed cost. This is something easily avoided by undergoing a proper discovery process prior to inking a deal.
Muddy Expectations: Agencies and developers need to do a good job setting expectations for clients. Clients who come in with a poor understanding of what it takes to complete a project, the challenges they will face, and the effort that it will require post-deployment are often going to end up unhappy either mid-project or shortly after. The expectations of both parties must be appropriately set and agreed to, or disaster could ensue.
Bad procurement: The hiring of a bad developer or agency is where we see that most projects fail before they even begin. There are tens of thousands of “development companies” around the world, yet in an industry where regulation is lax, and credentials are often not asked for, bad developers usually take on projects they shouldn’t be anywhere near. The result is never good.
Admittedly, there are more reasons why projects fail. Internal client politics, lack of skill on the part of the developer, loss of budget, legal or regulatory challenges. Those all can happen. But for the most part, the common themes we see are those mentioned above. So, what do you do when you feel as if your project is about to collapse?
First Things First
It may sound silly, but the first thing to do when your development project collapses is to admit you are in trouble. All too often, it’s human nature to sit back a bit and wait to see if things straighten out. But, it behooves you to make an impartial analysis of your situation and act with skill towards a proper resolution. That all means that you need to adopt some level of acceptance to the state of the situation. Then, you can begin to work on remedies.
How can you remedy it? Well, you have a couple of possible fixes. First, try to work out the issue with the current developer. If it’s just miscommunication and the talent of the developer suffices, then you should be able to work out the problems and move in the right direction. However, if it seems as though the developer simply isn’t capable, or the trust between parties has degraded, then it may be time to move on.
If you are in that situation, and remediation of the agreement or project with the current developer isn’t possible, then it’s time to plan how you can transition to a new resource. In that case, you want to read on about what you need to do next.
Making the Switch
Changing developers midstream is difficult. It means a re-initiation of the procurement process, which I’m willing to bet, was painful enough in the first place. And, it also means that the project is now more complicated because there was already some work done. Therefore, the value of that work needs to be determined.
The first step is to reach out to vendors that are familiar with how your project is being built. During the original procurement process, you may have spoken to several development teams. This may or may not be beneficial to you now - if you hired a team that decided to build upon a different technical stack than the others, it means the others can’t help you now. So, determine if any of the other candidates are still plausible in terms of both their technical ability and the capability of the team to get the job done.
Procuring a team to take over a project is not as cut and dry as hiring a team to build something from the ground up. In the case of a project that is falling apart, this means that you already have some level of assets that are built. New potential developers will need to evaluate what you have in place to see if any of it is salvageable. Every development team will look at this differently. Some want just to dump any work that was completed because they don’t want to deal with legacy code. Others will carefully consider what can and can’t be reused or reclaimed. Every developer will be different, and the process may be slow at times. At this point, you should seriously consider how much of an investment you made in the project to date and if continuing to iterate the work product is even worthwhile. It may make more sense, given what you know about the state of the project, to just start over.
Upon determination of the viability of what is already in place, you can then figure out the next steps, arrange a scope of work, and arrive at a budget to complete the tasks required. Now, it’s time to move forward. But, not so fast… You need to onboard the new team, too.
Onboarding & Triage
Onboarding a new development team often follows a familiar script, though, each case does have it’s own unique characteristics. Typically, the following steps or stages are required for successful onboarding.
Gather Assets: First, you need to make sure you have everything you need from the previous development team. If the relationship is broken down, it may be challenging to get everything of value from them. Though, in other cases, they may be happy to hand over what they’ve worked on. Every situation is different. However, if you cannot arrange to receive all of the materials, you may be in trouble with incomplete assets with which to move onwards.
It's also worth noting the difference between a design project and a development project. If you are working on a website redesign, you may want to transition during the design phase. In this case, make sure you have all of those graphical assets in editable formats. If its a pure development project, you want source code, database structure and data, and so on.
One final note - it's best not to burn bridges with removing the previous developer. Chances are, you'll forget something. The last thing you want is to have a nasty separation and then have to go back to them for a key component. Chances are, that will end up costing you something.
Lockout: If you do have assets such as a development environment, code repositories, project management tools, and similar devices, you should work to lock out the previous developer. Most of the time, the former developer won’t be a problem, but you never know. We always feel that safety and security are tantamount, and as such, you are better off taking all of the proper steps to lock out your previous developer.
Evaluate: Now that you have all of the materials you need and the previous developer is out of the picture, it’s time to do an in-depth, functional evaluation of what you have, and how useful it is. The new developer should, if they know what they are doing, first work to become acquainted with your development environment, or if you lack one, install a new one. This step is an essential best-practice, as you need a sandbox to work in anyway. And, in creating development environments, we often can determine functional bugs or quality of code along the way.
Establish proper procedures: Now that you have a development environment in place, this is an excellent time to establish procedures around how the development will progress with the new vendor. How can you review new changes? How can you test and accept/deny features? How will the deployment be handled? Any qualified developer will be able to work with you to establish these procedures and best practices, which will be in place throughout your project.
With the above steps taken, you now have an environment to move forward with, and hopefully, you have retained some control over the process in case you have yet another development crisis or need to switch teams yet again in the future.
Formulate an Immediate Action Plan
At this point, most of the worst is over. You have found help, onboarded, locked out the previous developer, and have procedures in place which will enable developers to start. The new developer has evaluated the quality of your code and is ready to work. But what do you do first?
Again, every scenario differs, but the process is always familiar. The key is to focus on what is right and carve out what’s wrong in a prioritized fashion. So, an action plan could look similar to this:
Find any immediate issues that need resolution: In the case of a new project that failed, and wasn’t yet in use by end-users, this isn’t always an emergency. However, if a developer took over a public-facing application or website, you may have true emergency issues that need immediate consideration. Focus on these areas first and formulate a plan to address them in an agile fashion as quickly as possible. If your project is not yet live, use this opportunity to evaluate the foundational changes that need to happen before further progress is made. These are items that fall at the core of what you are trying to accomplish. IE, if you don’t fix a specific problem now, the future of your product or application is not ensured. Those types of items are what need to be addressed quickly.
Review the existing specification: Everyone is now acquainted with the situation and aware of how things work. It’s time to formulate a plan to take you from where you are today, to the finish line. There is no magic formula to this process, but rather it takes some ingenuity between client and developer to come up with a strategic vision to wrap the project up in a way that satisfies everyone. One tip we can say is to consider making a list of sprints with features underneath. These “phases,” for lack of a better word, will help you guys stay focused on progress in short increments. Don’t confuse my use of the word “sprint” as indicating you should take an agile approach to your project, but rather as a way to break a large-scale effort into manageable pieces.
Prioritize remaining items: If you have taken my advice, and broken up your project into chunks, then you should prioritize the items in those chunks and sprints so as to focus on the quick wins you may need, or any pressing issues that place a priority on one item versus another. Again, this is project-dependent, so your requirements will most definitely vary.
By focusing immediately on triaging crisis items, identifying the gap between the current state and where you want to be, and then breaking it into prioritized pieces, you now have an action plan that should result in wins quickly, and produce some momentum to continue moving forward.
Complete the Reset & Stay in Control
At this point, you can again return to normalcy. However, your focus must always be on avoiding another similar instance from occurring. Relationships can sour, and it’s up to you to always make sure you are empowered along the way.
How does a client stay in control of their project? By executing a few common-sense tactics:
- Have milestones along the way with deliverables. As you pay, receive the assets you have paid for.
- Understand every aspect of your project. How it’s built, where it lives, etc.
- Have regular standing calls with your developer to review progress.
- Have access to project management tools to view updates.
- If you feel like things are spiraling out of control, have a code review done.
These steps, which are all common sense, should give you some more power, or at the least, some diagnostic ability to see how your project is progressing.
Wrapping Up
It is sad that such a post needs to be written, but disaster recovery is a large part of any development business. All-too-often we hear from clients who have had a bad experience one way or another and need to go through the above process. If you are still with me and reading this, remember that you can remove much of your risk during procurement. So, if you haven’t already signed on the dotted line, take a step back and work on evaluating where you are at, and whether or not your project is doomed to failure before it even begins.