A key part of managing change is testing and quality assurance. This guest post was written by a dear friend of mine after finishing another arduous sprint on an Agile-run project. Here's to all our QA people out there who ensure we deliver quality Kronos projects!
Friends, we live in a world that has software and that software needs to be thoroughly tested. Who's gonna do it? You? You, [fill in a name]? I have a greater responsibility than you can possibly fathom.
You coddle the developers who miss deadlines and curse QA's setting of high goals; you have that luxury. You have the luxury of not knowing what I know: that setting high goals, holding people accountable and enforcing processes, while difficult, creates a quality product and that my existence, while grotesque and incomprehensible to you, creates a quality product.
You don't want the truth because deep down in places you don't talk about at meetings you want me to test, you need me test. QA uses words like accuracy, consistency, quality. We use them as the backbone of a QA person working hard to create a quality product. You use them as a punchline. I have neither the time not the inclination to explain myself to a person who rises and sleeps under the blanket of quality I provide and then questions the manner in which I provide it. I would rather you just said "thank you" and went your way. Otherwise, I suggest you learn how to QA and match the level of our commitment to quality. Either way, I don't give a damn what you think, for we in QA
will not change.
How do you handle change?
Welcome to the first in a series of blog entries about Change Management, Change Control, and Environment Management with content and brainstorming provided by a many including some regular guest bloggers such as Chris Flanders and David Goldhirsch. This is all still in the brainstorming stage so excuse the mess! Please comment, call, email, whatever. We want your input. Thanks to all for your generous help and support to Kronosblog.
The not so clearly defined terms Change Control / Change Management and Environment / Instance Management come up more and more these days as the WFC product line becomes larger and more complex itself. However, unlike from the big guys at SAP or Oracle there is little documentation and tools available at a reasonable cost for Kronos products. Given this is an important part of our new initiative "The Upgrade Studio" I’m starting this discussion and research of best practices to improve what we all can manage for a reasonable effort (always leading to serious cost savings!)
Managing and controlling change; customization, configuration changes and upgrades to Kronos Timekeeper and associated Workforce Central products can be a truly daunting task, with more than its fair share of perils and dramas. What we’re going to present in this series is a simple combination of all those terms and call it the Kronos WFC Upgrade Studio Change Management Toolkit. I'm not going to go into the gritty details of these topics as there are numerous good places to study the science and psycho-babble online like:
Change Management 101: A Primer
Change management - Wikipedia - check out the early links to Change Control and Configuration Management too.
The Information Technology Infrastructure Library (ITIL) is a set of concepts and policies for managing information technology (IT) infrastructure, development and operations. 6.1.4 - 6.1.6 applies to what we're talking about here.
Why Change Management?
Numerous changes initiated by support, project teams or by Kronos are moved into the system landscapes and semi-automatically or more often manually transported to Production servers. Because of the typically elaborate, complex implementations of large customers, the risk that something goes wrong is high and complex; expensive manual interventions are often required to get changes applied without impacting the running systems and operations.
Goal 1: The most important reason to implement Change Management processes is to reduce the risk of your production system. There are three primary risk factors we meet. They are: (1) crashing the system, (2) slowing down the system, and (3) causing inaccurate results in the system. There are other benefits to Change Management as well, like having documentation of change and coordinating communications, but reducing the risk to your production system, by significantly reducing the probability that problems will occur when change is introduced, is the primary goal.
Goal 2: The most important reason to implement Change Management processes is to increase the ROI of the system. Yep. Just as important as not breaking it IMO. I believe in not only avoiding risk (see Goal 1) but in growth from change. Every change to the system should improve the organization in some way. Even fixes to existing problems can do this if approached correctly. Over the years you’ve probably engaged workarounds to various problems. If you don’t address the cultural change of the fix the workarounds will continue to be used, hampering productivity. Prof Frances Frei makes the analogy that "workarounds" are just adding water to cover rocks. The Change Management process NEEDS to uncover the rocks and find the best path to improvements in the organization; changing processes, procedures, training, documentation, etc.
Agree/Disagree? Please comment and look for much more to come soon here at the Kronos Guy Blog.
Our last major testing step pre-upgrade is to review the Kronos release documentation for new features.
This may seem like kind of an obvious step, but it is one that often gets missed. Every new version has new features somewhere, and sometimes they are not going to be evident just by utilizing the application. You need to read about every new feature and decide if it is something you want to utilize or include in a process or change your configuration to account for. This helps you make sure that nothing is overlooked and reduces the likelihood of "surprise!" after you've upgraded.
It can also impact the new upgraded user manual you are creating. And finally, it will help you develop an upgrade "script", where you define out all the things you need to do during your upgrade process, especially if some of those things involve configuring new functionality that you never had before but you want to start using right away.
SO...what do you think? Is that what you do now for your testing? Any other great can't-forget-to-do-this testing ideas?
I promise you that those three things are going to help you test more efficiently and more effectively than any old generic UAT checklist that you've hung onto since v4.1...!
Good luck with your upgrade!
------------
This is the last in a series of articles by guest author Chris Flanders, "The Pioneer of the Schedule-Centric Model". You can reach Chris at http://www.linkedin.com/in/cflanders!
The third in a series of articles by guest author Chris Flanders
The second major area of testing is payroll. It is vital to retotalize your previous pay period.
Confirm that your configuration still works exactly the same way it has been. This will give you the confidence that, if nothing else changes, your employees in & out punches will get totalized in the same way and the employee will get paid the same way.
You can do this test by going through the following steps:
- Take a backup of your production database and upgrade it in a test environment to the new version.
- Remove signoff on all employees in the previous pay period.
- Force all employees to be retotalized by the BGP. (Run the SQL command "update totaleventts set totalizationstatus = 2".)
- Signoff on the previous pay period for all the employees.
- Run your payroll extract against the test system. (NOTE: To do this, you must have already upgraded and tested your interfaces. This process will help you confirm that your payroll extract interface is working correctly.)
- Compare your new test extract to the real production extract that you had before you took your production database backup.
This final step lets you see & confirm that all the time records that you extract from your existing system are identical to ones that have been totalized by and extracted from the upgraded test system. For any exceptions between the two (and there will probably be some), you just research and figure out why it was there. In most cases, it will just be some quirk of the extract timing, but what you want to find out is if anything in your rules configuration is now calculating differently. THAT is the key output of this test and successful completion of this test should give you (and your executive mgmt) a high level of confidence that when you upgrade, payroll won't suddenly change and you won't start paying out tons of OT!
There is a secondary benefit to this test as well. In order to complete it successfully, it means that you will also have been able to successfully:
-upgrade your database
-get an app server working
-get a BGP working and totalizing
-log into the application and do group edits
-run your extract interface
The second in a series of articles by guest author Chris Flanders.
Presumably you have something that tells your users how you want them to use the system. This can be a training guide or a user guide or something that helps you get your new employees & managers up to speed on how you use Kronos. In a lot of cases, this is the generic Kronos user guides that you have added to or tweaked to be custom for how you use WFC.
This user manual that you already have is the best place to start your testing. Take that manual and go through everything you do in the new, upgraded test system. If it all works -- great! You now have the confidence that your users can at least do what you've asked of them and trained them to do. If it doesn't, then you know where you need to focus some time. Using this as a UAT checklist is a great idea too, especially if you have end users coming in to help you test. Because that way they are confirming that the skills and functions they already have with Kronos will continue to work in the upgraded system, giving them confidence in the upgrade and helping user acceptance.
Also, going through your user manual in the new test system will let you know if you need to make any updates to it like screenshot changes or process flow changes. Every time Kronos changes the major version number of WFC (from v4 to v5 to v6), there is usually an new "look & feel" to the application that means new screenshots are required for your manuals, at a minimum. So there is a secondary benefit to using your user manual as a testing guide.
We have another guest author this week! I'd like to introduce you to Chris Flanders. Chris (or as we affectionately call him, "The Pioneer of the Schedule-Centric Model" is an expert within several areas of Kronos, and is one of the best scheduler experts around. You can reach him on his linked in profile: http://www.linkedin.com/in/cflanders This is the first of a 4-part series by Chris; the next 3 parts will detail areas where testing is critical.
Occasionally I get asked if I have or would recommend a standard checklist of items to test when a Kronos user is going through the process of a major version upgrade (like going from v6.0 to v6.1 -- not an SP install). I thought I would summarize some of my recommendations here in this forum and see if anyone else has any thoughts that they can add, as testing is something that we are probably all horribly familiar with.
The importance of performing pre-upgrade testing cannot be understated. If you have gone through a major version upgrade, you know that there have always been things you found after the upgrade in production (good and bad!) that you wish you had known about beforehand. They can be "bugs" or behavior changes or new functionality. And if you are a Kronos customer who has never had the experience of upgrading, then it is something you are especially concerned about because you want to know how to make sure you "catch" everything beforehand.
So when it comes time to do your upgrade, is there a "standard checklist" of things to test to make absolutely sure there are no surprises beforehand? Probably not. You can have a checklist of things that your company has experienced issues with before and want to test or you can go down through the Kronos navigation menu and check every single menu item to see if it looks right, but none of these things are going to GUARANTEE you that you will uncover all of the things you want to know about beforehand (bugs, behavior changes, & new functionality). But, there are some things you can do to test to gain a pretty good level of comfort that you are going to be okay after upgrading, and those are the things I recommend and want to talk about.
But before that, let me mention something real briefly about Kronos. The Kronos WFC suite is a vended application that Kronos engineering develops and supports. Kronos also does their own QA testing before releasing. That doesn't mean that there are no bugs in the software -- obviously they still have service packs they release and really every complex software vendor does the same thing. Also, since Kronos customers have the ability to do such unique & custom configurations, it's kind of impossible for Kronos QA to test every possible way that their customers are using the product. But what it does mean is that they have already tested (and you can have pretty good confidence) that the basic, obvious stuff all works. So when you do YOUR testing, it's not really so important to make sure that you click in every single cell on a timecard or have testing scripts that try to recreate all of the QA that Kronos has already done. That'll end up being a waste of time and it won't help you find those three things you want to know about beforehand. Instead you want to focus your testing on what Kronos can't test -- your configuration and your processes.
Tomorrow: Testing The User Manual!
This week we've discussed the three main reasons to upgrade: Software currency, tech support, and optimization. However, do these reasons mean your company should just jump right in and upgrade?
Next week we start a series of blogs with another guest author who is the "Pioneer of the Schedule-Centric" module. He talks about several tasks you MUST do before beginning the upgrade process.
So back to the question we asked at the beginning of this series: Due to the significance of the Kronos 6.1 upgrade, it's one version that demands a verdict. Do you know what side of the line your company is on? Should you?
The Improvizations team has developed a process called The Upgrade Studio. Regardless of the size of your company, this process provides a comprehensive look at your current Kronos usage, infrastructure, and other components to create a plan to upgrade (or in some cases, NOT to upgrade!)
Optimization: Another Reason to Upgrade Software Applications
Upgrading any software application can be a major undertaking across an organization. Of course, since we ARE in the business of workforce management consulting, we will again concentrate on the latest Kronos upgrade.
Some of the enhancements in the new Kronos 6.1 are better analytics and reporting. What is the financial impact to your company's bottom line? What if improved reporting and analytics features save 1 hour per week for each manager within your organization? If you have 100 managers with an average hourly equivalent of $45/hour, that's $4500 per week in soft dollars. That's over a quarter of a million dollars ANNUALLY in work hours which could be used elsewhere. Suddenly, it seems much more cost efficient to upgrade, doesn't it?
Another benefit to optimization is increased usability, better performance and the automation of current manual processes. For example, if you are able to eliminate a manual process that requires 1 FTE per location, an organization that has 25 locations can easily see a cost take out of about $750,000 (assuming a payroll cost of $30k per person). What could your company do with an extra $750,000?
Is it time to build a business case to upgrade to 6.1? Do you know all the variables to include in making a case for ROI?
Coming in June of 2009, Improvizations is launching the Upgrade Studio, a process that your company can use to determine if and when you are ready to upgrade to Kronos 6.1. We will work with you to create a comprehensive upgrade plan so you have ALL the variables in place to plan for your next upgrade. Want to know more?
Yesterday we considered why keeping current is one of the reasons to upgrade. Another reason to consider upgrading to Kronos 6.1 is:
Technical Support
Most software vendors phase out support of older versions and only support the current release and one version back. Anyone still using Windows 3.1? Anyone even have access to it? You see my point.
Imagine you are the Payroll Manager for a company with offices across the United States. Imagine there are thousands of people relying on their paychecks.
And imagine there is a sudden system-wide issue with your workforce management solution.
And - because your company chose not to budget for upgrades and software maintenance fees - you have no access to your vendor. What do you do? Delaying a needed upgrade costs money, time, and frustration in the long run.
Of course, we are in the business of providing technical support to companies using workforce management software system such as Kronos. Nevertheless, whether you use us or another vendor for your support, a current and valid technical support contract is key to ensuring your system is up and running when you need it to be.
Coming in June of 2009, Improvizations is launching the Upgrade Studio, a process that your company can use to determine if and when you are ready to upgrade to Kronos 6.1. We will work with you to create a comprehensive upgrade plan so you have ALL the variables in place to plan for your next upgrade. Want to know more?
Kronos has released a major upgrade. The features look exciting, the new reporting functions are enticing and - ah...the dilemma. To upgrade or not to upgrade? There seems to be an even divide on the reasons whether a company chooses to upgrade or not.
Two weeks ago I got a call from a company with a version of Kronos that was so old (how old was it?) that we could only find one person who had actually worked with this version. It was from 1999. It had never been upgraded.
Clearly then, some companies go with the "if it ain't broke, don't fix it" methodology.
Is this an overall good business strategy?
It can be. If you have a good, solid product like Kronos Workforce Central, just use the bare minimum basic functionality, and don't need to take advantage of the additional functionality that has been added over the years and don't need to change your infrastructure...then this might work for you.
However, this can also result in your HR and Payroll Manager not being able to sleep at night. Tell me, what happens when the system goes ‘clunk in the night'?
There are solid reasons why our clients should upgrade. Although every client is different, there are some universal reasons to consider upgrading your version of Kronos. Each day this week, we'll discuss one reason to consider upgrading.
Keeping Current
When a software company upgrades a product as complex as the Kronos suite of products, you can bet your bottom dollar that they have involved many of their users. They also have access to every technical support call reporting bugs or other deficiencies in the system. A new release will have bug fixes and additional features that may benefit your organization. For example, it might eliminate manual processes, reduce processing times, or improve interfaces and workflow for your users.
Coming in June of 2009, Improvizations is launching the Upgrade Studio, a process that your company can use to determine if and when you are ready to upgrade to Kronos 6.1. We will work with you to create a comprehensive upgrade plan so you have ALL the variables in place to plan for your next upgrade. Want to know more?