Why Software Development Projects Fail

Why Software Development Projects Fail

Software Development Projects Fail due to Four (4) Business Issues

Much has changed in the software development world over the past three decades and much has stayed the same – namely, for the past decade or more, I see businesses struggling with the same four issues, year in, year out.

Below are four reasons why most software projects fail.  They are also the same four reasons why Campbell Custom Software Development exists: our commercial development approach addresses these issues in a manner that most companies cannot due to internal resource pool, expertise and budget constraints.

Problem #1

Management wants to hire a developer. So they post a job with all of the skills desired for the position.

Below is a random job posting I copied from Monster for a .NET developer position paying $65,000 to $85,000 per year. Note: I’ve trimmed down the descriptions for sake of brevity.

  • Minimum 4 years of Experience with .NET (C#)
  • JavaScript, HTML/CSS
  • WCF/LINQ/Entity Framework
  • Scrum or Kanban
  • SQL Server
  • Additional Web framework experience (Angular, React, Bootstrap, jQuery)
  • CMS Development Experience
  • Unity3d Development
  • Azure Development
  • Mobile Application Development (nice to have).

What’s wrong with this picture?

The candidate this employer is seeking cannot possibly exist. The skills listed encapsulate three or four completely different careers. For example: SQL Server (DAL) / LINQ / Entity Framework – this is a data layer career.  JavaScript/ HTML/CSS/JSON/ Angular, React, Bootstrap – this is a UI/X career.  Mobile Application Development – this is a separate career, and for native development, it’s actually three careers (Win, iOS and Android) as each require expertise in different languages, API knowledge and specialized focus.  Odd-Ducks – Unity3d (gaming is a specialized field), KanBan (a different JIT development process)… Get the point?

No developer can possibly be competent in all of the above. Based upon the example above, my guess is that even the best developers in the business could be as much as 70% incompetent in most of the skills required.

Would you knowingly hire someone you consider to be 70% incompetent?  Of course not.

Which leads me to the next problem.

Problem #2

Jobseekers just want to get the job (of course they do). They exaggerate their experience, expertise and depth of knowledge. This can be said, to some degree, for perhaps anyone who has ever applied for a job.  But in the development world, it’s an increasingly costly and downright dangerous problem.

Employers expend untold effort verifying the candidate’s past employment, credentials and references. But few take it a step further and actually test the skills and competencies of the person they are hiring – not where it counts.

Sure, management may request Brain Bench tests, but these tests (other than live, real time vetting by an expert) can easily be fudged.  All a developer needs to do is setup three or four phony accounts, take the online test multiple times – perhaps even with a few people assisting them – and her or she can waltz through the tests with ease.

I once interviewed 50 people for a single skill set (Telerik).  Of those 50, 29 passed the initial interview (with back ground checks, reference checks, confirmation of employment, etc), 28 failed a live, real-time exam producing nothing. When it came down to it, only two actually had the experience I was looking for, and only one person was able to code a tiny test project in the allotted two hours (compared to 45 minutes by our people). In summary, upon vetting verification, only 2% of the 50 applicants had  proven, retained knowledge OF A SINGLE SKILL.  The other 98%?  Complete fails.

Vetting is extremely important but most companies do not do it, because they can’t do it.  And this is compounded by Problem #1.  Employers do NOT REALIZE they are hiring a person that is 70% incompetent where it counts.

Problem #3

The CTO or management doesn’t utilize a multiplication factor for time and cost estimates. In some 200 projects my company has been involved with, estimation breakdowns provided to us were not deep enough. In my experience, if an estimate does not drill down to three levels of depth, down to tasks, methods, models, etc, a multiplication factor of 2.5 to 3.0 is required for medium complexity projects. For F1000 companies, this factor must be raised to 4.

I worked as a contractor with one of America’s largest telecom corporations – (Hint: it was Verizon) for four years. I worked with them every day, 360 days per year, for four years. Verizon used a 7x factor due to their stringent security and code review processes.

So next time, when a developer states a task will take 30 hours, it’s more likely 75 to 90. However, for commercial development houses like mine, the range should be within 15% (plus/minus).

Here’s another tip… How many times have you been asked for a quick estimate, knowing the push is on for you to deliver at the lowest possible cost.  You instantly get caught in a no-win situation as we all know, additional requirements will be discovered, people will get sick, a lead developer will quit or need to take leave AND there will ALWAYS be numerous unknown technology issues.  Unless you utilize a multiplication factor, your project timeline and budget costs will be so far off your job could be at risk.

So how can you be sure when a project will actually be completed? This brings us to the next major problem.

Problem #4

Most project managers in the industry do not actually know the true status of a project, even if they have daily review meetings.  Why?  Because developers or team leads continually mislead the state of progress since they do not want to be berated for being behind. It’s the nature of the beast in the industry. But it’s also a beast that is devouring productivity – and credibility – across the sector.

Since most project managers are not coders, they cannot independently verify the state of the code.  Are they checking for “empty” non-coded methods?  What about blank try/catches? Non-compliance to security?  Are developers performing QA on code they wrote instead of a separate team testing code the developer wrote?

Either the project manager must be provided the tools they need to confirm project status or they themselves must have extensive development experience to determine the status of a software development project, EVEN if the visible progress “seems” to be good.

Few companies take it upon themselves to make this happen.

Here’s the summary of this article – What you need to know (and avoid):

  • Out of the chute, the average developer hired is actually 70% incompetent as they are expected to know everything, but, of course, they can’t. No one person can.

Here’s what Dino Esposito, Microsoft MVP, author of 20+ books, hundreds of Cutting Edge Posts and speaker at probably some 100 developer conventions stated:

“Gary Campbell’s approach to development is unique in that he understands that today’s developers cannot be experts in all technologies.  By separating development into a proven architecture, and then further separating the layers to specific skill sets, his infrastructure forces developers to develop software using a limited but expert skill set.  This development approach provides true separation of concerns, while also providing an optimal infrastructure for unit testing and ensuring maintainable code for the life cycle.”  – Dino Esposito, MVP

  • Developer skills are not vetted or assessed, the most important aspect of a technology hire.  Hey, we all know developers have quirks.  But if they have excellent skills, they will help you to succeed.  Perform a deep vet on each skill they state they have.  Otherwise, you are in for a thunderstorm.
  • Time and cost estimates are not deep enough. Most in our industry are under-estimated by 200% or more. Don’t get caught in a no-win situation.  When asked for an immediate estimate, just state that you need to look into it before you can determine a meaningful number (this is engineering, it’s not a game).  Then drill down the effort required, all the way to methods / models / layer efforts / security required.  and after that, use a multiplier that you can tweak based upon similar requests.
  • Project managers cannot verify the state of a project, because the project’s actual status is hidden from them. Address this by providing the PM with a verification team (developer separation) or hire a PM who understands code and who reviews all code check-ins.

It is no wonder that 68% to 70% of technology projects fail. Or that every day, major organizations report that their data was exploited, hacked, or their servers went down due to unintentional mismanagement, most likely due to Problem #2.

Incompetency has been a hard fact for the past decade, as reported by reputable auditors such as KPMG and others.

Until these points are addressed, just like over the past decade, almost every company will encounter a project failure this year.  If you are responsible for a project, your job may be at risk unless you address these issues.  But on a brighter, simpler note, if you need assistance, just ping me.

About Gary Campbell

Gary Campbell is the founder of Campbell Custom Software Development. He and his company provide commercial custom software development to USA and Canadian clients across North America. His developers and management have nearly 500 years of COMMERCIAL (extremely different than a person who was employed by 3 companies over 10 years versus a person who has coded software development for 200 different commercial clients), being involved in over 200 complex business software projects.