Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

POM > Lecture 7: Contracting > Flashcards

Lecture 7: Contracting Flashcards

1
Q

Contracting in the Project Life Cycle

A

How does contracting work?!

  • • Part of the project preparation
  • • Procurement, acquisition, “ and bidding procedures

Acquisition and bidding!

  • • Can be very formal, incl. rigorous evaluation and selection processes, i.e. in the context of public sector/ government projects
  • • Don’t underestimate!

Critical:

  • Price-performance ratio
  • Good estimations
  • Good calculations
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Contracting in the Project Life Cycle: Interaction (1)

A

Key concept (adopted from” V-Modell® XT)

A Decision Gate:

  • • Milestone and Quality Gate
  • • Requires completed work products to determine project progress
  • • A project plan (coarse grained) is a sequence of decision gates

Client Project

  • • Get a system
  • • Often: Waterfall-like

Contractor Project

  • Build a system
  • “Flexible” approach
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Contracting in the project life cycle: Formal style

A

The formal style…!

As part of the project preparation, procurement, acquisition, and bidding procedures are implemented to conclude a contract…

Example: formal process from

V-Modell® XT!

Note: Although much rules, definitions, and guidelines are part of the V-Modell XT, activities for acquisition and predevelopment etc. are”

not part of the V-Modell XT…

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Contracting in the Project Life Cycle: Roles (1)

A
  • Procurement, acquisition and bidding –> Project Roles
  • Client (also: Customer, Purchaser, “Contracting Entity)
    • Define initial requirements
    • Request proposal(s)
    • Monitor (proposal) projects
    • Acceptance testing
  • Contractor (also: Supplier)
    • Submit offers (bidding)
    • Ship results (softwareàconcrete “ deliverable, services)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

How to agree on an internal project without a contract

A
  • informal agreement
  • formal agreement
  • cross-unit collaboration
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Influence Factors

A
  • Main influence factors:
    • Goals
    • Business Case
    • Initial estimations
    • Legal restrictions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Influence Factors: Contract Content

A

What’s in a contract?

  • Services and responsibilities, incl.
    • Functional requirements
    • Deadlines (incl. procedures for delays)
    • Quality requirements (non-functional requirements)
    • Price and payment schedule
    • Acceptance
  • Warranty and liability
  • Provisions
  • Copyrights
  • Regulations and standards, compliance

Project context variables and formal legal requirements need to be balanced in order to create an environment for the project

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Basic Procedures

A
  • A project (usually) starts with a dialog (acquisition J)…
  • Acquisition strategies:
    • Pro-active
    • Re-active
    • Client request/request for an offer
    • Call for bids/submission
  • Regardless of the strategy, a project needs preparation
  • Practice: plan the offer’s development as a project; for this:
    • Procedure 1: Prepare Offer
    • Procedure 2: Develop / Submit Offer
    • Procedure 3: acceptance of the system under development
  • Note: A contract is always concluded based on the accepted offer!
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Basic Procedures: Overview

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Basic Procedures: Prepare the Offer

A
  1. Collect and complete information “ regarding the client
  2. Evaluate business value
  3. Conduct feasibility study
  4. Develop offer and sales strategy
  5. Estimate cost and effort
  6. Check resource availability
  7. Initial project planning
    1. Cost Plan
    2. Resource Plan
    3. Risk Analysis
    4. Scheduling (initial)
  8. Create proposal
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Basic Procedures: Develop the Offer

A
  1. Build proposal development team
  2. Develop proposal development strategy
  3. Develop and continuously improve proposal parts

a. Sales Parts
b. Economic Parts
c. Solution Parts
d. Contract Parts
4. Develop initial project plan
a. Project Plan
b. Effort and Cost
c. Resources

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Basic Procedures: Prepare Acceptance

A

Acceptance procedure should define!

    • Contractor: Shipping (incl. preparation)
    • Client: Acceptance test, incl.
      • Who is authorized to accept?
      • Formal or silent acceptance? (acceptance slot, “slot for correcting measures)
      • Partial delivery
      • Reporting

Don’t forget: Just in the contract, procedures for the system’s “ acceptance procedures have to be defined, incl.

    • Delivery dates (e.g., milestones)
    • Acceptance procedures

Why is this important? “
–> Acceptance always means a reversal of the burden of proof

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Basic Procedures: Prepare Acceptance

A
  • Acceptance tasks
    • Check for completeness: “Was everything shipped as expected?”
      • Basis: the contract
      • Further artifacts: additional agreements, change requests, management decisions
    • Verification of the project results: “Was the software developed right?”
    • Validation of the project results: “Was the right software developed?”
  • Problems in the acceptance phase!
    • Errors and bugs
    • Acceptance delays
    • Acceptance refusal
    • Acceptance with conditions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Legal Aspects

