Most projects suffer delays and rework because the true requirements are rarely fully understood.
Business analysis is harder than it looks. While the product people have an idea in their heads about what they want, turning that into a complete functional description of the finished application is a major undertaking. The difference between an idea in someone’s head and the final, complete description is a long, long road.
Doing the analysis can be like mining for gold. The real requirements are buried deep beneath the surface. You have to keep digging to get at them. Unfortunately, if you fail to do the hard work, you will end up with insufficient and wrong requirements. Then a lot of development time will be wasted building things that will need to be re-done later. Time spent constructing features not desired is one of the saddest forms of waste in an engineering team.
Beware of assumptions, misconceptions, and politics. It is very easy to make assumptions during the development process. The best way to defeat bad assumptions is through repeated communication, documentation, and redundancy. Review the requirements from time to time, to make sure everyone understands them correctly. This also helps with misconceptions. The more times people review things, the more opportunities to uncover gaps in understanding.
Politics are another monster entirely. People who are more concerned about their own standing in an organization than with the success of the team sometimes don’t ask in the team’s best interest. Always be wary of political animals. They’re dangerous.
Another thing to keep in mind: you can’t estimate work effort until you know what you’re really supposed to build. Anytime you’re asked to provide estimates without doing a proper analysis, you’re going to have a bad day.
Or year.
Today's Card 