5 Things You MUST Do During Your Kronos Implementation

Over the years I've found that the obvious, simple things are missed when starting and then during an enterprise ERP or other software implementation (or upgrade, customization, etc.) It's crazy, I know, these are the things people learn first, and then ignore because they think there is no time or budget for them. They are wrong. But, still, right away I apologize for the following:

1. You probably know this
2. This information can be found in myriad places on the internet, in the classroom and in the corporate PMO
3. It's longer than I like a blog entry to be

I'll come up with the other reasons to apologize for later...
So here's the list. Aargh. I'm getting tired of lists like this. The 10 things to make you rich! The 100 steps to self esteem. The 4000 steps to a successful project implementation... oh, that's us. Well, I'm only using five so this part doesn't have to be an apology.

One: Have a serious project manager.

To me this is obvious; however in most projects I come across the PM is the vendor (not good), the Payroll Clerk (worse) or an IT analyst (yikes!) None of these perfectly nice folk know squat about Implementation Project Management. Grab someone who's at least got a standard methodology that's proven in previous projects and is focused on keeping things simple. One I like right now is JPACE, and it's simple. Justify, Plan, Activate, Control, and End. (Don't ya LOVE a project that ends!) The PM drives the project though these steps. She or he (‘he' from here on out to mean either) motivates management, the core implementation team and the users towards the project outcome. He is not just a PMP. He is a team leader, a bodyguard (Risk Management) and most importantly a communicator (OK, sometimes a cheerleader.) He is one that is able to clearly speak with the steering committee in their language of ROI, Statistics and Business Impact, the IT geeks in SQL (or whatever) and the functional users as the real folk the project will most affect.

He does NOT need to have managed the exact project as you are dealing with. Who cares if he's done a 5.1 - 5.2 Kronos Workforce Timekeeper Central upgrade for a Retail organization on SQL Server 2005 before? If he's a great PM, and you have a good solid team, it doesn't matter. To quote Chris Freeman, a Sr. PM for Farmers Insurance from a LinkedIn post,

"... companies consistently look for and hire Technical Leads to be project manager. We all see ads looking for skills in a particular industry, but I always remind my clients, look for a good PM, and they'll learn the lingo and the buzz words of the industry as they go along."

Have the PM help build the team of people who know how to execute. Yes, they actually have to do stuff. Not just fill in project plans and come up with clever TLA's (Three Letter Acronyms) and produce pretty charts with lots of color. People who know Connect, SQL, and who know how to spell HR are crucial. Without them, your project will fail (although you'll look good doing it). Get people who know how to deliver, tell them clearly what you want, and let them do their thing.

Two: Have support and cheerleaders all over the organization
The next most common mistake is implementing Kronos in a silo. Improvizations often does implementation audits after a failed or subpar implementation and almost every single one shows a lack of participation in the process by those whom the software will affect most.

This software is one of those few that are used in some manner by every person in the enterprise. Build a cone of teams, not a cone of silence! We work to build three teams during an implementation which I'll outline briefly in case it's not obvious.

• The Core team at a minimum = PM, the Project Sponsor, the IT implementation team, consultants, HR person, PR person, Operations representative, Finance representative
• The Requirements team expands this group out to a slightly deeper version of the same. Management in each of the core team areas should be added in (unless part of the core team, then add a clerk or analyst) Also bring in someone from Facilities, Security and some Supervisors from each of the departments and locations. Think of this group as part of the Analysis, Design Review and Alpha Test team
• The Extended team builds upon the requirements team to include simply more people. We want to have the test plans run by a greater number of employees after other teams have tested. Consider them Beta Testers. Every step of the way the PM requires complete buy-in from the appropriate te
  am to continue.

Note that there is a certain amount of pressure, or weight, that each team feels from the larger group above. If they really care about the project they won't WANT to release anything to the next team until it's right. That's a good thing. Of course the PM will continue to drive them forward to do just that though!

Three: Document everything clearly and implement change control early
It's 2009! Use the tools available to us. Start the project right with a SharePoint or other collaboration and document management site. Be sure the system handles change control for the documentation. If changes are made to the configuration after the document has been approved, then update the docs to match. This seems like a lot of work but I PROMISE it will save you overall time and $. Nuff said.

Four: Test, Make it easy for people to test, test the test, validate the test before it goes out to the testers, then test some more
Then run it though a UAT, QA and any other acronyms you have access to
A significant portion of your budget should be in testing. AAMOF, I think it's analysis and testing that are most important to the project. Configuration, coding and the likes are driven by and then proven by those two items. Not that I think the code jockeys are unimportant. Just the opposite. But they are framed by the two tasks that I deem vital. And Yes, I've been all three of those so I can say that!

Like each part of the System Development Methodology, including for this example; analysis, design and config/code, testing must be targeted at multiple levels. Think the cone again! After the config is completed the core team runs through the test plan and the test scripts. Only after they approve does it go out to the Requirements team. Then the test/break/fix cycle happens again. Once the Requirements Team approves it can move out to the Extended Team.

Five: Implement the software generically
Even if the ROI is dependent on the fancy smangdangle "Special Supervisor Holiday Request Self Service with Java code doing wild things in the background," don't do it. EVERY TIME I come across a project doing just this, it's a failing project. It's simply too much to ask. Put it in the project plan along with everything else. (I do mean everything should be in that plan. All the modules of the software even though you are only implementing one at a time, those 300 other locations; no you are only rolling out one to begin with, everything should be in that plan reviewed and approved by at least the Requirements Team (and the Steering Committee if you've left them out of your teams [g].))

Well that's it. I promise it'll be shorter next time. Hey. If you like this. It's what we do ya know. Implementing, configuring, and developing for Kronos Workforce Central products. All of ‘em including Timekeeper, HR, Payroll, Scheduling, Attendance, Accruals and Leave. Call me at 970-396-7529. If you didn't like this, well, that's ok too. Consulting firms make a lot of money when these simple suggestions aren't followed

Are you preparing for an implementation or upgrade?

Learn the secrets from an IT Director and CIO about the most important things to not miss when upgrading or implementing Kronos.