Kronos Best Practices - Really?

There has been a lot of chatter this year about so called 'Best Practices.' I must admit that I've been part of this; trying to advocate proven practices rather than the typical complex ones floating around IT. We suggest best practices for Kronos Upgrades, Training, Change Management, Module Config and almost everything else. However, one must not blindly follow any of them! Keep this in mind:

• They are important, but not the final word.
• They are guidelines that change over time.
• They should be proven, to your organization, as successful, not simply written up by someone who you think probably 'knows.'
• They should NOT be followed. Yikes, management doesn't want to hear that. But I mean it. They MUST not be followed. They are meant to be integrated with the knowledge of the PEOPLE in the organization who know how the applied practices will affect the project and the organization. Each working group has their own view, culture and needs that differentiate them from the ‘best practice' currently out there. Apply, don't copy blindly.

Sometimes Best Practices excuse management and the AC's and TC's of really understanding what needs to be done. "But I did what I was told! It's the vendors fault!"

If we just implement the "best practice," we'll perceived as doing the right thing. However, My experience is that you have to create and manage your own proven processes for the work at hand.  This doesn't mean we should ignore them though! They are guidelines which feed and nurture the process which are not simply to be checked off.

Kronos WFC Change Control Best Practices - details

So with those best practice concepts under our belt, let's get into the details of our 5 step process.

Step 1 - Use PRAC to figure out your configuration changes

1. Update your PRAC environment with a current copy of PROD, so you know your manipulating the right configuration.
2. Create and update all the elements you need to get a successful test within PRAC for your desired configuration change or new configuration.
3. Once you have it working, go through and identify every configuration change you made that was critical to the final result.
   

Ignore all of your other practicing!

Step 2 - Put all of your final configuration changes in the DEV

1. Keep careful track of every element that you create, rename or update in your spreadsheet, database or SharePoint. Do not create unnecessary elements.
2. Perform a simple test in DEV to confirm that what you have created works as you expected.
3. Update any other configuration items that you intend to move with SDM (like data access profiles).
4. Make note of any configuration items that you changed which SDM cannot move (like global hyperfinds).

Step 3 - Copy those changes to your TEST

1. First rename every element in TEST that you renamed in DEV.
2. If necessary, delete any elements in TEST that you deleted in DEV.
3. Use SDM to select and copy the individual configuration items from DEV into TEST.  First the pay configuration items, and then anything else.  It is best to copy just one grouping at a time.
4. Make any needed manual updates from your list from step 2.4.

Everything you do here should be carefully documented. Use screen shots. This process needs to be repeatable in PROD later.

Step 4 - Perform your formal testing in TEST
Testing is out of the scope of this series but at a minimum, you must confirm every item that was changed in Step 3.

Step 5 - Copy your changes from DEV to PROD  (This should be exactly what you did in Step 3.)

1. First rename every element in PROD that you renamed in DEV.
2. If necessary, delete any elements in PROD that you deleted in DEV.
3. Use SDM to select and copy the individual configuration items from DEV into PROD.  First the pay configuration items, and then anything else.  It is best to copy just one grouping at a time.
4. Make any manual updates that you needed to make from your list from step 2.4.

And you're done!  Now PROD has exactly the same configuration that DEV has and it is exactly the same configuration that you tested in TEST and all of your practice work and mistakes are safely isolated in PRAC.  Risk has been minimized and you have documentation of what you changed and when it was changed!
Hopefully you'll find a process similar to this that works to improve the limited, native change control abilities in WFC. Let's face it. All we can do is wrap good processes around it.

-------------------------------

As we close out this series I want to again thank all the folk I've spoken with and who've written articles and bits to make this so successful. Change Management has been so popular that next week Jeff Hill and I will start a discussion on ensuring accurate standards are kept in CM. If there is something else you'd like discussed in this blog feel free to comment here or email me directly. Thanks!

Kronos WFC Change Control Best Practices

When it comes to defining a Change Control process one needs a way to get updated or added configuration into the production environment. So let's start by creating a process flow. Using SDM as our primary tool we’ll define the process using three non-production environments--Practice, Development, and Test.

