I first came across Steve McConnell’s Rapid Development when I found it on a colleague’s desk last year. Inside were several pseudo-bookmarks where people have left off reading and had probably forgotten to return. If I remember correctly, I myself have stuck in a calling card and some restaurant’s flyer. Anyway, my fave part of the book has got to be the bits on Classic Mistakes. They’re classic so, in one way or another, I had personally come across them in my own projects. As I went through the list, I could recall going “ooh” nearly cringing in recognition. But the reason for having this list is not to rub salt to the wound. Rather, this list highlights what you need to consider during project planning and risk management. It includes 36 classic mistakes categorized into 4 areas — People, Process, Product and Technology.
Here I list the people-related classic mistakes, together with some excerpts mixed in with a few notes:
- undermined motivation – study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor. some examples of stuff that undermines motivation include hokey pep talks, requiring overtime, management going on long vacations while team worked through holidays, providing end-of-project bonuses that didn’t compensate the overtime effort rendered.
- weak personnel – hiring from the bottom of the barrel can get project off to a quick start but doesn’t set it up for rapid completion.
- uncontrolled problem employees – failure to take action to deal with a problem employee is the most common complaint that team members have about their leaders (Larson and LaFasto 1989). seeing nothing being done about problematic team mates and suffering for their lapses can lower morale.
- heroics – emphasizing heroics in any form usually does more harm than good. an emphasis on heroics encourages extreme risk taking and discourages cooperation among the many stakeholders in the software development process. by elevating can-do attitudes above accurate-and-sometimes-gloomy status reporting, you miss out on taking the appropriate corrective action.
- adding people to a late project – most classic. think brooks’s law!
- noisy, crowded office – workers who occupy quiet, private offices tend to perform significantly better than workers who occupy noisy, crowded work bays or cubicles. a related link I tweeted before – http://tinyurl.com/7qyvta
- friction between developers and customers – customers may feel that devs are not cooperative; devs may feel that customers are unreasonable. effect of this friction is poor communication which leads to poorly understood requirements, poor ui design, and in worst case, customers’ refusal to accept the product.
- unrealistic expectations – inability to correct unrealistic expectation, overly optimistic schedule estimates. by themselves they do not lengthen the devt schedule. but there’s just trouble when unrealistic expectations in schedule or in features are compared with reality… it gives off the perception that it has gone too long or the features too insufficient.
- lack of effective project sponsorship – without an effective executive sponsor, other high-level personnel in your org can force you to accept unrealistic deadlines or make changes that undermine your project.
- lack of stakeholder buy-in – all major players in a sw devt effort must buy in to the project — executive sponsor, team leader, team members, marketing staff, end-users, customers. good buy-in leads to close cooperation and precise coordination of the rapid devt effort.
- lack of user input – projects without early end-user involvement risk misunderstanding the project’s requirements and are vulnerable to time-consuming feature creep later in the project.
- politics placed over substance
- wishful thinking – this isn’t just optimism. it’s closing your eyes and hoping something works when you have no reasonable basis for thinking it will. It undermines meaningful planning. causes trouble when reality blows up in your face.