Your web browser is out of date. Update your browser for more security, speed, and the best experience on this site.

You may also visit the site on your mobile device.

General

Change Matters

Three-apples-green-and-red-water-drops-black-background_1920x1200
Three-apples-green-and-red-water-drops-black-background_1920x1200

Welcome to the second in the series of the Kronos WFC Upgrade Studio Change Management Toolkit. Remember, no psycho-babble. No discussion of checkpoints, Change Control Review Boards or big flowcharts. We're going to focus on the stuff that matters.

CHANGE is CONSTANT
CHANGE is INEVITABLE
CHANGE MATTERS to EVERYONE

So let's cut to the chase. How does an implementation team decide just how much Change Management (next blog I'll clearly define my use of the terms) is required for the organization? One has to carefully analyze both the functional and technical impact of the changes that will be promoted into Production.

The Technical concerns are usually just "Make sure the change does what it appears it's supposed to do. Don't let it break Production."

The Functional concerns are simply, well, often ignored except for development requested by a particular person/dept/location. The scary part here is that it's the functional areas for which ALL this is done? Why do anything if it doesn't improve Operations, ROI, User Experience, etc.

With this in mind one should ask serious questions about the way we manage change.

  • Do you care about the cultural change that's coming? We should consider this every bit as important as not breaking something! 

  • Do you understand the ‘WHY' of the change and what it might impact? 

  • The change will likely need training. Who needs it, exactly what and why? What will change in their work? How can we leverage the good stuff to come (consider the potential widespread impact)?

  • How large is our organization and what are our internal requirements for managing change? Do we have strong automated and/or well documented and understood approval processes for moving through environments (DEV-PROD)? Why not?

  • How much development is going on? Coming? And will there be multiple teams who interact, or don't? (We'll chat about Environments and Sandboxes later)

  • How are we going to manage the changes as they move through the environments?

  • How often are we going to handle patches and upgrades?

  • How do we handle issues that arise while migrating change through the environments? 

Those are just a few thoughts to get one started. More to come tomorrow right here in this space!

Comments

YouTube Icon LinkedIn Icon Twitter Icon