About Dalip Mahal

Dalip is a principal consultant at Accelerated Development and has worked his way through all aspects of software development. He started as a software engineer and worked his way through engineering and product management.

Failed! You get what you deserve!

Consider this, few projects fail because of unusual or unforeseen problems.  If you are trying to go so fast that you don’t do your due diligence or decide to skip steps then — “You get what you deserve!“.

Projects succeed because they do not rely on force of personality and luck.

Only 3 of 10 software projects succeed (see Understanding Your Chances). Success happens when you implement best practices and avoid worst practices; not just talk about them and convince yourself that you are doing them.

 
law-unintended-consequences
Therefore 7 out of 10 projects fail, even if you redefine ‘challenged projects‘ as political victories; these projects are often severely over time and budget.

It is estimated that between $3 trillion and $6 trillion dollars are wasted every year in IT; by organizations that “don’t know, and don’t know that they don’t know“, i.e. what you don’t know can definitely hurt you.

 

 
RinseAndRepeat
What is amazing is that failures do not prompt the incompetent to learn why they failed.  After the post-fail finger-pointing ceremony, people just dust themselves off and rinse and repeat.

There is never enough time to do the project correctly, but there is always enough time to do it again.

 

Ingredients of a Successful Project

Ingredients
Successful software projects have the following characteristics:

  • Effective capital budgeting
  • Proper project sizing
  • Estimate uncertainty
  • A focus on defect removal

Capital Budgeting

RJ_Reynolds_Tobacco_Company
Capital budgeting means having business cases for major projects and allocating capital to the most promising projects; a little due diligence prevents bad projects from starting.

For example, RJ Reynolds invested $325 million to develop smokeless cigarettes when they knew in the initial pilot that the cigarette tasted bad and no one would buy them.

Project Sizing

SizeMattersIf a project has a good business case, then the next step is to figure out how big the project is. This requires that you expand the requirements sufficiently to estimate time and cost.

When it comes to software — size matters.

Not only does size matter, you need to understand the level of uncertainty (requirements, technical, or skill) tied to your project to understand how much re-work or discovery will be necessary.

  • Re-engineering a product with new technologies?  (high technical uncertainty)
  • Building a new product with existing technologies? (high requirements uncertainty)
  • Building software with a team unfamiliar with the technology? (have high skills uncertainty)

Skipping the time to get estimates is a major cause of project failure.

There are still executives that give engineering a few hours or a few days to estimate major projects and wonder why the projects go late or get cancelled.

Estimate Uncertainty

uncertainty

Project methodology needs to take into account expected uncertainty.

Projects with low uncertainty can be handled with a traditional project methodology; these projects can have there work breakdown structures elaborated and dependencies can be worked out ahead of time.

Projects with moderate to high uncertainty will require rework and discovery.  This must be built into the project plan or you need to switch to an Agile methodology.  If you don’t then there will be missing tasks on the project plan as well as task duration that is under-estimated.

Project tasks get stuck at 90% complete because the sources of uncertainty are not established a priori.

Executing a project with personnel that are not competent with the technologies that you want to use is essentially professional malpractice.  If you must use existing personnel that don’t know the technologies you want then you need to build in a large margin for training and rework over the project; these projects will take at least 2x as long as your worst estimate.

Focus on Early Defect Removal

Developer’s say: “There is never enough time to write the code“. Statistics say, “There is never enough time to find all the defects” (see The Programmer Productivity Paradox). To be successful you need to find defects as quickly as possible, especially since:

  • If it costs X to find a defect pre-test
  • It costs 10X to find it in QA
  • It costs 100X to find it once deployed in the field

You do the math, it costs less to find defects before they get to QA.  You are kidding yourself if you think that it is cost effective to have huge QA departments (see The Cost of Not Doing Quality).

Conclusion

MissingPieces
Building software reliably and repeatably is not difficult.  What is difficult is getting organizations to realize that there is a minimum set of processes that must be followed to have a successful project.

Organizations regularly skip one or more steps and wonder why projects fail to come together and succeed.

Reference: Failed! You get what you deserve! from our JCG partner Dalip Mahal at the Accelerated Development blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


four × = 12



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close