Step 1 - Use the Practice environment (PRAC) to figure out your configuration changes.

Step 2 – Key the final configuration changes into the Development environment (DEV) and validate the interaction with other changes in the works.

Step 3 - Copy those changes to your Testing environment (TEST).

Step 4 - Perform your formal testing in TEST.

Step 5 - Copy your changes from DEV to your production environment (PROD).

Seems simple enough, right? Well, as the saying goes, "the devil is in the details." We suggest using Excel, Access, Sharepoint or an online tool such as DabbleDB to track what and how changes are going to be migrated. This document should include things like the item name, persons responsible (requestor and developer), where it needs to go, how it needs to be moved (SDM often but not always), when it can be moved and anything else appropriate.

Let's talk about some best practice concepts to follow and then flesh out these steps a little more. Of course there are exceptions to every rule, but these guidelines are going to be applicable most, if not all, of the time.

Best Practice #1 - SDM should only be used to copy from DEV to a target environment. There's really no point in copying data from somewhere else. Because in our scenario, DEV contains the master configuration and you don't want to copy something INTO DEV and potentially compromise your configuration. And, since DEV does have the master configuration, you are always going to want it to be the source of what gets distributed out. That way there's no confusion. Let me expand on this.

If we use SDM to copy pieces out of PRAC into DEV, you run a high risk of moving stuff over that didn’t need to be there. Plus the payroll manager may have lost track of all the tweaks that were done to prove out the pay practice during development.

Instead, by requiring the rekeying into DEV, you create a process where only the exact changes/additions that are needed for the pay practice are put into DEV and you’ve left all the unnecessary pieces of practicing where they don’t hurt anything, in PRAC. You also end up with an exact list of things that were touched in DEV that you can move over into TEST for testing and eventually into PROD.

Best Practice #2 - Don't delete configuration elements from DEV. This is a good rule just in general for Kronos configurations. Just because you no longer use a work rule doesn't mean it is a good idea to remove it from your configuration. And actually, you'll have a hard time accomplishing that because Kronos doesn't want to let you remove it if it has ever been used, to protect your historical integrity. Instead, just rename it with some indicator that lets you know the element is no longer in use. Something that starts with "zzz" is convenient, because that ensures the Kronos screens that sort alphabetically will always have those elements at the bottom and out of the way. The exception here is if you have elements that you created but never used.

Best Practice #3 - Be very careful about changing how existing elements work. This is a good idea just in general with the WFC system. The reason is that if you update that combined pay code or break rule, it will interfere with your historical integrity. You could attempt to audit employee data from the previous year and not be able to prove why totals were calculated the way they were, since those same punches calculate different totals today with today's rules. The best solution then becomes to rename the element and create a new element with the same name as the original one so that you keep the old one for the historical integrity. But this becomes especially tricky to handle with SDM. Which leads us to the new Best Practice....

Best Practice #4 - If you ever rename an element in DEV, you must rename that element in your target environment manually before doing any SDM copy. The reason is this: When you rename an element manually in WFC, it updates all of the pay configuration elements that reference that element because it uses the element's internal ID number as the key. But when you copy via SDM, it only copies using the element name as the key. So if you have a pay code named "Evening Differential" and this pay code is referenced in a combined pay code you use for reporting, when you rename the pay code to be "zzz-Evening Differential retired on Jan 1 2009", you would see this new name in the combined pay code as well. But, if you didn't do that and you just renamed the pay code and then created a new one with the same name and copied both of them over to your target environment with SDM, both pay codes would be there. Your target's combined pay code would only reference the new pay code and lose all association with the old pay code. When you consider that this also happens to your pay code distributions and your data access profiles, it can begin to get messy very quickly.

