Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to increase the success rate of software development

1,142 views

Published on

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

Published in: Software
  • Be the first to comment

How to increase the success rate of software development

  1. 1. HOW TO INCREASE THE SUCCESS RATE OF SOFTWARE DEVELOPMENT
  2. 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. 3. CHOOSING THE RIGHT DEVELOPER 1
  4. 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. 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. 6. IDENTIFYING THE JOB 2
  7. 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. 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. 9. PROJECT ESTIMATES 3
  10. 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. 11. FACTORS STRETCHING PROJECT TIMELINE
  12. 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. 13. IDENTIFYING RISKS 4
  14. 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. 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. 16. DON'T 'GOLD PLATE' 5
  17. 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. 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. 19. PROJECT MANAGEMENT 6
  20. 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. 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. 22. DON'T OVERSTAFF Brook's law in software development: If you need a lot of people, get them BEFORE the project starts.
  23. 23. TESTING 7
  24. 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. 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. 26. MAKING CHANGES 8
  27. 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. 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. 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. 30. LOOKING INTO THE FUTURE 9
  31. 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. 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. 33. Consider product improvements with information gathered from: ENHANCEMENT User feedback Industry responses Emerging technology trends
  34. 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

×