Introducing a Ketura system into an organization is not simply a technical matter of installing the system and making it available to users. Ketura collates and makes readily available to managers, perhaps for the first time, information that is potentially sensitive. This creates sociological factors that must be considered when planning a Ketura deployment. Examples of sensitive information include who has been working on what and when, which individuals are causing a project or milestone to fall behind schedule, whether users are working their allotted hours, and so on.
If users are not to resent the introduction of a Ketura system, it is therefore essential to consider, and prepare for, the sociological ramifications of such factors on the intended users of the system and the work culture of your organization.
Planning a successful Ketura deployment
The suggestions presented here should help you to think about how users will perceive the introduction of Ketura and thus avoid common pitfalls when deploying Ketura in your organization.
Decide to deploy Ketura for the right reasons.
Ketura can bring immense transparency to your organization’s working practices. It can also help managers and their workers communicate more effectively. Such transparency can highlight problems in an organization’s practices that will need to be resolved. It is therefore essential that managers resolve to work constructively with their employees to solve any problems that Ketura brings to light. A Ketura deployment is unlikely to be successful if it is introduced as a mechanism to monitor employees lest they step out of line.
Trust your users.
Most successful working environments are those where there is a high degree of trust between managers and those being managed. This is a management issue: Ketura cannot create trust where none exists. Ketura works best when managers can trust that employees are providing the system with correct information. Although Ketura makes it easy for managers to review and approve information (such as work journal entries) provided by users, it is best if this only needs to be done to detect genuine mistakes, rather than to uncover deliberate misinformation.
Communicate clearly to users why Ketura is beneficial to them.
You want to introduce Ketura to help users be more productive and to enable managers to meet deadlines and cost constraints. Explain this to your users. Make sure they understand that Ketura can help them to give their best and be more productive, thus making them even more valuable to your organization. They will understand the benefits of knowing exactly what they are supposed to be working on, and how much time has been allowed. They will appreciate being able to give continuous feedback to managers about how they’re getting on and whether schedules are realistic, but only if you explain to them that this is why you are deploying Ketura.
Provide adequate training.
Ketura has been designed to be easy to use. It comes with extensive documentation and help, available when and where it is needed. However, Ketura is also a sophisticated and flexible system. One organization might use it in a significantly different way from another. It is therefore important to provide users with training appropriate for the intended use of Ketura by users in your particular organization. This should be done in advance of Ketura being introduced: it can be very frustrating for users to have to use an application for which they have not been trained. Such frustration can quickly turn to resentment (‘Why are we having to use this system rather than get on with our real work?’), and so must be avoided.
Once initial training has been provided, consider providing an evaluation deployment of Ketura for users to try out and play with. Encourage users to ask questions at this stage and provide supplemental training if necessary.
Prepare managers for realistic schedules.
When used correctly, Ketura is capable of producing realistic schedule estimates. These can be disconcerting for some managers, particularly if an organization is used to more informal (and perhaps optimistic) methods of estimating schedules.
When faced with an unacceptable schedule estimate, the temptation is to revise work effort estimates downwards simply to achieve the desired schedule outcome. Managers should be encouraged to resist this temptation, as such an approach is likely to be self-defeating – the schedule estimate might become more palatable, but is most unlikely to be met. Furthermore, users who are held by managers to unrealistic schedules are likely to become demoralized and disillusioned.
A better approach is to ensure that managers understand that Ketura is most valuable when given the most accurate information available. It is precisely when Ketura tells managers things they don’t like that it becomes most useful. Such knowledge enables managers to take appropriate action and properly deal with the situation in question. Managers need to be aware of the different ways that Ketura can be used to reign-in a slipping schedule or over-running budget. For possible approaches to such problems, see Ketura Tour Step 5: Keeping Projects On-Track.
Walk before you run.
Introduce Ketura step-by-step. For example, consider using Ketura initially just to capture issues. Once this is being done successfully, have users start to log their working time against tasks. Gradually introduce more sophisticated workflows as appropriate for your organization. Communicate clearly with your users throughout: make sure they know exactly what you expect of their use of the system.
Listen to users.
Encourage feedback from your users about Ketura. Listen to their suggestions and comments. Perhaps users feel overly constrained by the workflow you have introduced? You might consider relaxing it. Perhaps Ketura itself has some shortcoming that is causing problems for your users? If so, please report it to Araxis.