Best Practice #5 - Only implement a strict process for configuration elements that can increase the risk to your production environment. There is such a thing as too much change control! Some of the setup elements that SDM lets you move are really low risk elements as updates to them don't cause employees to be retotalized nor do they affect the integrity of the data or the pay configuration  Examples of this are comments and scheduling shift templates. There are other elements that might be important, depending on how they are used or treated. Examples of elements in this category are FAPs and Genie-related configuration elements. For these elements, it can sometimes be more efficient to not subject them to a strict Change Control process. You need to determine what are the risk items that you are most concerned about causing risk to your production environment. A good rule of thumb is: If a element causes an employee to be retotalized (all accruals and pay policy elements), then it should be included. Otherwise, it is up for discussion.

Next we'll expand on the five step process to managing change in Kronos Workforce Central using SDM.

--------------------------------

 Thanks again to Chris Flanders and others for contributing to this series

A Few Good Testers

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.

Understanding Kronos Environments

Change IS inevitable! So let’s be prepared.

Environment Management reflects the Change Management doctrine and the implementation of it typically looks something like this picture. Of course smaller companies might just have TEST and PROD, but that’s a minimum.

Everyone experiences the need for change in their Production system. Whether that change is tweaking pay rule configuration or adding pay codes or even implementing service packs, if you have a WFC system, there will be a need for change on a periodic basis. Because of those change requirements, there are things you can do and a structure you can create to give yourself confidence that the changes will not cause bad things to happen in to your production systems. Kronos provides Record Manager and the tool Setup Data Manager (SDM) to help you administer your environments, but to make the best use of those tools, you must have the right environments in place.

In order to provide a decent explanation here, we will follow a process through each of the environments described above to see what their role is and why it is critical. In a later article we might present an alternative setup just for fun.

Let's start with a common scenario: The HR department has just dreamed up a new pay practice and they want you to implement it in your Production Kronos environment.

SANDBOX Environment(s)

A common best practice on agile teams is to ensure that developers have their own "sandboxes" to work in.  A sandbox is basically a technical environment whose scope is well defined and respected.  The primary advantage of sandboxes is that they help to reduce the risk of technical errors adversely affecting a larger group of people than is absolutely necessary at the time.

So, the purpose of the Sandbox is to provide a Kronos playground to "practice" configuration and development. The Sandbox database is a copy of Production and often times it’s stripped of sensitive data. There isn’t a need for tight controls around what is being created or changed in this environment -- that is not the purpose. Use it to figure out what needs to be done at the individual or small team level. Some companies employ multiple Sandboxes for different teams and those get merged into DEV for integration testing.

For our scenario, when HR communicates that they want a new pay practice implemented, the developer would work here to figure how to configure everything that it will take to implement the new policy. And since it is just a playground, you can try different things, different approaches to make it work, until you are satisfied that you know exactly how you want to go about implementing the new pay practice. If you break it and can’t fix it, just refresh the database.

DEVELOPMENT Environment

Sometimes called ‘Project Integration’, the purpose of the Development environment is different depending on if you have Sandboxes. Without them, all development is done there and promoted to TEST for all testing and training. If you have a Sandbox, DEV is primarily used to integrate development from the other sources and make sure those changes don’t affect other parts of the system. Some might perform all simple changes directly to DEV and create Sandboxes for bigger or more intrusive projects.

Doing the integration testing here is great. We can’t really trust the sandbox to reflect the Production system after all those kids have messed up the Sandbox. So refresh DEV and promote your finished changes from the Sandbox to validate your work.

TEST Environment

This final non Production environment is where one performs formal testing and it’s often controlled by a separate TEST/QA group. I’ve seen this one called Pre-PROD, TEST and STAGE. Its purpose is to provide an environment that simulates PROD as closely as possible.

Understanding how it fits in with the other environments is what’s important here. In SAND, you have played with the configuration until you got it working the way you wanted. Then, you put that configuration in DEV and confirmed that it works the way you expected. TEST is used for two primary purposes. Testing that you can successfully migrate the changes, run though the full test scenarios required by your Change Control Process, and if these are the only environments you have it’ll be used for QA & UAT.

The final scenario step, of course, is to use SDM and move your configuration from DEV or TEST depending on your Change Control process, into PROD. Since you are just moving the configuration and not recreating it, you can control the timing of the move such that it has the least amount of impact on PROD and its users.

