|
|
|
Troubleshooter 13
To the Travel Sector Account Manager, Mr Jones, I am yet to reassemble a RAD (Rapid Application Development) team for BritBreak, but I have held a series of focus groups to understand the difficulties I have faced. It became obvious early on that there was a split of opinion. Managers and those who have been programming for many years are uncomfortable with RAD, and would prefer to pretend it doesn’t exist. Younger programmers are generally in favour. When I began to probe, I found layer upon layer of excuses. They started by saying that RAD was unsuitable for large, complex projects. While I don’t agree with this, I thought it best to gain their confidence and acknowledged that traditional waterfall methodologies are best for some developments. However, many projects aren’t enormous. Why not get the benefits of RAD there? Next they argued that their staff could not understand RAD. It required too much flexibility and innovation. I pointed out that this implied they were hiring second-rate staff. Was the board aware of the policy? Particularly when there was a possibility of outsourcing development work. On consideration, the managers decided they were thinking of the industry in general; their staff were entirely up to the job. The last attempt at distraction was suggesting that learning RAD tools would involve a huge training overhead. I was able to show examples of other companies where the training costs were low, thanks to the usability of visual development environments. Finally they cracked. The true reasons were driven by fear. RAD means the demise of the detailed specification. Without this, they were worried that the users would be able to change their minds when they saw what the system would actually do. It didn’t matter that this was a key benefit of RAD – the detailed specification was a visible sign of power over the users. Secondly, they were worried about using timeboxing rather than a full project plan. There would be little to measure against, and since they considered a checklist full of ticks to be a sign of their own success, there was concern that management would be considered ineffectual. Despite my saying that delivering systems was generally considered an achievement, it was hard to convince them that it compared with having lots of ticks. Finally, they were worried about the staff. With conventional methods, tailored to BritBreak, the staff had few saleable skills. With RAD, they would become interesting commodities. I reassured them that we could make RAD just as BritBreak-specific as anything else. I should now be able to set up an effective RAD group, but this will have to wait a while. My contract with BritBreak has the usual requirement to fund two months of training a year. As is also usual, my “training” will involve spending time on another contract, so SMcTR gets paid twice. I’m joining the team that’s doing a crash overhaul of Nanoware UK – it should be interesting. ... read next column Copyright © Creativity
Unleashed Limited 2006 |
The Troubleshooter column relates the experiences of a fictional consultant. Although the context is made up, many of the experiences related in Troubleshooter have happened in real UK businesses. Take a break from the creative pressures with Troubleshooter and return to your creativity refreshed. Originally published in PC Week magazine.
Check out more articles on our creativity information page
|
