Quite a few companies and teams that I encounter have an expectations problem. They have unrealistic expectations for the time and effort that it takes to develop an embedded system. On the spectrum between pessimistic and optimistic, they typically blow past optimistic into the fantasy land zone. The result is often debilitating, stressful, late, and buggy embedded systems. What can development teams do to avoid unrealistic expectations? Here are five tips developers can use to help ensure they set expectations that are realistic and not fantasy.
1. Track Project Metrics
My all-time favorite recommendation is that developers define critical development metrics such as features, estimated effort, actual effort, and lines of code, just to name a few. Developers and teams can’t set realistic expectations for delivery times and costs if they don’t have any data to help them create their estimates. Keeping historical project metrics provides a baseline and allows a team to go back and see how they performed on other projects, time required to create similar features, and should help bring the project expectations back toward reality. Without any data for comparison, estimates become nothing more than hunches and can vary drastically depending on the teams’ mood that day.
2. Don’t Sugar Coat it
Sometimes a project might be for a new client and the team becomes tempted to provide the customer with information and data that they want to hear rather than how it will really go. This may make the customer, or even your project manager, happy in the short term but it will only end in disaster. Don’t sugar coat estimates. Instead, give the hard facts and provide alternatives on what might be done to mitigate delays or budget overruns. It may disappoint the project manager or client but in the long run it will result in a better working relationship.
3. Consider Parallel Projects
There are times when development teams will properly determine the time and effort required to develop and deliver a project. Fantasy once again enters the equation because they don’t consider that the team may have multiple projects in process simultaneously. Resources may not be available for an entire project or may be bouncing around. When 80 hours of work needs to be crammed into a 40-hour work week, the projects are not going to be done on time.
4. Use a Project Management System
Project expectations are rarely set in stone. They often shift throughout the project and even sometimes based on the mood of the developers and clients involved. One way to make sure all stakeholders stay on the same page and have the same expectations is to use a project management system that can track the project. Developers can then use burn-down graphs and many other tools in order to track projects at least on a weekly basis, which will also allow for fine-tuned adjustments to be made to the development cycle. There are plenty of systems available ranging from free open-source projects such as Trac to systems like JIRA that require a subscription.