At GitLab, the Handbook is an essential tool for our team and many of our community members.  Does your community have a Handbook? Maybe it should. Using Chaos and GitLab as examples, this next talk will show why Handbooks create communities that are diverse and inclusive. They level up the playing field for all community members and ensure the communities can be held accountable. Jaskarot and Naritzy also share the work they're doing with IEEE SA Open to bring Handbook standards to more open source communities. If your community doesn't have a Handbook yet, it might soon. Enjoy. Hi, everyone. We welcome you all to our session of Community Handbook, Best Practices for Diversity and Inclusion. My name is Jaskarot Singh, and I'm working as an open source research strategist and tech writer under Chaos, which is a project of the UNIX Foundation. So I basically help organizations, youth release and contribute to free and open source software, which is beneficial for both, that is for the community as well as for the end users. And today I'm leading the session with my co-facilitator. Thank you. Yeah, my name is Naritzy Sanchez, my pronouns are she, her, and I'm the senior open source program manager at GitLab. That means that I run the open source program. And I've also volunteered at many open source communities. I am a former president of the GNOME Foundation, I've helped organize conferences, and I'm currently part of the Chaos, a Chaos Working Group, and also IEEE SA Open. So let's take a brief overview about what we would be covering in this session. So before we go ahead, I just want to let you know that first up of the session would be covered by me and the second half would be covered by Naritzy. We have divided this section, like this, especially this session in three parts. So the first one is gonna be the community handbook and why is it important? Then we would be talking about the general components of the community handbook, the last, but not the least, like how you can basically join this movement specifically. So yeah, let's get started. Like what's the community handbook? So talking about the community handbooks, it has various attributes, starting with the documenting the process. So inside the community handbook, the community needs to define the processes involved within the community, like how the newcomers and existing community members can avail the leaderships involved inside the community. You just have to make sure that a technical documentation is different from the product documentation. So this is the kind of the community handbook documentation you could be writing, it's gonna be different from the actual technical documentation. Then we have the one centralizing the information. So again, we want to make sure that we have a single source of truth, like basically for finding like how to do things inside the community. You don't have to replicate up the things at different places and it should be easy for any newcomer to find the information at one place. Not really the last one, but the third one, which is very important. So basically it's about like how the newcomers can join the community. So you need to define the guidelines like how one can contribute towards development, design, documentation, and the outreach. So basically you have to lay down the processes that one can follow while participating inside the community. And again, you have to understand the accessibility and make this community handbook more easily searchable, keeping diversity in the mind as well. So you need to provide a better user experience to you. Well, it also enables the diversity. It can be accessible to various people who are actually present across various time zones like who works asynchronously. They can have the basic translator study up or like it is easy to translate so that people can understand it wisely. It also enables accessibility, keeping in the mind that the content inside the community handbook is really easily accessible by disabled people. And the last one, which is very much important that you have to understand inclusive language. So basically it enables by creating an environment that basically attracts the diverse contributors. So you also have to make sure that you don't use any such expressions or the words which actually are considered excluding the general group of people. Next slide please. Well, it also creates the transparency and openness inside the community. Like this is the way you actually get a chance to empower the contributor base, follow the best practices, like writing up a documentation for the community. You also have to make sure it is easily applicable by the other communities, either by the crediting to the setting the source. So yeah, this is how it enables the transparency and openness as well. Next slide please. Again, we would be talking about the examples of the community handbook where I would be covering the handbook or the chaos project and the GitLab handbook would be covered by the new agency. So yeah, let's get started. So chaos was established two years, I'm like probably like in 2017 at open source North America. So two years after the chaos establishment, the community handbook came into picture. There were a lot of discussions around it, but there was not a strong base to start this up. So in 2019, actually, this the community handbook was proposed as a project within the major Google open source program, which is the Google Season of Dogs, which is the program run by the Google where technical writers work with the open source organizations, helping them writing a better documentation. So I was lucky enough to avail this opportunity where I work with the chaos project, helping them build up the chaos community handbook. So there were again, a lot of many discussions around it regarding the tool stack we used and how to deploy it, but we finally ended up having the kitbook. I mean, like you are free to explore the chaos community handbook as well, but here we are just giving a brief idea about like how we have actually organized how it's actually started up. So the chaos handbook has been divided into four different sections, like which is about community contributing and mentorship. About section generally contains the general, the history or the rules and responsibility inside the community. And the community part actually contains the various subsection, which talks about the governance, the leadership ways, things, and the ways or the processes one can involve inside the community. Again, within the contributing section, it have various subsection, which includes how the newcomers can join this pace by contributing towards design, documentation, development and outreach. And since chaos has been participating in various mentorship programs, so the mentorship section basically contains about these development programs details. So next slide, please. Okay, so here you see a brief snapshot taken from the chaos handbook. This is the chaos history page. At the left side, if you see, it is the NABAR, which contains different sections and subsection. The center aligning is the information or the content actually needed for this specific page. Here, if you could see, I have defined illustration image, which basically talks about the chaos history, like how the chaos originated and how it is going now. It is always encouraged or suggested to have illustration image for the specific page for the people who are not really interested to get through the whole page, right? So this is, if you could see, like this is how I have drafted the illustration image over here. And the right side contains about the general idea, like how you can contribute towards it and the table of content as well of the specific page. Next slide, please. Again, this is another page taken from the handbook. So this is the partnership page, which talks about the different leadership involved inside the chaos community. Next slide, please. So I feel like this was all about the chaos handbook. You are free to explore it by redirecting to a specific link. Now let's hear about the Kitlab handbook from you. We'll see. Awesome, thank you so much. So before I begin, I just want to mention that unlike Jessica's handbook that you just talked about, the chaos handbook, the GitLab handbook is a company handbook, but because GitLab is an open core company, we also work on a daily basis with our community. So it sort of serves the purpose of both things. And it creates a whole new level of transparency. So I'll give a brief overview of what that is. First of all, when each new team member on boards, they're expected to read through the handbook and contribute. There's actually something specifically in our onboarding that says that if you notice content that isn't clear, that maybe you have questions about, then it's likely that other people have questions about it too, so you should go ahead and update it. We use GitLab pages to host this as the tool that we use for the community handbook or for this handbook. And that means that it requires editing through merge requests or MRs. While that might seem a little bit scary to people who are not familiar with how merger requests work, it actually is a great thing, because GitLab allows you to create merger requests in a way where it's almost like editing a document, and then it also gets people familiar with the way that merger requests work so that they can start contributing in other ways. So in that way, the community handbook ends up being almost like a gateway to other types of contributions, perhaps updates to a website or things like that. In each page, there is a little image on the top right that shows which people or who is responsible as the code owner for each page. These are basically like maintainers of projects or yeah, something like of a code base. So essentially everybody can update the content, but the code owners are the ones who are responsible for making sure that the content is continuously updated, and also they can make the final decisions on whether to include something or not, or how to format it, things like that. There is, here, this is like the very beginning of the handbook, so you can see that there is an introduction to the company about the mission, the values, what kind of communication, what tools we use for communication, et cetera, and each team is expected to manage this. They have their own section, and then besides that, as I mentioned, each person is a code owner of a particular page to kind of show also who is responsible for that area or who can take leadership. So the last thing that I wanted to highlight here before I move on is that this is distinct from GitLab docs. So as Jessica mentioned before, the community handbook should be something that is different than the documentation, so or than docs. So communities have already sort of recognized the importance of technical documentation, and now it's time to start documenting processes in this new community handbook like mindset, all right? So I'd like to show another page here of what our community handbook, or what our handbook looks like.  On this page, you can see that I have all sorts of information about, for example, what my quarterly goals are or what metrics I use for the open source program. So this page is distinct from our website because it really talks about the processes, and so hopefully this gives you a little bit more of a visual of what I mean by this. There are really detailed things like what products use the open source program uses when it gives away free licenses or things like that, so it's very detailed. And then in order to maintain the content fresh and make sure that it's constantly updated, GitLab has adopted a handbook-first culture, and what that means is that we should always respond with a link. And this gets people in the habit of making sure that what they're trying to say is documented in the handbook, that it's updated, that it's still relevant, and then it also helps the people receiving the link to be able to go and look through it and make sure that it's easy to understand, or if not, they should contribute back and help make it easier to understand. So by adopting that handbook-first culture, it's actually key to the success of actually rolling this out and maintaining it. So it's something that I think that every community should adopt if they're trying to include community handbook for their own community. All right, so hopefully we've now given you a background on what a community handbook is and why it's important. So now we're going to talk about how you actually begin a community handbook. And I wanted to start off by just saying that this is all sort of in flux, the term community handbook and also the different components, all of that are still being defined. So we have joined, Jessica and I have joined the IEEE SA Open Community to help define those standards. We encourage you to join us and I'll have some information about that at the end. But again, I just wanted to start off by saying that this is a work in progress. So what I'm sharing with you today is just the beginning. Okay, so when you're first starting to roll out or develop a community handbook for your community, you first need to make sure that you create buy-in. In order to do this, you need to start off by documenting your proposal. This can be in an issue on a wiki or whatever tool that your community uses. It should be something that you can link to and again, have a larger conversation about. So that's why having it in an issue or maybe in a wiki and then starting an issue so that people can have a conversation about it is really important. You should then request input from the community because if you just make a decision and then try to roll it out, it's likely that it won't be adopted. People will feel like it's being forced on them or that it's incomplete, et cetera. So having a timeframe for requesting input, maybe it's a few weeks or even a few months really helps people feel a shared sense of responsibility and they feel included in making something. This is incredibly important when you're having really big changes to communities or in processes or just the way that things are done. After you have that period of community input, it's then time to get formal approval from the governing body. So this could be a technical or community advisory group or the board of directors, depending on how your organization is set up and having this formal approval, just having the governing body say, yes, this is important to us and we want to establish a working group will again, will lend it legitimacy. Once that's done, you want to set up the working group. So this can be just a group of interested people. Again, you should let anybody express interest and join the working group, have a core group of people that are doing it or you might want to tap into something like the Google season of ducks program that Jessica mentioned earlier and have somebody lead it and then that way it's somebody who is taking it on as a project. Something that's really important whether you go with a working group or have somebody lead it through again, the season of ducks type program is that there should be regular updates to the community about the progress and to gather input. So maybe once you've decided what topics you want to have at the top level, you send a message to the community or an update in the issue when you say, this is what I've worked on this week. If you have input, feel free to let me know. And so in that way again, you're creating multiple chances for the community to weigh in and help collectively shape it while still having that momentum moving it forward towards actually completing it. And lastly, when you have finished creating the community handbook or this first iteration, it's time to employ change management skills to roll it out to the community. And for those of you not familiar with that term, change management, it is essentially a skill set that you can develop to help really roll out big changes to any organization. And so what this might look like is for example, gathering people that have high visibility in the community. These might be maintainers of projects or strong community advocates and getting them to understand what the community handbook is, how it works, how to update it, et cetera. And then they are more likely to help newcomers or do it and to be able to themselves adopt that handbook first culture and then start to spread it to the rest of the community. So change management is still a skill that I'm developing as well, continuing to develop. And I encourage you to look into that as well. The next thing when starting your own community handbook is thinking about the tool stack or maybe not the next thing, but a very important part is deciding what tool you're going to be using. And so we think that there are some desirable characteristics. This might not be a fully inclusive list, but we think that it should be searchable, accessible, visual, user-friendly. And we think that there should be some form of version control. So keeping these characteristics in mind, we have recommendations for you to look into. That's GitLab Pages, GitBook and GitHub Pages.  But these are the three that we recommend looking into first. When creating your handbook, you also need to think about the topics that you want to cover. These are some like high level topics that you might want to consider. The first is having an about section that talks about the community's mission, the vision, the values, history, the governance model, code of conduct, et cetera. So this helps to give newcomers an idea of what the community stands for and the various ways or the things that they need to know like the code of conduct. Then there should be a section about the different teams or the groups within the community, how to onboard onto each team and any specific processes that the teams or groups follow. There should also be a topic about the handbook. So this is kind of like a meta category of how to use the handbook, how to update it, et cetera. And then we think that there should be some sort of social component. So how to meet other community members or tools that you use to communicate. All right, you should also, when creating any kind of documentation and again for this community handbook, you should be keeping in mind using inclusive language. And like Jessica mentioned before, this is really important. So try to avoid using acronyms or referring to people just as he or him, making sure that you really take into account just something that will be friendly to everybody and also that anybody from around the world will be able to jump in and use. So don't use elaborate language. And then accessibility is really important when you're creating your handbook and then you should have a tone, a documented tone and voice so that there's a level of consistency throughout the community handbook. Another thing that you should be thinking about as you start your handbook is how updates are handled. And we mentioned these before so I won't go into them too much, but having code owners or maintainers for pages or sections and then having that handbook first mindset or culture is really important because the worst thing that can happen is for you to put in all this effort into creating the handbook and then for the content to go stale and for it not to be used. So making sure that updates are something that are routinely done is incredibly important. All right, so now I'm going to tell you how you can get involved in the community handbook movement. And before I start, I just want to bring attention to this QR code that we have on the right hand side. If you scan it, you'll be able to see the PDF version of this presentation with links to various resources. There are links throughout the presentation as well but we have a section specifically on resources and we hope to be adding to this library. So go ahead and scan that. And so what if you would like to join us? The first thing is to help us define the standards. You can join the documentation and curation team at IEEE essay open. And this is where we meet on a bi-weekly basis to define those standards. We also want you to help us coin the term. And that means help us make the term community handbook well known. It's fairly new, so we want people to know exactly what we mean when we talk about what a community handbook is. And then spread the word in your own communities. Feel free to copy this slide deck and use it to help pitch the idea further. And again, we're going to try to continue to create more outreach materials. So keep checking back on our resources library. And then we will welcome outreach ideas from you as well. Feel free to reach out to us on Twitter or LinkedIn. Jessica and I both would love to connect with you. With that, we thank you very much for attending our session. Thank you and we'll see you around GitLab commit. Thank you, bye-bye.


