Risking to express a controversial opinion, I would say that technical documentation has slightly different priorities than normal texts. Being in I.T., I read and write tons of technical papers, and I always prefer readability and text size versus formal grammar.
Think for a moment, your reader is often a non-native speaker as well, but, most certainly, they are a busy person. Overuse of large grammar constructs may just increase the size of your writing, without adding any value.
No, I don't say your document should be ungrammatical. Instead, it must be based on keywords, the shorter the better (unlike my answer :-)
Let's review individual phrases (I took those from your original edit):
- Description of the Project vs. Project Description — are you really sure that project is strongly necessary? If you leave just Description, wouldn't it make your documentation more succinct? I think, it would; There's also special terms, purpose and abstract to denote sections containing verbose description of a project and its rationale;
- Justification of the project — I wouldn't use justification at all. It has several meanings, and you may confuse your reader. Alternatively, it may be review, analysis, or clarification, depending on the context;
- Definition of the scope of the project — there's a term, Scope of Work;
- Bounding of the projects — use Special Requirements or Dependencies instead;
- Benefits of this proposal — just a keyword, benefits, seems to be sufficient (indeed, if not of this proposal, of what then?);
- Competitive Advantages — it's a term by itself, stick to it;
- Deliverables of the project — Deliverables and Artifacts are standard terms;
- Preliminary schedule of this project — just schedule. Everyone understands that it your schedule is proposed, therefore it is subject for change, and, because of that, is preliminary;
Summarizing:
The difference is in the metaphor within the idiom. Different metaphors create different contexts which create different usages.
End to end conveys a linear sense; a line or length of some sort, and an end to end solution covers the complete range. In software, this phrase would mean a solution that covers each piece involved, from the client interface to the data storage and everything in between. End to end testing is a very common example of this usage in the industry. This idiom has a common and generally well understood meaning.
360 degree suggests a circle, and such a solution would cover every possible angle. This would likely be used to suggest that the software works on every platform: desktop, server, phone, tablet, etc. This is because software is often spoken of as facing a particular platform or audience when supported (e.g. mobile facing, web facing). Alternatively, this could be taken to mean that the software provide any and all desired functions within its domain; users don't have use anything else to do what they need. This term is much more nebulous than end to end and is more likely to be viewed as marketing fluff.
If you have an end to end solution then you've got every necessary step in the pipeline or process covered; nothing is missing or needs to be supplied by a third party. If you have a 360 degree solution, then the solution works in all applicable environments; it covers all the angles and users can access their data from any entry point.
Is there anything like 180-degree solution? Does it make sense in English? Is it an end-to-end solution?
No, this is not a common term (I've never heard it before), and it does not mean the same as end to end. You could use 180 degree solution sarcastically to imply that a proposed 360 degree solution only did things in a half-assed fashion, because 180 degree means that only half of things are covered.
Best Answer
There are a number of options:
English speakers frequently use would in the place of used to.
For example, they say things like:
which has the same meaning as I used to.
So you might change the passage (and make several corrections) to read: