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” • Don’t 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 1’s effort • Team 2 • Present SOW • Team 1: Critique Team 2’s 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 1’s effort • Team 2 • Present SOW • Team 1: Critique Team 2’s effort • Discussion • Did we get better? • Does your role (buyer vs seller) influence what you look for in a SOW?

9. Today’s 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 • Murphy’s law around every corner • Many project managers are naïve about Business Integration • You don’t know what you don’t know • What you do know isn’t always so

10. Today’s 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. Vendors ??? Vendor Products Integrated System 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. Vendors ??? Vendor Products Integrated System 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 weren’t built to work together and that you don’t 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. We know quite a lot about constructing systems from components (over which we may have little or no control). Unplanned, unexpected, emergent behavior here… We know something about composing systems of systems from individual systems (over which we may have little or no control). System “B” Network “X” System “A” System “C” An Instance of the Problem We know very little about constructing an interoperable network of systems…the key distinction being that the network is unbounded (or very loosely bounded) and has no single controlling authority.

15. Automobile Microprocessors … and thisdoesn’t 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 aren’t • Product support for each component won’t 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 can’t 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 can’t 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 don’t 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