Fear of Non-Progress
<< Page 2: The Waterfall Effect
Page 3: Increase Communication
There is always a danger that your project, however well it
is progressing, may give an impression of slow progress.
This can give rise to all sorts of problems, e.g.
senior managers decide to "crack down" on the project; insist on unnecessary and time-consuming daily
updates; try to embellish the process with their
own "best practices" which just hinder the project; mix staff around; reassign the project; or worse still
get cold feet and can the project entirely. Frustrating, when you knew that the project was doing well.
All you had to do was convince them. This is where communication comes in. It's an essential part of the mix.
Steve McConnell writes about the perception of slow development in Rapid Development: Taming
Wild Software Schedules (Microsoft Press). The first thing to do is eliminate wishful thinking, and make planned
schedules more realistic. If expectations are reasonable, everyone can relax and get on with it without resorting
to that most time-consuming of development modes, panicky hacking.
|
"The quality of the product inevitably suffers"
|
|
It isn't always possible to convince management to allow you a reasonable deadline. Market pressures mean that
the deadline is regarded as immovable (e.g. go live in mid-September ready for
the Christmas rush). In this case, the only possible way to achieve this is to cut down the amount that will be delivered.
The customer can have some of what they want by their proposed deadline (and get the rest later), or they can "go for broke" and almost certainly
end up with none of what they want.
Taking this reckless approach, the quality of the product inevitably suffers. They might get what they want eventually, but it probably won't be until Christmas
the following year. It's even more likely that they will end up with a buggy mess that has to be scrapped.
In this instance, it is vital to make the customer understand that leaving something out of this delivery phase doesn't mean they will never receive it. They may just have to wait a few months. Prioritisation is key. Use DSDM-style MoSCoW rules if you must (but don't be surprised if everything ends up as a "Must-Have"). You need to find a polite way of saying "You can have some of what you want now, or you can try to have it all and end up with nothing." If the customer can be made to understand this, then 90% of the battle is won.
However, what happens if your project really is suffering from slow development, and not just the illusion of slowness?
>> Page 4: Tackle the Problem Head-On
<< Back to Lifecycle
|