With an enterprise product as flexible as TimeControl, how to deploy the system is as important as the functionality it contains. HMS has been deploying enterprise project management and timesheet systems for over 40 years and TimeControl itself for over 30, so we bring some experience to the process.
There is no need to have HMS help with a TimeControl deployment. The system will be fully functional on the first day the client gets access whether that is for TimeControl Online or TimeControl on-premise but leveraging our experience can make the implementation go quite a bit faster and avoid the risks of forgetting an important step.
If we are commissioned to assist, one of the first things we’ll do is set up one or more design sessions. The number of sessions and the length of those sessions is completely dependent on the client. We usually start with the list of requirements that were given to us during the sales process. That starts the groundwork of what TimeControl will have to deliver. Our design sessions start with a product overview given by one of our experienced deployment personnel. They will go over the major points of functionality then delve deeper into the requirements themselves. This keeps the focus on what the client is trying to solve but also ensures that we don’t miss talking about what other functionality in TimeControl might be useful either in the first phase of deployment or later.
We use our QuikStart program to condition the conversations. There is a brochure for the QuikStart and slides to help during design sessions, but that is really guidance, not a single formula.
We have lots of questions for the client and usually this means after a first session, the client will need a break of a few hours or a few days to do homework. Some questions might seem obvious but then need thought and discussion before the system can be configured. “How long should a timesheet be?” is a common one. “Is that for everyone or will some people have different lengths of timesheets?” “Who will approve timesheets?” “Will you track costs and if so is that just for one requirement or multiple?” “Are there auditability requirements for the DCAA or Research Tax Credits?” “What about line-item approvals?” “What reports does the system need to produce and do you have examples already?” “Will you be tracking start/stop times?” “Will you be tracking expenses?” “What external systems will TimeControl be linked to?” “Are the people representing those systems here on the design call?” “Who will be the TimeControl Administrator(s)?”
And so on…
When the answers are all in, we have to work backwards from outputs to inputs just like you learned in Systems Analysis 101. If, for example, a report will be needed by location, then we have to make sure the location of work is represented in the user defined fields per task. If there is a need to do a report of costs spent by department, then we know that employees will have to have a department field defined and a list of departments to choose from. We’ll also need to have rates set for costing at either internal cost, external billing rates or both.
When the exercise is complete, we assemble a design document and the client gets a chance for a final read-through before signing off.
Then it’s time for the client to go find some data. Given the different requests, we assemble a template spreadsheet for Projects, Charge Codes, Rates, Users, and Employees as well as approval paths. The spreadsheets will have in them the fields that were defined as needed for the different requirements of the system.
Once received, HMS pumps that data into the client’s TimeControl and turns it over for testing to the client prior to going live. Sometimes there are changes. It’s possible that something looks different when the client sees it live from how they imagined it in the design meetings. Those changes are usually very quick to make.
Then it’s a wrap. Usually the client will roll out to a select group of users first and if they already have a timesheet system have that group work with both systems in parallel before making the “go live” decision for all users.
The length of time for the entire process varies greatly depending on the number of users, the number of external systems which will be integrated with TimeControl but most of all by the level of clarity by the client of what they need TimeControl to do. It can last 2-3 days or several months. It wouldn’t be surprising for a client with several thousand licenses to engage HMS for 3-4 weeks of work to be delivered for a 12-16 week period.
There can be further phases once the deployment is complete but usually for the existing functionality, there’s nothing more to configure for the foreseeable future. We keep track of the documentation we create for the system and the client is responsible for creating their own process documentation and maintaining it internally.
If you would like more details on how TimeControl is deployed, you can go to https://www.timecontrol.com/resources/services/consulting or contact HMS at https://www.timecontrol.com/contact.
It’s Activity Based Costing week here at HMS and we’ve got a bunch to talk about.
You must be logged in to post a comment.