So could you have gotten your new pay practice into Production without each of these environments? Of course you could have. But not without more risk
-----------------
Thanks to Chris Flanders and many others for contributing to this and other articles in the series.

What is Change Management - Part Deux

For this series we're using the ambiguous term Change Management (CM) as a hybrid of all three descriptors mentioned last article. It's a way to manage change in an organization related to Kronos Workforce Central software development, configuration and upgrades. For our purposes this includes both the cultural/functional (actually CM) and technical changes (actually CC) the improvements will bring.

Are the users going to know how to use the new stuff? How about changing and improving processes and procedures because of the change? These types of issues are often ignored, especially at the Kronos Service Pack level changes. So many new features are not even looked at. Many fixes that could dramatically change and improve the processes & procedures currently used by the organization aren't implemented. And don't forget the workarounds! The technical side is easier (yea right/no really!) and is going to come in more detail later in the series.

CM should be a strong, as automated as possible, well documented and understood approval process for moving though environments. There should be an integrated tool for administration and handling of change request and change documents. This is something that Improvizations is working hard on the R&D right now for the Kronos Upgrade Studio.

So, to begin the high level part of the discussion... The difficulties and dangers are real...without good Change Management practices:

• Connections between business issues we are trying to solve or improve and their associated technical changes are easily lost.
• System problems always come at the worst time and are an ever-present risk.
• Stuff that worked in Development doesn't work in Test or worse, Production
• "Communication problems" are often blamed for mistakes and system instability. 
• Budgets are often (usually) overrun.

Some sources of Change are:

Technical

1. Configuration
2. Enhancements
3. Bug fixes
4. Service Packs
5. Version Upgrades
6. Development Projects

Functional

1. Senior Management
2. Operations Management
3. Project Managers and Team leaders
4. Functional Experts
5. Configurers
6. Developers
7. Quality Assurance
8. Training
9. Help Desk

There are ways to handle the technical issues with a reasonable effort and the use of Record Manager and Setup Data Manager. We still need a procedure around the process.

• Changes are grouped according to projects, areas of use and common technical objects involvement, so that the transport is unlikely to cause conflicts with the system environment. The projects have more autonomy concerning transport.
• Transport and routine tasks are automatically executed in the correct order, including comprehensive measures to ensure consistency.
• Potential errors caused by changes that are transported faster than others or by unintentional overwriting are recognized in time and remedied proactively. Entries into the Change Control documentation are made automatically and users of dependant objects for a change are being alerted.
• Change processes are strictly followed.
• All changes are executed in a secure way; rollback functions can be made available and changes run repeatedly.
• There is a complete audit trail for all changes.

The functional part is all manual unless you can tie into one of those big expensive SAP systems or plan to get involved with the Upgrade Studio! The technical part is handled well enough by the tools mentioned above, Record Manager and Setup Data Manager. The next part will discuss the Environment Management setup one should have and we'll then follow with details on the How to Manage them.
-----------------

Again... Thanks to Chris Flanders and many others for contributing to this and other articles in the series.

What is Change Management for Kronos?

Change is constant. Right, we all know that. So what's the big deal? Firstly let's get some definitions down for this series as these topics cross one another all over the place.

Change Management (CM) is the process of developing a planned approach to change in an organization. It's somewhat of a holistic approach in that CM looks at everything. Cultural, financial, and technical affects of change; not just for the project but how it fits into the organization. Typically the objective is to maximize the collective benefits for all people involved in the change and minimize the risk of failure of implementing the change. In many circles the term change management deals primarily with the human aspect of change, and is therefore related to pure and industrial psychology in those cases. This is a BIG deal, and in our opinion is usually ignored, or sometimes worse OVER DONE and not really done at all.

Change Control (CC) is the phrase typically used in IT to manage technical changes developed and installed into the applications. It includes tracking Requests for Change and the implementation of those requests safely and efficiently from Development to Production.

