One of the most blatant examples of unrealistic expectations I have experienced was at a motor manufacturer whose UK subsidiary was rewriting their dealer system. The system controlled just about every part of their business from sales, through parts and servicing to accounting. The then current system was DOS based and although worked fine was looking dated and reaching the end of its usable life. The replacement was a n-tier, VB5, MTS (now COM+) system with Oracle as the database. The specification was the old system, a pile of enhancements and knowledge held in 3 dealer consultants heads. Already this isn’t looking good. Then the bombshell, planning. The conversation went along these lines:
“The accounts system will take 3 months to complete”
“How have you calculated that, these plans aren’t detailed enough to work out how much time is required”
“Accounts represents 25% of the complexity of the old system, and we want the new dealer system developed in a year, hence 3 months”
“And how many developers?”
“3″
So that’s 3 man months to:
- Understand the old system
- Find and understand the enhancements
- Pick up further changes from the dealer consultants
- Technical design
- Approval for GUI
- Development using technologies that then were very new
- Unit and system test
- Integrate with the main shell and with other parts of the system, e.g. sales
Clearly this was unrealistic expectations on a grand scale, but it took 9 months to realise that this was the case.
Unrealistic expectations is not restricted to only planning and timescales. Over the years I’ve seen a number of other cases:
- Sales made on the back of features that don’t exist in the application, then a scramble to implement them
- Inappropriate software selected and expected to be configured or changed to fit business practises
- Old, slower development environments, but development speeds of newer development environments
- Development and/or implementation using old, slow, small hardware
In my experience people working with projects that have unrealistic expectations tend to have one of two mindsets: 1. Heroics - let’s get it done and 2. We’re not going to make it so do what you can, but only 9 to 5.
Neither of these mindsets is good for the project. Heroics we have discussed, but there is the other side of the coin in which everything is viewed negatively. Getting either of these entrenched in a project is deadly, which is why effective planning and being in control of the expectations is vital. Going back to my example, the project manager should never have agreed to initial timescales as they were clearly too short. The particular project had 3 different project manager over 2.5 years before the project was cancelled, to be replaced by a third party application.