A

“A contract is really just a set of written playing rules” (Peter Stevens)

  • Content, responsibility, trust, and risk:
    • How is a contract structured?
    • What are the basic rules for delivering scope and invoicing revenue?
    • How is risk and reward shared between customer and contractor?
    • How are changing requirements handled?
    • What relationship model between contractor and client is implemented?
  • Two basic contract types, each addressing aforementioned questions slightly differently…
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Fixed Price

A
    • Subject: A System
    • Price is fix
    • Milestone-based progress definition
      • payment schedule
    • Low flexibility regarding changes”
      • formal change requests”
      • changes are expensive
    • Project risk is transferred to the contractor
    • Requires fully-specified system
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Time & Material

A
    • Subject: Resources and time
    • Price is based on actual effort
    • Feature-based progress definitionà not necessarily congruent with payment schedule
    • Open to change requestsà feedback and evaluation are welcome as long as the client pays for it J
    • Project risk is transferred to the client
    • Requirements can be under-specified
17
Q

Legal Aspects: Relationship Model (Fixed Price) - Client

A
    • Negotiation and contracting procedures are well known
    • Clients stick to waterfall process (e.g., public sector)
    • Client provides exact description of product –> fully-specified system
    • Contract ensures that the client gets the product as described “ –> client gets what they specifies, but not what they want
    • Low budget reliability
    • High cost risk (in-flexibility of CR’s and
  • learning curves)
    • Risk: max(System) for min(Price)
18
Q

Legal Aspects: Relationship Model (Fixed Price) - Contractor

A
  • Realizes project exactly as stated in requirements specification
  • Has a better perspective on project than customer (cf. “mining rights”)
  • Scope and status can be determined based on the requirements
  • Fixed price project is not realized for change”
    • –> Changes have impact on architecture/functionality”
    • –> Many contractors have adopted this as business (risk compensation) model “mining rights”
    • Risk: min(System) for max(Price)
19
Q

Legal Aspects: Relationship Model (Time & Material)

A
  • Goal: maximize valueàget a meaningful solution
  • Allocate resources as needed
  • Responsible for project success by

–> Providing feedback

–> Taking part in the project

  • The idea: one can exchange contractor during project (to prevent vendor dependencies)
  • Risk: contractor might increase effort (and cost) unnecessarily
  • Risk: contractor has no duty to ship a product
20
Q

Legal Aspects: Relationship Model (Time & Material) Contractor

A
  • Yield supplies as stated in contract (only requested resources are delivered)
  • Invoice as many person-days as possible (to make the project more expensive)
  • Make yourself irreplaceable
    • Risk: “client might refuse the price increase
21
Q

Legal Aspects: Relationship Model (Behavior)

A
  • In projects, project parties have interests (e.g., the system)
  • Interests are reflected in the behavior and the interaction strategy:
    • competitive (my win is your loss),
    • cooperative (win-win),
    • indifferent (I don’t care-you lose) or
    • dependent (heads-I-win-tails-you lose)
  • Contracts should be designed according to the “win-win” interaction strategy:
    • Fair contract
    • Allows for an open atmosphere in the project
  • The other strategies imply that one party outruns the other
22
Q

Practices (Overview)

A

Several practices exist to make contracts more “ flexible and to adopt agile methods, e.g.:

  • Maximum price
  • Change for free
  • Exit point/Money for nothing

… and combinations thereof

  • How to handle failure?
  • How can these practices help the design of the contract?
23
Q

Practices: Maximum Price

A
  • Idea: work according to time & material approach, but set a limit
  • For this:
    • Define and estimate the system
    • Define the max. price for the system
    • Define the cost (e.g., as a constant) per unit (e.g., story point)
24
Q

Practices: Change for Free

A
  • Idea: client is participating in the project all the time (on-site customer)
    • Gives continuously feedback
    • Has learning curves (better understands the system)
  • For this:
    • Allow the client to add features, but
    • Identify other features that that be removed/stalled
    • (opt.) Update the contract accordingly
  • Example: Given n features for a Sprint
    • Client decides to add a new feature x to the next Sprint
    • As compensation, a feature y is removed
    • Removal of y is mentioned in an updated contract
25
Q

Practices: Exit Points/Money for Nothing

A
  • Idea: define an approach in which a project can be stopped, but good performance is awarded
  • For this
    • Define exit points (when and under which conditions to stop a project)
    • Define payments to “compensate” or award early termination
  • Example (exit point): Given a project has 6 planned sprints
    • Exit point: initial phase = 2 sprints for n story points
    • Contractor is paid for 2 sprints à if no exit: whole project budget
    • If exit, contractor can demand compensation
  • Example (money for nothing): Given a project is finished early
  • § Contractor can be awarded with extra money, e.g., 10k for every month saved (practice often applied in construction projects)