Environments & Instances. To create the structure in which one can implement a good Change Control process one creates multiple WFC "environments". An "environment" is defined as, at a minimum, a database, application server instance, and a BGP. There can be more to an environment -- a DCM, multiple application servers, load balancers, etc. This is different that a WFC "instance". One can create multiple application server instances on a single Windows server and these instances can point to either the same database or different databases. The primary difference between an environment and an instance is that while an instance must share a physical server with other instances, an environment can be on a separate physical server. This may seem like splitting hairs, but it will be important to understand later as each environment need is explained.

Besides your Production environment, the best practice structure for Change Control means having other non-Production environments. These environments can be referred to as Sandbox environment(s) (SAND), a Development environment (DEV), and a Testing environment (TEST). What you label each of these environments is really inconsequential, but we will use these terms prupose, and why each of them has a critical role in the Change Control function later. Please note that we're using these three as examples. Depending on your organization, Change Control processes and complexity you might have two or ten instances.

Coming soon! A blog entry or two detailing best practices for managing Kronos WFC environments.

Change Matters

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.

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!

Kronos WFC Change Management - A Start

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.

Talent vs Cost OR... Is my Kronos Timekeeper Consultant too cheap?

The Practice of Managing Human Capital through the Right Solution

Most consultants begin their Workforce Management (WFM) career in house with a major software vendor. Often the sales order "thrown over the wall" to the service side to begin the client engagement. This sales order might and might not fit the clients actual requirements, but it's all we're given and what we have to work with. In this environment, we are stuck in a one dimensional view of what needs to happen next. License seats were sold, and it is our job to figure out how to implement the software according to the promises made.
The difference in my opinion is simple and clear.

1. The WFM "Application Consultant" or AC is focused on gathering information related to the automated calculation of gross pay, better transparency to front line managers and payroll and reporting surrounding these areas.

2. A "Business Analyst" or BA focuses on the business processes areas within an organization. From the Standard implementation model, enterprise wide considerations are implemented shown in the Expanded Discovery model.

The result is the client's business intelligences needs are uncovered and they actually meet the enterprise wide business requirements. Now they can take full advantage of WFM data. This creates a deeper level of transparency in the organization as a whole. It also results in having strong decision making data needed to navigate the financial health of an organization. Typically this level of consulting provides tangible tools to the finance department where most of the critical evaluation of the company's health is being monitored.

3 Best Practices

ONE: Engage the Right BA early in the discussion (Pick the right guy)

