It's no secret that competent project estimation can make your project hit a home run, especially in the embedded industry. A project manager will facilitate project development by making realistic prognostications about the size of the team, expected timeframes, and tools a client's project requires. A client may have specific numbers in mind, but it’s a project manager’s job to precisely determine the hours anticipated for a project, as well as what tasks need to be performed before, during, and after development; examples of this are with the code audit phase, during an additional round of QA testing, or with using radio analysis hardware.
A PM also negotiates with a client on what requirements and acceptance criteria should be met, which will help the engineers develop product features effectively and within a reasonable timeframe. A PM's contribution cannot be underestimated since both clients and developers need a practical person who can ensure buffers from risks and down-to-earth predictions.
This is even more important if you wonder how to estimate embedded software projects, which are harder to assess due to the complexity of embedded development itself. Engineers need to research which components are compatible with each other, but there’s still so much more a PM needs to research: How long will it take to ship them to the lab and return the finished device to the client? Maybe there are government restrictions on specific components the client wants to use, or the manufacturer made the components differently from what engineers expected? All these questions are a PM’s responsibility to foresee using specific project estimation techniques and communicate to the client.
Before we get to specific tips, Nazar Kohut, LS Project Manager and Business Analyst, will take you through important terms PMs use to sort out project estimation.
Timeline project estimation techniques: duration vs. effort estimation
Here, I will reveal how to estimate embedded software development projects by applying development effort estimation, total effort estimation, and duration estimation methods.
Development effort estimation is used for forecasting the amount of effort needed to make actual code changes and consider the tasks done. During development effort estimations, a PM and engineers discuss all the tasks, including how much of a contribution they’ll require (like smoke testing and bug fixing in development time for each project stage).
Total effort estimation is a collaboration between firmware engineers, QA testers, and a PM while they analyze the amount of communication, types of required testing, time for identifying acceptance criteria, writing test cases, and alpha, beta, and release candidates (possibly load, edge, and security testing). On top of that, they must evaluate the time that has to be spent on regression testing, depending on its complexity. While executing embedded software project estimation, a PM should also allocate time for bug fixes and code cleanup.
Duration estimation is all about the timeline. For instance, a specific task takes eight hours, including smoke testing and fixing, but QA testing, deployment, and the client's approval take one more week, while sending samples and waiting for ordered components or tools takes two more weeks. In total, we get two weeks and eight hours that need to be included in a project plan with all the risks, mitigation work, and other details.
Types of embedded development project estimation you should know about
Three-point estimating is a probability analysis where each point defines the possibility of risk realization and falseness of predictions (being either wrong or unfulfilled):
Optimistic case — no issues will occur at all. The assumption is that, according to predictions, there'll be no bugs and no need for additional modifications. All other functions won't be affected, and the tests will be passed in one take. You can rely on this case if the team has done a lot of similar projects on particular MCUs, and they certainly know what can go wrong.
Most Likely case — a few non-critical issues will occur, and the project implementation will take more time due to minor bug fixes. This type of estimate is the most common because minor complications happen far and near. The name of this case reflects the way most projects are done, but it’s not disastrous. There’s always room for human error or external risks you as a PM can’t predict.
Pessimistic case — issues will prevail, while all assumptions won't be realized. You'll face numerous delays throughout all project stages, dealing with predicted technical risks. The developers will have to run multiple tests and retests, fixing the affected modules, and so on. You can take into account this case if your engineers haven't worked with a particular technology, OS or MCU, or you’re significantly changing the logic of a source code. During the project, you should expect constant architecture and module logic tweaks, leading to new use cases, scope creep, and budget overshoot. The pessimistic case should reflect actual time that can be spent on implementation and dealing with the risks.
Each variant determines the likelihood of the risk realization, and the possibilities you estimated will or won't come true.
Steps to take after calculating each estimate case
Knowing your assumptions about each case, you should write down the conditions in front of every task. For instance, the time when needed equipment, documentation, and SDK will be delivered to engineers or how much time they will spend on testing and getting an approval from the client.
But how to estimate time for a project you are going to undertake? Write down the impact and possibility of issues and conditions. Next, choose the most plausible ones and think about mitigation plan measures. These actions will help you establish efficient risk management and work organization before any problems can block the development process and timeline.
Include vacations, weekends, approval expectancy, testing phases, and everything that contains dependencies in the timeline.
Project estimation preparation
Now that we figured out the terminology, let’s proceed with the tips you should use to make your estimation more detailed and effective.
- Define at a minimum a general acceptance criteria list with your client. You should clearly understand what functionality should be implemented to allow engineers to consider the variants of feature realization.
- Oftentimes, clarifications about features arise after work has been started, which can affect a project's defined time and budget limits. Engineers should think about particular feature implementation methods before an estimate is sent to a client.
- Provide the engineers with sufficient time (at least six to eight hours) for examining SDK documentation, basic module logic, and source code. They need to find out whether required information about specific tools or modules is publicly available, or engineers will have to request it from the manufacturer. Developers should also indicate whether they have dealt with a particular OS, technology, and protocols, matters which can significantly influence the project's estimate and deadlines.
- Involve QA engineers in the estimation process since they can evaluate how much time will be required for writing test cases and testing the product. You should include alpha, beta, release candidate testing phases, and possible regression retesting (fixing critical bugs could affect adjoining functionality, which requires additional testing). The complexity of a project directly influences testing volume; that's why the typically allocated 30% of development hours for quality management is frequently not enough. In addition, if a client provides test cases, QA phases should be estimated separately, depending on their number and complexity.
These measures will ensure a better understanding of potential risks, allowing PMs to provide more accurate project estimations.
Estimation process
In this part of the article, I will explain how I usually nail the estimation process by showing what valuable information should be discussed with engineers and why.
1. Engineers in tandem with a PM specify the tasks but not from a technical perspective. It's more like features divided into smaller parts from which engineers can get a detailed picture of the project. Then, developers can choose the most reliable and simple technical implementation methods to be integrated into the estimate. You can ask engineers to estimate the task as a whole and, after decomposing it, estimate its separate parts, then sum the pieces and compare to the first estimated number to see the difference. If a PM notices that the total estimation of the task and the estimation sum of its subtasks differ, they should opt for the subtasks evaluation sum.
2. Next step, a PM and engineers discuss each task from a technical viewpoint to know how the features will be realized. This way, a PM will be more aware of how much time to devote to each task and the definition of the assumptions for successful implementation.
3. Search for potential pitfalls during project estimating, like incompatibility between modules or features.
4. Highlight your assumptions concerning successful project delivery and write them near proposed tasks for project planning and risk management.
5. Ask engineers to inform you about the equipment and devkits they plan to use, technical advisors and documentation they require, and what solutions will receive a client's approval. With this knowledge, a PM can successfully avoid potential blockers.
6. Get more information about the possibility of an assumption's failure to know the potential impact on a project's timeline. For example, what tools your engineers need from the client and how much time task implementation will take if the client can’t provide them or what to do in cases when specific logic cannot be implemented and the team will need to discuss other options with the client.
7. Identify dependencies: for instance, which tasks cannot be started without other tasks finished. Such an approach will help to choose the right methodology and proper work breakdown structure.
8. Find the possibilities of parallel development, like what modules and features can be developed concurrently and separately without affecting one another. Additionally, it should be determined which features and modules should be developed first.
9. Clarify with the engineers whether feature implementation won't affect the legacy code or core SDK logic or what level of influence is likely.
10. Consider the quality of existing or planned architecture by creating a simple diagram, working out the logic and use cases with QA engineers, and then trying a “Poka-yoke” kind of development approach for error-proofing the final product.
11. Estimate the experience of the team working on a project (for example, whether engineers have worked with specific tools, equipment, and features).
12. Write down the risks: technical ones in the first place, then related to a team, other resources, a client's attitude to bureaucracy, and so on. Don't forget about the risks not related to a client or team, like PCB production time, delivery, and unexpected global or regulatory events.
13. Learn from others' experiences. Ask your fellow PMs who were involved in similar projects you have to work on about their estimations and predicted timelines. Maybe there were some unforeseen events, technical risks with specific MCUs, team members, and so on?
Determining a final estimate
Review Optimistic and Pessimistic project estimate prognostications, comparing them to the Most Likely scenario. If you notice that the difference between the Most Likely and Pessimistic is significantly higher than between the Most Likely and Optimistic, add buffers for the likeliest risks influencing the timeline and confusing dependencies and conditions; the more risks, the bigger the buffers and inclination to an estimate closer to the Pessimistic one are.
If the risks you take into account are possible but still don't stop the project realization, add a buffer. However, if the risks lead to failing the project, explore different variants of a feature's technical realization or discuss the possibility of changing or abandoning a feature with a client in advance.
But don't worry and keep your chin up, you shouldn't do this for each task (it's quite time-consuming), only for those that contain numerous assumptions and possible risks. Also, discuss this information with the engineers since they realize what's necessary for technical implementation due to their experience and technical conditions.
Three-point estimation formulas
These formulas are used for averaging three implementation cases to one number of hours, including the time it takes to deal with the risks and assumptions a PM anticipates.
The Triangular Distribution — the average between Optimistic, Most Likely, and Pessimistic scenarios (O = 4 hours, M = 8 hours, P = 16 hours). Adding the hours, we will get (4+8+16)/3 = 9.3 hours. You can use this formula in cases when none of the three estimates leads or is more probable.
The Beta (PERT) Distribution — the average between the three estimates but by multiplying the Most Likely by four and dividing the sum by six, meaning that the Most Likely scenario takes over the others, being the most probable (O = 4 hours, M = 8 hours, P = 16 hours. (4+(8х4)+16)/6 = 8.7 hours).
Confidence level ratings
Now that you’re done with the formulas, you should go through the tasks and define how confident you are in their implementation, meaning that the features will be developed as a matter of course or whether there’ll be specific risks that lower your confidence in getting things done.
PMs distinguish between three confidence level ratings: high, medium, and low. These ratings are applied to each task or feature to show a team's confidence in an estimate's accuracy.
If half or more tasks are signed to the low confidence level, a PM should discuss them with project owners and manage them even more thoroughly.
Three-point estimation implies a fairly high confidence level since each of the three estimate scenarios is analyzed, the risks and conditions identified, and the formula chosen.
Another way is to put heads together with the engineers and find an average confidence percentage based on their experience of working with specific projects and technologies.
However, note that engineers frequently estimate the tasks either overly optimistically (neglecting the risks) or pessimistically (to win more time).
Negotiation techniques for getting better estimations from engineers
1. Say no without saying no. Your goal is to make engineers work on alternative solutions. You can offer different options and ask open-ended questions.
2. Focus on the goals. For instance, the team wants to devote more time to feature implementation with additional options, but if it means that you cannot deliver on time, the approach should be changed. A PM needs to ask the engineers which quality criteria can be decreased to meet the deadline.
3. Search for a compromise. Offer engineers to choose a simpler implementation variant that will reduce the timeline and ease the team's work. The team can use MCU code feature examples that are usually well-developed and integrate their improvements.
4. Insist on establishing objective criteria, like legal restrictions, FCC or other certification regulations, objective information from the engineering community, and experience from previous projects. It's necessary to agree on the criteria that both engineers and the PM trust.
If the team is overly pushy around their estimate, ask them to provide objective information or back up their confidence with previous experience.
Wrap-up
Objective and realistic estimation plays a crucial role in project planning and development processes. Not only does a client get a realistic analysis of their future product, but also the engineers working on a project get the chance to brainstorm possible solutions and are not locked into only conventional methods. A PM's main goal is to find the golden mean between a client's expectations and the team's potential. But with the recommendations Nazar has listed in this article, you will be confident during the planning and project execution phases, which makes you a comfortable and reliable partner for your clients.
Need to develop an embedded product but are having doubts whether it will shoot? Doubt no more! Our professional PMs will make an objective estimate that will help you develop a clear roadmap for your project. Reach out to us via our contact page.
