IPA Proposal Template

Integration Project Proposal template
Proposal Template
Tips when using this template:
Read the Guideline (>link) further explaining considerations when writing proposals using
this template
 The frame area surrounding this text is intended for illustrations (figures, pictures etc).
Example: When showing customer logotypes place those centered vertically and
horizontally!
 If you have a printer capable of printing bleeding images at the top and bottom paper edges
you may change the margins to utilize this. Go to the button “Functions” on the Ericsson
toolbar and then choose “Template for External Communication only” and you will find two
menu alternatives starting with “Logotypes
at.....”.
 Read more about the above subjects in the Directions for use found via button “Help” on
the Ericsson toolbar).
 Remove this textbox after reading! (Mouse-click on the textbox frame and then press
Delete).
EAB-09:028662 Uen Rev C

Proposal information
Subject of
Proposal:
Author: For the
Attention of
(Customer):
Approved by: [insert name of Ericsson
Signatory]
Signature: Date:
Company Name Telephone

and address: and Fax:
Proprietary nature of proposal

Ericsson has prepared this proposal for the sole and exclusive use of the party
or organisation to which it is addressed. Therefore, this Ericsson Proposal is
considered to be proprietary to Ericsson and shall not be made available
without the prior written permission from Ericsson to any other party than the
addressee or persons within the addressee’s organisations who are
designated to evaluate or implement the Proposal.
Note on Confidentiality: Although this document has “Confidential” status, this

may not necessarily constitute a legal obligation on the part of the customer,
since the document is only signed by Ericsson. In cases where the disclosure
of information provided together with the proposal could be detrimental to
Ericsson you should consider whether a separate non-disclosure agreement
(NDA) should be signed prior to release of the proposal. Delete this note
Copyright
Copyright © Ericsson <insert company name, YEAR>. All rights reserved.
This Proposal or parts thereof may not be reproduced or transmitted in any

form by any means, electronic or mechanical, including photocopying and
recording, or by any information storage or retrieval system, except for the
exclusive use of the addressee’s organisations. Copying for other purposes
shall only be carried out when permitted in writing by Ericsson <insert
company name>.
Ericsson has made every effort to ensure that the information contained in the document is adequate and free of errors and
omissions. Ericsson will, if necessary, explain issues that may not be covered by the documents. Ericsson’s liability for any errors
in the documents is limited to the correction of errors and the aforementioned advisory services.
EAB-09:028662 Uen Rev C 2013-06-05  Ericsson AB 2012 2 (30)

Subject to Contract COMMERCIAL IN CONFIDENCE
Guidelines to the user of this document:

Introduction
Delete this entire Guidelines section, as well as all instructions that are
inserted in the document before the proposal is finalised.
Editing Instructions
This document is prepared using the standard ESOE template for external
documents. Ensure you have the “Ericsson toolbar” activated and follow the
normal procedures when updating header/footer information in order not to
corrupt the document.
Instructions are included in the text of this document (in italics); these
comments should be read but deleted before the document is provided to the
customer. Some texts need adjustment, or indicate options or alternatives for
the particular proposal; these are indicated – e.g. by [yellow marked or text in
brackets].
Text in green colour is specially marked since it is to be considered as

mandatory (of legal purposes) and no changes (apart from format changes)
should be made to this text without consultation of expertise from Contract
Management or Ericsson Legal.
Follow the instructions incorporated in the model agreement documents.
The model agreement documents must under no circumstances be provided

to an external party (Customer or a supplier) in unedited form or including the
comments and instructions
Delete the guidelines above, and all other instructions and guidelines
before sending this document to any external party - including
“partners” and suppliers!

Table of Contents
1 Executive Summary / Introduction..............................................4
2 Project objective............................................................................6
3 Proposed project scope / project deliverables..........................8
4 Main milestones and project phases........................................15
5 Prices............................................................................................16
6 Acceptance and terms of delivery.............................................18
7 Project management and Governance......................................18
8 Handling of Changed Requirements.........................................18
9 Time Schedule.............................................................................19
10 Customer’s obligations..............................................................19
11 Solution Life Cycle Management and support.........................20
12 Terms and Conditions...................................................................20
1 Executive Summary / Introduction

The Introduction / Executive summary is a key part of the proposal which is
truly intended as a sales tool. The executive summary focuses on key decision
makers and shall emphasise the main benefits of our proposed solution and
answer to the question “Why Ericsson, why not the others”. This introduction
section is written in an open language that directly addresses the Customer.
In larger proposals the Executive Summary is often a separate document.
The “look and feel” of the Executive summary also depends on the type and
background of the customer engagement and how far we have come in
discussions with the customer, and what sort of tendering procedure we are
facing. A formal “RFP” situation requires much thought, comprehensive and a
well designed proposal since we may not even get the chance to present the
proposal orally. The Executive Summary is then really a “selling tool”.

If, on the other hand we succeed in applying a Project Sales approach, the
written proposal should be the result of an established relation. Such an
engagement would typically include previous projects and consulting work.
The proposal can then be more direct “on target” as it would summarise and
confirm things that are more or less agreed already. In that case, the
executive summary could focus on:
 Restate and confirm what has been discussed - What is the

background that we have considered (“recap”) including the outcome
of preparatory consulting work.
 Show that we understand the customer’s situation and main concerns

so that we acknowledge the importance of this project (or programme)
for their business. This will be of particular importance in when the
proposal includes reaching operator performance or business targets,
managing or transforming customer operations, risk or revenue sharing
pricing models.
 What we offer
 How it will be done
 What is the Price and the conditions for fees and payments
 What are the main conditions, dependencies etc (positive) that we wish
to highlight (like special discounts if we can have the order before
….etc)
Some advice:
 There is no universal recipe for the executive summary.
 We recommend that the Executive Summary is written according to

principles in “Proposing to Win”. The principles can be applied also in
small scale. Link to Proposal Management::
http://internal.ericsson.com/page/hub_inside/sales/proposalmgmt/index
.jsp
 It must be based on the analysis of the customer and competitor

