Last week we discussed the inherent complexity in a Kronos implementation: part one of our three-part series about simplifying a complex enterprise Kronos implementation or project. We reviewed how to properly assess your project team’s mix of resources and skills by performing a current state analysis and how to create a resource inventory using that information. In part two of our Kronos Implementation series, we will discuss the next step of the simplification process: starting with the end in mind.
When planning for your Kronos implementation project, the likelihood of a successful Kronos project management increases when you start with the end in mind. What does this mean? Starting with the end in mind is centered on the process of defining your organization's Target State. The Target State is a model that illustrates the end goal of the IT project, and is composed of your overall business goals, expected ROI, level of user adoption, optimized business and process flows. The following are a few questions to consider when defining your target state definition and model:
What are the current state dependencies and how will these change in the target state? Example: a target state model may illustrate a reduction in manual processes and/or a consolidation of several interfaces into a single, more robust feed.
Which systems or processes will retire or be eliminated as part of the transition to a target state? This is an important communication element to consider, especially if departments/owners will change during the transition.
Based on the target state model, what support model changes need to be planned for? For instance, if your project is moving away from a de-centralized model to a centralized model – what will the support model look like? Will the legacy system business owners support roles change? Will there be savings realized as a result of consolidation of support processes?
These are all ROI-impacting details that can be gleaned during the target state definition process.After you identify your desired Target State, compare it to your Current State, or what exists now. Comparing these two models will likely uncover gaps in your organization, further clarifying your project requirements. How you will close these gaps represent your Transition State: what operations will look like during the project.
Current State: What exists in your organization currently.
Transition State: The state of your organization during the project.
Target State: The end goal of the project.
Many project planning efforts include the creation of a Transition State Model, which illustrates what the landscape will look like during the project. For example, a Transition State model may include the use of a temporary system or process that does not exist in the Current state, and will retire by the time the Target state is realized, but still requires support in the interim.
The benefit of using a Current, Transition, and Target State modeling approach is that both the exercise and the actual diagram(s) will capture the system and process landscape at the time the project begins (Current State), what the landscape will experience mid-project (Transition State), and ultimately the end-destination layout at the closure of the project (Target State).
After you complete your state comparison and analysis, you must begin to consider the Post-Project Support Model. Tune in next week for part three of the complexity series, highlighting how to create a successful Post Project Support model, initiate change management, and to download the complete Kronos Implementation: Planning for Complexity Overview.
Subscribe to our blog to be notified when part three comes out next week!