Hey guys, this week in the rundown we have an important message from C&P and Fleet Beldo. We have an interview with Mikpon where we talk about the Navy's review of rating titles. And commands can now submit a BBD access request. C&P and Fleet Beldo have a message regarding suicide prevention. They both want all sailors to remain vigilant and to always be available to our shipmates in a time of need. Check out some of their message to the fleet. Whether it's operational challenges, maintenance challenges, social challenges or psychological challenges like this one, it makes all of us better. We all recognize that so we have to talk about this together as a team. And I think we all know that the stronger the team, the more we look out for each other and the more we're going to recognize when things aren't going right for sailors or something's out of the normal. And those are the indicators that hopefully people recognize and they step in. And I think whether you step in and actually save a life or just express an act of kindness, that's going to strengthen the team at the end of the day. C&P's and Fleet Beldo's full message can be viewed on Navy Live. On last week's episode we talked about the Navy's review of rating titles. The review is designed to make job titles more inclusive and relevant to the demands of today's Navy. Taking the lead on this is Mick Pond Stevens, who I had the opportunity to talk to about the review, his plans for implementation and what it all means for the future of the Navy. Here's some of what we talked about. There's probably some ratings out there whereby the title of the rating doesn't necessarily align or match very well with the job that they do. So it doesn't always have to be about the men portion of the title change. It could be a title change because it makes more sense. So this is again a total and holistic review of the rating title nomenclature throughout our Navy. You can check out the full interview on Navy Live. We have more information on the hot topic last week that was billet based distribution or BBD. NPC is asking all command designated representatives to submit a BBD access request. The request will allow sailors with roles related to CMS ID or BBD access to the system. For access instructions, go to the NPC main website, click the enlisted tab, billet based distribution and BBD access instructions on the right. There's a lot of information on NPC regarding BBD so be sure to check it out. Well, that's all we have for this week. If you have any questions, send us a message at usnpeople at gmail.com. For the Chief of Naval Personnel, I'm MC2 L.J. Brelison. Thanks for watching.


