IBM Software Group

1
IBM Software Group
Proposals and Statements of Work Gordon Lee
2
Agenda

• Why learn how to do proposals?
• In the workplace
• For this course
• Exercise 1
• 2 teams, build your first Statement of Work
• Review
• Exercise 2
• 2 teams, build your second Statement of Work
• Review
• Lecture
• Business Integration Projects
• Different components of a Statement of Work
• Exercise 3 (optional)
• 2 teams, build your third Statement of Work

Acknowledgements Patricia Oberndorf, Carnegie
Melon Software Engineering Institute
3
Why is this lecture included in the curriculum?

• Real world content
• The Apprentice 3rd season Booksmart v
  Streetsmart
• What you learn in school vs what it is like in
  the real world
• Theory vs practical
• Dont confuse sell with install
• Business Integration special considerations
• Preparation for the real world
• Avoid making the mistakes that others have
  experienced
• Course Workshops
• You will experience some of the practical
  integration challenges

4
Requirements gathering and Proposal writing

• How do companies do business with each other?
• Company A needs to have some work done
• Company A issues a RFP request for proposals.
  This action initiates an open competition. It is
  important that they do as much as possible to
  eliminate any appearance or possibility of an
  inside job.
• Companies B, C, D, and E want to compete for the
  job. Each company will prepare proposals, and
  will submit these proposals to Company A by the
  due date
• Company A reviews the various proposals, and
  selects winner, Company C, say
• Company C is invited to submit a Statement of
  Work (contract)
• Company C prepares the SOW, including scope,
  price, and presents it to Company A
• Negotiation occurs
• Signature on both sides work starts
• For this course
• I will give you the complete format of a SOW,
  with all the sections described
• It will help structure your thinking of how to
  approach a business integration problem
• You may choose to use this format for project
  reports/assignments
• Have some fun
• Learn from each other
• Form two teams, come to front of the class

5
Exercise 1 Write a Statement of Work

• Learning Situation
• A metaphor which uses a different context will
  help bring out key learning points
• Team 1
• You are parents of a 2 year old boy, looking for
  a babysitter
• Prepare a SOW that you want the babysitter to
  sign
• Team 2
• You are a babysitter, looking for work
• Prepare a SOW that you want the parents to sign
• GO!
• You have 20 minutes

6
Exercise 1 Review

• Team 1
• Present SOW
• Team 2 Critique Team 1s effort
• Team 2
• Present SOW
• Team 1 Critique Team 2s effort
• Discussion
• Why is SOW important?
• What should it cover?

7
Exercise 2 Write a Statement of Work

• Same teams
• Switch roles
• Team 2
• You are parents of a 2 year old boy, looking for
  a babysitter
• Prepare a SOW that you want the babysitter to
  sign
• Team 1
• You are a babysitter, looking for work
• Prepare a SOW that you want the parents to sign
• GO!
• You have 20 minutes

8
Exercise 2 Review

• Team 1
• Present SOW
• Team 2 Critique Team 1s effort
• Team 2
• Present SOW
• Team 1 Critique Team 2s effort
• Discussion
• Did we get better?
• Does your role (buyer vs seller) influence what
  you look for in a SOW?

9
Todays Environment What are SW Projects really
like?

• Booksmart
• In school, students learn how to take projects
  from start to finish in a clean room (sterile)
  environment
• Projects follow the traditional project planning
  process
• Problem statements are often contrived or
  artificial to ensure learning points are achieved
• Project assignments are known to be do-able from
  a technical perspective
• Time needed to finish assignment is also
  pre-determined and known
• Streetsmart
• Nothing is as simple as it should be, eg.
  Gathering requirements, testing
• Murphys law around every corner
• Many project managers are naïve about Business
  Integration
• You dont know what you dont know
• What you do know isnt always so

10
Todays Environment What are SW Projects really
like?

• Budgets
• Companies are spending more and more of their IT
  budget on maintenance of existing systems
• There is never enough money to do everything that
  is needed
• Priorities and tradeoffs
• Fresh projects are rarely started
• Existing code is not thrown out
• We never start with a clean slate
• Use what we have vs create new
• This includes older versions of code that have
  not been upgraded
• Especially if the existing systems still work
• Business Integration
• The world is moving towards increasingly complex
  systems
• Many of these systems are actually be systems of
  systems
• multiple pre-existing systems networked together
• The frequency with which off-the-shelf items are
  being used is rising
• Buy vs Build

11
What Makes Integration Challenging?

• built-in assumptions of end-user processes that
  may not match yours
• licensing, data rights, warranties

• Frequent, continuous change of Vendor products
  and marketplace
• Vendor products driven by marketplace, not your
  system context

12
What Makes Integration Challenging?

• varying architectural paradigms across system
  components
• dependencies among system components

• limited control of frequency or content of Vendor
  releases
• limited visibility into Vendor product internals
  and behavior

13
Thoughts

• How do you create systems from a variety of
  pre-existing parts that werent built to work
  together and that you dont own and/or are not
  free to change arbitrarily?
• Interoperability is the fundamental problem
• Scope is far greater than simply interoperability
  of data
• Scope includes degrees of coupling, ownership
• Scope includes interoperability at the
  programmatic (and other) levels
• We can never anticipate fully the boundaries
  within which a given system will be expected to
  operate
• There will always be new things to integrate into
  the system
• Integrating systems in a network can affect all
  other systems in the network in unintended ways

14
An Instance of the Problem
We know very little about constructing an
interoperable network of systemsthe key
distinction being that the network is unbounded
(or very loosely bounded) and has no single
controlling authority.
15
Automobile Microprocessors
and thisdoesnt include things like on-board
entertainment and navigation systems
16
Digital Cameras
There is code (logic) reused in many cameras,
related to lighting/exposure This is in place to
prevent users from taking bad pictures How many
times have you wanted to just take the picture
and had the camera prevent you from doing so?
17
Airbus
From http//www.aboutairline.com/safety_eng.htm
18
Diet Coke Mentos
http//eepybird.com/exp214.html
19
Exercise 3

• Your examples
• Unintended interactions between products/systems
• Eg. Add a USB external hard drive and your webcam
  stops working
• Eg. Install a new game, and your internet
  connection is broken
• Eg. Take an Aspirin, lowers risk of heart attack
  or stroke

20
Conclusions

• We are all facing the challenges of integration
  and interoperability
• Of components subsystems whole systems
• That we do not control
• Installing one software product may require JVM
  V1.2.3
• Another software component requires JVM 1.2.2,
  patch level 1
• The JVMs should be backward/forward compatible,
  but arent
• Product support for each component wont look at
  your problems unless the full stack (which they
  have tested) is present
• Every vendor is pointing their finger at each
  other
• The number of possible combinations of products,
  release versions, patch levels, etc. is
  uncountable
• Despite the potential problems, smart reuse and
  componentization is absolutely the way of the
  future
• Companies cant afford to build from scratch each
  time
• The ability to build systems by connecting
  existing components will be a competitive
  differentiator
• Those students who are able to understand and
  master this skill will be in great demand

21
Components of a SOW

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

22
1. Project Description

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

23
1. Project Description

• Why do we need this section?
• People who have management and financial
  responsibility to sign this contract are often
  further away from the project details
• Should be written in the language of business,
  appropriate to the industry and parties involved
• Use appropriate level of detail (relative to size
  of deal, complexity, expectation of the client)
• It will also be reviewed / critiqued by technical
  people, so a reasonable amount of technical
  content (eg. Architectural drawings, component
  description, interface standards, etc.) should be
  included
• Requirements
• Client will always want everything (wish list)
• Up to the vendor to draw out what is Negotiable v
  non-negotiable
• Prioritizing and trading-off the negotiables
• Assigning costs to each requirement is often a
  good way of helping the client prioritize

24
2. Our Responsibilities

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Testing
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

25
2. Our Responsibilities

• Why do we need this section?
• When a project goes well, everyone fights for
  credit
• When a project fails, blame is assigned
• Assumptions
• You cant know everything about all components
• Your SOW will be overwhelming if every detail is
  documented
• Dependencies
• How can we verify supplier assertions?
• If we know the right properties of all the
  constituents, how do we use that information? Is
  that enough?
• Questions/challenges
• Predicting properties of composite systems
• Even if you know all about the constituents, how
  do you know how the aggregation will behave?
• Behaviour of unbounded systems
• Getting the right balance of centrality and
  independence
• Eg. When you have a system of autonomous
  constituents, how does one communicate failure so
  the others can react appropriately?

26
2. Our Responsibilities

• Examples of Responsibilities
• We will validate your requirements
• We will design and test the solution
• We will deploy to end users
• We will set up production environment
• We will provide documentation
• We will do training of your staff
• Examples of Assumptions
• How many users will be supported
• What hardware is supported
• What operating systems are in the user community
• Coexistence with other software, systems

27
3. Your Responsibilities

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

28
3. Your Responsibilities

• Why do we need this section?
• When a project goes well, everyone fights for
  credit
• When a project fails, blame is assigned
• Assumptions
• Who buys the hardware, who buys the software?
• Who owns the hardware, who owns the software
  after the project is complete?
• Dependencies
• Who is responsible for setting up the network,
  and what response time?
• Examples
• You will provide a project manager
• Your staff will be available to make decisions
  and clarify
• You provide office space, facilities, and
  machines
• You provide the necessary documentation and
  clerical support for photocopying
• You will provide access to data for testing
• You will give us access to your lab

29
4. Estimated Schedule

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

30
4. Estimated Schedule

• Why do we need this section?
• Timeline associated with deliverables,
  milestones
• Resources staffing, hiring
• Examples
• Phase 0 Workshop and Interviews
• Phase 1 Solution Design and Testing
• Phase 2 Solution Implementation
• Phase 3 End User Deployment
• Phase 4 Deployment to production
• What to include
• Schedule (eg. Microsoft Project), with critical
  path clearly identified
• Dependencies you have on the client
• Deliverables that you must deliver to client
• Assumptions
• Testing, testing, testing
• Testing, testing, testing
• Testing, testing, testing

31
5. Completion Criteria

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

32
5. Completion Criteria

• Why do we need this section?
• Both sides need to agree, beforehand, how we know
  a project is finished
• Protect both sides
• Examples
• Number of hours spent
• Calendar date
• Delivery of functional system
• Delivery of report
• Completion of function test
• Completion of performance standard

33
6. Charges

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

34
6. Charges

• Why do we need this section?
• The almighty dollar
• Examples
• Upon project start
• At major checkpoints, deliverables
• Penalty clauses for missed milestones
• Different rates for different skill levels
• Include software and hardware, travel costs
• Minimum charges (hours)
• How to change rates
• Accounts Payable terms

35
7. Acceptance Process

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

36
7. Acceptance Process

• Why do we need this section?
• When the solution is delivered by vendor, project
  is not finished until accepted by client
• Payment is often tied to customer acceptance
• Need to describe, in advance, what acceptance
  criteria, acceptance tests will be used to
  evaluate
• Examples
• Reasonable timelines for acceptance (within 3
  days of deliverable)
• How to rectify, correct, resubmit

37
8. Ending Project Early

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

38
8. Ending Project Early

• Why do we need this section?
• An out for both sides
• Why?
• Sometimes things just dont work out
• Consultants unable to deliver
• Changing environment

39
9. Project Change Request procedure

• Sections
• Project Description
• Our Responsibilities
• Assumptions
• Your Responsibilities
• Assumptions
• Estimated Schedule
• Completion Criteria
• Charges
• Acceptance Process
• Ending Project Early
• Project Change Request procedure

40
9. Project Change Request

• Why do we need this section?
• Projects are so complex that not all requirements
  or assumptions can be anticipated at the start of
  the project
• Used primarily by project managers to control
  scope creep
• Used by clients as a vehicle to communicate new
  requirements
• Investigated and sized, costed out, and mutually
  agreed to