« Letter to a PM – Going to the Customer | Main | A Brief History of Change – System as Change Driver »

A Brief History of Change – The Future of Change

We have looked at Change as a barrier and an opportunity. What can we say about the future of Change Management in software development?

Our initial focus was managing change in the requirements set – getting the system right in a changing environment. We recognized that change in requirements is not a result of users changing their minds, or not knowing their needs. Change in the requirements of the system is natural, and ever present.

The central challenge today is not getting the system right from a requirements point of view, it is implementing a meta-system – a process that periodically optimizes the multivariate calculus of resources, feature set, ROI for the customer, delivery dates, user change management, and quality.

In a software product organization, this dynamic covers many different groups with different priorities. The product managers want the most functionality for the users. The development team wants well-defined modules that fit together with clean interfaces. The QA group wants a clean, testable interface. The Deployment team wants clean code, with no emergency patches two weeks after release. The users want more more more, but often can’t handle more functionality.

So how to you balance the needs of the organization, the needs of the users, and the overall goal of delivering maximum value?

I think that the answer is to stay flexible. Create global definitions and reference them in all requirements documents. Specify requirements in smaller, less-intertwined modules. Write code that uses the modern techniques that reduce visibility and change effects across modules.

Practice “late binding” of features to releases to avoid the “feature packing” tendency that causes bloated releases and quality compromises. This means structuring all parts of the process to deliver smaller, more independent modules that can be individually tested and deployed. This gives you back control of your release schedule, and lets you timebox – adjust the scope to fit the schedule.

Change is inevitable, in every project.  The true Art is adapting, and using Change as a strategic advantage.

Posted on Thursday, April 13, 2006 at 10:21PM by Registered CommenterLarry Cone in | CommentsPost a Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.