situation and needs.
 NEVER make an executive summary by cutting & pasting phrases

from product/ services marketing documents.
Delete this text
1.1 Background
Provide background information why this project will be undertaken. Discuss
issues such as the reasons for this project highlighting the following:

Who is the initiator?
What are the reasons for the project?
Any relevance to previous projects or proceeding studies, consultancy,

discussions?
Any other general information that could explain the present status quo?
Delete this text
1.2 Partnership [optional]

If the proposal is made together with a business partner we suggest it should
be described. A partner is another company that we form some sort of alliance
with and where the alliance strengthens our competitive position in this
specific proposal.
Normal 3rd party suppliers or subcontractors are not mentioned here.
Delete this text
2 Project objective
This section is intended to provide an overview and introduction stating the
main points, highlighting key benefits and strong points. It is not intended as
the detailed exact specification. This section is only intended as an overview
It is very important to understand that the specification of Ericsson’s delivery is

intended to be made in the Statement of Work (Appendix 1) + the detailed list
of deliverables, e.g. in “Detailed Prices and Quantities (annex 3.1).
The content of this section - as well as of the initial chapter of the Statement of
Work - depends on whether or not the proposal contains separate technical
specifications of IT or network systems such as e.g. a Solution Description
document (SoD). Delete this box.
2.1 Solution overview

The intention with this section is to describe the objective with the project – the
“final goal”. This is a part of the content of a Solution Description (SoD)
document
 Try to visualise the end result.

 Show that we understand the customer’s situation – i.e. describe

everything in the context of the customer’s environment. This could be
his system environment or processes.
 Keep it relatively short and on high level
 Information should be aligned with Solution Description (SoD), if one is

provided, but must be customer specific.
 Don’t make this a “system specification” chapter
The standard model agreement template for the Statement of Work also
contains an initial Solution Overview chapter. In the proposal phase it may be
wise to keep it in one place. Our suggestion is then to place it here (i.e. to
“move it” from the Statement of Work) – but to leave the heading in the SoW
with a reference.
Later, as we enter a contract negotiation and start working the detailed

documents of the project agreement, this proposal main body document has
played out its role and the overview is re-inserted in the Statement of Work.
If the proposal includes a separate Solution Description document (in this

Proposal template the SoD listed as a enclosures in section C “Supporting
Documents”), you may refer to it here.
Always keep in mind that it is the Statement of Work including a Requirement

Specification + Detailed Prices that strictly defines our project scope and
deliverables. Remember we do not sell a “Solution” as if it was an
industrialised product or “system”.
A “disclaimer note” like the one suggested below is important, since the
Solution Description in some cases are written in less precise language – it
can intentionally be written in a rather “marketing” style. There are also
“standard Solution Descriptions” similar to standard product descriptions. That
is also the reason why the Solution description (SoD), if included in the
proposal is placed under Enclosures Part C “Supporting Documents” and not
under Section A, which contains the specifications. This may be changed if the
quality and consistency of the proposal is properly secured.
Delete this text
The Solution Description (enclosure xx) that is included in this proposal is for
overview and descriptive purposes and shall not be interpreted as an exact
specification of deliverables or work results. This proposal is limited to the
Consulting and Systems Integration Services, Software and Hardware
explicitly specified in the Statement of Work and as applicable in a detailed list
of deliverables (Bill of Quantity).

2.2 Ericsson experience

Use this heading to reinforce your statements to build credibility and match
competition.
2.3 Ericsson’s project approach

Describe HOW we will perform the project. This is where you sell “why let
Ericsson handle this sensitive project”. The objective is that the customer shall
feel safe & comfortable by relying on Ericsson.
Mention something about our Quality Assurance, project Management model,

using certified Project managers and experience consultants etc…
Program Management can be a highly selling point for larger projects.
Delete this text
2.3.1 Project team (optional)
This heading can be used to sell in the “competence” side of our offering by
listing and highlighting the core competencies we provide. In more
consultancy-oriented project this is typically a key area of the proposal. Often
even complemented by enclosed CVs. Delete this text
3 Proposed project scope / project

deliverables
This is where you describe PRECISELY what the proposal covers. Remember
the link SCOPE = PRICE. The scope of the project must be sufficiently
described. If the Price is given on time and materials the scope specification
can be simpler than for the normal “fixed scope & fixed price”.
This section is intended to contain a comprehensive description of the project,

the specification of the scope and requirements as well as describing project
management set-up. The level of detail will depend much on whether or not
the proposal contains a separate Statement of Work. It’s then a matter of
styles what to include below – focus on making this document easy to read
and understand!

For projects where we offer a WORK RESULT and services at firm price a
Statement of Work is absolutely mandatory.
Depending on situation (i.e. the background, the complexity of project, how

advanced the discussions with the Customer have been etc) it may not always
be possible or desirable to include a full fledged fully detailed or “final”
Statement of Work in the first proposal version.
As described in section 3.4.1 below, the Project Sales Approach (PSTB) and
in the IPA model agreement, the normal approach in SI deals is that the
detailed specifications and the final SoW is subject to an “Analysis and
Specification” phase (or a “Pre Study”).
Delete this text
3.1 Proposed project deliverables [per phase, per activity

etc]
Define the scope of this project including the Integration Services and any
Hardware and Software included. Describe the boundaries and interfaces.
Detail clearly what is in scope and what is excluded. If necessary, also detail
who were involved and how this scope was derived. See further instructions in
the Statement of Work template.
Presenting the project deliverables per phase is one way to describe in a

concrete way. This depends on complexity of course.
Another way is to simply list activities:
[Example]The proposed main activities to be undertaken in the Project will be:
 A business analysis phase including workshops and interviews in order

to further detail objectives and requirements. This consulting oriented
phase will provide the base for Customer and Ericsson to make
necessary decisions how to proceed further into the programme /
project (-s).
 An analysis and specification phase covering detailed requirement

