1 / 31

Client Interaction

Client Interaction. Nupul Kukreja , Arlene Williams (MSB) 12 th September 2014. Purpose. Breaking the ice  Do’s and Don’ts How to get the best out of each other Setting expectations Work wise Project wise Knowledge wise. What is the “team”?. It’s all “US” or “WE”

bert-stafford
Download Presentation

Client Interaction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Client Interaction Nupul Kukreja, Arlene Williams (MSB)12th September 2014

  2. Purpose • Breaking the ice  • Do’s and Don’ts • How to get the best out of each other • Setting expectations • Work wise • Project wise • Knowledge wise

  3. What is the “team”? • It’s all “US” or “WE” • Not “I” or “THEM” Team = Clients + OnCampus + DEN • Whenever we say “team” we mean the “whole team” • We’ll allude to “parts” explicitly 

  4. Clients(Business) OnCampus(IT/CS) Avoid Pure Knowledge Transfer DEN(IIV&V/IT/CS)

  5. Prefer Collaborative Learning Clients(Business) OnCampus(IT/CS) DEN(IIV&V/IT/CS)

  6. Good Practices • The WHOLE team must: • Be on an email distribution list (e.g., Google group) • Be included in teleconferences • Have frequent interactions, even if brief • Identify tasks where the client and students (i.e., software engineers) can work together • Say “we” instead of “I” • Go out for lunches/ice-cream and reward yourselves for interim milestones • Focus more on “system usage” than “system development”

  7. Why are “you” here? • Discuss this as a team (5 minutes) • Students: • State 2-3 honestreasons, why you’ve enrolled in 577a • Mention if you’ll be continuing to 577b • Clients: • Other than having a system built, discuss what other objectives do you seek to have fulfilled? • Understand everybody’s expectations so you can see what would make them feel like a “winner” • Will come in handy later!

  8. Creative Friction • Clients: • Encourage the student teams to say “No” when appropriate • Students: • Have sound justifications for the above “No”  • Team: • It’s okay to disagree • Clarify the differences of opinion • Avoid staying mum (or bitter ) for too long! • Be polite  • Language may be a barrier, be accommodating • Avoid conversing in your native language • Remember the mantra: We’re all in this together

  9. Get Yourselves a PM • As a team decide on who’ll be the project manager – soon! • Project Manager: • Note down “minutes” of the meetings and email it to the team • If the team members are “stuck” try fix the hurdle to ensure a smooth working • Make sure the team has everything it needs to work smoothly – ask them ever so often • Ensure “everyone” participates in the discussions • Coordinate things/timings with the client and student team members • Stay up-to-date on the status of the team’s progress/schedule and be ready to dive in if the need be

  10. PM Don’ts • This is just a role name - don’t boss around! • You “have” to do work, not a mere spectator • Avoid saying “because I said so” • Don’t micromanage • Don’t commit “on behalf” of the team without everyone’s involvement • Don’t shout • Don’t just tell the client “because it’s a deliverable”

  11. Client “Interaction” Participation in Artifact Creation

  12. Client Participation • Student teams are not only developers • Think of getting consultants who also happen to be developers (or vice versa ) • 577ab teaches them to adopt business risks and understanding of the initiative as a whole • Just developing the software is not the goal • Your participation is paramount, especially with certain artifacts for the “consulting”

  13. 1. Program Model • A model to help articulate and capture ‘program/business vision’ • Ease of use for communication amongst stakeholders • Helps see the ‘broader vision’ and all encompassing view of the ‘program’

  14. Program Model Assumptions: Under what assumptions is this model true? Initiatives that need to be undertaken to help beneficiaries derive value from the expected benefits/value propositions Initiatives that need to be undertaken to help deliver value to the beneficiaries (i.e. “how” will the benefits reach the beneficiaries?)

  15. Program Model Assumptions: Under what assumptions is this model true?

  16. Example – Volunteer Management System • Assumptions • Growing needs of volunteers • Continuously growing volunteer pool • Increasing activities requiring more volunteers

  17. Who? Who? What? What? Visualizing Causality Who? Why? Why? Why? What? What? What? What? What? Who? Who? Who?

  18. Discussion • Teams: • Hand over the print outs to your client • Discuss with the client the assumptions behind the “program/business model”: • The project/product/program will succeed if and only if ______ is true • 5 minutes • If something is a 0/1 case, it may be a fact, not an assumption: • Ex.: Someone should use the system • Internet connection is available • …

  19. Capturing The Requirements • Two-step approach employed at 577 • Step 0: Capture Program Model and rank value propositions • Step 1: Break down expected functionality into high level features (a.k.a., Minimum Marketeable Features, MMFs) • Step 2: Decompose each MMF into constituent requirements • Requirements captured as user stories • All of above, captured, managed & prioritized using Winbook – homegrown tool

  20. User Stories • We capture ‘software’ requirements as user stories • Usually of the form: As a <role>, I can <activity> so that <business value> Ex.: “As a Consumer I can see my daily energy usage so that I can lower my energy costs and usage” • Details conveyed primarily through conversations and formalized via acceptance tests

  21. MMFs

  22. Go to Winbook

  23. Discussion • Teams • Have the client list out a few requirements in the user story format • Make sure everyone on the team is comfortable discussing in the user story format • Clients: We expect you to state the requirements in the user story format all throughout the course, good to practice  • 5 minutes

  24. Winbook Usage • De-facto “Project Management” tool in 577 • Clients are expected to check Winbook frequently • Add/Update/Modify content • Clarify/Comment on items • Avoid falling back to email/phone conversations alone • 577 staff can ONLY monitor Winbook

  25. Business Process Modeling • We ask teams to capture the “business process” in a flowchart like format • The process to be captured is: How is it done now? • If automating capture manual process • If “new idea” capture how have people managed up until now • Necessary to know/understand what changes and how much it impacts existing process (for the better) • Provides a much needed “context” for understanding client needs

  26. Discussion • Clients: • Describe “how things are done now” to your team • Preferably in a step-by-step form • Not too detailed, just a high-level overview • Teams: • Capture the above in a flowchart-like notation: Activity Decision 5 minutes 

  27. Teams • Next week (9/15) – Off Campus • Program Model and Results Chain • Business Process Modeling • The week after (9/22) – On campus • 1st WinWin Session • Prioritize Value Propositions • MMF decomposition • Prioritize MMFs • Capturing of initial user-stories • The week following (9/29) – On campus • 2nd WinWin Session • Disambiguating user stories • Negotiating requirements scope (first cut)

  28. Welcome to 577a(b) We hope you enjoy the ride

More Related