Posted Jun 7, 2008 5:10 PM
I do not see a lot of emphasis being given on planning and managing the change brought about by a Software/System implementation. The focus is generally too technical.
What I am referring to is the change impact assessment, assessing user readiness, preparing the stakeholders/users for the change all through various stages of the project, building up a good communication and training plan, executing these through different modes like formal classroom training, webinars/VCs, CBT/Self-study materials, User Manuals, quick references, Posters/flyers/announcements/brochures, user awareness forums, etc.
Can someone direct me to good resources, models, samples, templates, checklists, etc. on this, and experiences of how effective these are?
Thanks in advance. Saving Changes...
Sort By:
Gordon MacMasterw3r Consulting/Day Is Done Inc.Grosse Pointe Woods, Mi, United States
I agree with your observation. For many reasons. there is a tendancy to see IT and the users as very isolated entities. There is a blind spot regarding the interdependence between software implementation and the changes it will have on business operations.
Awareness – of why the change is needed
Desire – to support and participate in the change
Knowledge – of how to change
Ability – to implement new skills and behaviors
Reinforcement – to sustain the change
My own opinion is a lot of material on change management has a fundamental flaw - that everyone can be convinced to support a change. There will always be some die hards who, no matter how reasonable an arguement, will try an thwart a change. It is best if they are open about - worse if it is done behind the scenes. Be prepared to do battle with these folks.
Given that you need to gather requirements on any project, I would suggest that the change be assessed by the various groups contibuting to the requirements straight after the requirements are gathered.
This ensures that everyone takes the time to determine what needs to change within their dept and if required, they can update the requirements spec before it is signed off. This way, you get people thinking about the change earlier on in the project and you also have a set of deliverables to build into the plan to ensure the change is delivered in the right way. This would include processes mapping, training design and delivery, user guides etc.
Hope this helps Saving Changes...
Anonymous
The project and organization structures play a big role in planning and implementating changes needed to support a successful software implementation. Sometimes the clients tend to shield the IT implementation vendors from the organizational dynamics. It is important for IT vendors to understand what change management prcoesses are in place even though the How's can be managed by the client organization. It is very important to establish the trust in the relationship between vendor and the client for a successful implementation. Often times, these changes impact people and processes, and multiple entities in the organization need to get involved. Saving Changes...
Peter WrightProgramme Manager| BAE SystemsSouthport, Merseyside, United Kingdom
You are highlighting one of the areas that a lot of businesses do not scope in their project management. The focus tends to be on the product/system and not the surrounding business support and functions that need to change to support it.
The information you are seeking changes depending on the services, systems and products you are working within, for example a climate CIA checklist will be different from a Financial CIA.
I have seen a scope used before called Lines of Development that can be used to develop in house CIA by then breaking these down into more detailed catagories.
Training:- The provision of the means to practise, develop and validate, within constraints, the practical application of a training document/material to deliver the product./system effectively.
Equipment:- The provision of platforms, systems and software, (expendable and non-expendable, including updates to legacy systems) needed to outfit/equip an individual, group or organisation.
Personnel:- The timely provision of sufficient, capable and motivated personnel to deliver the product outputs, now and in the future.
Information:- The provision of a coherent development of data, information and knowledge requirements for products and all processes designed to gather and handle data, information and knowledge. Data is defined as raw facts, without inherent meaning, used by humans and systems. Information is defined as data placed in context. Knowledge is Information applied to a particular situation.
Concepts and Documentation/Proceses - A Concept is an expression of the product/systems that are likely to be used to accomplish an busienss benefit in the future. Documentation/Process is an expression of the principles by which staff guide their actions and is a presentation of how activity is conducted today. It is authoritative, but requires judgement in application.
Organisation:- Relates to the operational and non-operational organisational relationships of people. It typically includes permanent, contractor staffing and organisational structures providing support.
Infrastructure:- The Design, provision, development, management and disposal of all fixed, permanent buildings and structures, land, utilities and facility management services (both Hard and Soft facility management (FM)) in support of bsuinesses. It includes estate development and structures that support personnel.
Logistics:- The science of planning and carrying out the movement and maintenance of staff. In its most comprehensive sense, it relates to the aspects of business operations which deal with; the design and development, acquisition, storage, transport, distribution, maintenance, evacuation and disposition of materiel; the transport of personnel; the acquisition, construction, maintenance, operation, and disposition of facilities; the acquisition or furnishing of services, medical and health service support.
Interfacing and Interoperability (Overarching Theme):- In addition to the other lines of development Interoperability with legacy systems, business processes and business entities that must be considered when any line of development is being addressed. The ability of Engineers, when appropriate, with other partners to operate and work effectively together in the execution of assigned activities.
In the context of Lines of Development Interoperability also covers interaction between Business units including compatibility with Civil Regulations.
For some reason I never knew there were so many responses, hence did not bother to look into this thread. Only today I chanced upon it. Thank you all for your detailed responses, and my apologies for the delay.... The most available model and framework online seems to the one from Prosci at http://www.prosci.com/. Check it out.
One other thing I realize is that Transitions Management discipline caters to this much more than project management, but even that is incomplete.
Another observation is that change management in IT field has become a much tougher discipline because
1) many a times the impact of an automation is dependent on many more extraneous factors than what the PM or even the sponsoring business could ever think of. Hence the desired effect is missing and and analysis of this leads to the next software.
2) The average lifespan of a software application has come down drastically over the last few years, especially with advances in technology and more because with every CxO change and change in market conditions - with Clouds, Mobiles and Facebooks abound.
What do you think? Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
The reduction in the average lifespan of a software development actually makes change management more important. Shorter development timescales means more change can be fitted into a year, and while that is great news for the IT department, it can often be too much to deal with for the end users.
Good change management principles take into account the impact on the operational teams, and there comes a time when a particular department just can't take any more change in a short time period. Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
There are two important aspects that we need to deal with in managing change - soft aspect (resistance from people), hard aspect (impact on people). In order to deal with the soft aspect, we need to address the 'Why?' piece. We need to prepare the mindset of the people through educating them on the objectives and benefits of the change so that they are aware and willing to buy-in and support the change. For the hard aspect, we need to address the 'How?' piece. We need to understand the impact and come up with a good transition plan for people to follow in order to keep the impact to the minimum level. Saving Changes...
Woo - Like your categorization of change into soft and hard impacts. While the transition managers seem to be good at the hard part, the "soft" areas seem more easily dealt with by the senior management of the team undergoing the change, and the HR of course.
Elizabeth - You are so right in saying that there are many organizations/enduser-groups with whom the IT teams face the scenarios you mention, especially if they have long-established processes undergoing change, or the initial settling down process takes a little longer giving them a feeling that the "disruption" happened just "a few weeks" ago, or they are simply not convinced on the opportunity cost of not changing.
Meanwhile, we do also see the businesses
1) pushing the IT team for more on their Blackberry or IPads or Facebook for instance because their competitors are going for it or
2) spending through their noses to maintain and procure hardware, when "Cloud" comes with the promise of a lower IT spend,
3) showing impatience in not having their post deployment feedback and suggestions for improvement not coming out fast enough.
The success I guess depends on how quickly we identify the category the user base/sponsor belongs to and plan expectation setting communication, training and the product lifecycle accordingly. We now see the SCRUM and AGILE software development evangelists as well who have gotten PMI also to consider their methodologies quite seriously.
Here the inputs of transition managers and the Business relation managers can be very helpful. Saving Changes...