specification work, development of use-cases etc that results in draft or
final versions of the project scope (defined in the Statement of Work),
technical solution outline, draft project timelines etc.
 Detailed design and dimensioning of the XXX.solution including

integration specifications, finalisation of scoping and time planning and
…
 Dimensioning and procurement of xxx Systems and YY network

(Hardware and Software) delivered from BB-Systems
 Upgrade of Customers ZZ systems including data migration

 Integration of the complete and verifying tests
 After completed acceptance Ericsson will perform switchover and

commissioning of new systems to live operation including operational
assistance and onsite training program for 4 months.
The project scope and activities are described in detail in the Statement of
Work enclosed as Appendix 1.
A Transformation Program represents a type of project business that typically

comprises several projects over a longer period of time. The Network
Transformation project / program scope template should be used as guide.
Note that such programs often use a different commercial model (pricing and
payment model), and different terms and conditions than regular deliverable-
based SI projects.
See Project Sales Toolbox for further guidance.
Delete this text
3.1.1 Software
Mention major Software products directly here, but refer all details to
appendices:
Use the document “Detailed Prices and Quantities” (annex 1 to Appendix 3) as

the detailed list of quantities and numbers (“BoQ”). Ensure all software license
parameters are specified in full detail and in accordance with each 3PP
vendors wording in the appendix.
Avoid adding too much technical specification for products (valid for both HW
and SW), but if needed add them in VENDORS ORIGINAL product
descriptions as “Supporting Documents” under Enclosures item “C”. Delete
this text
This proposal includes the following Software:
 X
 y
Ericsson will procure the Software listed in this proposal (Appendix 3, Annex
1) and deliver to Customer. Ericsson’s responsibility with respect to Third
Party’s Software is limited to the specific responsibilities specified in this
proposal [preferably insert a reference to the Statement of Work] and under
conditions as stated in the enclosed terms for Third Party’s Software. Note
that Software may require direct license agreements between Customer and
third party as indicated by enclosed third party’s license conditions (Appendix
10).

Ericsson reserves the right to substitute offered Software at any time prior to
delivery with other Software that substantially fulfils the agreed requirements
for the Project.
Note that we want to minimise risk and responsibility for 3PP products. Use
Appendix 10 to enclose original License grant from 3PP SW vendors for
“Direct Licensed Software”. Delete this text
3.1.2 Hardware (where applicable)
You could mention major products directly here but refer all quantity and
model details to appendices:
Use the document “Detailed Prices and Quantities” (annex 1 to Appendix 3) as

the detailed list of quantities and numbers (“BoQ”). Ensure all software license
parameters are specified in full detail and in accordance with each 3PP
vendors wording in the appendix.
Note that we want to minimise risk and responsibility for 3PP products, and
there is a business decision to be made if we handle the HW (re-sell) or only
do the service part and require the customer to have the HW installed in time
for the SI project to start: Delete this text
Ericsson will procure the Hardware listed in this proposal (Appendix 3, Annex
1) and deliver to Customer. Ericsson’s responsibility with respect to Third
Party’s Hardware is limited to handling the procurement and delivery as further
stated in the enclosed terms for Third Party’s Hardware. Ericsson reserves the
right to substitute offered Hardware at any time prior to delivery with other
Hardware that substantially fulfils the agreed requirements for the Project.
Avoid adding too much of technical specifications for standard products (valid
both for HW and SW, both Ericsson and 3PP), but if needed add them in
VENDORS ORIGINAL as “Supporting Documents” under Enclosures item “C”.
3.2 Resource Plan (optional)

A resource plan can be used in consultancy like proposals where the exact
location of consultants is important.
This can be used as an alternative to a deliverables-based Scope specification

outlined above.
Discuss the resource plan as agreed with the Customer during the negotiation
phase.
Example text below:
Delete this text

The location in which the activities described in the Scope of Work will be
performed according to this proposal is the country of ………..text to be
provided for country or countries…….
Ericsson will provide the necessary expertise to execute the Scope of Work in
accordance with the stated time plan, subject to the terms and conditions of
this proposal. Should Ericsson for any reason need to exchange any of the
Consultants nominated, the replacement shall have similar experience and
knowledge.
The location for each Consultant’s work to be performed (Site) shall be:
Name of Consultant Full address (including country) of

location where such Consultant’s work
is to be performed
3.3 Work Breakdown structure [optional]

A high level WBS can be provided in a proposal in some cases.
(Typically WBS Level 1 and 2 – the EXTERNAL view)
But be restrictive with this detail. Consider that the WBS primarily is our
internal planning tool and may reveal too much information.
It may be wise to save it to use during negotiations, if we come that far.
3.4 Requirements
Describe the basis for the specification of requirements, previous
investigations, customers RFQ and any assumptions.
All requirements, also those taken from a RFP or SoC should always be
defined by Ericsson and in our Requirements Specification format. The RS
should be included in or attached to the Statement of Work. This in order to
keep requirements strictly organised and “tagged” (numbered).
A good solid specification of the requirements is instrumental to define and

argue at a later stage what is within the agreed scope and what is not.
Note regarding compliance statements (SoC) to the customer’s stated

requirements in an RFP:

Avoid direct references to or inclusion of a Statement of Compliance (SoC) in

our proposal. Conflicts between SoC statements and Statement of Work or
Requirement Specifications are common and very difficult to manage. Key to
secure consistency is to use our standard proposal and contract
documentation (the contract appendices) as base. SoC replies have to be
clear and unambiguous.
Only use SoC when it is required in an RFP. The reply (the SoC) can be done
in such a way that we take control of the requirements. The recommended
approach is to take the pain to restate and re-phrase the requirements in our
format in one document – the Requirements Specification. The SoC replies
can be phrased “Yes, complied, as specified in the attached Requirement
Specification, Statement of Work, etc
That way we can turn it around in the next stage, asking the customer to
commit/sign to “the full and complete requirements”.
Contractually (in the model agreements) these requirements are defined as

the “Agreed Requirements”
Ericsson standard terms and conditions (IPA) should be the base when
answering the “commercial SoC”.
Delete this text
This proposal is based on Ericsson’s current understanding of the needs and

requirements of Customer………based on the Customer Requirements
provided in Customers requirements specification (document reference). …
and the requirement identified in workshops and documented in (document
reference, e.g. to MoM)…
The Requirements provided by Customer are listed in the Requirement

Specification included in …..[Appendix 1 - Statement of Work or Annex 1 to
Statement of Work].
Subject to the terms of this proposal the Requirement Specification will be

updated [… following the completion of the relevant Analysis and Specification
phase (-s), Pre-Studies and/ or work-packages as the case may be] and
subsequent approval of the requirements.
3.4.1 Further Specification of Requirements (Analysis and Specification

phase)
Describe how we will work to assist the Customer to establish the needs and
specify the requirements to the necessary detail. Here is where we can
describe the benefit and purpose of the Analysis and Specification phase.
Delete this text

The initial project activity is an Analysis and Specification phase to closely

examine the requirements & solution. This study will produce a detailed
specification of requirements. Based on this document it is assumed that the
parties will engage in further joint work to specify the full detail of the Project
and hence that the final specifications of the Project scope and the Project
Requirements will be developed in detail. It is also a prerequisite that both
Ericsson and Customer approve all relevant specifications of requirements
before the project is allowed to continue into the realisation phase.
3.5 Excluded
Define specific major exclusions. As a principle work results, or items that are
not explicitly listed in the Statement of Work or in the “Detailed Prices and
Quantities”, are “out of scope”. But in order to avoid misunderstanding use this
section to clarify. We can also use this section to specifically point out things
the customer must arrange (with the risk we forgot something):
This section may not be needed if the section “Prerequisites and assumptions”
is fully clear on the subject. Delete this text
Example:
To avoid any misunderstanding please note that the following items

[hardware, software, integration, adaptations, upgrades etc…], are not
included in Ericsson’s proposal:
 Analysis and clean up of Customers current database and the

migration of historical data to…..
 No separate test or lab system is included since the Customer is

assumed to provide all test equipment and facilities needed in order to
verify the XXX…..outside the live environment.
 In building local data networks (LAN)
 Local transport of goods from place of delivery to……
The above is a non-exhaustive list based on Ericssons current understanding.

According to the best judgement of Ericsson the above-mentioned items are
pre-requisites for the execution of the proposed project and for the correct
[operation / integration] of the solution. These items fall under Customers own
responsibility and Ericsson’s deliveries under this proposal are conditional on
their presence and/or operation.

3.6 Prerequisites, assumptions and Limitations

Assumptions and prerequisites that have been identified during the
preparation of this proposal are listed in their context, and in particular in the
Statement of Work (Appendix 1). It is however assumed that the parties will
engage in further joint work to validate all assumptions and specify the full
detail of the Project and the complete list of prerequisites and limitations prior
to the signing of the agreement.
3.7 Responsibility matrix

An integration project requires Customer and Ericsson organisations to co-
operate closely in a many ways to ensure the correct & efficient execution of
the project.
Ericsson believes it is in our mutual interest to clearly specify each party’s

responsibilities and describe the dependencies between the Parties. Therefore
this proposal includes a Responsibility Matrix that shall be part of the project
agreement. A preliminary version of the responsibility Matrix is enclosed
(Appendix 2).
4 Main milestones and project phases

Describe on reasonably high level how we propose to perform the project,
when in sequential order we will reach key objectives / milestones.
Show that we have a good understanding of customers needs in terms of

Priorities and time. A more detailed description of the project will developed
later and included in the Statement of Work as well as in a separate Time
Schedule/Milestone Plan. See standard SoW (Appendix 1) template for a
more detailed example that also includes a WBS).
Keep in mind also the connection between the milestone layout and the
payment schedule, which impacts cash flow.
Delete this text
Example:
Ericsson suggests that [project in X] will be executed in phases, starting with

an analysis and specification phase (pre study) phase where the detailed
requirements and project scope will be established. This activity is estimated
to take [Z weeks to complete]. The total project is currently estimated to run
over XX weeks, but the final dates will be established after the conclusion of
the analysis phase. The project outline is illustrated below (time durations are
indicative only).

Figure 1 – Project Outline
4.1 Total Project overview

Example of possible headings to structure this section:
4.2 Project Milestones
4.3 Project Planning

Describe how and when Ericsson will deliver the detailed planning (if we want
to commit to doing that)
5 Prices
State if prices are indicative or “fixed and firm”. Describe what the price covers
and what may be extras. Depending on where in the sales/ negotiation
process you are, you may want to define a fixed price or express it as an
“estimate” or budgetary quote.

5.1 Estimated project investment

Example
The quoted price includes the scope of work estimated as specified in this
proposal. The daily rates offered are based on the assumption that the project
can be planned to allow Ericsson to use local resources from COUNTRY. If
this cannot be achieved these daily rates may need to be modified. As agreed
in our mutual discussions this also requires that the project will be ordered no
later than 2012-xx-xx. All charges will be on time and materials based on the
rates quoted unless explicitly stated as fixed price herein.
The total estimated investment based on these conditions is EUR XXX.XXX.
5.2 Agreement on project price

This section naturally has to be adapted to the type of proposal and tendering
situation – formal open RFP response, “unsolicited bid”, closed negotiations
etc.
The text example is based on the assumption that further specification work is
necessary, which is typically the case for CSI projects.
Ericsson is prepared to commit to a fixed price for the Analysis and