We often find that the BA, in-house or contracted, arrives on the scene way too late. Many promises and decisions have been made that have little basis in reality or actual company practices, abilities, budget or data. Bring in this person when you are beginning to think about purchasing new software. (This might be a good time to review Bryan's 5 Things blog entry. Build those teams and build them early!)

As an independent consultant I have heard the conversations from WFM vendors jockeying to figure out how to justify an additional module or higher number of license seats base on the preliminary information discussed during the sales cycle. We LOVE the vendors, but it's all about the licenses right? This is not intentional deception because that is the sales rep's job and he does it well! The issue is that the rep only sells one vendors products so the environment that enables a full discovery effort is cut short and therefore the integration matrix is not fully recognized. Many times vendors use a partner model to solve this issue. Integration and transparency through a complete fit/gap and process improvement analysis should be paramount to any discovery effort early on in the WFM implementation planning phase.

TWO: Can the budget drive the process when it's just been made up? (Not the cheapest one)

The next most common problem with engaging the correct person for the task is that the Vendors salesman might have great models to use to help the client determine his budget for the project. What those models don't know is well, anything about the company other than how many employees it has.

So we budget for junior level consultants to be deployed into complex engagements without understanding the risks they are introducing into the project. You can only know so much when you sign that sales order.

I can remember my early years in the WFM practice and being deployed to an engagement with very junior level skills. In fact I spent a large part of my time on the phone with senior level staff while they guided me through how to program certain aspect of the WFM software. The bottom line was that I had a set amount of service hours purchased to accomplish my task. This is fine and satisfies the vendor and client's initiative to automate payroll and have better control put in the hand of front end managers over their staff. OR IS THIS FINE?

THREE: Expand your horizons. (Don't depend on one person, one dept, on business unit for all decision making data)

It was not until I took the leap into independent consulting that I learned I was missing a critical piece. And truthfully, this piece starts long before the sales order is signed. Companies operate in a vacuum. Sometime as shallow as a single business unit. The "New Consultant" is not equipped with the experience or knowledge to dig deeper. Even when the Application Consultant does possess the skills to accomplish this, the world they live in often doesn't offer them the environment to get creative in the early stages of the project. If you remove the one dimensional view during this process and engage the client at a level that is focused on the company's business processes throughout the entire enterprise, the magic starts to happen. You can develop a Future State that is meaningful with actionable tools that maximize their investment in a WFM solution.

The BA often works for a consulting group and is therefore positioned in a non-biased open approach when engaging clients and clients are recognizing this. This is key! Consulting to a client at deeper levels brings real value into the project and results in huge value added components added to solutions that offer actionable tools to the company and allows them to better manage the bottom line. This is what clients are expecting when they purchase solutions and services but often they don't realize critical gaps exist and opportunities where missed or undiscovered until after the implementation is complete. Missed opportunities and remaining gaps are why clients are retooling with new solutions often in an attempt to get at the BI they need to better manage the company. The Business Analyst's job should be to discover, design, build and deploy a solution that has real value.

What Your Next Project Should Look Like

WFM consulting practices and WFM software vendors work very well together and have been successfully implementing WFM solutions for years with solid results. Clients considering their next implementation just need to slow the process down a bit and evaluate what it being proposed, the team that will be required to implement as well as long term goals that should be clearly defined. The model that I see working out there working is a combination of things.

• Chart your course: Clients START with a solid business case study working with a consulting practice. Company's having success start with consulting firms who deploy a good BA long before software is discussed. The BA and client work together to look at Current State of the entire enterprise by developing a detailed outline of the processes and BI. They discuss and decide on potential solutions, determine the budget required and look and what can be done this year, next year etc. This does two things:

1. Educates them completely on where the TRUE needs and business requirements are throughout the organization and give them a road map through for a 1 to 5 year plan on where their BI needs to go. It sets the BI goals. It eliminates future vacuum decisions that impact the total BI goals.
2. Now that they posses a full understanding of their requirements, a solid business case now allows them to entertain the software vendors being considered and better equips them during the sales cycle discussions.

• The "A" Team: Resources in a Best Practice environment are made up of a multi-vendor matrix of the Consulting Firm, Software vendors and often third parties. This is critical to ensuring that the right set of skills are deployed throughout the lifecycle of the project.
• The Lighthouse: The resources assigned to the project should begin with a solid Project Manager. Now that you have your goals, business case and requirements in place a non-biased PM can ensure that the project adheres to them. The PM will have your interested on the radar throughout the implementation. This is critical because it is all about supporting the client's goals and keeping them at the forefront of implementation when building the team of resources involved and managing the project management matrix as well as maintaining the project charter initiatives.

• You Get What You Pay For: Resources around a project should be considered carefully!! I cannot stress this enough. Know what you are getting because "YOU GET WHAT YOU PAY FOR". Successful implementations that are staffed with the "Cheapest" consultant on the market have a significant negative impact to any project. I could go on and on about this. Perhaps I'll write another blog entry.

With over 10 years in the WFM business, I can say with confidence that companies are not making bad decisions when considering solutions but rather uninformed. Companies have access to highly qualified consultants in the WFM field that are ready and willing and more importantly "Qualified" to help. You will find that they have a deep passion for improved process, quality and follow key best practices in our field that is the Management of Human Capital. They truly have a staked interest in helping company's truly realize their full potential in BI and to maximize the budgets our clients set for these projects. As well, the creative non-biased freedom they have to bring in WFM technology and marry it to an organizations business processes and systems is their driving force.

----------------------

Guest author Dean Mercier has been consulting as Project Manager for the past ten years on Workforce management business application suites such as Kronos, ADP and Ceridian. His focus is health care integration and HRIS/Payroll.