Software development projects don't have to be stressful. Follow these steps to improve the chance of a successful software product launch. Check out the previous slides on Top 10 Myths about Software Development at http://www.slideshare.net/EnabledSolutions/10-myths-in-software-development-to-debunk-now

1. HOW TO INCREASE THE
SUCCESS RATE OF
SOFTWARE DEVELOPMENT

2. OUTLINE
1. Choosing the
right developer
2. Identifying
the job
3. Project
estimates
4. Identifying
risks
5. Don't
gold plate
6. Project
management
7. Testing
8. Making
changes
9. Looking into
the future

3. CHOOSING THE RIGHT
DEVELOPER
1

4. There is a potential bias as
we tend to choose people
who reinforce our worldview
(selective exposure).
Thus, look for people who
make a good fit, but still
leave enough room for
innovation.
SELECTIVE
EXPOSURE
Dos & Don'ts of
Choosing Software
Developers
CLICK TO READ

5. TRUST
Start building trust by practicing mutual empathy.
Repeat business is always better for developers,
which means there is more in it for them to complete
your project successfully than dragging it out for
extra charges.

6. IDENTIFYING THE JOB
2

7. Answer the question:
What job are your
customers/users trying to
accomplish with your
software?
Multi-faceted job (benefits):
JOBS‐TO‐BE‐DONE
FRAMEWORK
Functional
Social
Emotional
Primer on
Jobs­to­be­done
CLICK TO READ

8. WORK WITH YOUR DEVELOPER
Identify the job with their input, which helps determine:
Project scope
Software functionality
Budget
What development methodology/practice to use

9. PROJECT ESTIMATES
3

10. THE COASTLINE
PARADOX
When measuring a coastline,
the shorter the ruler used -
the longer the coastline.
Similarly, unless you want
high granularity level from
the start, the actual software
development time is most
likely longer than the
estimates.

11. FACTORS STRETCHING PROJECT
TIMELINE

12. BEST PRACTICES
Break a project down into small sets of useable features
prioritised by value
Re-evaluate the plan and estimates after each
deliverable
Fixed price = high price
Small milestones and constant renegotiation
Start the project early to ensure ample time in the end
for tasks such as review and changes

13. IDENTIFYING RISKS
4

14. Referencing this book:
BEST PRACTICES
Identify, track and label
risks
Find trigger conditions
for each risk
Define impact and
mitigation strategies for
each risk
Estimate risk probability

15. BEST PRACTICES (CONT.)
Calculate value impact should the risk eventuate
Discover showstopping risks ensure you are OK with
them. Find ways to remove these if not.
Ensure all components & parts of the system are defined
early on in the project
Monitor & re-evaluate the list of risks regularly (at least
at each deliverable milestone). Execute contingencies as
they are triggered.
Add new risks are they become apparent

16. DON'T 'GOLD PLATE'
5

17. Once you’ve identified the
Minimum Viable Product
(MVP), try not to over
serve and waste
budget/time on things that
customers will not value.

18. THRASH UPFRONT
Do a bulk of the discovery and invention upfront
Experiment with small bits throughout
Make sure all important stakeholders are included early
Increasingly reduce the amount of influence these
stakeholders are allowed to have across the project

19. PROJECT MANAGEMENT
6

20. Keep track of roles and
responsibilities but don’t
over-document everything.
Sometimes,
visual/graphical
representation does a
better job than word
documents, e.g. app maps
ACCOUNTABILITYExample of app
map we did for
our client
CLICK TO VIEW

21. EFFECTIVE COMMUNICATION
Is two-way (rather than one-way reporting)
Is timely
Is directed to the right stakeholder who has authority to
act promptly
Is comprehensible by the receiver, i.e. not full of
technical jargons
Is delivered using the most efficient channel (e.g. email,
phone, face-to-face)
Fosters team spirit across different organisations/teams

22. DON'T OVERSTAFF
Brook's law in software
development:
If you need a lot of
people, get them BEFORE
the project starts.

23. TESTING
7

24. TYPES OF TESTING
Automated unit testing: increases development cost by
30-50% but reduces the number of bugs by up to 90%.
This is done throughout the project, not just towards the
end.
End-to-end testing tests a fully integrated system as if a
user was using it.
Staging environments allow changes to be heavily
tested by users before deploying into a production
environment for general use.

25. Developers should not be
testers in the project they
are working on, as their
familiarity with the software
may skew the results
NOTE

26. MAKING CHANGES
8

27. SAY NO TO NEW IDEAS
TOWARDS THE END OF PROJECT
If “The Sudden Go-Live Realisation”
hits you, resist the urge to ask for
changes that could potentially break
the system if rushed

28. MINIMISE DISRUPTIONS
Small changes that don’t have significant impacts on
solution architecture: can add up over time and derail
the project if not controlled properly.
Big changes: refer back to Jobs-to-be-done. Would this
help the user solve anything?
Assess any impact of change and obtain appropriate
approval.

29. WHAT TO DO THEN?
Consider moving those changes to the next phase after
gathering enough user feedback.
This would help you stay within your desired time frame for
the current project, as well as refine your new ideas for the
next project.

30. LOOKING INTO THE FUTURE
9

31. THE BEST SOFTWARE IS
SOMETHING THAT RECEIVES
CONSTANT CARE.
Software is eating the world, so you
need to keep improving in order to
remain indispensable to customers.

32. MAINTENANCE
Security updates, bug fixing and regular maintenance
ensure a smooth performance of your software product.
Having a Service Level Agreement (SLA) with your
developer gives you peace of mind that technical issues
are ironed out as soon as they crop up.

33. Consider product
improvements with
information gathered from:
ENHANCEMENT
User feedback
Industry responses
Emerging technology
trends

34. T H A N K S F O R R E A D I N G
C R E A T E D B Y
Read full blog post at: blog.enabled.com.au/successful-software-development