Specification phase (Phase 1) after the successful completion of the
[……….including the 3 planned workshops……] and subsequent agreement of
the scope. Correspondingly, Ericsson is prepared to offer a fixed price for
project Phase 2 following the completion of Phase 1 when the Statement of
Work and the Requirements Specification has been agreed.
Phase 3 will however, due to the nature and risks, which have been discussed
extensively, only be offered on time and materials.
A price breakdown for the major project phases and the detailed prices for
Hardware and Software are provided in Appendix 3 (Detailed Prices and
Quantities).
In case that a fix price is offered or intended to be part of the contract for work
or software or hardware items, ensure that the following text is included:
However this detailed prices breakdown shall not be interpreted as a price list
of separately orderable items. Project work offered at fixed price or items that
are part of a system or part of a fix scope of work may only be ordered as a
complete entity (all items included). Only items that are expressly listed in this
proposal as priced on time and materials and listed with per item prices (in the
Detailed Prices and Quantities appendix) may be ordered separately.
Project expenses
In addition to the Agreed Price, Customer shall reimburse Ericsson’s verified

project expenses [as further defined in Appendix 5 (Travel and Expenses)].

5.3 Additional work

Any out of scope items, additional work (unless solely caused by Ericsson)
and waiting time will be charged to the customer at Ericsson’s current daily
rates for time and material.
6 Acceptance and terms of delivery

Ericsson standard Acceptance Procedure applies for this proposal (enclosed
as Appendix 6).
Deliveries of Software and Hardware will be completed upon successful

completion of delivery inspection on [insert named place of destination /place
of delivery] or as further defined in Appendix B (general terms and conditions).
Integration Services shall be deemed accepted upon successful completion of

the relevant service required for the Milestone in question as laid out in the
Time Schedule and in the Acceptance Criteria provided by Ericsson.
Title (ownership) to Hardware shall pass to Customer only upon receipt of full
payment to Ericsson. Title to Software and Documentation shall remain with
Ericsson or as applicable with the original IPR owner and Licensor (as further
defined in separate list of 3rd party Software to be attached to the contract).
7 Project management and Governance

The parties shall agree on the details of the project organisation and the
escalation procedure as outlined in the Statement of Work (Appendix 1) and in
the Integration Project Model Agreement (Enclosure B) to be completed and
made part of the Project Agreement. The Parties shall provide named persons
for all key roles.
8 Handling of Changed Requirements
8.1 Change Control Procedure

Either Party may initiate changes to the project by issuing Change Requests.
In such cases the Parties will follow a formal procedure for all changes to the
scope of delivery including changes to Integration Services, Software or
Hardware. The principles are illustrated in Figure 2 below. Change Request
(CR) are initiated by the authorised representative of either party (normally the
project or program manager) and provided to the other party in form of a
formal document.

Figure 2 - Change Control Procedure.
The detailed Change Control procedure is described in IPA Appendix 8

(Change Control procedure) and the relevant sections of the standard terms
and conditions (Integration Project Agreement terms and conditions
(Enclosure B).
9 Time Schedule
The proposed schedule is included as Appendix 7 (Time Schedule) including
major milestones for which both Ericsson and Customer are responsible.
Commencement date will be dependent on final agreement and acceptance

by Customer. The start date will be negotiated and defined in the project
Agreement to be negotiated. Note that there may be several weeks lead-time
from the Agreement becoming effective before any of the work specified can
commence.
All dates are therefore indicative until the project is further specified and an
Agreement is signed (and where applicable Purchase Orders placed and
accepted) so that resources can be secured and Software and Hardware
ordered.
10 Customer’s obligations
Please consult the IPA and its appendices (in particular the Responsibility
Matrix) for lists of typical and mandatory obligations. Customer’s obligations
should be clearly stated in the proposal. They can be listed here, in a separate
Responsibility Matrix, or in the Statement of Work. List only those obligations
that are specific to this proposal and project.

Some obligations are “general” – for example the obligations related to the
Warranty as defined in the Integration Project Model Agreement (Enclosure
B). Don’t restate those.
11 Solution Life Cycle Management and

support
Include an appropriate “selling” text. Solution Life Cycle Management and
support service are key components of CSI engagement. The services are
necessary to ensure continuity in the customer engagement and to future
proof the solution.
Make the appropriate references to the services included in the offered scope
of project (preparation work packages detailed in the Statement of Work), as
well as scope of the Solution Life Cycle Management to be provided after the
integration project is completed
Note that Solution Life Cycle Management shall be contracted separately from
the project. S-LCM is covered by a Support Services contract applying a
subscription type price and payment model. The base should be Ericsson
standard Support Services model agreement. Refer to Ericsson Product
Catalog for further information.
12 Terms and Conditions

The terms and conditions, including the definitions, in the enclosed standard
Integration Project Agreement, enclosed as “Enclosure B”, shall apply for this
proposal, unless otherwise explicitly stated in this proposal.
In case of inconsistencies or contradictions the provisions of this proposal

main body shall prevail over the provisions of the appendices unless and to
the extent it can be demonstrated that it was otherwise obviously intended by
the Parties. The appendices shall prevail between themselves in the order
listed.
Solution Life Cycle Management and support services are subject to the terms
of Ericsson’s standard Support Services Agreement [or insert name of the
appropriate support services agreement] and the Solution Life Cycle
Management Service Specifications enclosed (Appendix 12).
Normally it is sufficient, as it follows general practice, that the proposal main

body has precedence over the other documents.
However, there may under certain circumstances be of interest to highlight a

particular condition, where we want to be 100% clear that we wish to replace
any possibly conflicting terms.

Then it is recommended to enter a statement in this Section 12, under the

relevant heading, that explicitly overrules a conflicting statement either in a
previous agreement between the parties, or a condition in the model
agreement
Example:
“ ……..……the specific terms of payment listed herein below shall apply for
this proposal and replaces and supersedes:
a) any conflicting standard terms of the Integration Project Agreement, or
b) any other agreement between the parties or
c) any previous proposals issued
12.1 Price conditions

Instruction: Please note and read the full Price Conditions in IPA Appendix 3
and Terms of Payment and Invoicing in IPA Appendix 4. The below terms are
a short version of those.
For further guidance on Incoterms (related to VAT), please refer to the

