The critical steps to delivering a successful software product & making $$$. Vol1.

Michael Hamilton
Small Business Forum
3 min readJan 14, 2016

In this post I’ll share 3 of the 7 critical steps to delivering quality software.

1 — Business Case/Concept Do-ability

  • Business viewpoint: Is there a market and realistic return on investment for the concept? (The answer to this question doesn’t have to be a financial gain. E.g. it can be an improved customer experience or does it meet and fulfil the business needs, or does it simply come 80% of the way, near enough may not be good enough.
  • IT viewpoint: Does the technology and market skill-set exist to support the concept? E.g. In-house capability or does the business have a strategic partnership with whom they are confident can support new initiatives?

Key Note: If you are a business owner or IT manager, be honest with yourself at this stage. If this concept is pursued, is the company and return on investment doomed to begin with? Clearly understand your risk exposure!

2 — Strategy

  • Business viewpoint: What is the overarching strategy that will aim to deliver the business case?
  • IT viewpoint: What is the most appropriate IT development methodology to deliver the business case? E.g. Waterfall or agile methodology.

Key Notes:

  • The choice or type of software is important. If using a new solution the 7 steps must be carefully considered.
  • If you’re starting with an existing solution, the strategic direction has already been established and the 7 steps is applied to ensure new changes and old functionality work in unison.
  • Does the proposed strategy align with the overall business architecture and technology roadmap? (No point delivering something that other areas of the business

cannot/will not use).

  • At this point there should be an overarching strategy driving the project/initiative and a test strategy on how the software will be tested.
  • If the software is to be integrated with another system or third party, this should be clearly articulated in the test strategy. The same rigor we are applying in the 7 steps for ourselves should also be asked of the integrating third parties.
  • Functional and the multi-user/performance testing approach needs to be considered at this stage.

Within the next steps of 3–7, special consideration must be undertaken when adopting the waterfall or agile methodologies:

  • The waterfall methodology aims to develop/configure the software entirely within steps 3–7. E.g. all business requirements for the software are identified and locked down within step 3.
  • The iteration based agile methodology aims to develop/ configure particular parts of the overall software using steps 3–7. E.g. the log into system function will be created and deployed to market using steps 3–7, while the next iteration will focus on the funds transfer function if a banking application is being developed.

(Agile allows specific features to be delivered to market quicker, while waterfall waits for the entire software/solution to be built before being released to market. Agile also allows more rapid/adaptive change, but the drawcard is there must be a champion who has final decision to not allow too many external influences to push the original concept “off-course”)

3 — Business Requirements Collaboration

  • Business viewpoint: At a detailed level is the business case broken down into easy to understand language?
  • IT viewpoint: Is the business case broken down into easily to understand language which can be understood by IT personnel? (Requirements or user stories should be written in a way that anyone that is new to your business can understand them)

Key Notes:

  • Ensure all personnel who are involved in the overall development of the software have reviewed the business requirements. (This is technical and non-technical personnel)
  • For agile software development requirements can be referred to as user stories. (Agile doesn’t mean requirements/user stories are no longer needed to be documented, you may need to refer to these again in the future. Especially if staff move on from your business).

Hope you’ve found interesting my thought so far and hopefully this article would be useful to you! The second part is coming next week and meanwhile I’ll be happy to hear from you in the comment section or at http://www.mikehamilton.com.au/

--

--

Michael Hamilton
Small Business Forum

Test Architect at National Australia Bank, Author of “It Should Just Work; Customer Satisfaction & The Value of Software Testing http://www.amazon.com.au/gp/product/B015453ZDO?*Version*=1&*entries*=0