Campbell Custom Software Development

Four Reasons Why Software Projects Fail

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 limitations, range of expertise and budget constraints.

Software Project Fail #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.

What’s wrong with this picture?

Based upon my 20 years keeping pace with software advancements, the “candidate” this employer is seeking cannot possibly exist.  The skills listed encapsulate three or four completely different careers.  The employer is attempting to hire a dentist, a surgeon, a mechanic and a unique specialist.

For example:

1. SQL Server (DAL) / LINQ / Entity Framework – this is a data layer career.

2. JavaScript/ HTML/CSS/JSON/ Angular, React, Bootstrap – this is a UI/X career.

3. 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.

4. 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, based upon my experience, even the best, most expensive developers in the business could be as much as 70% incompetent in most of the skills demanded by this listing.

Would you knowingly hire someone you consider to be 70% incompetent?  Would you consider a dentist to perform surgery?  Or a mechanic to fix your teeth?  Of course not.  The reality is that many of the job requirements are different careers.   Yet this “Job Posting” is demanding knowledge, and the employer  expecting competence of all of these technologies.

Which leads me to the next problem.

Software Project Fail #2

Job seekers 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 a 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 EACH of the skills and competencies of the person they are hiring.

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 and get “recording breaking” marks.

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 only 1 single skill, only 2% of the 50 applicants had  proven, retained knowledge … OF A SINGLE SKILL.   98% completely failed.

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.

Software Project Fail #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.  For F100 companies, the factor is 4 to 7.

I worked as a contractor with one of America’s largest telecom corporations – Verizon.  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, when a commercial development house like Campbell Software quotes, it 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 management position 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.

Software Project Fail #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 schedule.  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?  That’s a sin in my books, a separate QA team should be testing the code.

Either the project manager must be provided the tools and people 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.

Summary

• 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.” 

• 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.
• Most Time and cost estimates are not deep enough.  Most projects 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 like 2.5 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), a separate code reviewer 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 in this industry 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 and a simpler note, if you need assistance, just ping me.  We can help take the load off your shoulders.