26
Q

Combined Practices: “best of” = Agile Fixed Price (1)

A
  • Idea: combine fixed price and time & material, and other practices into a defined, but flexible contract
  • Example:
    • § Basic instrument: fixed price contract (maximum price)
    • § Work is done and paid according to time & material
    • § Exit points are defined (incl. cash flow, exit conditions)
    • § Money for nothing is implemented to award good performance
    • Note:
      • § These techniques focus on awards and achievements
      • § However, contracts also contain penalties for poor performance, etc.
27
Q

Downsides: agile fixed price

A

The agile fixed price contract is considered a good way to balance legal requirements and agile methods, however:

  • Agility says: be open to change
  • Change is critical, as changes may affect the functionality/quality of the system –> deviation from the contract
    • This can become an issue, as contract-relevant changes require a (formal) change request
    • If changes are not reflected in the contracts/project documentation, formally, the shipped software does not fulfill the (formal) requirements” àproject is a failure
28
Q

Combined Practices: “best of” = Agile Fixed Price Conclusion

A

The agile fixed price contract is considered a good way to balance legal requirements and agile methods

Agile fixed price is an option anyway, but:

  • Ensure a mature change management system is in place
  • An open and cooperative project atmosphere is required (trust)
  • Contract should define minimal (stable) requirements, and a set of exchangeable requirements
29
Q

How to handle failure

A
  • Practices: How to handle failure?
  • Recall: contracts also contain agreements regarding acceptance…
  • Contract-relevant failure in a project can occur for many reasons It is important to be prepared, for this:
    • Define Warranty: when do liability and damage compensation start?
    • Define Ownership: who owns the project results?
    • Define Copyright: who is authorized to publish and use project results?
    • Define Escalation: don’t go to court immediately; give mediation a chance…
30
Q

Contracting: Important to know… basics

A

Contracts define the basic rules of collaboration – they set the stage…

  • They define
    • Functionality/deliverables and their respective quality
    • Responsibilities
    • Time/Schedule
    • Money
  • Two basic types (defined and legally solid)
    • Fixed price
    • Time & material
  • Several additional practices exist to adopt flexibility and to reflect actual software development business (changing requirements, technology, etc.)
  • *
31
Q

Contracing: Important to know … What contracts are for? And, what not…

A
  • Contracts define the rules –> It’s not the goal to outrun the partner
  • Contracts need a balance (keyword: risk share)
  • Contracts need to be fair –> all participating parties have rights and duties
  • It’s good to have a contract, but:
    • In projects, talk about the system; not about paragraphs
    • In projects, open atmosphere is better than a legal skirmish
    • Name escalation authorities that are not lawyers
  • Don’t forget: A court case gives you justice, but no working software…
32
Q

Regarding the practices to embody contracts, the following statements apply

Select one or more:

a. Money for nothing is an incentive model awarding good performance
b. Maximum price is a means to better control the project budget by setting limits
c. The agile fixed price combines many proven practices thus fully replacing the classic fixed price

A

a, b

33
Q

For contracting parties, it is important to know

Select one or more:

a. There are always two parties (client and contractor) that have individual goals and approaches
b. Once the contract is concluded, contractors have to implement quality management procedures to meet all project goals defined in the iteration plan
c. Once the contract is concluded, clients just receive deliverables and confirm timely shipment

A

a

34
Q

Contracts, in general, define
Select one or more:
a. How quality requirements regarding real-time are implemented
b. The responsibilities of the respective contracting parties
c. The basic project parameters in terms of deliverables, schedule, and budget

A

b,c

35
Q

Select an interaction strategy that should guide contracting procedures as well as project operation in general to establish a fair set up

Select one or more:

a. Competitive (my win is your loss)
b. Cooperative (win-win)
c. Indifferent (I don’t care - you lose)

A

b

36
Q

For the different contract types, select the statements that apply

Select one or more:

a. Fixed-price contracts do not allow for defining any incentives
b. Fixed-price contracts are the option preferred by clients to minimize their project risk
c. Using a time & material contract, clients face the risk to never get a working system

A

b,c

37
Q

Select all acceptance-relevant aspects to be considered in contracts

Select one or more:

a. Verification of the project results (Was the software developed right?)
b. Check for completeness (Was everything shipped as expected?)
c. Validation of the project results (Was the right software developed?)

A

a,b,c

38
Q
A

POM (22 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions