Latest Research


This content is currently locked.

Your current Info-Tech Research Group subscription does not include access to this content. Contact your account representative to gain access to Premium SoftwareReviews.

Contact Your Representative
Or Call Us:
1-888-670-8889 (US/CAN) or
+1-519-432-3550 (International)

Comprehensive software reviews to make better IT decisions

Continuous Improvement May Not Be Good Enough

Delivering faster change is attractive.

Organizations try to become more agile and responsive to changes in competition and customer preferences. The commonly adopted pattern of periodic (quarterly) releases of new application functionality is seen as too slow to address change in a timely manner. In this approach, the period between conception and deployment of a change can be as long as half a year or more. As an alternative, organizations are adopting a continuous improvement model with changes deployed weekly. A change could, in theory, be deployed in less than a month from conception, a significant improvement.

However, the adoption of frequent change cycles has several drawbacks.

First, the limited and fixed capacity of an application support group limits the amount of work that can be accomplished in a cycle. This can enable many minor changes but generally precludes major changes.

Second, limited attention is paid to the changes by impacted users, as they are typically minor and occur frequently. This can limit the achievement of the intended collective benefits of multiple implemented changes.

Third, some steps in the development process (for example, architectural review and testing) are generally minimized as they slow down the change process. The result can be higher total cost of development, when one considers the longer-term rework required.

You can’t make major changes in a short time frame.

Continuous improvement (frequent releases) enables the rapid implementation of application changes compared to a bigger bang approach. However, the short time frame imposed on a development team to design, develop, test, and deploy changes, limits the scope of change possible. The approach can deliver a series of improvements quickly, but the degree of system change is typically small. Small changes can have big impacts, but organizations that want to achieve significant scope of change (consider an ERP deployment as an extreme example) need more development time and will generally need to revert to a longer release cycle.

If you introduce changes frequently, does anyone notice?

Many IT leaders complain about the limited adoption of the new features deployed in an application. Small frequent changes are even less likely to have an effect on anyone other than the individuals who requested the change. The effective communication of impending changes and their value to the user community is an essential contributor to effective and broad adoption and usage of any new features.

With weekly deployments, messages from IT are likely to be broadly disregarded. The communication of change should come from the user management or supervision and be positioned as a valuable business change and not as an IT change. When changes are deployed frequently, it is useful to communicate monthly an overview of all changes that are planned or have been deployed.

Are you short-changing architecture and testing?

Any rapid deployment approach is likely to short-cut considerations of architecture, infrastructure, and vendor changes and testing. In many cases this works out, but in some situations, these omissions can require later rework to address issues not identified during the development process.

When planning a quick release, confirm that skipping the activities normally included in a comprehensive development process does not create major risks. Do not assume that because the changes are small, the risks are as well.

Recommendations

The adoption of a continuous improvement approach involving frequent changes to applications can significantly reduce delays between opportunity identification and opportunity deployment. This does not make it appropriate as a universal approach.

Consider a more disciplined approach to development and a longer release timetable in any of the following scenarios:

  • The degree of development is significant, and breaking up a change into several smaller components will delay the overall completion of a project.
  • The benefit of the change requires significant user awareness and process adjustment, unless you have a very effective way of communicating frequent changes.
  • The omission of key elements in the development process in the interest of speed will create a risk of deployment problems or the need to rework the solution later.

Bottom Line

A continuous improvement approach for the evolution of application systems can accelerate the availability of improved functionality. However, it should not be adopted as the universal approach to application enhancement.

Large development initiatives, initiatives that depend on broad adoption of change and projects that require consideration of architecture, vendor relationships, etc., do not suit the small, frequent approach to application change.


Want to Know More?

Five Barriers to Continuous Improvement

Continuous Improvement – The challenges we face today

Visit our IT Cost Optimization Center
Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019