Our next speaker is a lawyer and former Australian and British Army officer. Major McBride was the whistleblower who provided evidence for war crimes in Afghanistan to the ABC. It takes integrity and courage to be a whistleblower. They're rarely celebrated and more often vilified and imprisoned. Today we have some good news because David McBride has been awarded the Blueprint International Whistleblower Award. It's my pleasure to introduce David McBride. I might have to take this out. Karaoke style. I think there's not much that hasn't been said. I may as well do a bit of comedy. When I was over in Western Australia I got some tips from Mark Jacko Jackson who said that I was a bit stiff and that I should walk around to engage the crowd a bit more. But if I ever get out of jail I might be doing a tour with him I guess. But one of the messages I've got is from our foreign minister Penny Wong. You'll be pleased to know she says she's going to be putting sanctions on those bad countries around the world that don't honour human rights. Good on you Penny.  And I've got another myth and that's not bad enough from Mark Dreyfus who wants to particularly honour a is it human rights day because he's working day and night to make sure people in government if they see something wrong can go to their supervisor and tell them about it. And if the supervisor doesn't do anything they can go to the media. Good on you Mark. The same guy's trying to put me in jail for 100 years.   There isn't I would not take anything the Albanese government say seriously. I'm afraid it's it's it's a sad truth. I don't know what the Americans have got on them but in the one yeah it's you know they have committed to unlimited U.S. troops unlimited U.S. troops in Australia. We are now just a U.S. base in Australia and the American troops can commit crimes. They will not be prosecuted under Australian law. And at the same time they are pretending that somehow they care about human rights. Now if we are aligned with the world's greatest abuser of international law and human rights we can't support human rights at the same time. You don't protect Australian sovereignty by giving up Australian sovereignty. It would have been it would have been a fantasy 10 years ago but it's quite the good news is I mean I've got a lot of bad news for you to have to tell you that we are owned by the Americans and I've seen the documents but the good news is people like David Shoebridge the next election could see the Labor Party clean out because what if you believe in the Labor Party principles you would not vote for Albanese and his next time they will be cleaned out and people like David Shoebridge one day may be running this government we might finally have an Australian government who actually stands up for Australia and actually says we'll protect ourselves thank you very much I mean we all know Donald Trump was a bit mad and we know Biden's a bit mad imagine who they're going to have as president in 2040 or in 2090 and guess who's going to be making decisions for Australia yeah Mike Pompeo Mike Pompeo's son Mike Pompeo on steroids I mean they get mad at each year that they will be directing us and we don't get to vote in their elections we don't have a defense force anymore we can't go anywhere without American helicopters we can't go anywhere we are just a division not even a division we are a brigade in the US Army and we go whatever they tell us to and that is a disgrace that's actually treason they put me on trial for treason but that is treason anyway the good news and I'll end now the good news is you guys are on the right side of history it makes no sense that Daniel Ellsberg is a hero and Julian Assange is a criminal I mean Albanese knows that in his heart he's going to look like an idiot he's going to he's going to be the sort of Billy McMahon the Harold Holt he's going to be remembered as a goose who just lay down for the American and it's such a shame he could have been a contender and all he had to do is say no the hardest word for the Labor Party you guys on the other hand will be heroes you guys will remember being here day in day out winter summer obviously vilified a lot of the time but you guys have a lot to be proud of when I'm in jail which is likely going to happen because the Americans want it to happen and Albanese he can't say no to the Americans you people will always make me smile and you people have got a lot to be proud of and Julian I'm sure will thank you so thank you


Welcome to the Welch Medical Library. This video will introduce you to the library's website and the resources available to you on it as a Johns Hopkins student, faculty, or staff member. The Welch Medical Library supports the research, clinical, and educational needs of Johns Hopkins medicine, nursing, public health, and its hospitals and health system. So you'll see that our main focus is on providing access to biomedical resources. Regardless of where you're physically located, you can access Johns Hopkins resources from the Welch website using your JED ID and password. When you select a resource from the library's website, you'll be prompted to log in with this information. Alternatively, you can log in as soon as you open the Welch website by clicking on the login link located on the top corner of the home page. The search box located in the center of the home page provides easy access to browse or search our resources. We know people like an easy way to find a few on-topic journal articles. Therefore, the primary search box on our home page is an integrated article search driven by Scopus, which is the largest abstract and citation database of peer-reviewed literature. To begin, type your search terms in the lower box showing the word search Scopus for. Select the field you would like to search from the box above. Then click on the magnifying glass icon to run the search. If you prefer to search through Scopus directly, you can access it by clicking on the link in the top corner of the search box. Clicking on the journals tab allows you to search for journals. Typing words in the top search box provides you with access to approximately 20,000 journals by title and subject using subject terms curated and provided by the National Library of Medicine. To search all Hopkins Library collections for a specific journal or article, select the Access Journals A to Z link located in the top right of the search box. This will take you to our finding at Johns Hopkins Library's search interface where you can look up journals by title, ISSN for other specific citation information. The Databases tab allows you to access approximately 1200 databases. You can browse or search through a list of biomedical databases by using the top box or you can search for all of the databases available at Johns Hopkins by using the box just below it. Last, the books, journals, and media tab provides access to two searchable catalogs. The default setting searches the Hopkins online catalog known as Catalyst. Using the Search Catalysts 4 box searches the entire collection of resources available from all of the Johns Hopkins University Libraries, which includes over 150,000 journals and nearly a million electronic books. It also searches for articles through EBSCO databases similar to our Scopus article search. The Search World Catlink searches the collections of libraries around the world. Search results contain a link to the find it at Hopkins interface to provide easy access to materials. In the key resources section, we've highlighted some of the most frequently used Welch Library resources. These links will take you directly to the tools and databases listed here. The clinical tools box provides easy access to our most popular point of care tools used to find evidence-based summaries on specific diseases, conditions, or medications. In the literature databases box, you can access our most frequently used peer-reviewed literature databases. Last, the research tools box provides access to resources for managing your citations and conducting systematic reviews. To learn more about how to use these specific resources and the many other resources available to you at Hopkins, contact your Welch Informationist. Every school and department in the Hopkins Medical Community is assigned a Welch Library Informationist. Informationists have expert knowledge about resources specific to subject areas and are available to teach about their use. You can use the drop-down list on the library's homepage to find your Informationist. Informationists also provide subject guides to help you get started with your research. The list of these guides is available by selecting the heading, Find Your Informationist. From this page, click on the Informationist guide, search box, to see a complete list. The library also offers classes that you can register for. They cover topics such as searching techniques and how to use specific citation management tools. Many of these classes are offered in person while a growing number are available online as webinars. Select the View All Welch Classes link for the complete list of upcoming classes. If you're teaching or taking a course, your course reserves are accessed in the Reserves box. There is a link for student access and one for faculty access. Finally, if Hopkins doesn't have access to an item you need, we'll borrow it for you free of charge from another institution. This program is called Interlibrary Loan and Document Delivery and is also known as WellDoc. Clicking on the Request and Item link will take you to your WellDoc account where you can request items and learn more about using this service. Just like the other resources on this website, you'll use your JET ID and password to log in. In summary, the Welch Library website is your access point to library resources and services available to you as a Hopkins affiliate. Logging in with your JET ID and password allows you to seamlessly access a wide range of databases, journals, books, and much more. For more information or to get help using the Welch Library website, visit the Get Help section of our website. Reach out to the Welch Service Center through chat, email or phone or contact your informationist directly.


All right, I'm gonna go ahead and get started I get very excited about this topic So I make sure I have enough time to fit everything in here and still have time for some QA Hi, my name is Tom Martin. I am a senior technology consultant at metal toad We are a digital agency out of Portland, Oregon in the United States. We focus primarily on Drupal based projects. I Found my way into the internet back in the in mid late 90s got very excited about it And yet somehow became an animator instead And then somehow found my way back into doing web-based work and development and spent a lot of time doing e-commerce and At some point wound up at metal toad learned Drupal and I've been there ever since so this session summarized is Basically at metal toad we've been experiencing this phenomenon recently where a lot of clients are coming to us and they have these very big grand ideas But they don't necessarily know how to make these ideas reality. You know, what does the project actually look like? What does this actually mean to produce this thing that they have in their heads? And so we've been doing a lot of discovery projects lately And I wanted to come here today and share a little bit of this some of the things we've learned with you folks So what exactly am I talking about when I talk about a discovery project? Discovery project is essentially just a small project to define the big project You know, it's planning. It's defining the goals. It's doing requirements gathering. It's plotting out a road map And it's determining the scope so that you can actually estimate or even have some sense of how many sprints the big project is going to be More importantly than that. It's a fantastic opportunity to build trust between yourself and the client How many of you have ever done any of these types of things before? Right, I mean, I'm not you know reinventing the wheel here in any way All I'm simply doing is you know, we've we've taken a lot of these practices and processes and combined it into a Service that our company can provide to the client So which customers, you know, does this really apply to it's not every project. It's not every client, you know There's a little bit of a spectrum You know on one end you kind of have your fairly basic websites think of these as brochure wear sites I mean this could be a restaurant that needs to post their menu or locations. These are very easy You know typically they're going to be marketing based a lot of the requirements are going to be dictated by the design comps So do you really have to do a thorough discovery on these, you know, maybe not But of course on the other end of the spectrum you have these large monolithic ERP systems These are very very large architecture, you know think of Starbucks and you know internationally the types of systems that they have to support for You know, not only you know the point of sale, but supply chain You know HR, you know, these are massive systems And that's not really what I'm talking about here either because when you get into that scale You're starting to talk about some form of architecture framework What I'm talking about is what I like to refer to as our little discovery project Goldilocks zone. It's not too big It's not too small. It's somewhere right in the middle The way I like to think about it is as as the web Evolves and as we start to see more and more that what constitutes a web project is becoming more Complex those of us that were in the agencies of in in the business of building websites are starting to see these more complex Requirements coming in and as a result we have to do a little bit more thorough planning ahead of time to just make sure We know what exactly it is we're embarking on All right, so we need to do some planning and one thing that I absolutely love to do is to take lessons from other industries That's let's face it. We're a relatively young form of media I mean, we've matured a lot in recent years. We've been around for a while now, but in the grand scheme of the world Web is still pretty young and there's folks that have been doing things a lot longer than we have so Let me ask you this imagine if an animation studio went out and they just Wanted to make a movie and they decided on day one. They were just going to start animating Just right away, you know, they're starting to render stuff by day two How do you think that movie is going to turn out? It's going to be pretty terrible. It's it's safe to say What are the odds that they're going to be around to make another movie? Not very high and why do they do all this planning up front, you know Because simply it takes a lot of time and effort to make animation You know three seconds of film is going to take them a lot of time Now I think everyone in this room probably realizes the work we do takes a lot of time also I know probably most of us have been nights and weekends and we know very well how painful and how long these things can take so Again, let's take some lessons from these other folks One of my favorite quotes one of my animation professors used to say all the time Said if I had three days to animate a scene, I'd take two days to plan and one day to animate it This was from Eric Larson. He was one of the brilliant nine old men from Disney's golden years But this is just another way to say something you've heard many other ways many other times like in carpentry when they say, you know Measure twice cut once. It's the same thing And so how do they plan and animation? The very first thing they do is draft a script. This is the core of the story Basically, nothing moves forward until they feel like this is this is panning out At the end of Toy Story 3 or Inside Out or any of these recent Pixar movies It was not the ray tracing algorithms that made you teary-eyed at the end. It was the story. It was the characters The next thing they do an animation is conceptual design They develop the characters The layouts the color palettes locations and they start to figure out how all of these different objects are going to connect You know, basically what you know, where your objects? What are their methods? What are their properties sound familiar? Storyboarding is where most of the magic happens. They do quick sketches rapid ideation budget-friendly experimentation Something isn't working. They can throw it out. They can do it early and they can move on with production Once they have their storyboards, they can throw these together into an animatic They'd actually drop it in with the audio clips. So at this stage They pretty much know how long the movie is going to be they know Long all the shots are going to be and they can run this in front of a test audience So that by the time they actually get down to doing the animation They pretty much know whether or not the movie is going to be successful or not and if not they can change it So over a hundred years of grueling work is taught animators how to plan and in order to avoid costly budget failures So what can we do? You know, what's the equivalent in our industry? You know user stories Tech specs diagrams wireframes flowcharts, you know ia ux, you know prototypes These are all things you've heard of and done before So what is the Discovery project? It's our script. It's our conceptual design. It's our storyboards. It's our, you know, animatics It's basically our way of making sure that when we get down to building this thing We're on the right track and it's gonna most likely be successful and if not, we'll know before we start So let's take a quick couple quick brief looks at why we would do a Discovery project For me personally most this all boils down to one thing and that's narrowing the cone of uncertainty Have any of you heard of this concept? So essentially the cone of uncertainty is when you walk into a new project, especially with a new client there can be a massive amount of things you don't know and You basically want to try to whittle that down to some degree So that when you and your team start to actually go into production you have some level of confidence So if you're doing agile, do you still need to do a Discovery project? I get this question all the time and my answer is yeah, it's not a bad idea You know at metal toad we we try to do agile as best as any agency model can Of course the clients always throw a monkey wrench into agile when when you're dealing with many clients But yeah, absolutely. There's no reason why you can't do a little bit of discovery up front because if you think of agile You're kind of saying that at the very end of the project you're going to be the most informed to make decisions Well, if you think about how that plays with our animator friends, not very well, you know But there's nothing that says even with agile you can't do some Homework ahead of time some research to make sure you at least know how many sprints you're going to need or how about how many resources You're going to need do you have to narrow the cone of uncertainty very far in agile? Not necessarily you can start development maybe a little bit further down because agile is going to give you a lot more Flexibility when you get into your sprint structure But of course if you're doing waterfall, you're going to want to get that very very far down before you start Development you're not going to want to run into any surprises. Otherwise that's going to be on you You're going to be eating that budget Most important thing though is that you and the client are ready to move forward you both feel confident You both feel like you know what you're embarking on where that line between discovery and development Lands that's going to be variable. It's going to depend on how agile the client is going to be willing to be It's also going to depend on how many requirements are already set in stone and not flexible But you definitely want to be able to define some boundaries if you're doing agile like I was mentioning earlier You want to at least be able to know about how many resources you need and what skill sets they need to have And you're going to know about how many sprints that you're going to need them for Because if you want to be able to look at your pipeline and plan your future projects You got to have some sense of where this this big project is going to land and when it's going to be over And of course if you're doing waterfall, you're back to the old iron triangle scope cost and time And you're going to want to lock those down as best you can to protect yourself So what some of you may be thinking is this is all great and fine to think about all this planning But you have a business to run and you've got to be able to get paid And it is a lot of work But don't forget that I am saying project the word project is in discovery project And that's exactly how you should pitch it to your prop your clients. You should be able to get billable hours for this When you're trying to pitch this to a client if they don't like the term discovery project try where they might be more familiar with like Consultation or strategy when we go in and we try to pitch a discovery I mean, this is again the hard part you got to kind of guess how long is it going to take you to determine all the variables It's a little bit like what came first chicken or the egg because the whole point of discovery is to help find out How complex the big project is so it's a little hard to tell just how much time you need to spend up front It's an art form. I guess but what we try to think about is if We can ballpark how big we think the big project is we try to get at least three to ten percent of that is a discovery budget And there is a little bit of decent sized variants variants there and a lot of that depends on you know Just how much time where we think we think we're gonna have to spend doing R&D to research any of the components But believe it or not these projects can actually be very easy sales to large businesses like when you're talking to an enterprise Client someone who's used to doing digital projects. This is not a hard sell. I myself first coming into all this type of thing I thought it would be But but that's that's be blunt at least in the United States I don't know about here in Europe but in the United States there is a huge percentage of digital projects that fail and Enterprises that work with many vendors and do many digital projects are aware of this and so essentially When you go to pitch this to them You got to keep in mind that they love planning and documentation You know, they absolutely love narrowing, you know The estimate ranges and getting that ballpark to be something a little bit more tangible that they can take to the financial teams And they love minimizing risk, you know from their standpoint a discovery project It's gonna lower the cost most likely and lower the risk of the entire engagement You got to remember a lot of these c-sweets these directors that are putting You know, they're putting their butts on the line to get these projects through and they're people just like you and I They want to be comfortable and they want to know that these large engagements these large budgets that they're trying to get through through their Corporation are going to be successful and you're basically giving them an insurance policy that it will be and The process scales you don't have to think about as this huge monolithic thing. It can be fairly small You know for relatively, you know straightforward not complex sites that maybe just have one or two complex elements Maybe an integration or two, you know those we can just do some fairly quick Maybe just like a two-day discovery even where we were really just looking at that integration. We're looking at the API We're making sure we understand it that we understand the requirements and the communication methods and then from there You know the rest of it might be fairly easy We've also been pushing a lot lately for what we call you know sprint zero on our projects You know, this might be a very light sprint. It might only be one week It might not be full-time, but it brings the actual production team together and gets them in a room And a lot of this actually involves, you know starting to build out the backlog, you know Ideally, they've got a product owner available. I'll talk more about product owners in a minute But it's essentially, you know getting getting the planning phase together when maybe not a full-blown discovery is necessary but at least get the team planning and identifying some of the the complex situations or Or higher priority tasks Though of course on the opposing side of that we've done some discovery projects that have lasted multiple months These are very large engagements and they have decent sized budgets We've had some discovery projects where the budget for the discovery Was bigger than some of our smaller brochure where marketing sites All right enough with that. Let's get to the how So before we write our script You know, we got to go into step one and step one is we've got to actually go out and talk to people We've got to listen to some people Before we go Too deep we have to learn to accept our own limitations Most of us are developers by trade not all of us. I mean there's people that come into the Drupal road from from various ways But most of us are fairly technical minded and what we have to remember is that While we may know technology and software better than most people out on the street The people in these companies that we're working with they're gonna know their jobs a lot better than we do They know all the little details the gotchas the little things that we don't know and nor should we But if we really want to make magic happen, we've got to learn to meet in the middle We got to know where our institutional knowledge stops and where theirs picks up Before we run out and I did an interview just anybody because interviews are a huge part of this process You've got to be able to absorb and listen You got to be able to take in everything that they're saying before you make your opinions But before we go out and do that you got to identify who you want to talk to Of course, you're gonna want to talk to whoever's funding the project If there's a director involved someone in middle management. Yeah, they're there again. They're putting their their Reputation on the line with this project. You've got to make them happy. Of course However, are they gonna be the ones that actually use the software you build? Maybe but but maybe not you want to try to find the actual users of your system and talk to them and look at The users that are using whatever system they have today in an increasingly global world It's very important to pick how you're gonna communicate with these folks You know, I'm a huge fan of body language Not so much of doing it even though I make weird gestures But but I'm a huge fan of observing it You know, they say body language can be up to 55% of human communication and I think that is very true So if you can when you do these interviews go in person if it's possible to physically be there It's worth it. If you've got to add some budget to the discovery project for flights for travel do that It's very important that you're able to observe not just, you know, what they're saying, but what what are their eyes saying? What are they thinking of? What are their hand gestures?  You're not going to know that if you're not there at the very least try to do a video chat But whatever you do don't try to conduct these interviews via email. That's that's essentially Almost insulting. It's it's a waste of time Do keep in mind that when you go out and do these interviews some of these stakeholders may need to be put at ease They may be a little nervous You know, whether we want to admit it or not people are very tribal and territorial by nature We just are and so when you walk into a corporation as an outside entity talking to them about how you're going to Introduce this new software this whole new solution that's going to change the way they do their jobs every day Some people are going to be nervous You know, if they seem hostile towards you, it's not don't take it personal. It's not you I went into a company recently where they had a team of eight people who their entire job was to manually take emails and believe it or not faxes and retype everything into one system and then they were also retyping it all again into Excel and Then emailing that out to people and then it walks me saying how I'm going to automate their entire process These people have job, you know, they're it's their job on the line. They have maybe children at home They may have to pay for their house for their cars Were they comfortable or happy to see me when I come in there to say I'm going to automate their job Of course not But you have to try to make them feel at ease because in the end you do need them and you need their help You have to be very humble with them. You have to let them know that you're going to work together and try to make things better You have no no ability. I mean hopefully it's not your responsibility What their supervisors or superiors tell them to do after you automate their job? But at the very least you need to to cultivate a relationship with them so that you can get through this process and and just hope that There is other work for them in the company that you're freeing them up to do something better Than manually retyping faxes All right, so we're going to interview and really the most important thing to do is to just be quiet To just listen and that's more difficult than it may sound In the end we we are very excited people a lot of us in Drupal We really want to talk about the solution we want to provide we really want to like have this plan of action But we have to remember that this is not the time for us to say those those plans This is our time to absorb. This is our time to take in what they're saying and After we've done that we can form our opinions Always remember if you're telling someone your plan at this stage, you're not listening to what they're telling you right now in that moment You're also going to be very surprised how much the more you hear The more your opinions of what that ultimate solutions are going to be are going to change I do recommend you take notes during all these but even better yet if you can record the conversations and follow up and take notes afterwards If you're if you're not having to look down at a device or even a pen and pencil and paper Then you're you're more freed up to view that body language those those non-verbal cues And you have to make sure you're actually asking the right questions, especially if you've like flown To see these people you don't want to just be asking them yes or no questions You want to be asking questions that make them have to think to make them have to explain to tell you a story You know you didn't fly all the way across for yes or no You have to think of yourself as a detective and you've got to you got to solve this this puzzle this this this case And you need to be looking for clues and you only get clues by making them tell you stories couple questions I like to always ask I mean of course there's whenever they start saying something and you sense that there's more there of course tell me more about that But a couple good ones are like, you know, what do you want at the end of all of this? Or another good one because a lot of you know, especially middle management. They're uneasy about the budget I'll ask them other than money. What does this cost you? Or what is the risk to you if and then propose a couple scenarios and just see how they respond to that You do want to go into these these interviews knowing what you want as an outcome You want to know what you want to have at the end when you walk away But you also want to step back a little bit and think of yourself is more like nudging or guiding the conversation But feel free to let it go wherever they take it More than anything if you have the opportunity have them give you a demo a lot of us go into these Enterprises and we think about how we're gonna demo something switch the mindset. Let them demo what they're already doing That's almost every single time. I have a client walk me through what they're doing today It radically alters my opinion of what I need to build for them tomorrow Bonus points When you do this you see the solution that you have to be better than you know You have to be better than this thing they have now and it gives you a target But more importantly as they walk you through everything It's a great opportunity for them to show you all the pain points for you to basically see it firsthand The things that take them a long time the things that are repetitive These are all opportunities to make their their next solution even better And when you're finished make sure you step back after all the interviews and you take some time to compare notes across them all When many times I go into these large corporations and you find out that one department doesn't even have any idea What the other one has been doing for years even though they work together? recently went to a very large distributor of foods and We talked to three different Branches of the organization and all three departments thought that one of the other three were the ones that actually entered all of their Customers into their their customer database Still to this day. We don't know who actually does It's got to be one of the three, but they all think it's someone else Sorry, we've listened to them and now it's our turn to make some deliverables some things. We're going to hand off My best advice is don't limit yourself out of anyone in your your organization if someone has to be flexible It's going to be you you're taking whatever it is that this client gives you this idea this concept Whatever it may be and you've now got to funnel that down and whittle it to something that your team can can actually make And so you have to have a very diverse tool set Now of course you're going to want to be have some tools that you use frequently you're going to want to get really good at certain ones You're going to want to have certain packages or Plans that you execute repeatedly and you get very efficient at it But when you notice that a client is is different be willing to go and an experiment to try different tools Every client is going to be their own unique Experience and even if they're building something similar to something you've done before Odds are something's going to be different Even down to you know, just communication styles Before we talk about some of the tools we use at metal toad just want to have an awareness or make sure that we we all know that You know, there are these larger architectural planning frameworks out there When I think about architectural planning, I like to think of city planning I Lived in Los Angeles for about ten years. I Lost years of my life driving on those roads Because if you think about it When you've gone through cities that have been very well planned where the infrastructure is very well organized You really notice that compared to cities where that is not the case But when we think of architectural ecosystems, I like to I think this is a great analogy because you've got all these different You know plumbing, you know architecture all these different connections different systems I think it's fairly similar But when we get to talking about these types of systems, I mean you're really going to want to basically opt for for some framework At metal toad we've been using togaf recently, you know the open group architecture framework We've been working with a fairly large client that has been using that for years And it did really improve our means of communicating with their internal teams These types of frameworks each one of them could have a talk here today. So obviously I'm not going to go through them But if you want to do further research, there's great resources online. They pretty much all have training programs and But that's again, not really this is when you're talking more of the larger ERP type systems the very very large Not really what we're talking about here today. So let's go back to talking about more Slightly smaller into our Goldilocks zone again All right so one of the favorite my favorite personal tools on my workbench is Whiteboarding metal toad we have whiteboards and every off every planning room We have whiteboards all the way down the hallways. We have every conference room We love whiteboarding Because again rapid ideation very quick sketches brainstorming If something isn't panning out you just erase it you move on, you know, if you can't draw It doesn't matter the client doesn't ever have to see these the world never has to see these that it's just the process of brainstorming very very low cost of failure Very high probability that you will stumble upon a great idea But whatever you do just make sure you're staying very energized and actively engaging the rest of your team get everyone involved All right, so we've done our interviews. We've done some brainstorming sessions and now it's time to write our script Our script is our user stories Now what you may be thinking is the product owner is supposed to write the user stories That's great in a perfect world But it's not a perfect world. We're agency life and a lot of times our product owners You know, they're not trained They're coming from the client a lot of times and they don't really know what it means to be a great product owner And at the beginning of the project, we usually have to help usher them into it We have to help train them on how to be a product owner. So a lot of times Very often we end up doing a lot of the initial User stories and we do it with the product owner. We work with them and we work from the interviews But but we end up drafting a lot of them It's not perfect world wish it was but but it's not and a lot of times You got to remember that these these large companies if they're coming to an outside vendor They probably don't have a resource available, you know, they're coming to you for a reason They're outsourcing work to you even if they know because they probably have their own teams But for whatever reason that person's either not available or already overworked And so they're counting on you for for many of these things One thing to keep in mind is you write your user stories write them for the audience that's going to read them We played around for a while doing gherkin So we do be had a metal toad and we realized that when we had to get approval from the people in the companies They weren't actually reading the stories because gherkin was still not close enough to English It still seemed a little Nonsensical or whimsical to them and so they would get partially down a few pages and just sort of zone out and not pay attention Well, if they're not actually looking at the stories and approving them and and moving forward Those stories are just for you and that's that's missing the point You want to make sure that whoever needs to read and approve these is going to read and approve them We do a lot of diagrams at metal toad because a lot of times, you know, it's just easier to To say something with pictures than it is with words So this is a lot like our conceptual design where we're talking about a lot of our connections between objects and our methods and properties But the first thing you kind of want to do again also looking at your audience You know, you want to write it you want to make the diagram specific to whoever you're going to have actually viewing them Is it going to be or is this diagram meant for your team during development? Is it meant for the client's it team or is it meant for the the stakeholders? Is it meant for executives? All those are going to require different styles of diagramming with different levels of complexity You certainly don't want to hand an executive a very detailed UML document if it's not the CTO You know if it's the you know the chief marketing officer, they're not going to understand what they're looking at most likely We do a lot of UML, you know, of course the bonus there Unified modeling language of the bonus being that pretty much anyone who's gone through computer science has is familiar with it you know people can read it and Especially if you're handing off to the client's it team, they're going to be able to work work their way through it But also don't be afraid to you know, touch it up make it look a little prettier No one ever really said that you can't Especially if these do need to send this off to some of the other teams We do a lot of process flows these come in handy, especially when we're doing anything that involves workflow You know business system portals We usually do a lot of these it really helps communicate You know the different user roles and how the flow is going to go across those different swim lanes to get to a bottom and End here a lot of times these can be referred to as user journeys We also do a lot of you know system flows user interface flows and decision trees, which are all Loosely similar to this It's great to show the clients it team how you see your system fitting into their existing ecosystem You know, they should be able to see how other systems are going to interact with it And you know basically what you're giving them some context around where you see your solution fitting into their Existing other solutions that they are already maintained The clients it team may also want to know exactly how this new system, but it's going to look like, you know They may have to maintain this thing after you're finished, you know, or Alternatively if they don't once they look at the architecture of the stack if they feel they're not capable of maintaining it They're going to have to have some heads up to to go out and find someone who can whether that be you or some other vendor If you're going to be integrating with their other systems It's probably a really good idea to give the clients it team some very decent details on Exactly what that connection is going to look like they're going to know what ports you want to use how you're going to authenticate How the data is going to flow You want to be able to map this stuff out for them way ahead of time? Keep in mind enterprises are going to move a lot slower than us quick nimble agency folks If they need to open up firewall rules or they need to set up things on their end to enable this integration You want to give them plenty of time and you're going to be able to tell them exactly what they need to do? So moving on to wire frames This is our equivalent of the storyboarding When we break out the wire frames at metal toad hands down we get the best feedback of any of our other tools the highest quality and quantity of comments from our stakeholders Ever hear that a picture is worth a thousand words You can talk to the client till you're blue in the face. You can show them all these are stores you want But as soon as you show them some diagrams they get it they understand it clicks They know what they're going to need to do with this software at that point. They don't have to use their imagination They're not filling in the gaps with their conceptions or potentially misconceptions of how software works You've you've essentially filled in all those gaps How high fidelity you make these can vary it depends on who's seeing them again, and it also of course You know how big is the budget? Do you have time to get detailed on these if you don't that's fine You can do them very rapidly But as long as you're conveying the information and it creates a springboard for further conversations Do you need to be artistic to do these? I'm not going to lie. It certainly helps It certainly helps if you have an artistic background or if you have a lot of user, you know UX experience You know if you've done a lot of UX But even if not, there are some tools out there that can help you. I'm a huge fan of OmniGraphil I like it even there's one reason I like it even better than using Adobe products for wireframing And that's the stencil kit library. You can very easily just drag and drop As fast as you can from the library right on into the page and make high fidelity wireframes incredibly rapidly almost as fast as I can think them up The other nice thing about that stencil kit is it allows you to make custom stencil kits So you can go in and make one. It's actually branded for your company I also do all the diagrams that I did previously that we were looking at I do all those in OmniGraphil as well and all those little icons were from our metal toad stencil kit So an added bonus there is if everyone on your team is using the same tool You can share a stencil kit. You have consistency across all your different team members So proof of concepts So sort of like the the animatic that the animators were doing Sometimes we do have to take all these things together and put them together in a proof of concept a Lot of times you're actually figuring out can your team actually do the thing that you think you're able to do For these we say roughly about 70% confidence is about all you need to achieve You don't want to be 50% sure that you can do this thing because 50% sure means you're taking a 50-50 shot on your team Have to work nights and weekends for there to be pain in their future But of course if you do 100% well, you've probably already built most of the thing so You're almost done So about 70% confidence means you're fairly sure you're going to be able to build this thing You you you're feeling pretty good about it. You're ready to move on but sometimes You don't have to write fully functional software There are instances where you're simply still trying to to prove that the whole concept is a good idea Sometimes clients will come to us. They've had that big crazy idea They we've started to talk about and we've realized what this would actually look like But they still need to you know push it up to their Executives to get approval to get budget and sometimes you just have to convey You know basically what is this thing going to look like for those types of prototypes make sure you time box them Don't spend too much time on it. Don't plan on it being something that's going to move into production my my baby brother is a civil engineer and You know when they go in and they make a prototype You know they're going to make with their they're building like a new bridge You know they're going to build a prototype. It's going to be a little four-foot wide balsa wood bridge They never intend for a truck to drive down this bridge That bridge that balsa wood is never going to go and be a real bridge It serves a very important purpose, but it's temporary by nature and I encourage, you know You know folks in our industry treat prototypes as temporary We do a lot of stuff in envision If you haven't checked it out you can I believe there's a free demo You can do like one project for free. It's really cool. You can upload a lot of photos You can walk through but most importantly the thing I love about envision that you know I love I love doing demos and actual code, but What actual code doesn't give you that envision does is commenting You're you can invite the client and the stakeholders into envision They can browse around in the little mock-ups that you make and they can comment right on top of things and you can actually have conversations as you're going through the the Process of making the wireframes and prototypes Sometimes you just need a little bit more pop You know sometimes you just really got that get to get that project sold So here's a case for a discovery project that we had done this was for a large Fortune 500 company and The end of the discovery project was to actually give a presentation to a whole like a big shark tank style panel of C suites and and directors and So what we really wanted to do when we walked in there Was to to allow them to actually touch it to have it on an iPad that we could pass it around that they could Actually play with a mock-up a prototype of what the system might be You just can't be tactile and so yeah, we went in we did a great presentation We did some had some leave-behinds and it all the stuff, but honestly the the prototype is what sold it You know, that's the thing that that made it happen now The dirty little secret is is that prototype is nothing but HTML CSS and JavaScript We did not put a lot of time into this You know we put more time into the design and the concept than we did into the prototype that was just a Movie prop more than anything documents, so This you know, I know we kind of talked about our script being our user stories, but these are documents are also part of our script So depending on the size and nature of your project you might deliver several other documents You know the most important being the big discovery document And then of course a statement of work because if you've done all this work to plan for a big project You're gonna want to be able to actually say okay now Here's what it's gonna take to build it and here's the basically the contractual agreement In addition to these depending on the situation you might be doing also a pitch deck risk assessment API contracts comparative analysis data migration plans Any dozen of the available? Deliverables that you have in your workbench Our tool of choice for all of these is Google Docs Beyond our team we generally share our documents with our clients. We'd like to have full transparency the entire time We highly value this transparency. We love it when our clients give us comments right down on the side The sooner we know we're going down the wrong path the sooner we can fix it It's a general rule of thumb for documents again. I love taking lessons from other industries like journalism Have any of you ever heard of the inverted pyramid? Inverted pyramid is basically putting the most important stuff at the very top and working your way down to the stuff that if someone's not really Reading it's not very important that they don't see it So one of the very very first things I like to put at the very top of the things that we absolutely need to make sure that Everybody sees the critical stuff the content that you absolutely have to have conveyed to these stakeholders Below that anything that's going to require them to take action again as I was saying they're going to be slower moving than us So give them the heads up as fast as you can on anything you need from them From there the bulk of the actual implementation plan. What are you going to actually do? What does this look like? What are all the topics and then at the very very bottom the stuff? That's really mostly for your team. It might be even be stuff that they all the client already kind of knows So the discovery document, this is the big one. This is the big thing that we deliver You know we whatever we call it changes depending on the client whatever they want to hear we don't care We'll change the title But whatever you call it this acts as the the binder of everything that you found it pulls everything together Definitely keep the audience in mind when you're writing it. Who do you need to read this? Don't use jargon if they're not going to understand jargon if they don't know Drupalisms don't put Drupalisms in it You know or at least you know keep it You know to to a point that they're going to be able to follow When I start on one of these documents I Usually start by writing my outline first at the very beginning of my project I'll do the outline all my I'll start by doing all my h1s and these are usually the biggest questions I have about this project and then within each h1. I'll do some h2s and if I have to do h3s I'll do that too, but usually try not to go down that deep From there I actually use this as my guide as I do my discovery project basically. I'm filling in the blanks I'm asking all the hard questions all the things I didn't know and throughout the course of my discovery project. I'm filling in all the content Does my outline change by the end of the discovery project probably and that's fine That just means you've had insights gained and that's that's perfectly acceptable But it does kind of like set the the whole path of the discovery project Oops, I was supposed to show you that slide first The very next thing I like to show are you know basically some of the links to the other Other things they need to see make sure they know that other stuff exist If you've got other documents some of them may be too large to include in this one like the user stories document Usually that's fairly large or I'll link out to like the envision so they can see the prototypes You know also very important and at the very very top. I like to do the project goals I usually keep these very very simple not even sentences These can be very simple like you know provide an interface for editing their catalog or increase hit rate by improving search results very simple From there I'll usually involve Some of the diagrams usually very basic high-level diagrams not technical This would be something that an executive could look at in one glance and understand what's happening Then I'll do some technical not again probably not the most technical ones that we've got You know a lot of those are going to come a little bit further down in the document But again higher level is someone at a glance even if the IT team is now looking at this at a glance They understand what's going to happen. What are we going to build? What's the stack going to look like? I've kept this all very simple up to this point I've kept it very visual. I've had very few words It's because when the C-suites are looking down through this You want them to be able to get it at a glance you want them to feel comfortable And then you want them to be able to feel like they can move on that they don't have to sit through their next 30-some pages of Document that you're going to have because once this thing gets moving. There's going to be a lot of information in this particular document You know we covered quite a bit of ground and we were looking at various API's we had to integrate We had system security user roles and permissions connections to some other business-to-business portals You know tons of things how they wanted to handle revisioning all that stuff But at the very bottom the very last thing I like to add are some calls to action and it much like the project The basic objectives at the very top very simple not even sentences these could be things like Sign the yes, you know receive and sign you this statement of work So the statement of work Kind of at a glance the way we handle this at metal toad We usually do these are about six to ten page documents depending on the complexity We're going to cover usually the project overview, you know the purpose statement the business objectives Overall the deliverables and like the success criteria. What does it actually mean to succeed in this project? You know and then we'll also be able to look at our timeline and milestones and how many resources we plan to work on this Those two things together are going to help us dictate the scope and the cost We usually define roles and responsibilities, especially if there's another one or more other third parties involved You know where does our work end and where does their work pick up? We talk about how we're going to do quality assurance How we handle our maintenance support and warranty and then one of my favorite sections is actually the assumptions and exclusions This is where you kind of get to draw a nice little safety circle around your project To kind of define where you as far as you're aware according to this contract This is what the project is not going to entail You know a couple good topics to have in there would be you know handling around multilingual You know that that's one that's that's bit us in the past You know and another great one is you know just down to what level of Internet Explorer are you willing to suffer? But at the very bottom, you know, we go through some of our boilerplate We go through the terms and agreements, you know, maybe some there's some other key features specific to this project And then of course at the very bottom is the signature I mean this is where they sign off and you do your big project. All right, so we've delivered everything It's time to hand it off to the client Wait, that doesn't Make sense The end of discovery project.  There should be no surprises had not even in the SOW They should already know about what budget, you know, because they've been in there looking at the dock Maybe not the executives or the C suites, but at least the directors you're working with So guess the big reveal is not for us We don't want to you know walk by and be like here's our master plan last thing we wouldn't have happened as them Say that's totally off the mark. So all right time to celebrate You've given them your your You know your your discovery document your SOW and they signed they're ready to come in and do the big project But your work isn't done you still have to work with your team So turn around and look at all of your team and you've got to be able to set them up for success Make sure you share everything with them everything you did during your findings, you know all the documents everything you've got Make sure you walk them through with those documents and that they understand everything and they know where the important stuff is I share my whole Google Drive directory with my team and You need to make sure that they're they're not lost in the weeds that they know where the important stuff is located If you happen to have known that the project was looking like it was going to be to go through Start to involve the team early bring them in on the discovery have them sit on some of the interviews and some of the meetings That way they're already partially informed because in the end when all this is said and done if your job like in my role I'm a consultant. I'm not going to be a developer on the project You know, I'm going to phase out as they start to actually build this project and as I phase out I've got to transition all that knowledge. I've got to transition the ownership and more importantly. I've got to transition the energy Because that entire discovery project you've been up on a stage and everyone's been looking at you from the client They've been talking to you. They're used to talking to you They're giving you all their questions and now you're going to phase out and you're going to walk away If you don't have someone else from the the actual development team carry that energy Then they're going to keep coming back to you their clients going to keep wanting to talk to you about things And that's fine to an degree, but you might have other work to do like in my role I've got to move on to the next discovery project So it's very important that you identify, you know a project lead or a senior developer You know someone who's ideally got experience working with clients that they're going to step up and be That representation of your company with this client Maybe it's a project manager Just just someone who's going to be willing to carry that and you're going to have some frequent check-ins You're going to remember that you planned this project You you were there for the form formulation of what was going to be executed So you have to be your team's compass you have to make sure that they're following the true north that the client Wants to head towards that they've they've got the right idea and continue on that path so show up at some of the sprint planning sessions show up at the demos and Certainly show up at the retros and just make sure that everybody is is still continuing in the right direction So that seemed like a lot of work, but was it actually worth it? first off let's go back and Back to reality all that stuff. I talked about you're probably not going to do all of it for every discovery project Most discovery projects are going to be fairly small I mean a lot of the stuff I walk through that like that 30-page document that was for one of those You know multiple weeks small almost a month-long discoveries, so there was a lot more work to that You know depending on the budget and the size of the project that's going to dictate how long you actually spend on these things But was it actually worth it? That's a very hard question to answer because frankly you Don't know how many icebergs the ship did not hit You didn't waste an entire sprint building something that wasn't necessary And you knew about that crazy integration to some custom built system that they had before you started development So you planned for it, so whether or not it's worth it is very hard to gauge But it's a safe bet that you're doing things right if You see a sharp decline in project escalations pre-launch blockers Change orders and developer face-palming The client trusts you and feels that you have a rich understanding of their business goals Your internal champion within the client gets a promotion a Stakeholder buys you a beer Remember these are the people that were afraid nervous when you first walked in if you've taken the relationship to a Point where they're willing to buy you a beer You've worked some magic And most importantly you're definitely doing it right if the client becomes a partner Thank you very much So I'd open up for any QA if anyone has any questions or I Think if you could use the mic because I believe they record so the the mic will actually go through Hi a lot. That's a lot of what you said really rings true for me One of the questions I have is around when you're doing User research is a huge part of your discovery process one of the difficulties I've had selling this in is that you know in your heart when you get a request from a client and They don't understand their users what they have asked for is totally stupid And you're going to have to go in there and say in the most polite terms possible When this touches an actual user you all of your assumptions in this document are going to change radically There's no point me pitching for what you've got now. So what I'd like to Hear if you've had any experience of that kind of pitch where you're going to have to radically alter what they're What their business goals are what their assumptions are with users? Absolutely, and you're right. That is a huge challenge and it does come up very frequently a great example I have of this just happened recently where I'm working with a fairly new client and we're doing one system for them, but then we started talking about this other one and To put it in perspective, you know, they're gonna a lot of times these stakeholders and the clients They're gonna stick with what they know and in this case they knew FileMaker 4 And so they were they've been spending the last three years building this system based on FileMaker 4 And when you put that in perspective FileMaker 4 came out in I think 1997 But it's what they know and so you're in that case it was a terrible idea and that's what they thought that their users were gonna want to use it was an internal tool and they had a lot of users internal to the company and You're right. It was a delicate situation because I knew it was just a terrible terrible terrible terrible idea And it's like how do you communicate that and you know the first thing? I think you got to do is you've got to you got to be somewhat humble and you can't just shoot them down because they've Been working very hard or they've it's their idea and they cherish it and you have to be sensitive to that you have to have empathy and You got to get them to explain certain things about that and maybe as you start to have them explain ask questions Not necessarily pointed but directional that get them to kind of start to admit some of the potential downfalls And if they can see those holes themselves if they if they even steer the direction towards them saying Some of those holes in their plan out of their own mouths You know a lot of times that's gonna go a long way and then once they've kind of started to to question things You know a lot of times it's I find it very useful to start to discuss well Have you thought about these other solutions? Have you checked this out? You know and start to like feed them? better ideas and Ideally if you do it right, they almost think it's their idea to switch it up to this other thing It's not really manipulation Parse Because you're actually helping them you're helping steer them towards you're steering them towards a better solution But yes, it's incredibly challenging Very sensitive any other questions all right guess we're all set. Thank you all very much


