PRINCIPLES - based on type of change

[Harden-p40]

As an employee of the Church, we are seeking experiences from the tech community on change management. As all technologist have had to deal with change management, we would like to receive your feedback on underlying principles you have found to be extremely effective in managing change. For example - for a given type of change (defect, new project, configuration, Data Model, etc...) what underlying principles control and manage such changes extremely effectively?

[sochsner]

I don't exactly know what you mean, but I think it is common sense... Please correct me if i am wrong.

[thedqs]

As an employee of the Church, we are seeking experiences from the tech community on change management. As all technologist have had to deal with change management, we would like to receive your feedback on underlying principles you have found to be extremely effective in managing change.

Ok I figured it out, you want to know how we as a tech community handel change.

• Defect

For a defect in a program the way I handle it is mostly based on how I keep track of it, usually I'll takle the important, system crash type bugs first. After that I'll try to do any cosmetic stuff and finally add features.

• new project

This is the hardest since that means reallocating time and resources. First off any previous project recieves more of a maintance role until the new project is brought up onto a working level. Then both projects can move onto active development. But if you have lots of projects, as in a large organization, you'll have to break up into teams that manage one or two projects. Once a team gets above two projects, all the projects suffer, or the team focuses on one only.

• configuration

What would be an example of this?

• Data Model

I am assuming how the data is organized. This is also hard unless the application was built on interfaces that were inherited by the classes. Since in that case you can change the underlying implimentation and data struture without having to worry about conflicts. But if that is not the case, the first major undertaking is to make everything interfaced related and then change the underlying system. (This takes more time at first but in the long run it is a lot easier then having to redesign the system each time.

What underlying principles control and manage such changes extremely effectively?

Basically what will result in a visable improvement in the products/services that are given. Which covers user input, system responce time, etc.

I hope this is what you were going for if it was a management question for HR I'd have another response.

[LittleGreen-p40]

Change agents are one of the most effective tools for facilitating change within the organization around new technologies. Change agents are typically power users with passion - for instance, those who check new.familysearch.org every week to find out if it is finally available in their area. Since change agents are users (not developers) they can effectively communicate the benefits of the new system to their fellow users - rather than it appearing to be an imposed change from IT.

The broader the base of change agents you can pull from, the quicker and smoother the implementation of new technologies will be. For example, imagine a university setting where each college has faculty representatives on a committee that previews new faculty technologies and provides feedback to IT. These change agents are then able to train the faculty of their respective colleges on the new technologies and will do so with passion since they have been involved in the product development. You can also be sure that the passionate change agent will be discussing (and sometimes demonstrating) the new technologies with their fellow users well in advance of the release of the product. The anticipation of the new product also facilitates user adoption.

By the way, this site could be a great resource for recruiting and training change agents throughout the Church. Since many of the technologies being developed by the Church are web-based, you might create a technology preview section on this site for change agents to get involved in user reviews. You might also consider how the stake technology specialist could function as a change agent.

[bhofmann]

The most important principle we've found where I work is to have a point person or group who decides the priority on projects. This group would know all projects currently in the queue and would understand how bumping up the priority on a particular project would affect the other projects at the top of the priority list. Of course you would need to decide what criteria are important for you so you know how to prioritize. For us it is revenue and return on investment. I'm not sure what it would be for the Church. A good process and proper controlled priorities goes a long way for all types of change.

[portseven-p40]

As a Enteprise Arcitect my view on principles are that they should underpin any change. They define the reason, shape and direction of the change. The principles should be the IT principles that are derived from the overall organizations business principles.

Good examples are...

• Reuse before Buy before Build
• The Principles ALWAYS apply
• Control Technical Diversity
• For main/large Database systems ORACLE on SUN Solaris should be used
• One version of the Truth
• Wherever possible manual interventions (e.g. data input) should be avoided

There are many others, but they will vary per organization

[LACourt403]

I thought that the explanation of how people, named 'Change Agents' who often check regularly for new updates could advocate and encourage change to happen, was very well written.

However, I must say that human nature being what it is, tends to resist change, particularly those who have management-level decision-making abilities and who are steeped with the traditions and conditioning of maintaining the "status quo" and don't understand all of the possible impacts of creating change, and conflicts that are associated with change.

In my opinion, there are many huge gaps typically between the technical and business parts of any business or institution, including the corporation of the Church. Sure, there is Information Technology Infrastructure Library (ITIL) and other methodologies, but these practices just define what the ideal change model(s) should be. And people being people just don't communicate perfectly, or follow instructions correctly, or even give instructions properly for that matter.

It's important to understand the differences amongst administrative convenience, technical challenges, user resistance, and gospel principles. For example, in I/T, the cliche of "it's easier to seek forgiveness than ask for permission" seems to make sense in most institutions. Yet, there are subtle differences that require understanding how Church Doctrine is used to explain how certain methodologies and practices are best followed.

Perhaps, that why the seeking the Spirit and applying our best talents forward is always the best policy as we learn to use a variety of management styles.

At no time is that more useful than now, where we are transitioning between the classic or old website to the new website.

[welder]

good

[welder]

cambiar para mejorar darnos mas facilidad para resolver algunas situaciones como no puedo colocar el pais en mi perfil de empleo me produce alguna curiosidad cual es el objetivo