Had an interesting issue with terminology and preconceptions when initiating a FLiP project with a client recently. We were debating the project plan, and he expressed some concern over the amount of time allocated to the Prototype stage.
We explained that time spent here was saved many times over in the final build, and that when you have a really good FULL prototype, it leads you naturally to a complete architecture, and that doing it this way meant that the user experience was driving the back-end rather thatn the other way round, etc etc.... but he still wasn't convinced.
It turned out that although he was experienced in managing software projects, they were nearly all Windows desktop-based GUI apps, and that's how he was looking at this web system:
In the Windows GUI world, a "Prototype" is generally something that you whip up quickly in something like Visual Basic, but then completely throw away when it comes to the final build stage, which is typically done in C++. This was the root of his concern - he didn't want to spend the majority of his budget on something which he thought would be thrown away once complete.
So we explained that the display templates we develop during the Prototype stage can (with a little foresight and hopefully not too much tweaking) pretty much be dragged into the final app, and he brightened up considerably. Once we decided to rename the Prototype stage as "Front - End Development" he was sold.
I guess it goes to show the power of a name, and the danger associated with differing interpretations of what seems a fairly innocuous word. But then again, eliminating ambiguities from textual descriptions of abstract notions is part of the whole motivation for using a "Prototype" rather than a Requirements Document in the first place.... makes me wonder how many other times the words we use have counted against us, without us ever even knowing it.
1 comment:
Post a Comment