Good afternoon, friends. On the podium, all participants, friends of the conference, CBA 9 is moving on. Coming nearing a closer, we are moving on to CBA 10. But climate change remains one of the central issues of our generation, of our time, of this century. Unfortunately, climate change is here and now and it is affecting the human system and the communities. It is also affecting the ecosystems, the whole governance process of development, environment and climate change use. It is the greatest challenge human beings are facing and this challenge has been recognized virtually by everyone now including the President of the United States who has not been very helpful in the whole negotiation process over the years. However, there are opportunities to be looked into, into the whole climate process and CBA is such an opportunity of accessing the communities and trying to be with them, learn from them, assist technologically with methodology, with various issues and tools and trying to put forward the view of the most vulnerable across the world to the power be it. All communities are being affected right now, but very in degree and in degree of severity. Particularly the most vulnerable communities include a small island state and islands of other states. Coastal communities, pastoralist, migratory people, ice and glacier based populations, countless dependent on ecosystems, forests, agriculture and other land levels. Climate change has come here the whole planetary population but has to be confronted with seriousness, with science and whole climate process is science based policy research leading to action where what we are doing is integral part of that process. On the one of the two major ways of addressing climate change is mitigation and adaptation. We have been more engaged in adaptation, but if we do not mitigate rapidly we will reach the limits to adaptation very fast. Then we move into loss and damage, further into territories where we have not yet. Imagine how drastic that would be. So mitigation in the past, and this morning I said mitigation is the best form of adaptation, has to be done rapidly by the country and by the populations who are evicting host and should be done rapidly. The molecules do not distinguish what it has come from, not that that phosphate, but it has to be reduced. Two degree centigrade is objective and for many studies it shows that we have probably crossed that limit of trying to contain two degree centigrade. So the mitigation failures have led to much greater need for adaptation already. Hence community-based adaptation becomes so central into the whole debate and discussion. The whole issue of IPCC was to address this question and about ten, eleven years ago there was a big conference of IPCC in Fortaleza and the question was what is the dangerous anthropogenic intervention? About 700 scientists worked for 14 in this conference came to the conclusion that scientists cannot answer that question. It is a political process and the politicians must. And the politicians in Copenhagen agreed that two degree centigrade was the limit. But no systems are failing to contain it within that limit. Hence adaptation will raise like a very rapid economic loss beyond our conceptualization right now. One of the understanding of science is as I have said and others, modelling is they use as a tool and they do what is the mean temperature, two degree centigrade per second. Mean behavior shifts in precipitation. But it is not the mean, it is the extremes that are going to hit the population most. It is not the round the year, it is the second day where the water is one meter high or two meter higher. That is going to make the difference between life and death. That is making going to make the difference between population, moving or not. People's right at this point in time is what IPCC predicts about 300 million people in this place by the end of the century. We see few displaced people in the Mediterranean Sea. We see some in the Middle East claiming themselves to be states where we do not have the laws, migration hasn't really started. And we have studied migration for a long time and one of the basic principle learning is that people do not want to move. They don't know how to live their home easily. So they are forced to move. And what that happens, the whole stability, all intergovernmental process is based on governments and nation states. Those nation states are being challenged and will be challenging also. The whole climate issue has been taken with far more rigor and vigor than our governments have done so far. So, as we call here, adaptation must. There must be resources for adaptation and that has to be done rather fast. We, the severe community, will continue our journey. We started a bit earlier than 2004 or 2005. We had the first world conference on communities adaptation, severe one. Since then we have moved to various countries. Tanzania, Vietnam, Nepal, Kenya, we are going back to Bangladesh again. So, on behalf of the organizers, the co-organizers, IIT, BCS, and for this occasion our co-organizers will act. On all of their behalf, I welcome you to Bangladesh. Sometime in action, I am not giving a date yet. In Dharka, in Bangladesh, I will let you know as time passes. On the theme issue, we have been talking about, we, the community, engage people for all. In Asia, Africa, there are very few totally exclusive urban people. What we call is rural urban continuum. They have a holiday facility, they all go. So, it's a continuous process. So, our definition of urban is based on rural urban continuum. The resource when it comes to population in a climate change world, that we have done the studies of 9 countries where we have tried to. So, it's a much larger issue. So, those of you who are here think that, oh, I don't do urban world connections. And there are immediate connections, there are remote connections with urban issues. So, always think, open, we will keep it very open. It will be a learning exercise similar to this and we will learn from here. There has been significant difference between what we learnt in Vietnam to the modality how we organise the conference here. But there have been far higher interactions, much more integrative system, more space, more opportunity. And we will try and improve on it, hopefully, if we get your input as Salif has requested to set quickly. So, we will be on it and we will take that message, those messages forward. It also only leaves me to say that thanks to AACS for all the fantastic backup support and to the Indian government for all the support that you have given, Salif, for virtually holding as the additive to the conference and doing all the hard work and colleagues of IAED and Miss A.S. who have put in all the work behind the scene where I am Salif and then we are much more on the front. So, it has been on the journey. The journey goes on. It is the milestone. We again move on and we move towards Dhaka from here.  Hope to see you in Dhaka in April 2016. Thank you very much.