It is important to develop key applications in-house and not just buy off-the-shelf software. How else can you differentiate yourself in a market with rapidly evolving competitors? Your organisation must be able to build these key applications quickly. Moreover, the work it will have to do in a few years’ time will be different from what it is doing now. But here we run into a problem: project management is no longer suited to evolving applications with business agility.
The answer is to put together product teams that are involved throughout the entire life cycle of their ‘babies’, so that they manage their application or its enabling infrastructure as a product. Give these teams the autonomy to make decisions and make them ultimately responsible for their products. This alternative approach will enhance the focus on adding value, delighting your customers and bringing other benefits. The latest ‘Accelerate State of DevOps’ report by DevOps Research and Assessment (DORA), which is now part of Google, proves that this kind of empowerment leads to much better results. Agility, for one thing, which is a big advantage as most organisations still take too much time to deliver software applications with the quality and reliability expected.
Long-term thinking
Many organisations and companies still find it difficult to look beyond the initial costs of a project. They don’t always fully assess what the technology investment might yield in the long run. Or they don’t make forecasts about how certain investments could bring in money. Another issue is the big gulf between IT teams and the business owners, who still rarely talk to each other. Finally, add to that too many levels of decision-making and you get the picture – a lot of improvement is possible.
In our experience, IT works best if the daily management is entrusted to teams who run the application or platform as a product and have to serve their external or internal customers for a long period of time.
Cross-functional teams
The product team should consist of different profiles, although a single person can have different roles. It needs to include software developers and IT infrastructure and automation experts (operations side), plus people from the business side. The ‘product owner’ should be someone who not only has sufficient understanding of the business to know how the company can stand out in the market and can promote the platform or application internally and externally, but also has the technical knowledge to assess IT problems, limitations, risks, opportunities for improvement, and the time and costs required. For example, it could be a Chief Marketing Officer who knows about IT life cycle management.
Product life cycle
The team’s work doesn’t stop with the delivery of the first version of the software. It still needs to maintain and further adapt the application. IT operations people will do a better job if they are involved from the start. And software development people will perform better if they are also responsible for the operational management of the application. Take the example of cloud software providers, they know it is essential to keep up with their competitors and that their job is never done. This reasoning should also apply to in-house software development, so that you not only deliver value but also keep the product fit for purpose. However, technology management is still often seen as a cost centre: make sure you stay within the project budget, finish on time and consider the work done when it offers a solution to a current problem.
So, what if two years after delivery there is a vulnerability in the software? It would be better to have it solved by someone who has worked on the application right from the start and therefore is familiar with it. Experience always beats any amount of documentation. Most developers prefer not to work on documentation anyway and there aren’t many who would first read a 2,000-page document before getting to work. You can’t document everything in every case. There is always implicit stuff that you know but which is not included in the document. What is self-evident to you may not be for someone else.
Commitment
The walls between software development, IT operations and business need to be completely demolished. Let product teams make their own decisions within a budgetary framework. This leads to more commitment, and better software that is faster available and easier to improve in the future.
We would urge companies to invest more initially in order to be better off in the end. Look at the entire life cycle of the software and the long-term potential instead of just looking at IT as a portfolio of projects. Involve people with different profiles. Be open to external expertise and experience.
Devoteam can help put together the ideal product team, making well-informed decisions and coming up with new ideas and experience to prevent you from making mistakes that others have made before you.