Computerization in the clinical area is a path that many health institutions are undertaking worldwide. This path is not easy, it is full of obstacles, problems, misunderstandings, unfulfilled expectations and failed projects.
In this hostile context, will there be any methodology or process that brings us closer to success or keeps us from failure? The objective of this article is to give an opinion on some “sensitive areas” that project managers should take care of so that “the boat does not make water”.
Some of these points may more or less coincide with the methods and strategies used by project managers, and should be considered as the humble opinion of someone who observes and analyzes reality (closely), not as a solution to all problems. I also try to emphasize the “what”, not the “how”, but the discussion is open.
The project should be just a grain of sand
The computerization project must be located in an organizational improvement strategy, the project should not be the strategy, but a result of it. Having this point clear makes it easier for the support of the institution’s decision makers to become visible, and places the project at a place on the institutional agenda. Otherwise, support becomes elusive, and there is no door to go to knock when there are problems at the institution level.
Computerization is a one-way road
Along with the planning of the different stages of development and implementation of computer solutions in the clinical area, the strategy to eliminate the role of clinical processes should be planned. Leaving the paper “alive” is an attempt against the use of the project’s products.
Avoid project of infinite duration
Every project manager knows that a characteristic element of these is that they have an end date. That end date should be fixed and immovable, and it should be clear what is to be delivered and what is not. Three factors must always be taken into account: the scope (quantity and complexity of needs to be satisfied), the quality (number of improvement cycles over a satisfied need) and the time (delay in satisfying a need or improving the way in which it is met). that this is satisfied).
It is said that we have 3 bullets and we can only shoot 2, for example a project with a very long range and with great quality, will take a long time to develop. Another possible combination is that if we have little time and a fixed range, we cannot ask for much quality. The general rule is that if we increase scope, quality or time, the cost / budget increases.
There are always aspects that can be improved, and there will always be time to improve them, but on the delivery of the products we cannot start improvement processes. It is much better for the project, for the supplier and for the client: 1. deliver what was agreed, no more and no less; 2. accept what must be delivered; 3. close the project; 4. Sit down and think about improvements (… and see if there is any budget left).
Expectations and communication are also elements to manage
After setting the scope of the project, customers and end users should know what is to be delivered and when. This includes knowing what is NOT going to be delivered. Communication of these elements should be done at every opportunity, and if these opportunities do not occur, they must be created. On the other hand, all end users (especially doctors) have an idea of what they want, and everyone imagines that the product will be exactly as they imagine it. To avoid disappointing these users (risk of product rejection), a clear image of the product must be given, of what it will and will not have, and lower or raise expectations to the correct level. This should also be done on every opportunity.
Counterpart is more than eleven letters
Without a counterpart there is no project. If we are a software provider, the counterpart is made up of decision makers, end users and the client’s IT staff. The client must be clearly communicated that for the project to be a success, it takes time for the institution’s human resources: doctors, nurses, technicians, computer scientists, etc. One way for the client to become aware of this need is for them to clearly know what the process of development and implementation of the project’s products will be, and that in each of these stages the participation of certain key roles will be required, which need time assigned to those tasks, and that they should stop doing other tasks that are assigned to them today. This point is so obvious that managers often overlook it, and as a consequence time is wasted by not having someone on the other side to ask questions or to discuss possible solutions to the problems that the client himself poses.
Maintaining audiences and interest is a big plus
In health computerization projects, there are two large audiences: decision makers and end users. It is frequent that due to the low visibility of the project and its progress, due to the lack of communication, or sometimes due to the long duration of these projects, the audiences that previously supported us, contributed and were interested in the project, are no longer so interested. Losing the interest of the audiences is losing support and gaining resistance, which is a great point against the project. Interest is another point to manage and take care of, because it must be recovered before it is too late, for example: the product is delivered and nobody uses it. Managers like to know that they have ready products, and users like to give their opinion and see how this affects the product they are going to use. They must participate in all stages of the project!
The medical computing project
Computer science is a way to achieve a goal, it should not be considered as the goal itself. Both decision-makers and end users should not talk about databases or servers, with them and they should always be discussed on a medical level of uses and functionalities that the tool will support. As a general strategy, the project should be presented as a medical project, not a computer project.
The hyper-market paradigm vs. small specialty stores
There are two ways of approaching health informatization projects. The first and most frequent is that of a large centralized tool, with a single database, which provides support to different sectors and different users. Where the requirements and needs of each of these sectors and users is essentially different from that of the others. These types of projects are usually developed over a long period of time, contributing to the loss of interest that I mentioned earlier. This product is the hyper-market.
On the other hand, there is the approach of breaking the “problem” into pieces, the classic “divide and conquer” (which we often forget when managing projects). The idea is to develop small tools, specialized to each sector or type of user, and independently of the other tools, sectors and users. These types of tools are easier to develop, have a narrow target audience, a shorter development time, and therefore a lower risk of project failure. On the other hand, this approach adds a new element: it is necessary to think about standards and interoperability so that these tools can share information to achieve true synergy. These are the small shops where everyone finds exactly what they want and need. This second is my preferred approach, since as managers it allows us to focus on one limited element at a time, and it allows us to do the best in each one, while keeping track of the overall project.
Project success should not be measured in numbers of users or registrations
Many managers, to show the success of their projects, show numerical results such as the number of users, the number of clinical records, the number of electronic prescriptions that were made, etc. Although these values serve to measure levels of use (which must be done frequently), the success of a project should not be measured in these terms, but should be measured in terms of “how the project products helped to achieve organizational objectives (both clinical and management). ” Let us remember that these projects are tools to achieve objectives, and that without organizational strategies and improvement objectives these projects would not exist. Therefore we should ask ourselves questions such as: with these tools, how can we increase the quality of patient care? Or how is the use of limited resources improved?
Taken from: informaticamedica