Introduction to

Management in IT
Lecture 5

Contracts

Tomasz Bogucki
Sales process
B2C Passive sales

• AIDA Model

• T&C – terms and conditions

• Adhesion Contract
(prepared by seller only from the position of power – “take it or leave it”)

• Standard licenses
eg. Google Play Licensing
 Prospects
Sales process
B2B Active sales Follow up Collect info

7 stages
Close the
Find
deal, sign
approach
contract

Analyze
Handle
needs and
objections,
make
negotiate
proposal
Preparing proposals
• Develop an attractive template
• Main content: addressee, scope, price (& tax), time
• Obligatory: expiration date
• Good to include: company profile, reference list (or letters), additional options
• If asked for an offer, agree on when will it be prepared and do not be late
• After passing the offer contact the client, asking if everything is clear, are all
requirements covered and about his impression. Send corrections if needed.
• An accepted offer is legally binding!
• Decision making on the customer side may take time
Negotiations

• Prepare – predict questions and possible scenarios, have ready answers

• Customers are likely to demand price and time cuts, while increasing scope
• Justify price by detailing offer elements, listing difficulties, pointing out risks
• “Cheap – fast – good: you may choose only two”
• Customers will try to use your competition as a threat, it is essential to know your
advantages and chances of your competitors. They will most likely have a BAFTA ready
– “best alternative to a negotiated agreement”

• Don’t get upset, it’s a game

• Don’t be afraid to ask questions, identify people who support your offer
• “What is your budget?”
• “What do you like in the offer of our competitors?”
• “Which element is the most important for you?”
Negotiations - continued
• Under price pressure, find win-win solutions
• Instead of cutting the price, consider adding features (especially those, that do not
add cost), expertise, know-how
• Balance price elements: cheaper license but more expensive ongoing maintenance
and customizations
• Break the offer into parts (half now, second half in the future), pay-as-you-grow
• Transfer risk to customer (lower price, but if … happens, then customer covers costs)

• Always take notes and send current arrangements to all participants after
the meeting
• Negotiate the final price in only one attempt, after settling other price
influencing matters, and only with the person authorized to make decisions
• Negotiations may take time, especially with large companies. Be patient
but don’t lose contact
• Don’t give up
 Sales process of a product vs. cash flow
$
Marketing
Developing the
(reaching Selling Negotiations Contract Delivery
product
clients)

Early selling based only on a concept / prototype/ vaporware:

Marketing Developing
Selling Negotiations Contract Delivery
(reaching clients) the product

Always be honest with the

customer about the current
state of the product
$ Payment in
installments $ $
Contracts
• Have a contract template ready
• The contract should reflect the offer (including negotiated items)
• Although signing a contract is cheerful for both parties, it is wise to
have this perspective of the future:
• Agreements are written for cases of conflicts
• People change, the one accepting delivery at the end may not be
the same one who signed the order
• Priorities change, so do budgets
• Where money is engaged there are no friends
• The one who holds the money (customer) has a better position
than the one who bears the costs (developer)
• No deal is worth risking the company’s existence

• The rules of the civil law prevail

Subject of contracts
Most common in IT:
• License (for products)
• Subscription (for services / SaaS)
For custom software development per customer’s requirements:
• Fixed-term contract (scope/time/price)
• T&M (“time & material”) / agile
Mixed
• Licensed product + customization
Service and maintenance
Usual contract chapters X – yes, O – possible

Contract for Product Service Fixed-term custom Time and material

Chapters development development
Scope X X X -
Ownership/IP - - X
X
License X X -
Time schedule O O X O
Fee schedule X X X X
Change mgmt - - X -
Responsibilities X X X X
Acceptance procedure X X X -
Penalties X X X X
SLA X X X X
Non-disclosure O O X X
Communication X X X X
Termination X X X X
Scope
• This will be based on the requirements gathered before
• Refer to ‘attributes of good requirements’ in the presentation on Project Management

• Be sure to have 100% of the scope listed, that the items are unambiguous and
measurable
• Remember about non-functional requirements too
• Add what will NOT be done if there might be any doubt about it
• It’s not only about the product or service but ALSO OTHER DELIVERABLES / activities like:
• Documentation • Installation
• Training • Configuration
• Source codes? • Data migration
 Ownership vs. license and IP rights
These two possibilities are available when building custom software per customer requirements

Selling Ownership Selling a License

• Customer has full control of using the • Limited usage (eg. customer cannot resell, reverse
software, modifying, improving engineer, modify, use against the seller’s intention)
• Customer has all copyrights and owns • Copyright and intellectual property stays with
intellectual property (IP) developer (if not otherwise regulated by contract)
• Requires transfer of source codes and • Usually source codes are disclosed only in exceptional
technical documentation conditions
• Means exclusivity to all the results of • Allows the developer to resell the solution, in part or
the project full
• Exclusivity should cost more • Developer can lower price anticipating future sales
• Secures customer from competition • Customer can loose unique know-how to competition
• Cannot be terminated • Can be terminated
• Developer limits his future sales • Opportunity for developer to create a product offer
Licensing products
• Range of license - how the customer may/may not use the product, eg.
• Number of concurrent users
• Number of installations
• Sub-contracting to other companies