following Group Instruction:
http://anon.ericsson.se/eridoc/erl/objectId/09004cff804687a9?
action=approved&format=msw8
Delete comment
Example:
The prices given in this proposal are in Euro (EUR) unless otherwise stated.
Prices for Hardware, Software and Documentation are valid DAP (Delivery at
Place) to [insert named place and country, e.g. the port of entry / the Site] or, if
not delivered to [the port of entry / the Site], the destination agreed between
the Parties in writing in accordance with INCOTERMS 2010.
The prices and fees quoted in this proposal represent the net amounts to be
received by Ericsson and subject to the Terms of delivery (INCOTERMS) do
not include any current or future customs duties or taxes, such as sales tax,
VAT and similar taxes, or any withholding taxes that may apply.
12.1.1 Man-hour rates [optional]
Instruction:
Manhour or daily rates are common for consulting contracts and basics in any
Time & materials type of contract. Predefined rates can also simplify change
order handling, but also has a drawback from price negotiation perspective if
the customer intends to sign a fix price contract.

Some customers require that rates are presented.
So whether to include or not include rates is a matter of the type and size of
deal and the negotiation tactics.
The current prevailing rates for resources are included in this document.
Ericsson reserves the right to review the rates for their resources according to
the prevailing rates at the relevant time. Ericsson will notify customer in
advance of any resource rate changes.
12.1.2 Expenses
Project expenses will be invoiced at actual cost incurred plus administrative

charges.
12.2 Terms of Payment

Note: IPA Appendix 4 (Terms of Payment and Invoicing) contains
comprehensive guidelines and alternatives.
In proposals the payment terms are sometimes simplified in wording and less
detailed. Here are many ways and styles to do this. An example with
somewhat simplified wording and style is provided below. Note that the
example contains some “room for negotiation” in comparison to the IPA and
the Sales Directive (RSI and Group/BU directives).
Any deviations compared to the Sales Directives and the model agreement is
to be handled in accordance with RSI escalation directives.
Payment shall be made as further specified in this offer an otherwise as

specified in Enclosure B (standard terms and conditions) and Appendix 4
(Terms of Payment and Invoicing).
Advance payments shall be paid within 7 days of concluding a binding

agreement based on this proposal. All other payments are due within thirty
(30) days from the date of Ericsson’s invoice. Overdue payments are subject
to interest, chargeable on a pro-rata basis on the unpaid balance for each day
of delay, at [one per cent (1%) per month on the amount of delayed
payment /…. alternatively use a reference rate such as…. “at an annual rate of
EURIBOR 90 days plus 8 per cent (8%) per year calculated on the delayed
amount]
In the event of a deemed acceptance event Ericsson will invoice and

Customer shall pay remaining fees and charges not previously paid by
Customer up to full and final payment of the contract including any additional
orders.

12.2.1 Project and consulting services on current account and/or without

milestone plan
Services delivered on current account (priced at time and materials) or without

agreed payment milestone plan will be invoiced:
a Monthly in arrears based on actual progress or upon completion if

earlier, or
b Based on monthly instalments at a pro rata share of the agreed

price for the services or at amounts agreed in advance.
Guideline: Can be applied for projects at fixed price as well as when “time &
materials” pricing is applied. In particular it is useful for
a) simple projects as it requires no milestone plan,
b) as fall back, and
c) to allow invoicing of waiting time or other services where the formal

agreement or order may be unclear.
Amounts less any previously paid associated advance payment.
Delete this text.
12.2.2 Project Services at fixed prices and agreed milestones
Services with agreed Milestone Plan will be invoiced and paid by installments
according to the agreed milestone plan and based on the agreed prices
(including as applicable the price for any additional orders):
a An advance payment of 20 percent (20%) of the Contract Value and

Twenty percent (20%) per cent of the value of orders following an agreed
change according to the Change Control procedure.
b Seventy percent (70%) upon service completion as defined by the relevant

Acceptance Milestone, Schedule or Milestone Plan, or as applicable other
agreed Invoice Triggers (Provisional Acceptance)
c Ten percent (10%) upon final acceptance or taking the project result or
part thereof into commercial operation [This is optional - note that 10% is
the maximum allowed. Else increase the advance payment and/or
milestone payment percentage].
12.2.3 Training Services
Training fees are payable in advance and will be invoiced upon ordering or as
applicable upon confirmation of booking.

12.2.4 Software, Hardware and documentation
The percentages should be adapted to the product mix, mix between standard
SW, custom SW, 3PP vs Ericsson products etc. Alternatively use separate
terms according to examples below to manage cash flow and risk exposure.
See Guidelines in Appendix 4 and in Sales Directive and RSI
 30 % advance payment on Contract Signature

 70 % on delivery (place defined by INCOTERMS) or as applicable when
software licenses are delivered whether by physical media, remotely
installed or activated.
12.2.5 Customised Software [optional]
If this portion is of substantial size and means substantial risk exposure, you
may want to secure a larger advance payment. Else use the same as for
standard SW
Example:
 50% advance payment on Contract signature /order

 35% on functional acceptance
 15% on system acceptance.
12.2.6 Third party Software and Hardware [optional]
If the 3PP portion is of substantial size, has low margin or means substantial
risk exposure, you can argue for payment on ordering. Else use same
payment as for general SW.
 100% payable upon Contract signature /order of products
12.2.7 Software Capacity and software usage fees
Ericsson will invoice one hundred percent (100%) of the price for usage fees,
and for additional licenses based on contract, purchase order or actually used
capacity whichever is the greatest from the date of software license delivery or
from the date a license limit is exceeded.
Additional software licenses means any type of usage or capacity related

license fees such as license for users, subscribers, processors, computers,
sites, processing capacity, or data throughput.

12.2.8 Solution Life Cycle Management and Support services
Solution Life Cycle Management and System Support services are annual
service contracts that are invoiced and due for payment quarterly in advance
with [twenty-five (25) per cent] of the annual fee.
12.2.9 Expenses
Expenses will be invoiced monthly in arrears.
12.2.10 Mode of payment
Instruction:
This section shall be reviewed by the CU finance controller.
Using documentary credits is the preferred method to settle payments unless

