Understanding Your Situation
Coming to terms with the fact that you are experiencing a problem in the software development process is not the easiest thing to do. Usually, by the time that company resources and developer hours are heavily invested in the project, there is a working relationship between you and the developer. In custom software development, there must be a level of trust that the developer is the expert and that he is able to complete the project to fit your needs.
It is generally not a comfortable experience to question this relationship and confront the developer, especially when the subject matter is outside of your own expertise. When your developer refuses to fix problems, adequately explain repeated delays, or provide you access to your own staging environment, there is a good chance that your developer may need outside help to complete your project the way your business needs it, in a reasonable time-frame.
As software development practitioners, we frequently run into these uncomfortable scenarios, and they always present quite a puzzle since it is not just a technology matter, but more often than not, there is a human factor involved. So, we thought this issue is a worthwhile topic to explore, since one thing is certain: software hostage situations happens too often, and at great cost.
Still not sure what I’m talking about? Consider these two examples of what a software hostage situation looks like:
Example: Scenario one
A small startup company contracted a software developer to create a system that would provide care services to people. The developer consistently failed to meet deadlines and was asking for money in order to move forward. After a couple of months of this, the company couldn’t go live.
Example: Scenario two
A planner at a large manufacturing company was using Microsoft Access to track international supplies. The company’s IT department decided to implement Oracle as a solution, only the task took them five years with nothing to show for it.
Faced with such scenarios, the question then becomes, “do you let the project continue the way it is in the hope that things get better, or do you contact outside help to get the project back on track?” This is your moment of clarity; one way or the other, you understand your situation.
Reviewing Your Options
Assuming your answer to the question above is that development has stagnated, and things need to change, the next course of action is to assess your options. The worst-case scenario for you is that your developer or development team was both unqualified and malicious in draining your company’s resources so that as of now:
Your project is not launched and there are unexplained delays;
It lacks the necessary features and the developer refuses to implement them;
You do not control development and the developer refuses to give you access to the source code without explanation;
And your developer increases the budget without clear explanation and even withholds project releases until they are paid more money.
Not all hostage situations are this dire, and the vast majority of developers that cause hostage situations are not malicious; they merely need outside support to get the job done. In any case though, you need to set a goal to move your project to a place where progress is possible and you can once again be in control of the development process. Your key options are as follows:
1. Communication
Solving almost any problem begins with talking to the developer. There is always a chance that miscommunications were the source of your problems. Clearing the air might just be the optimal solution for getting things back on track. Clearly explain what you like and don’t like, asking all the questions you have as well. Together with the developer, make a new plan of action to reboot the development process.
For instance, in “scenario two” above, Tizbi stepped in to salvage the situation. The first thing we did was to talk to the planner for whom the system was intended. The planner explained that he was comfortable using Access and therefore his requirement was simple: he wanted to be upgraded to a simple server database. The oracle implementation was thus an unnecessary waste of money and time.
The lesson: There was no alignment between the end user (planner) and the developer (IT), hence the wrong system was being implemented. Not to mention, both parties should have worked with clear deadlines and consistent communication all the way. Never allow a project to drag on indefinitely; communicate always and pull the plug once it’s clear there is no way forward.
2. Focus Development
Sometimes, the problem with the project occurs when there is a disagreement about what is essential. The solution to such a disagreement is to get a minimum viable product (MVP) as soon as possible. By excluding all of the features that are not absolutely necessary to the software at the present moment, you and the developer can focus on putting together a workable product. If your current project is blocked because there is a disagreement on what is important, stop adding new features immediately and finish the necessary functionality first.
Why an MVP is the best option
An MVP will give you the opportunity to test what you like or don’t like about the software, its features and performance.
-
You’ll get the software to its users within the shortest time and least budget.
-
It is also a great way to focus your developer’s time and effort. This way, when they get to work on the second phase, their main goal will be to improve on the first iteration.
Which features should you let go off and which do you keep?
Letting go can be difficult but at this point, you really have no choice. To help you decide, ask yourself these questions regarding your software:
What is the intended value/benefit of the software?
-
Which features best enable the software to offer this value?
-
Would customers buy the software if it did not have feature “X”, or would they mind not having the feature?
-
Does the MVP line up with what end users want? Will it be viable enough to support end users’ everyday goals? use and are the features sufficient enough to support end user goals?
3. Technologies
Sometimes, the issue can be a result of the developer using an incorrect language or library. This problem is a little more complex to solve. Your best bet is to talk to someone not related to the project and find out what is out there on the market and what the best practices are for development on projects like yours.
For instance, in “scenario one” discussed above, when the company couldn’t go live, Tizbi eventually stepped in. We established there was a case of bad quality of code going on, did a software quality assurance plan (SQAP) at no cost, and put a development team to create the product.
The Lesson: It is important to stress SQAP to assure you will get your money’s worth.
Oftentimes, this option requires reaching out to a different development company or outside developer for a second opinion. In most cases, it is not the best idea to code everything from scratch, but if your project is written in a language that is the software equivalent of Ancient Cuneiform, it is likely your only option. Rewrites are the best way to get rid of old database management systems and ancient languages that are not supported anymore.
Relevant questions to ask yourself here
-
How have customer needs evolved?
-
Will the current language produce software that will support these needs?
-
Will the software be viable in the next “X” period or will it quickly phase out?
-
Is your decision to rewrite code based on a customer-first approach?
-
Does your developer understand the problem you are trying to solve with your new software? Have you read them in? You may have, but did they really understand?
4. Build a New Team
When at an impasse with your current developer or development team, sometimes there is no cost-effective way to move forward. Whether there is a dispute over budget, features, or technologies implemented, you DO have the option to hire a new team. A new development team can offer fresh perspective and be ready to complete a struggling project that the previous developer could not or would not finish. If you find out that the technologies originally chosen for your project are out-of-date or ill-fitting for the purpose of the project, find a team that can convert everything to more optimum technologies.
How to avoid your previous hiring mistakes
At this point, I could tell you all the usual tips for hiring a software development team such as: ensure they give you value for your money, communication, a team of diverse capabilities, etcetera
But you probably used all these tips the first time round and it got you nowhere. The fact is, everyone will show you credentials. Therefore, the most important thing I’ll emphasize here is proof. Proof that your new developers have done this sort of work before, and delivered a working product within the agreed-upon deadlines.
It’s always better to go with a team than with one developer. Granted, you can find a freelancer who will deliver at a fraction of the cost. But unless you have worked with such a person before, is it worth the risk?
The Way forward. How to get it right the second time
At the beginning of this article, I gave two examples of what a software hostage situation looks like. We see situations like these all the time, where clients dig themselves deeper by continuing to sink money into a failing project. If there is one thing we have learnt from these types of situations, it’s that it is useless to put money, time and effort into something that isn’t working. It’s always better to cut your losses and hire another firm that knows what they are doing. That is not to say that you shouldn’t go after the funds you have already invested in the project. A good middle ground is to have some sort of mediation with your current developer, so that they try to get some value out of the saboteur (previous developer).
Either way, you can achieve your objectives on your second round by:
Prioritizing
-
After you decide which option or multiple options you will pursue, plan everything.
-
-
Follow best practices in development operations (Dev Ops) to bring the project under your control, maximize efficiency, and promote beneficial communication.
-
Talk to your project manager and discuss the steps needed to move forward. If you are refocusing the project with the same developer, prioritize development into phases.
-
Everyone should know the start/end dates for each job and understand what features and functionality each release should contain.
-
Along with your project manager, assign a responsible person for each job, stage, and phase.
-
If you or your developer do not have an issue-tracking system, seriously consider investing in one. They allow you to track progress and see all up-to-date info about the project, including what work was done during which time period.
Following the Chosen Path
-
When you have a plan, record it and stick to it. If your plan is not recorded, the project is more likely to revert to the methods and behaviors that led to the software hostage situation in the first place. Life is not perfect, and almost every step will require minor readjustments. That said, your plan should give you the framework you need to manage what is expected with every major release. Remember that small changes are acceptable to get the project moving again and dig yourself out of the software hostage situation.
Creating a New Spec
-
When your plan is recorded, it is a good time to write a specification that will contain all of the details about the project. If you already have a good spec, make sure that your plan reflects the details accurately so there is no confusion or dispute later. One of the most important purposes of the spec outside of defining the features of the end product is to manage everyone’s expectations and get everyone on the same page from the outset.
-
If you need to write a new spec, try to find someone with technical experience. It is appropriate to involve the developer or an outside consultant. Regardless of who writes the spec, the final step is to make sure that you and the developer agree on it before continuing with development.
Building a New Team
-
If you decided that a change in developer is the best way to move forward, choose a developer that is qualified to do the job. It sounds like an obvious distinction to make, but developers usually have specializations as to which technologies and features they work with. A senior developer in one technology might not know anything about another technology. Be diligent when vetting your new team.
-
Furthermore, it is important to make sure that every member of your team understands the project’s goal, your priorities, and the value of their own input on the project. If every detail is clear to all parties working on the project, including yourself, a software hostage situation moving forward will be nigh impossible.
Bottom line: Creating a Hostage Free Development Environment
-
By being involved in the development of your project, and by following the above methods for communicating and delegating to capable team members, you automatically exclude software hostage situations that could arise from misunderstandings or miscommunication. Once your project is lifted from stagnation and there is once again visible progress toward completion, remember to maintain good practices in Dev Ops to prevent backsliding into bad habits. The most important aspects of development for you to uphold moving forward are good communication, a steady development pace, and control of the project.
