One Shoe logo

Lifecycle management: how to maintain quality of software development in an evolving IT landscape

This article is part of a series about the key elements of successful enterprise software development projects. In the previous article we explained the difference between  built for purpose and built to last software and why this important for having a successful development plan to create software. In this article we will talk about how approach lifecycle management of software development projects to maintain the quality of the software in a changing IT landscape. 

Tibor Uittenbogaard | 04 dec 2018

This article is part of a series about the key elements for a strategic enterprise software development strategy

At One Shoe we specialize in the more complex software projects - projects in which typically a significant amount of custom coding is involved. When it comes to projects that involve custom software, system integrations, enterprise level content management, and multi stakeholder processes, we know that the software solution will evolve over time. When there’s more than one goal or purpose for the solution, and if those goals and purposes are expected to evolve over time, a strategy is needed to ensure quality and durability every step of the way.   

When it comes to developing enterprise-level content management systems or software on an enterprise level, one area of focus starts to differ greatly from smaller projects; the challenge of life cycle management. Life cycle management and quality assurance are less difficult if a software development project is small, and when the project focuses on providing a simple solution for a specific problem, or for a short time.

Built-to-last lifecycle management

When building software solutions to last, technical changes and requirements are just one part of the software development game. Properly and professionally managing scope and requirement changes, is not enough to maintain quality throughout the application life-cycle and the development of built-to-last software solutions. Because, even if you would be able to make your development roadmap fixed, and if you would be able to set the scope and requirements in stone for years to come, changes in other fields are just as inevitable.

Changes can, for example, take place in your (development) team, your client’s team and its stakeholders, and your client’s business needs. And a lesser thought of but equally important factor is the devaluating value of the software solution. As newer, better and cheaper alternatives might appear on the market, it is vital to stay competitive and provide added value. Quality of life cycle management and embedding agility in the foundation all underlying processes, may in such scenarios remain to be the one trúly distinguishing factor.

The human aspect of enterprise level software development

Aside from technical changes and challenges, the agency needs to take into account the changes that will occur in the composition of its own (development) team and that of the client (the stakeholders) from the very beginning. This - accounting for the ‘human aspect’ that is so critically vital to the success of enterprise level software development -  is the key to successfully developing software solutions that last.

Let’s for example start with assuming that changes in the development team will be an inevitable factor. Then add to that the evolving complexity of the IT-landscape, systems and source code, technical specifications and business requirements. And top it off with a healthy dose of alternating influencing-, and decision making stakeholders on the client side. It’s more than clear that being prepared for these changes is important.

Because of these changes, version control, documentation, knowledge sharing, testing and quality assurance safeguards become operational and non-negotiable must-haves, that outweigh the technical must-haves, (business) requirements and design.  

Technical- and business requirements, and design

Business needs, requirements, specifications (technical and functional) and designs are important for software development. I will not deny that. But to me those factors are 2nd place concerns. Because those requirements, designs, the product backlog, the development plans, and the roadmap are always snapshots in time. These will evolve along with the project. In the 1st place there should be processes in place that ensure that those evolutions can be managed at all times, without risking the loss of quality.

Safeguarding quality in a changing and evolving development project ensures the project (and its investor) a return on investment (ROI) and continuous quality of a software solution that can last many years. Therefore, starting the development of an enterprise-level content management or software solution should start with a proper development- and life-cycle management plan. That is - if your application is meant to have a life cycle of years to decades. And in my opinion, that development life-cycle plan requires first and foremost: test coverage.