• Source codes – are they included and how they may be used, eg.
• Only in case of developer’s bankruptcy to secure bug fixing - ok
• Giving away development to a different software developer – bad

• The license for commercial use should be granted only upon payment
• This will save you from being left without payment, while the customer uses the product
Standard licenses
• Mention all open-source and 3rd party commercial licenses included in your solution
• Same goes to graphics, music, fonts, etc.
• Read these licenses before it is to late (before you include them in your product, before
you resell them to a client)
• Some open-sources or images are free only for non-commercial use
• Some licenses after binding codes require your solution to be free as well (copyleft)

• Publishing using a license system, eg.

• GNU GPL (General Public License)
• Google Play Licensing
• EUPL - European Union Public License
• Creative Commons License
Time schedule
• Schedule of project phases within time
• Covers the whole project, not only the period of programming
• Divided into milestones and versions
• Time reserves and deadlines
• Delays being the customer’s fault:
• should extend the schedule
• may be reimbursed
Fee schedule
• Payment
• All prices (and taxes)
• May be divided into installments

• Triggers – conditions that need to be met to release the payment, eg.

• Delivery of a version
• Passing tests
• Every 1000 subscribed end-users

• Payment deadlines (eg. within 1 week after payment condition met)

• Warrants – eg. 10% of contract value withheld until non-critical bugs fixed
• Maintenance fees
• Bugfixing / helpdesk / improvements
Change management
Within the life of a project often there comes a need to change requirements (scope)
It is easier to process such changes if the contract anticipates such situations
• Change management procedure
• Impact on time and budget – authorization to modify without signing a contract amendment
• Cost per man-day
• Good idea to provide (sell) a pool of man-days for unplanned work or changes
Responsibilities
It is important to list all responsibilities of the customer related to the project, such as:
• Providing know-how, documentation, expert advice
• Arranging test data
• Having an installation site complying with product requirements
• Answering developer’s questions and making decisions on given design options
• Executing tests according to schedule
Consequences of not delivering on time:
• Delaying schedule
• Covering costs
Acceptance procedure and quality factors
• Delivery checklist
• UAT – user acceptance tests
• What kind
• Test scenarios
• How long

• If the customer starts to commercially use the product, this should mean
unconditional acceptance
• Quality threshold – allowing the acceptance pass despite some defects, eg.:
Defect category Quantity admissible Fix deadline Payment withhold
Critical none - -
Standard 5 2 weeks 10% contract value
Minor 20 4 weeks 5% contract value
Penalties and liability
• Penalties - rather to motivate than to punish
• Usually for delay
• Should relate to both sides
• Good to have a grace period – eg. delays up to 2 weeks are not penalized
• Should be capped (max total fees) – eg. up to contract value
• Liability – covering customer’s losses resulting from product’s use
• Try to avoid all - difficult
• For sure avoid covering lost benefits (profits that have not been made)
• Always should be capped – eg. up to yearly revenue from maintenance
• Some cases cannot be excluded – based on the rules of civil law

• Never risk the companies existence by not capping fees and liability
SLA – Service Level Agreement
Conditions for maintenance (fixing and improving the product after delivery)
• Incidents (interruption of service) vs. problems (cause of incidents, eg. a bug)
• Incident management (restating operations) vs. problem management (bugfixing)
• Types of failures (eg. critical / standard / minor) with description
• Response times and guaranteed fix times
• Penalties for not complying with SLA, penalty caps (maximum values)
• Example:
Defect category Respose time Fix time Penalty for delay Max penalty/year
Critical 1 hour (24/7/365) 4 hours $100.000/case $500.000
Standard Same business day 2 weeks 1/12 of mntc fee Mntc fee value
Minor 1 week Next version 1% of mntc fee Mntc fee value
Non-disclosure and data privacy
Both parties commit not to release to the public any information acquired within the project, eg.:

Customer will not disclose information on: Developer will not disclose information on:
• The design of the software • Customer’s business model
• Algorithms • Know-how
• Weak points, bugs and incidents • Trade secrets: costs, prices, clients
• Contract prices and received discount • Internal infrastructure
• … • …

Enforced by penalties for each case of disclosure

Communication, persons responsible and their authority

• Who is responsible for executing the contract on both sides (developer

and customer) – project managers
• Binding decisions - rules for communication:
• E-mails or project tracking software (always written form)
• List of authorized people and their backups
• Authorization levels (eg. up to $100.000 / above)

• Escalation rules (in cases of dispute)

Contract termination - if things go wrong
• Last chance recovery program (eg. 4 weeks from formal
notification)
• How to resolve the contract in case of project failure
• Customer gives back everything that was delivered
• Developer gives back any payments received
• Avoid additional penalties. The uncovered costs are painful enough

• If the blame is exclusively on the customer

• Customer covers all costs, developer may withhold all received
payments
• Possible contract penalty

• Contracts can be changed by mutually agreed amendments