Project heroes. Weve all heard of them. Some of us have even seen them. A project is in jeopardy. This guy (or gal) comes out of nowhere, analyzes the situation, tells you exactly what the problem is, and then goes on to fix it before you can even update your project plan! Some project managers place a high level of trust in project heroes. As a result, their superman (or superwoman) is assigned to the most fascinating projects and their technical decisions and sizings are never challenged. In the meanwhile, the rest of the development team implements banal functionality or fixes defects. Whats Wrong With This Picture? Well, for one thing, too many project managers pick heroes based on their can-do attitudes instead of their ability to consistently deliver software on time and according to specs. As a result, developers who are fed up with boring tasks and want to be treated as heroes suddenly become overly optimistic when asked to size features. Additionally, Ive seen many so-called heroes hold up entire companies because they wouldnt admit that they were having trouble meeting their schedule. By blindly trusting everything your champion tells you, you undercut your ability to take corrective action in a timely manner. Finally, an emphasis on project heroes discourages cooperation among the many stakeholders in the software development process since many champs tend to undermine their peers. Asking a developer to justify his estimate doesnt mean you dont trust him. Asking for a second opinion doesnt suggests she is incompetent. It simply proves that you understand risk is part of any project and that you do your best to assess and minimize it. Giving carte blanche to project heroes sometimes but rarely leads to high-quality software developed in record time. More often than not, the result is a pattern of schedule slips that are not acknowledged or reported until its too late, built up frustration amongst team members, and a lot of I told you so when your champion fails. |
