Contents:
Chapter Everybody does it
section The large development shop
section Smaller organisations
section My friends and I
Chapter How it grows
section As do we
section Increasing reliance on and importance of IT
section Bumps in the night
section The more things change...
Chapter Can we afford this
section The measure of things
section Cost escalation
section Right-sizing
Chapter Choosing a vendor
section Buying against building
section Pre-packaged against Customisable
section Big vendors against Small
Chapter Summary of models
section Application: One tool for all against Specialisation
section Control: Safe and secure against The freedom to act
section Location: Centralised against Distributed
section Extent: Omnipotence against Minimalism
section Division: Separate environments against Modes of access
Chapter Summary of features
section Degrees of authority, ownership, and access
section Compilers, generators, and versioning
section Completion and requirements validation
section Syntax and Standards validation
section Archives and backups
section Audit and reporting
section Activity and requirements documentation
section Migration and packaging
section Co-ordination and scheduling
section Reversing changes
section Migrating deletes and cleanups
section Effective dated changes
section Exceptions and exits
section Merging parallel development streams
section Externally supplied releases
Even though it may only be a memory of past efforts, everyone who writes software has a preferred method. As one gains experience that method is refined into some process that either guarantees accurate code, timely completion, and/or a cost effective solution. The only real reasons for a haphazard approach is inexperience or a disregard for the above three measures.
To this end, the value of this book is in passing on the experience of others for those new to the concept of organised software development; identifying all of the issues and opportunities that may arise. Not surprisingly, the driving requirements in software change management are much the same as for other occupational endeavours. Many who have been in business for some time will see these parallels. However any parallels are incidental. There is no intent to identify or force conformance to such co-incidence.
While this chapter is roughly divided by the size of an organisation, such division is representative of the different issues faced by such companies and does not infer degrees of change management complexity as such.
section The large development shop out prev next
It is simple for a large organisation to justify building a robust development environment. This is because they already have defined processes and culture for other aspects of their work. There is a built in assumption of correct procedure that often leaves no room for personal expression on behalf of those working within this type of structure.
This is where the first hurdle occurs, although it often goes unrecognised by successive generations of management. Software development is a relatively young profession which is populated by people who expect autonomy. Much of the ground rules are still being learned about computer science. Those who practice it may consider themselves as Artisans, whereas management might prefer an engineering model. Engineering as an occupation is fairly mature, and has well defined procedures for assuring measurable results (although it is not as exact a science as is usually assumed). It is common for programmers and the like to avoid such things as deadlines and job descriptions. This type of codifying is thought to limit free expression. That which management sees as a non-conformist or cowboy mentality is really a matter of general uncertainty of what quantity and quality is achievable for a given amount of time and experience. Such a degree of measurement is not well defined in the wider industry and so has not been taught to computing professionals let alone to company department managers.
Corporations who have established computing departments do not lack for justification of well defined software change management. But they do find achievement of such a goal to be difficult. The manager who is able to meld the competing attitudes and issues will succeed in building an efficient development environment. Keep in mind that as the industry matures, this balance will remain a moving target for all companies.
Most corporations who do software development are actually in some other line of business. Their reasons for doing their own development are varied, but usually revolve around esoteric software needs or a drive for competitive advantage. This factor serves to widen the gap between senior management and their computing department. When times are difficult, departments which appear to cost more than they earn are seen as an overhead. The costs of providing computing solutions are fairly easy to tabulate broadly. Whereas all departments who use these services tend to be loath to identify the technology as a source of their income or cost control. (customers are the only source of income, aren't they?) There is usually a pressure to continually reduce costs. On the whole this is a good thing, but occasionally reaches plague proportions because of the relative ignorance on behalf of other departments and senior management to the issues of attaching computing to the wider company (not necessarily their own fault). Large corporations usually need to divide the computing department into smaller groups. This leads to the inception of groups who exist only to support other computing groups. It is often at this time that a corporation learns the need for formal change management. Change management support as a function is then handed to one of the sub-groups who are least able to defend their cost to the wider company.
Groups, departments, and divisions within corporations have a tendency to come and go with disturbing frequency. While some appraisal of how to divide labour is useful in the search for optimum performance, an abundance of such change serves only to induce undue stress on staff. These structural changes may overshadow the actual work that is being done, but the real work generally continues to be required under a new regime. That is, each technical function is necessary regardless of how it might be distributed. One day change management may be a separate department, next the responsibilities might be split between several managers. Some activities may even be neglected for a while and later duplicated by several departments. It usually is only a matter of whether a given function is recognised or intrinsic, manual or automated. Only occasionally an activity truly is born or dies.
section Smaller organisations out prev next
A large corporation might have many departments working on computer related activities; sending memos and reports to each other and holding meetings to ensure co-ordination and common objectives. Smaller organisations, on the other hand, will likely vest the entire responsibility to a single department or team. Because some technician does not need to issue reports to himself or hold her own meeting, it may seem as though less functions are being conducted. In fact this is not the case. It is simply that many functions are intrinsic (not distinguished) by virtue of a lower volume of work.
For example, knowing the constraints of the live system, a programmer might copy a program to a temporary space and make a deemed change. They would then ask a fellow to try it out and, after letting the users know and taking a backup, copy it back into the live system at a time that is known not to be critical. The same person, might then be asked to amend some operational document for the benefit of future staff. This change involved three people for a combined effort of perhaps one day. The same change required by a large corporation might involve perhaps 13 people (including management) within 5 departments and take perhaps a week to be completed. However many more changes will have been worked on at the same time, so the effort expended on this particular change will only be perhaps twice that of the smaller company.
The key point though is that the same functions were required even though the division of labour and volume of work is different.
The common misconception is that software change management is not so important for the smaller company. Whether or not some automation is involved or some procedures are defined, the change process is still managed. How well it is managed depends as much on staff attitudes as it does on availability of suitable tools and procedures and as much on a knowledge of the opportunities and pitfalls. The state of each of these issues are usually dependent on the collective experience of a given organisation and the regular volume of changes that need to be made. It is typically when the experience has been bad that the likes of this text are sought. It is not to say that a company has done something wrong, only that conditions have changed and gaps have been exposed in the provision of service. This type of situation occurs continually as a company grows and strives to meet the ever changing market.
section My friends and I out prev next
The smallest group is usually responsible for the most innovative software of all. It almost seems as though becoming larger and more organised reduces ones ability to innovate. As a small production team, this group requires more in the way of dogged effort and team interdependence than to regulated management and nifty automation. Despite this, the same processes are involved. And some understanding of this will certainly increase the efficiency of the group's work.
Ironically, while each member of such a team is required to be expert in many disciplines, they are also most easily side tracked away from their primary objective. This is largely to do with the personality of those who find themselves in this type of employment. They are driven and self motivated but are not easily guided along a single path or task.
This group of people is likely to begin many more projects than they ever complete. It depends on both attitude and budget as to whether such a tendency is a fault or an advantage in achieving innovative results. It can be seen then that the management of software development is just as important at this level, even if perhaps for a different set of reasons.
The normal measure of company success is in the way it grows. A company which steadily increases market share or which manages the growth of its industry is said to be successful. Just as with any other part of a growing company, management of the change process is undergoing continual re-invention and evolution. While it may be said that 'change is the only constant', it is equally true that 'change is also changing'.
But software change management is just another discipline among all the others. Managing its growth is much the same as managing other changes of procedure. One does not have to be any more or less mindful of the pitfalls and frustrations involved. Bear in mind though that this book is about Software Change Management and not a discourse on Business Restructuring. However, it pays to understand the motivators which induce changes to the change process.
section As do we out prev next
It is apparent then that the growth of a company is the most obvious driver of change. Company growth would seem to offer an opportunity for well managed growth of all of its parts. Unfortunately, this is rarely the case. There is an intrinsic resistance to change and so the process normally occurs reactively. All the more important then to have a familiarity with the important attributes of successful software change management strategies.
A typical measure of company growth is by the number of people involved. Although it could be argued that the number of people is only a reverse indicator of efficiency. In any event, it remains true that a larger company always requires more people per process. And as such, risks are created when more than one mind is at work. It does not matter at which point more people are added, merely doing so creates a side-effect of increased complication, and therefore more sophistication is added to the change process which eventually resolves to further automation. How successfully this automation is implemented depends on how well the original growth trend is recognised.
section Increasing reliance on and importance of IT out prev next
Computers are everywhere. Few businesses can survive without some form of computerisation. As more companies find value in using computers, there is a greater need for specialised software and a larger market for standardised software. Suppliers of standardised software may then grow a need for their own specialised software. It is specialised software which has the greater need for controlled development practices.
As competitors begin to automate their operations, eventually all companies must follow suite. In some industries it is this identification of opportunities for automation which guarantees survival. Companies with a continual need to search out these opportunities will often be forced to conduct their own research and develop their own specialised software.
Successful implementations of automation invariably leads to growth of the computing department. Ironically, so can failed attempts at automation, if the company has deemed that a future success is necessary and possible. Companies playing catch up may invest heavily early on in computerisation/automation which can easily result in too much too quickly. If identified early enough, there is always enough time to manage the growth of a computing department.
section Bumps in the night out prev next
Sometimes a company is not in control of it's software destiny. Moves made by competitors, clients, or suppliers may force a company to invest in development of their own software or to customise their operations to conform to others' automation requirements. Equally, issues can arise within a company than might force a similar review of their use of computing facilities.
External drivers of change are not an indicator of lack of control. It is merely the way things are. Similarly, reaction to unexpected disaster is a normal business practice. Every attempt may be made to account for possible problems and provide stratagem for recovery/avoidance. But in the end, pragmatism will rule a line at some point beyond which money will not be spent on paranoia. The smaller the company, the earlier that line will be drawn.
A company which never needs to react to disaster, is probably too cautious to lead in its industry and may even find its costs overrun the resources available to operate at all. As in everything there is a balance to be struck, and each company will do so differently. It is the way a company reacts to or plans for disaster which marks its maturity.
section The more things change... out prev next
Over time, the manufactured product changes, the market changes, the process of manufacture changes, the business priority changes, and the process of change changes. Academia has analysed these trends and found repeating processes. So, it is possible to research in which ways change is found to be constant, and to recognise at which point ones own operation is positioned.
This is all quite off target for this text but serves to recognise why change occurs and to provide assurance that all is not out of control.
The reader should at this point be able to recognise their position in an industry and the scale of effort required for their software change management processes. In the end, ones gut feel of where to stop spending is probably correct. You would not be reading this book without having been successful in penetrating and growing your market.
section The measure of things out prev next
Spending on any aspect of business is mainly about providing for your company's ability to scale up to market demand while not committing resources too early. Software change management is several steps behind the front line of your business. Change Management serves the Product Development team, who serve the Manufacturing department, who serve the Sales and Distribution networks.
There is always more time available to manage the growth and planning of the rear guard operations than that for the front line. Requirements for growing these back end processes are much slower and more easily planned. But this is a double edged sword. While the requirements of software change management are relatively small, they are likely to be de-prioritised in favour of the urgency of higher profile business needs. It is important that Change Management be given equal priority in the allocation of funds. Equal priority, not equal allocation.
This is a surprisingly difficult thing to achieve. Urgency invariably out-weighs importance. And the benefits of spending money on rear guard operations is always more difficult to quantify. In a large organisation, this predicament is usually managed by shortening the reporting line to senior management. That is, the Change Management department reports directly to senior management.
section Cost escalation out prev next
There is little danger of spending too much on software change management. However, this specialty is capable of becoming extremely sophisticated and complex, as will be seen in subsequent chapters. The amount of code being maintained and the scale of changes being made may require such sophistication, or may not. It is therefore important to identify the appropriate scale for your software change management environment.
If not careful, one might commit to a structure that requires too much overhead for Development staff. That is, by complicating the breadth of baseline expertise that is required by developers, they may either spend more time managing the process than in doing real work, or more likely they will find excuses and methods for avoiding the official process. It can also lengthen the path to production by introducing unnecessary breakpoints and testing requirements.
These excesses represent indirect costs to your operation. Similarly, not providing thorough testing, or the skipping of revision check points, may lead to increased production failure rates. Another obvious cost increase. Measurement of these issues over time (metrics) can assist greatly in targeting the appropriate management scale.
section Right-sizing out prev next
Right-sizing is one of those terms one expects to hear from their consultants. It came and went quite quickly, mostly because it adds little value to any given discussion or report. However, while pedantic, it does need to be kept in mind when reviewing the various opportunities, models, and products that are available to ensure only the appropriate choices are made.
Fortunately, software change management is a craft that can be enlarged, or indeed reduced, according to the growth of your throughput, available funds, and acceptance by all impacted parties. Being a back end process, changes to the change management process do not generally have a severe impact to profit generation.
Changes to this process can be readily introduced if everyone recognises the need for such change. Bringing everyone on board is important. Parties who do not understand the need for change, or its implementation, will spoil some of the benefit of such effort. Again, one must analyse the reasons for conflict. It is better to collect the opinions, understanding, and priorities from all parties before implementing a change to process. This will help ensure that everyone is willing and able to change by ensuring their buy-in to that change process.
This discussion will avoid referring to specific products and vendors. For one thing nobody knows more than a few of them, and for another, over time, suppliers will re-focus and replace their products which would there-by render this text obsolete.
section Buying against building out prev Next
This is a tough call. In the end your own policies will be your main guide. A bought-in product allows you to leave as much as possible the maintenance of tool sets to the vendor. This is important if your company is actually supposed to be focussed on some other industry; not software development.
In particular, you may not hold the required expertise in-house to construct your own software change management facility. That said, there are no products available which fit any company's requirements sufficiently. There will always be a need for a degree of customisation and extension to align the selected product with your situation.
The only product which accurately matches your requirements is the one you write yourself. This may be too expensive an option for most companies. Apart from attaining the expertise and confidence necessary to undertake such a task, there is also the factor of then retaining the knowledge in-house over time. Will you be reliant on the person who created the change management facility? Or is there sufficient overlap of skills and sharing of the development effort? Where software development is the business you are in, this should not be a problem.
section Pre-packaged against Customisable out prev next
This is almost the same issue as that above. Having decided to use an off-the-shelf product, are your requirements fixed, well understood, and matched sufficiently to one or more of the available products? If all of these are true, then it is best for your development teams and processes be made to conform to one of these products. Lowering the maintenance effort surrounding a 'black-box' software change management facility is highly desirable for the company who conducts software development with reticence.
If your requirements are likely to vary between development projects or over time; if you are not entirely sure of what your requirements are; or if there are no suitable products available, then the next best choice is a product that is highly configurable. Such a package will be composed of a set of structures and processing objects and utilities, rather than be a fully self contained product with an on-off switch. Customisation is another two edged sword in as much that it adds flexibility and also requires more effort. In this case, it becomes important to not customise the selected product out of existence. Don't overly commit resources to maintaining the software change management tools and processes at the expense of the work that it was intended to manage.
section Big vendors against Small out prev next
This issue is fairly consistent with the size of your own organisation. Large companies typically seek relationships with suppliers who can offer a wider range of services and products. And there is an implicit expectation of higher expertise. While there is no logical rationale for this, it is normal practice. A large supplier is certainly more likely to share the types of processing requirements of their large clients, and so will develop products that generally meet their own needs too.
Similarly, a smaller company is more driven by the basic costs involved, and will seek out suppliers who can meet the immediate need. The growth of change management processes is more organic at this level, and may be met with manual processes while exact requirements are ascertained. Automation is usually constrained to easily identified units of activity, rather than the whole change management process.
Regardless of which end of town one searches, the building of strong and mutually beneficial relationships is paramount. It is always better that vendors and customers meet eachother's needs and do not consider the relationship to be one-sided. A poor relationship will ultimately reduce the efficiency of the end product.
section Local vendors against International out prev next
Likewise, this issue is relative to the size of a given company's target market. That is; not the size of the company itself. Each company wants support from vendors who can help with and understand the requirements of their down stream development requirements.
In technical terms, being a multi-national company is little different from being a multi-site regional company. However, a company which serves distinctly different markets will be required to meet each and every local condition. This may not be achieveable within the confines of a single corporate change management process. A vendor which understands the nuances of your target markets will be better placed to assist in matching their product's capabilities.
Choosing a vendor that is too broad in its own reach, will
similarly be less in touch with the degree of knowledge that your
own company has of a given market. If your own market is locally
based, it is usually best to consider vendors who are based at
the same level and/or locality. However, such a vendor may not
be entirely possible to find.
It is finally time to look more closely at the workings of a software change management package. This will be done by identifying the various dimensions by which a package may be measured, and comparing the extreme attributes of each such measure. This should allow any specific package to be recognised and its relative streangths and weaknesses to be readily acknowledged.
Based on the following measures, it should be possible for a package to be chosen which is sufficiently flexible in the dimensions which are important without requiring inordinate customisation in those dimensions which are less relevant. If an ideal package cannot be sourced, then at least it should be possible to understand where compromises will have to be made.
section Application: One tool for all against Specialisation out prev next
The first dimension to be measured is that of Generalist versus Specialist. A general purpose package can be expected to require either significant customisation to meet a company's development process, or a change in those processes to conform to the norms expected by the package. It will, however, be capable of supporting the majority of development projects and should scale well to the larger development efforts. A specially written facility, on the other hand, will use language and techniques which are already familiar to the resident development teams, and so not require significant education prior to deployment. The downside to such specialisation usually is with scalability as a company grows and its development community matures, this product itself may not grow sufficiently.
It is all very well to say that one needs a package that is specific to ones needs. But just how specific are your needs? In what way are they specific? It is most likely that specialisation is only required around the edges of what is usually a fairly common development process. Specialised change management software usually implies in-house specification and production of that software.
For example, a company which needs to develop mainframe software, generally will deploy the production code on the same physical machine, or at least at the same site, which facilitated the development. It is relatively rare for development to occur at a site or machine which is physically distant from the production environment. This situation is therefore not commonly supported by mainframe change management software, without some degree of customisation and writing of specialised code. Now let us suppose that the mechanism for deployment of production code is changed due to advances in technology. Will that specialist code remain applicable? What if the process is changed to require final testing on the production machine? Will your custom code survive?
section Control: Safe and secure against The freedom to act out prev next
.
section Location: Centralised against Distributed out prev next
.
section Extent: Omnipotence against Minimalism out prev next
.
section Division: Separate environments against Modes of access out prev next
.
.
section Degrees of authority, ownership, and access out prev next
.
section Compilers, generators, and versioning out prev next
.
section Completion and requirements validation out prev next
.
section Syntax and Standards validation out prev next
.
section Archives and backups out prev next
.
section Audit and reporting out prev next
.
section Activity and requirements documentation out prev next
.
section Migration and packaging out prev next
.
section Co-ordination and scheduling out prev next
.
section Reversing changes out prev next
.
section Migrating deletes and cleanups out prev next
.
section Effective dated changes out prev next
.
section Exceptions and exits out prev next
.
section Merging parallel development streams out prev next
.
section Externally supplied releases out prev next
.
| Working Title: | Software Change Management - The Incomplete Reference |
| Synopsis: |
To express the value of formal change principles, To explore various philosophies, strategies, and techniques, To contextualise for various organisation types, To detail opportunities and desirable facilities, and To acknowledge structural and practical constraints. |
| Author: | Copyright (c) 2000-2001 by Philip Trinham |
| Book Commenced: | 18 February, 1998 |
| Book Completion: | Never |
| Revision: | 20 December, 2000 - Convert to HTML |
| Book Title: | The importance of being earnest - Aearnest.htm |