Appeared originally in westartup.eu.
There are already some FP7-related services, two clicks from the google home page, but they are mostly about consulting or badly written tools that none uses anyway.
Companies behind these tools do not provide trial versions nor demo versions, only one has a (really bad) screencast. Technical features are missing from the descriptions. Moreover, they do not respond to inquiries to provide more information on their tools.
A proposal, especially an FP7 proposal has a fairly evolved internal structure. Its TOC does not almost change at the first two levels, and there are a few rules everyone follows, e.g.
There are three types of positions in an organizational hierarchy:
Note that only the middle managers communicate both with the top management and with the employees and workers. In a traditional enterprise, the communication is oriented top-down, with middle management only detailing and passing on the orders.
In IT, as probably in the other hi-tech industries, bottom-up communication is of a paramount importance as the problems arrive unexpected and are sometimes not only difficult to overcome, but even difficult to explain. However, managers are still evaluated mostly on their abilities to manage subordinates, not on the ability to channel information to the top management, guiding and orienting corporate decision-making.
My brief manager's career ended partly because my company could not avoid the usual problems of software development, the problems that I knew about, could forecast, but was unable to mitigate as they arrived, mostly because I could not guide the much less knowledgeable boss through the minefield of decision-making without hurting his ego.
A manager that can not influence the decisions of the boss is only a half-manager, I now see clearly which half I was. Being aware of this handicap in advance could have helped me. Reading this post and applying it to your situation will probably help you.
Here is a fictitious story of a business client that orders software for a mobile phone to an embedded developer.
Take such a trivial feature of a mobile phone as a the possibility to store last calls. What do you know about it besides that it allows to view last incoming and outgoing calls? This is the level of knowledge that a typical client has and he will express it as a requirement the same way:
— I want that my mobile phone software to store last incoming and outgoing calls.
The developer has two choices: either assault the client with question based on unconfirmed assumptions or tacitly do exactly what was asked. He writes code that keeps two lists ordered by the call time, one list for incoming calls, another one — for outgoing calls.
Soon after, the client finds out that a competing company uses a different design and demands the software to display:
Unfortunately, the previous code has already been written and is linked tightly to the UI code and to the rest of the mobile phone's OS.
So, instead of scapping the previous design and starting from scratch, the developer is now bound to implement new data structures that consists of one new list that combines incoming and outgoing calls in the right order to satisfy the first additional requirement, and three more lists for each of the 2nd, 3rd and 5th additional requirements.
This seems like nothing, but coupled to the synchronization code and error handling code, the result is likely to look cryptic for everyone, including its own developer.
