Again: Is it a tool (feature) or is it a product (media)?

People start to realize that something will change on the intranet. It can affect current processes, the way of working, and some smaller projects they have been working on and tried to design to fit exactly to their needs. - Emerging applications never fit exactly; you should not spend that much time on them. But they always offer ways to get about 85 or 90 percent of what you really need.
Some Wiki-Aficionados in the company had heard about our project and wanted to learn some details. Part of them had ideas on very specific requirements which they thought they would need, the other part had visions of bringing Wikipedia to the rich and lively world of balance sheet managers.

• In big projects, I'm not a friend of very specific requirements. I'm more into generic features with lots of embedded freedom. The reason is simple: Requirements change every month - the more specific they are, the more they will change, and te bigger the project, the longer the time for changes. But there is a difference between detailed and specific: Requirements should not be too specific, but the generic requirements should be very detailed.
• Specifying requirements just because you can, is a very bad habit. One of the wiki-aficionados, a junior Trainee, had designed a blue print of wikipedia for balance sheets managers, containing not only the classic editing, versioning and discussion features, but also news, company information and other contents from the "official" intranet. What for? To create and alternative intranet homepage? To double the work for editors (publish things here and there)? To create complicated syndication processes? To give himself and his colleagues the impression to have something on their own? Or just because wikis can?

That's one of the downsides of lightweight software: It's potentially easy to start something, but that does not help with the real problems: How do user authentication and permissions work if there is not open accessible solution yet? What contents will you have in these services? How do you align them to ensure standards and simplify user orientation? And how do you motivate people to participate in there? Can 100 controller really mimick wikipedia? The clear, fast and very distinct answer is: No.

Even with lightweight stuff, we need integrated tools and features instead of additional apps. Running tests and creating prototypes is great - but those who run around and sell their prototypes as a solution are a pain in the ass, to tell it straight.

Im a big fan of decentralized applications - but they only perform well, if they are really nicely integrated and don't shift additional burdens on the user: Which portal do i go to today? What was again the url of this one wiki? And why don't I find this interesting article anymore; was it in the news or somewhere else? And where does this search actually search in?

Using something new means adapting it to your needs - or adapting youself to the new stuff. That means to treat it as a tool, either to solve a problem or to create new ways of working and living.
Considering a something "new" (like Wikis) as a product, that you need to treat, handle, promote and sell as a piece on it's own means to set yourself up to fail: You definitely will learn something - but nothing you can use now.