This article is the final installment about a real-life journey undertaken by the Managing Director (MD) of a company and her team who had little knowledge of software development but absolutely needed this capability to sustainably serve the evolving needs of their customers.
In the previous article The Road to Building Sustainable Software Capability – Part 2: Stabilisation I covered the journey up to the point the newly minted team and their external software development provider had successfully made a maintenance release of one of their existing complex software Web Applications.
The existing Web Application in use by the company and its stakeholders was over 10 years old and nearing the end of life. Following the successful maintenance release and in discussion with the external software provider it was found that it was not economical to add the new capabilities the business and its stakeholders needed to the existing Web Application as each change was laborious and required careful programming effort in a defunct framework.
it was found that it was not economical to add the new capabilities the business and its stakeholders needed to the existing Web Application as each change was laborious
In my opinion the most important thing is gaining confidence when mastering a new skill such as building software solutions. So, having gained confidence by making successful maintenance releases of their existing software, the team was keen to tackle the problem of producing a new Web Application to provide the capabilities they and their stakeholders needed.
If you are new to Software, building a Web Application may seem as difficult as aiming for the moon
It would take a whole book to cover their journey of building the new Web Application but I will try and keep this article a bit briefer and stick to covering the following key learnings and techniques:
- Planning
- Good communications
- Configurability
Planning
It is customary to choose a majestic internal project name, ideally from a category with many names to cover future projects as well. Birds were selected. Eagles, falcons and even kingfishers are cool, or kookaburras for a local flavor – they could be considered a symbol of majestically soaring to their destination, right? Hmm no, project Seagull was born – something about how this name related to a certain software consultant and occasional article writer making a lot of noise, dropping software techniques on everyone and then flying away, just appealed to the team’s sense of humor.
Project “Seagull” was born
Planning and defining what should go into the new Web Application is difficult to get right at the onset of a project. Planning was done to captured the main vision and to create an initial prioritized list of the main features sufficient for the external software development provider to calculate indicative costing estimates and to engage with stakeholders. Visual Studio Online was used as it was pretty easy to use at the time but I would probably recommend something like Jira for new projects today.
Planning was done to captured the main vision
Communications
In the past, before the new software team and the new external software development provider came along, the previous team used to release software with many key internal and external stakeholders not consulted prior to the release. Some of the new team had painfully experienced features being released which they were expected to use but which were not really how they would have liked them. This was due to inadequate communication between the previous software team, the previous external software provider and the internal and external stakeholders. A key lesson the new team learned from this was that strong communication mechanisms would be essential to their success when building the new Web Application.
Some of the new team had painfully experienced features being released which they were expected to use but which were not really how they would have liked them.
Regular online meetings between the team and the external international stakeholders were setup to gain their input and better buy in to the new Web application. The team also ensured engagement with the internal stakeholders through team meetings and frequent discussions.
From personal experience software developers tend to be better at writing code than communication. To add to this, the external software developer operated across town from the team and regular on-premise meetings were not an efficient option. Skype and Microsoft Teams were used to hold online meetings as well as to provide a messaging service for the quick answering of questions. These online communications mechanisms alone, although good could still lead to miscommunications from time to time. As mentioned in the previous article the tester in the team was chosen from the customer support team. Having worked in customer support using the previous Web Application the tester had an excellent understanding of the business requirements. To further ensure strong communications and to foster a stronger sense of collaboration the tester worked on-site at the external software development providers location from time to time. This proved to be an excellent arrangement which not only gave the external software development provider a means of quicker feedback and deeper understanding of the business needs but also helped the tester to understand the system being developed to a greater level.
Configurability
Key to the organizations value proposition with its external stakeholders and their end customers are a set of reports and questionnaires. A major deficiency of the existing Web Application was that these reports and questionnaires were only configurable through laborious programmatic intervention. This stifled innovation and one of the key new features requested was the ability to configure key aspects of the Web Application non-programmatically using questionnaire builders and report templates. Such non-programmatic configurability is key in this age of rapidly evolving business needs (see here for a shameless plug of an article I wrote brushing on this topic).
The team tester became an expert in using the new questionnaire builder and other non-programmatic configuration tools to help the team create the Web application as well as better maintain them in future.
A major deficiency of the existing Web Application was that these reports and questionnaires were only configurable through laborious programmatic intervention.
The organization possesses an excellent brand and it is important to provide consistent styling and user experiences across their entire suite of web applications as well as their commercial Web Pages to complement the branding. The team engaged a separate web page development provider to upgrade their existing web pages and produce consistent styling. Incorporating the new styling would have been extremely difficult in the old Web Application but could be done simply and quickly in the new Web Applications being developed.
Conclusion
Yes, this story does have a happy ending. In July this year, despite the challenges of 2020, the team released their awesome next generation global platform designed to take their customer and other stakeholder user experience to the next level. I was privileged to receive a walkthrough of the product and it the best of its kind that I have seen. The team and their software provider did a stellar job building this product especially considering that the MD and her team had no prior history of creating software at the outset!
Confidence, Vision and Strong Communication were Key Ingredients to Success
In this article, I covered how the following went a long way to helping the team on their road to successfully building a successful Web application (even if it felt as difficult as a Moon landing at the outset):
- confidence gained by starting with a simple maintenance release,
- envisioning and Planning what the organization needed, and
- a commitment to excellent communication
Although not really an ingredient but more an outcome, I also touched on configurability. In these challenging and dynamic times solutions need to be rapidly changeable more than ever to better match evolving business requirements. We have been finding, that like the protagonists of this story, our customers at Xelleron are embracing configurability in their software solutions, ideally when it can be rapidly applied without additional programming, and if you go to the trouble of building your own software it may be worthwhile taking that into consideration.
Parting Words
I have tried to highlight some of the key learnings and considerations in this series of articles which I hope can be of use to other teams out there which find themselves abruptly facing the scary prospect of needing to take charge of their software solutions and building a sustainable software capability.
The moral of this story is that it is possible to take charge of your software solutions even if you and your team start from a non-technological base.