the Customer’s ability, willingness and promptness in paying are well proven.
Further details are found in the corporate (LME) finance directive regarding
this matter (contact LME Trade Finance). For some countries (listed by Trade
finance) it is mandatory to use Documentary Credits.
See Appendix 4 (terms of Payment and Invoicing) and Appendix 11

(guidelines for Payment guarantees) for further guidelines and links.
Delete this text.
Payments, except for the advance payment [TBD depending on whether the
advance payment as per above is covered by a documentary credit or not],
shall be made through and covered by an irrevocable documentary credit in
favour of Ericsson.
The documentary credit shall be opened by Customer, with a bank of

international standing approved by Ericsson, not later than [thirty (30)] days
after date of contract signature. The documentary credit shall be payable at
sight and confirmed with a bank stipulated by Ericsson. The documentary
credit shall be valid until all payments have been effected. Customer shall
bear all costs for the documentary credit.
12.3 Validity
This proposal remains valid until <date>.
12.4 Acceptance of Proposal

Acceptance of this proposal is expressly limited to the terms stated herein
below.

This proposal assumes that <Customer> and Ericsson shall enter into a
contract which is based on this proposal and subject to Ericsson's customary
terms for integration project agreements enclosed (Enclosure B1 – Integration
Project Model Agreement), and as applicable for Solution Life Cycle
Management services based on the enclosed Ericsson standard Support
Services Agreement (Enclosure B2 – Support Services Agreement).
Such agreements referred to above shall become the exclusive and binding
agreement between Ericsson and Customer for Customers purchase and
Ericsson’s delivery of the Software, Hardware, Integration Services and
support services (as applicable) when confirmed in writing by both Parties
authorised signatories.
12.5 License
The Software and Documentation is offered a under a non-exclusive, non-
transferable, non-sub-licensable, restricted license to use for <Customer>'s
own operation and maintenance and in accordance with the terms and
conditions of Ericsson’s standard Integration Project Model Agreement
(enclosure B) and as the case may be any specific conditions regarding
software from third party as may be included in this proposal, subject to
contract.
Customer shall report actual capacity related licenses to Ericsson on regular

basis and unless otherwise agreed every 6 months. Notwithstanding
Customer’s obligation to report actual usage Ericsson shall be entitled to
collect any information as it deems necessary to determine actual used
capacity, including but not limited to making own measurements, make on-site
audits or by requesting Customer to make measurements.
Should Customer fail to provide requested information on actual usage

reasonably asked for by Ericsson, or Ericsson is hindered to make
measurements Ericsson will at its sole discretion determine the usage or
capacity level to be applied for licence fee purposes.
12.6 Warranty
The Hardware and the Software included in this proposal will be warranted in
accordance with the terms of warranty further specified in the Integration
Project Model Agreement (enclosure B). Subject to contract, the warranty
period for the Hardware and Spare Parts is twelve (12) months and for the
Software three (3) months from the Date of delivery, Date of Acceptance or
when the Hardware, Spare Parts or the Software is put into commercial
service, whichever comes first. Specific warranty conditions may apply for
third party Hardware or Software as further defined in Appendix 9 and subject
to the contract.

12.7 Language
The English language will be used as the default language for the deliverables
and for all communication in relation to the offered Integration Services,
Hardware and Software. For clarity this includes but is not limited to hardcopy
and softcopy documentation, manuals, software and hardware user interfaces,
unless otherwise explicitly stated in Ericsson’s specifications or agreed in
writing in the Agreed Requirements.
12.8 Working day

One working day equals 8 hours during business days in the [Insert Ericsson
base Location (Country) or local base as desired}. The working hours for any
work undertaken outside regular office hours and business days shall be
agreed in advance between the Project Managers and may upon Ericsson’s
request be subject to overtime charges.
12.9 Limitation of Liability

This proposal is subject to relief of liability in the case an export license or
other required approval is not granted by the competent authority or by a force
majeure or other circumstances outside of Ericsson’s control.
<Customer> is hereby informed that <Customer> is required to obtain the

necessary authorizations and licenses for the use and operation of systems
and any Software, which is not explicitly included in the proposal but may be
required for the Customer’s lawful operation and use of systems or Software.
It is also the responsibility of Customer to obtain the appropriate import
licenses.
Notwithstanding anything to the contrary stated in this proposal or otherwise

and to the extent permitted by applicable law, in no event shall Ericsson be
liable (i) for incidental, indirect, special, exemplary, punitive or consequential
damages, nor (ii) for loss of use or data, or production or business or market
share, or lost profits, savings or revenues of any kind or any other economic
loss (whether direct, indirect or consequential); even if such party has been
advised of the possibility of such damages and whether or not the possibility of
such damages could have been reasonably foreseen.
12.10 Confidential Information

This proposal and all related information and documents, including but not
limited to drawings, samples or other data, machinery and special test
equipment of any kind, furnished by Ericsson shall be treated as Confidential
Information and shall remain Ericsson’s property and shall be returned upon
request. Upon Ericsson’s request Customer and Ericsson shall enter into a
mutual Non-Disclosure Agreement promptly upon Customer’s accept of this
proposal or upon start of contract negotiations, as the case may be.

12.11 Assignment
This proposal and any right or obligations hereunder may not be assigned
without the prior written consent of Ericsson. Any purported assignment
without such consent is void.
12.12 Governing law and Arbitration

To be adjusted by each Region/ Customer Unit, subject to Region Legal
decision.
Unless otherwise agreed in writing the [laws of Sweden] shall govern the
construction and interpretation of this proposal and all related agreements and
documents concluded pursuant thereto. Any dispute, controversy or claim
arising out of or in connection with this proposal, or the breach, termination or
invalidity thereof and all related agreements and documents shall be finally
settled by arbitration under the [Rules of Arbitration of the International
Chamber of Commerce, in Stockholm, by three (3) arbitrators appointed in
accordance with the said Rules. The proceedings shall be conducted in the
English language] and shall together with all related documentation be kept
confidential.
-------------------------------
Enclosures:
A. Project details and specifications
Numbering of appendices follow the standard Ericsson Integration Project

