Medical project estimation – what is worth remembering?
Hey! Today I would like to share with you a few, I think most critical experiences in the field of IT for the healthcare industry: medical project estimation. As you probably know from your own experience, a good estimation consists of a lot of factors, which is the reason why making it very often turns out to be too difficult, and the final result is far from the initial assumptions or expectations. That is why it is worth being systematic and remembering about the proper sequence of actions and helping yourself with a few proven tools, to reflect the reality that awaits our client and us if we undertake cooperation on the project.
What is the right order, then? My proposal is as follows:
- Understand the client’s problem,
- WBS (Work Breakdown Structure)/Backlog,
- Complete and understand the team and use the tools,
- Do not forget about the project-related costs.
- Check 3 times ????
1. Understand the customer problem
One of the most important points in the software medicalproject estimation, not only because it is very helpful at a later stage of the project, is of course the precise understanding of what we are really going to deal with. What is the essence of the problem to which the software is to respond? Working on the problem, about which we know where it came from, why and how it should work and how to make life easier for end users allows for better design of the solution and the fact that our project estimation will be closer to reality. It will also enable us to present ourselves in the eyes of a potential customer in the role of specialists who really care about his business and who maintain a systematized and a professional approach.
2. Medical project estimation and Work Breakdown Structure
Also known in Agile environments as the Project Backlog. It must be said that to a large extent the accuracy of your valuation depends on it. The more detailed, the better.
It is a known fact that the appearance of WBS and its content may change in the course of later work due to various external factors, but the lack of WBS in the valuation or its superficiality will surely be reflected in hiccups at some of the stages of the project, or it may not set off at all.
How to create a good WBS? The main key is to properly fulfill the first point from our list, i.e. to understand the problem. Only then can we feel confident that the list of tasks ahead of us coincides to a large extent with the objectives. It is a good practice to organize workshops with the client, which will be conducted by your business analyst and during the workshops list all the project requirements and translate them into a language understood by the team that will implement the project later on.
3. Assemble and understand the team
We know and understand the problem, we know what there is to do. But we do not yet know how and how much it will cost. In order to do this, we need to find a representative group of specialists to help us assess it. How do we get such a team together? It is often not easy. The team should consist of people who have all the competences to assess each individual task in a reliable way, so that the overall assessment never depends on the assessment of one person only, otherwise we risk mistakes.
How to estimate?
Personally, I prefer estimations in Story Points (the values increase based on the Fibonacci sequence 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 – read more about story points here!). This allows you to take your mind off time for a moment and focus on the three most important aspects of each task:
- the amount of work to be done in a task- the level of complexity,
- the risks and uncertainties associated with the task.
It is good to take on a task at the beginning, assess it in Story Points and then treat it as a reference for other assessments, what is important in assessments are the proportions between them, not the values themselves!
Tools
A good tool for estimating with the team is Planning Poker, which allows us to easily avoid influencing team members by expressing our opinion on a task before it is assessed, which could disrupt the assessment.
So far so good, now we have the Story Points, but what does that really mean? Nothing yet, so we need the so-called team speed, i.e. how many Story Points a team is able to deliver during a sprint (e.g. 2 weeks). Once we know this value, we will be able to convert it to the amount of time needed for completing the project and, consequently, to price it for the client.
A tool thanks to which we will get the result closest to reality, which gives us and the client a better understanding of what can happen in a project is PERT. To make this possible, the team should give 3 estimation proposals each time:
- Optimistic,
- Realistic,
- Pessimistic.
In this way, we obtain a project estimation according to the formula:
We can also present these values to the client, but we have to pay special attention to the fact that the optimistic variant is very unlikely, because the project is a cluster (WBS) of different tasks, and each of them can hold their own secrets, such as a hidden dependency, which will necessitate a thorough reconstruction of other functionality and extend the implementation time by a few days.
What else is worth remembering? It is important to understand why the team assessed a given WBS point in a certain way. Such knowledge is valuable when negotiating with the client.
4. Do not forget about the costs of the project
Apart from everyday work with the project, there are many other dependencies, whose costs and time of implementation must be remembered when we rub off the project schedule and its valuation. Remember that things such as hardware, software, additional services cost money, and their acquisition / use is directly related to the waiting time, which will certainly affect the schedule of activities in the project and burden its budget!
5. Check 3 times
Really, it’s worth it. Check, make sure that you have not missed anything, that you have not forgotten any dependencies, that every question has been asked and not left unanswered, simply that you have left no stone unturned, this will save you a lot of potential worries.
And voilà. Project estimation is ready to go. You can boldly make an offer to the customer. If you keep these few details in mind, it will surely give you a good chance to assess what is to be done. Good luck!
Contact us if you have any questions!
Are you interested in medical IT software projects? Read our post Medical software development difficult beginnings. How to cooperate?