Custom Software Development: 3 Silent Killers of Success
The brutal truth about custom software development is that most projects either fail, or go far beyond budget and schedule.
There are way too many companies with good project managers, and possibly even good software developers that still have this problem (estimated at 50% or more).
But... why is that?
3 KILLERS OF SOFTWARE PROJECTS
In software development there are many ways to kill a project, partially because of complexity. The more complex the project, the harder it is to relay status, properly assess risks, allocate resources appropriately, and the list goes on...
Whether you're hiring out your custom software development to a company (like ours), or doing it internally there are a few challenges that punch above the rest.
Killer 1: Resource Allocation
Before you roll your eyes, I'm not just speaking to the "having enough resources" issue. I guess it may be more appropriate to call this "Resource Alignment".
If your company has multiple business objectives, and you're using development to help that along, that's great. Where the risk comes into play here is resources being pulled off the project or bounced around.
With multiple company priorities, and limited staff, on-the-fly decisions often affect progress.
Make sure that if you're going to take a project on (especially one with a deadline), that you can keep the same software development resources allocated to the project for its duration.
Getting up to speed on a new project takes time, especially if your custom software project doesn't have time to document as you go.
Killer 2: Requirements Gathering
I know this one isn't exactly the sexiest one, but it's necessary. There are several fundamental parts to this, and two solid reasons to get this right.
First, the fundamental parts...
End Result & Business Benefit
This is where it really begins and is left out by many project managers and organizations, especially when it comes to planning custom software development activities and projects.
What is the end result you're trying to accomplish, and what will the business benefit be? Will it be cost savings, increased revenue, reduced support requests, or something else?
How will you measure it, and what does it need to do?
If you can measure it and have a clear way of tracking the project success, the goal of the project becomes clear to all involved and makes gathering the rest of the business requirements much more simple.
Don't forget, there is power in clarity... and being clear will reduce the amount of iterations it takes to ship a viable product (internal or external).
Risk Management
In the military, risk management saves the lives of thousands, and mitigates catastrophic occurrences. This is also common practice in the financial realm. Despite this, many IT projects come together without listing out risks and having a strategy in place for dealing with them if/when they occur.
The sad thing is that even a simple bullet list with a SINGLE sentence of how you will handle the risk can do wonders.
Here are the 4 main ways to address risk:
Mitigate
Avoid
Transfer
Accept
Just by consciously being aware of risks at the project onset can change the way that your project managers, software developers, and other team members handle the project as a whole.
Killer 3: Turnover Costs
Turnover costs in IT (especially software development) are insane. Take the following scenario for example.
Your company has a project that has been going on for 2 years, and one of your lead developers decides to quit, wins the lotto, or for whatever reason isn't on the project anymore.
You're now forced to hire someone, get their access, equipment, environment, tooling, and anything else they need setup before they can even start working
Next, they have to familiarize themselves with the team, the work environment, the project, any libraries used for development, and just think, this is still before they can start to be productive on your project.
Following that, they'll have to figure out your SDLC (software development life cycle) before they can contribute, and commit code.
Depending on the size of the project, the quality of the person you hire, the efficiency of your on-boarding process, and numerous other factors... This can take several weeks to over a month to replace a software developer.
See the problem?
Having this much downtime with a resource that isn't cheap is not only expensive, but it is stressful for everyone on the project.
But, it gets worse...
You now have to pull your most productive resources off of being productive, in order to catch the new guy up to speed.
This not only has a direct impact on deliverables and schedules, but this last part of the equation is it's very rare for management staff to adjust their resource plan to account for both resources instead of just one.
Good project managers will usually downgrade the capacity of a new resource, but still often miss downgrading the capacity of the other developers helping him/her get up to speed.
While turnover is challenging, and some turnover is inevitable. Make the time up-front to train and nurture the new resource so that they reach full capacity sooner.
Summary
Some of these probably seem obvious, but sometimes common sense isn't common practice.
Whether it's been very large companies, or smaller development shops, they tend to make critical mistakes with at least one of the above.
Also, this isn't an exhaustive list. I decided to focus on areas with the biggest impact, and potentially a slightly different view-point than "normal".
What's next?
Make sure you're avoiding the 3 silent killers... obviously.
Oh, and just because your project has already started... that doesn't give you an excuse to wait for the next project.
In a future article I'll go over outsourcing vs insourcing vs hybrid companies. Including the benefits and drawbacks to each.
In the meantime, if you want me to take a look at your project and see if we can help.
Which area(s) could you work on in your organization? What other common challenges do you face? Let me know in the comments below.
