//****************************************************************************//
//****************** Client Emails - January 15th, 2020 *********************//
//**************************************************************************//

- We're getting our participation cards today! Huzzah!
    - "...we wanted to have a more dramatic reveal of your projects, but, um, we put them on your cards, so..."
    - Everyone except one team got their first choice; most people chose different project preferences, which helped, and we had a LOT of project submissions this year
        - We got the CDC Malaria project! WHOOP!
- Other notes:
    - This Friday, the CoC Spring Career Fair is going to be going on; there are ~120 companies coming, and we'll give everyone an excused absence who chooses to go to that
        - ...in fact, let's just say that class this Friday is CANCELLED!
    - HOWEVER, now that you have your project assignments, we'd recommend getting in touch with your client pretty soon
        - Your email rough draft will be due FRIDAY MORNING; we'll review them as quickly as we can, give you some feedback, and then hopefully you can send those out within a day or two
--------------------------------------------------------------------------------

- Alright, you all have team now! Exciting! But what can go wrong?
    - "Here is an actual email I got from a client about a team last year:"
        - "I am at a loss to know how to give an evaluation of the project...I met with the team only twice."
        - Basically, they presented a mockup and asked for feedback, then gave a "shoddy website prototype...it's not clear who they think the user is and what the user is trying to accomplish"
        - The client was ESPECIALLY annoyed that the team didn't reach out for questions beyond those 2 meeting, as he would've been happy to give them more feedback and clarifications had they asked, but instead they didn't communicate and turned in a minimal-effort, irrelevant prototype that was unusable
        - "Frankly, I'm embarrassed to have talked up this project with my colleagues"
    - This is a WORST-CASE scenario: this client effectively fired the team
        - The client was a Georgia Tech alumnus, and he further wrote that he thought the team suffered from "well-intentioned technological arrogance:" thinking that even though they didn't understand the client's business, they could still solve their problem because they're smart Georgia Tech students and so could just made them a cool tool that they assumed was awesome
            - "I think our curriculum encourages this by constantly telling you you're problem-solvers and leaders, when oftentimes you need to be more humble listeners about what your clients know and need"
        - A LOT of students complain that in this class, they wanted to write code, but instead had to spend all this time writing emails and memos and research and such
            - "That's how the real world works; you don't write up your report an hour before the deadline, and you're not going to set the world on fire with your 100 lines of Python code"
            - Instead, you need to LISTEN to your users, understand their needs, do your due diligence and research, and try to give them something that's actually useful instead of just showing off how smart you are
    - Another example we've had in previous semester was a project where an all-male team was working on a project for fostering community in women's sports, and the client reached out to the professors asking if they could diversify the team
        - As professors, we initially though about setting diversity quotas, but ended up rejecting it for several reasons, such as it being infeasible to meet unrealistic client expectations (e.g. "As a healthcare company, I only want to accept disabled people," or being unable to make a team of 5 Ethiopian-Americans or something)
            - "I will say that I was personally supporting these quotas in some form, but we ended up backing away from it"
        - Now, this team of all men actually ended up doing a REALLY good job because after this, they paid extra-attention to the client and made sure to do some heavy research with them to give them what they needed
    - "So, at the end of the semester, make your client happy that they went with your team"

- So, since you've gotta send an email to this client, let's talk about what you need to do for that
    - First off, write back your understanding of the project summary somewhere in your email; this shows that you've actually read and understand your client's proposal, gives the client an idea of where you see the project as headed and your vision, and gives them an opportunity to correct you if you got anything wrong
    - Also, understand this about your relation to your client: you are NOT code monkeys who your client can push around and disrespect. If you have issues with that, see Professor Stallworth and I; you are CO-DEVELOPERS with your client as equals, and you should be working together WITH them, not just slavishly doing whatever they say
        - If you have disagreements with your client ("I think this page should look like X"), you should be able to argue about it intelligently using research, and while you should defer to their expertise and meet their needs, there may be times on the coding or UX side of things when you understand better
    - Make sure to put in a meeting time; DON'T mess around with "let us know what times would be convenient," but instead try and recommend an actual time to meet; I'd recommend giving them 3 potential meeting times that work for your team and saying "do any of these work for you?"

- Now, for team roles, make sure to make your team charter by this Saturday!