Model Agreement (appendix 1-11) and should for ease of work be kept intact.
Change will generate much additional work. If an appendix is not used in the
proposal, note instead “not used”.
M = Shall always be part of the proposal, however some of the appendix

documents could be omitted e.g. in small proposal if the content instead is
inserted directly into the Proposal main body
O = Optional
For further guidance read the instructions in each of the IPA appendices.
Name of Document Doc No / Note:

version
Appendix 1 – Statement of Work M
Annex 1 to Appendix 1 – Requirement M (separate

Specification document, part of

technical
specifications
document or
included in the
SoW)
Annex 2 to Appendix 1 – Solution O (see notes

Description (High level technical design below and in
or similar) chapter 2.1)
Appendix 2 – Responsibility Matrix M
Appendix 3 – Prices, including Annex 1 M

detailed Prices and Quantities
Appendix 4 – Terms of Payment and M

Invoicing
Appendix 5 – Travel and Expenses M
Appendix 6 – Acceptance Procedure M
Annex 6.1 - Acceptance Criteria M
Appendix 7 – Time Schedule M
Appendix 8 – Change Control procedure M
Appendix 9 – Conditions for Third Party M (if any 3PP)

Products
Appendix 10 - Direct Licensed Software O (depends on

licensing model
used)
Appendix 11 – Templates for Payment O

Guarantees
Appendix 12 – Ericsson terms and M

conditions for Support and Life Cycle
Management services, incl. annexes Unless in separate
proposal or already
existing in a relevant
and valid Support
Services frame
agreement with
Customer
B. General terms and conditions
B1 Ericsson Integration Project Model Agreement (IPA)
B2 Ericsson standard Support Services Agreement

Enclose the relevant model agreement templates in “clean” version
C. Supporting Documents
Examples only
Note in particular that the Solution Description (SoD) or similar can either be
attached as Annex 2 to the SoW, or attached as a “supporting document”.
There is a vital difference:
 An attachment in section A is a firm specification describing exactly what is

covered by the proposal scope and the price.
 If the SoD is a generic description (from the Product Catalog or similar) it

must not be base for firm commitments. Such a “standard SoD”
documents is not precise enough and also typically contains product
marketing terminology that is unsuitable for firm contracts.
See further instructions and the “disclaimer” text in Chapter 2.1
1. Solution Description: Ericsson Convergent Charging Solution, date/ rev

xxxx, Doc nr xxxxxxxx
2. Product Description: Ericsson Multi Mediation, , Document nr xxxx
3. NNN software – Company name, an overview description……
4. Service Description: Solution Life Cycle Management, date/ rev xxxx,

Document nr xxxx


IPA Proposal Template

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPA Proposal Template

Uploaded by

Copyright:

Available Formats

Integration Project Proposal template

Tips when using this template:

EAB-09:028662 Uen Rev C

Company Name Telephone

Proprietary nature of proposal

Note on Confidentiality: Although this document has “Confidential” status, this

This Proposal or parts thereof may not be reproduced or transmitted in any

EAB-09:028662 Uen Rev C 2013-06-05  Ericsson AB 2012 2 (30)

Guidelines to the user of this document:

Text in green colour is specially marked since it is to be considered as

Follow the instructions incorporated in the model agreement documents.

The model agreement documents must under no circumstances be provided

EAB-09:028662 Uen Rev C 2013-06-05  Ericsson AB 2012 3 (30)

3 Proposed project scope / project deliverables..........................8

4 Main milestones and project phases........................................15

6 Acceptance and terms of delivery.............................................18

7 Project management and Governance......................................18

8 Handling of Changed Requirements.........................................18

11 Solution Life Cycle Management and support.........................20

12 Terms and Conditions...................................................................20

1 Executive Summary / Introduction

In larger proposals the Executive Summary is often a separate document.

EAB-09:028662 Uen Rev C 2013-06-05  Ericsson AB 2012 4 (30)

 Restate and confirm what has been discussed - What is the

 Show that we understand the customer’s situation and main concerns

 How it will be done

 There is no universal recipe for the executive summary.

 We recommend that the Executive Summary is written according to

 It must be based on the analysis of the customer and competitor

 NEVER make an executive summary by cutting & pasting phrases

Delete this text

EAB-09:028662 Uen Rev C 2013-06-05  Ericsson AB 2012 5 (30)

Who is the initiator?

What are the reasons for the project?

Any relevance to previous projects or proceeding studies, consultancy,

Delete this text

1.2 Partnership [optional]

Normal 3rd party suppliers or subcontractors are not mentioned here.

Delete this text

It is very important to understand that the specification of Ericsson’s delivery is

2.1 Solution overview

 Try to visualise the end result.

EAB-09:028662 Uen Rev C 2013-06-05  Ericsson AB 2012 6 (30)

 Show that we understand the customer’s situation – i.e. describe

 Keep it relatively short and on high level

 Information should be aligned with Solution Description (SoD), if one is

 Don’t make this a “system specification” chapter

Later, as we enter a contract negotiation and start working the detailed

If the proposal includes a separate Solution Description document (in this

Always keep in mind that it is the Statement of Work including a Requirement

Delete this text

EAB-09:028662 Uen Rev C 2013-06-05  Ericsson AB 2012 7 (30)

2.2 Ericsson experience

2.3 Ericsson’s project approach

Mention something about our Quality Assurance, project Management model,

Program Management can be a highly selling point for larger projects.

Delete this text

2.3.1 Project team (optional)

3 Proposed project scope / project

This section is intended to contain a comprehensive description of the project,

EAB-09:028662 Uen Rev C 2013-06-05  Ericsson AB 2012 8 (30)

Depending on situation (i.e. the background, the complexity of project, how

Delete this text