Planning your next project BoF

TIM ERICKSON:
My name is Tim. I work at, my company is Triplo. One of my colleagues here, John is with me today and helped inspire this talk or this discussion. And this is a discussion. So, I'm a big fan of the un-conference format or when I go to MidCamp, it's usually I like to attend a lot of barfs and talks. So, this is not a presentation and I'm not here to impart all my wisdom. In fact, part of the reason I selected this topic, is it's something that I'd like to learn from other people about as well. Like what else you're doing. So, the format I have in mind for today, I have a Google Doc and I'd like for us to jot down some notes, but the format I have in mind is for us to really introduce ourselves, talk a little bit about maybe what we, if to the extent that you're willing and, or have ways of doing it, to share your own current processes for planning projects and or questions if you have them. So, I'll tell you a little bit about sort of my own background and in how I do things to sort of set the stage for this discussion.

And then I'd like to go around and again, the intent for this is to be very interactive and for people to participate, if you don't want to, that's fine, but I'd like to hear from as many people as possible. I had been doing Drupal and now I do a lot of backdrop as well. If anybody has questions about backdrop ask me later but I still do Drupal and have been doing Drupal for almost 10 years now. Most of that time has been either as a freelancer or working in a small shop with a small team. I have a lot of the projects I've done in the past have been just me or I've done quite a few of those certainly early on where you know, I would get a project, talk to the client, sort of scope things out in my head to some extent and then just start implementing it. When you're working with yourself. The process can be a lot easier. But over the years I have added a couple of contractors that work with me as well as I partner with John on a lot of projects. John is a designer and that has introduced, made the workflow a little bit more complex, for example.

And I'm beginning to find myself in situations where my role is primarily just a project manager. And now I've got a designer involved and I've got some contractors I'm passing work off to. And John is even some of the projects have come through him. And so sometimes he started conversations with the client even before me, or in parallel with me, which is something I'm getting used to where I'm not like the primary contact with the client. And so John and I are the part of the impetus for this topic was to, John and I had been talking about like, how do we, if we're working with even a small group, we need to plan our projects a little bit better and we need to get better at that. And so how do we do that? And we've been experimenting with things and I'm happy to share the things that we've tried, but by no means, am I here preaching that we figured it out, but I'd love to hear what other people have to say. So let's, first of all, I would like to just hear from other people, who you are and what you're looking for.

And are you here with secret recipes that you can share with us? Or did you come with your own questions, anybody care to go next?

JOHN:
Well, I'll check in (INAUDIBLE) the time. And I met Tim during my tenure at a small Minneapolis factory as an instructor that's focused for 25 years and working with nonprofits and food crops. And so, as you might imagine, we've generally been working with very small budgets by comparison with larger enterprise websites and things like that. And then I was just sort of pulled informally into the process. You can never really properly school from the topic that we're talking about today. Tried to just bring the best of common sense that I might or might not have to the process. And as Tim mentioned, I've a number of the projects have taken the lead and trying to sort out, you know, the basic side effects the navigational scheme, in addition to the interface design and that's the sum of parts that come out of my background as a creative director and working on message development and brand identification. And that as Tim said it's already been ad hoc. So, we're learning as we go. And that's, I think the emphasis for this session, to put our heads with some other people who have different experiences and see what we might learn.

TIM ERICKSON:
Ad hoc is definitely the word of the day for us. And, you know, I don't know that there is one secret recipe for this. Every project that we do is a little bit different. I just shared the Google Doc link in the chat, it's also in Slack, if anybody Is on Slack, but it's in the zoom chat If you want to look it up, I just threw some things in there. Gwen, will you need to say something or?

GWEN DANIELS:
I was, I can go next. So I'm Gwen Daniels. My position, role is a little bit different than I think most folks. I actually worked for a nonprofit. I'm the director of product development at Illinois Legal Aid Online. And so I kind of sit in the middle. I have to deal with clients in the sense that I have to deal, I have to work with my boss, our funders the rest of the organization that wants me to build things, at the same time I also manage our contract developers and designers. I don't have all the answers. I do have some things that I like, there are some things that I like to use both for me and for my teams. We rely very heavily on Jira for working with the developers and daily check-ins with the developers upon zoom. And then for me personally, I live in Todoist.

JOHN:
What's that again?

GWEN DANIELS:
Todoist, it's an app, it's a cloud service app. It basically makes fancy to-do lists, and I seem to step off everything I need to get done today so that the developers can work tomorrow.

TIM ERICKSON:
OK. So, you said you have daily zoom meetings with your developers?

GWEN DANIELS:
Yep. They sometimes they last three minutes, but it's a good way to make sure, for me to make sure that they're doing what I want them to do then.

TIM ERICKSON:
So, when you say daily, literally, it's like on the schedule for every day and it might be very short or it might be long, but there's no decision each day, whether or not they have it?

GWEN DANIELS:
No.

8:
30 every morning.

TIM ERICKSON:
Great. Sure.

JOHN:
Do you focus on staff of your nonprofit or an outside firm?

GWEN DANIELS:
They're an outside firm. But they work on our website for money. So, they're (INAUDIBLE) they're just not staff.

TIM ERICKSON:
Well, I want to welcome Blaine and anybody else who just joined us, we're having a discussion here. And we're just kind of going around and talking a little bit about who we are and what our, how it is that we plan the projects, what tools and techniques we use. Does anybody else want to go next?

SPEAKER:
I can jump in here. My company is sandbox studio and we work for primarily for not-for-profits higher ed. And I guess our like more corporate clients are higher ed institutions and government labs FOR ME LAB, Oregon kind of national labs. So, we a lot of the times on smaller projects, we're working completely in-house and we have our team has a long history together, so we're we kind of wear multiple hats and pretty like shift back and forth pretty seamlessly. But when we go out of house for specific, like, let's say non Drupal projects where I need back end development or that sort of thing Trello is great for that. Well, I think when there's like multiple areas of focus like where I have somebody doing front end, somebody doing back end, and then I'm managing the client, I think like Basecamp is our go-to traditionally for basically to keep, to minimize emails basically, and keep the thread, but Trello's nice as far as having like a Kanban card type thing. And then I think one thing I I'd like to see if anybody's done is, as far as content, like generating content with clients, we're looking at moving into GitHub to create some sort of like having markdown files, replicate the structure of the site and then potentially having the client edit those.

There's like a learning curve for the client, like you know, non-technical clients learn GitHub, but I think that learning curve is minimal compared to working with word docs and like whatever format the client is most comfortable with as far as content on a large site. So, in a nutshell, that's kind of like how I'm thinking about this discussion.

TIM ERICKSON:
When you say GitHub, are you thinking about like actually using files in the repo to create content or the Wiki?

SPEAKER:
Yeah, it's a bit, it's called, I think it's called, it's almost like a Read the Docs or I forget the, the GitHub type thing, but it's essentially setting up a skeletal site using a kind of Read the Docs sort of a file format and then using markdown files to populate those pages within kind of a skeleton structure.

TIM ERICKSON:
OK. So this is a special tool GitHub has for that, right?

SPEAKER:
Yeah. I could kind of, I could track it down in the next few minutes.

GWEN DANIELS:
Yeah. So we use Read the Docs for all of our internal website documentation, and I started using it because I like to write in plain text editors and use GitHub, but now I've got most of our content team and everybody and other members of our staff are all on board. They think it's cool. It's really easy for them to do the stuff directly in GitHub and commit them, hit the button and it connects it and builds it out on, Read the Docs for us. And there wasn't like there wasn't much of a learning curve for them to be able to restructure tasks.

SPEAKER:
Are you saying you would focus on like a site section that you're putting like a new site section you're putting together and essentially prototype it from a very bare bones?

GWEN DANIELS:
I use it to basically write our documentation that I can turn around and use that to share it with developers, but at the same time, I can also use it with the staff, if they need to understand how the site works.

SPEAKER:
OK. Right. For documentation, that's how we have been using it too. Yeah.

GWEN DANIELS:
But my non-technical staff did not find it difficult for them to be able to go in and make edits to it.

TIM ERICKSON:
Gwen, are you suggesting that you create documentation before you do development?

GWEN DANIELS:
It only took me 20 years to learn that. (LAUGHTER)

TIM ERICKSON:
OK. Anybody else that we haven't heard from yet, wanna introduce yourself and tell us a little bit about what your goals are?

LE'RHONE WALKER:
Sure. I can go next, unless you want to go Blaine. I'm a big man for sure. So, my name is Le'Rhone Walker. I'm with an agency called bounteous we're based out of Chicago, although I live in Delaware and it's pretty neat being part of a company like that because even though we are full service, meaning we do a lot, we have a lot of capabilities in house. You know, our foundation really started with technology. And so from a tools perspective we mainly live in Slack for just like day-to-day communication. And I think to cut down on a lot of the email traffic, which was newer to me, we were acquired by Bounteous like a year ago from another agency in Delaware. And so seeing my daily email drop from, you know, almost a hundred to like 10 is pretty amazing. But from an organizing project standpoint and communication there, we were pretty much sit in the Atlassian suite confluence for most of our documentation. Pretty much stand by the, if it's not written down, it doesn't exist. So we try to document heavily and use that for now sharing and teaching and all that.

And then for, you know, specific project stuff, we'll jump into Jira to assign tickets and kind of manage tasks that way.

TIM ERICKSON:
So, yeah, I have questions for everybody, but I want to let other people talk.

BLAINE CROSS:
I can go. Hi, Tim. This is Blaine Cross. I work in the marketing department at the University of Minnesota, Part of the college of continuing and professional studies. And I'm the developer there for a lot of different things. But we have clients that range all over the place. So, we have some in-house ones from our own staff. And then we also, we've taken on a project that's actually covers the entire five universe or five parts of the university with twin cities, Duluth, Rochester, Morrison, Crookston and we do for their online components. And so we've been building lots of different things. Primarily we work in Asana. We switched over to Asana last year. Thank goodness. I've been trying to convince people to use Trello and nobody was paying any attention to me. So, but we finally decided that Asana after, you know, a committee process, it's a university. So, that's how that works. But we got to the committee to actually agree that Asana would be a good tool and it has been, it's been fantastic for, especially now for the last, you know, year not being in an office, it's worked really well.

So, I mean, it was surprisingly well. Building out an online conference site, for instance, that we did within a couple months that involved using Asana and emails to many of the people who were not doing the project were kind of outside of that. But we did daily meetings for that you know, iterating through the process. So, that worked out really well. I'm part of the university. So there's a bigger group. We use Slack for lots and lots of different things. And then there are parts of the year that use Atlassian but unfortunately the way the licensing went, they kind of locked unit into using it last year. And then that meant everybody else in the domain has to also be part of, I don’t know, anyway, it's a weird mess with the licensing that happens. So, I had to give up Trello at that point for my own stuff, because it was conflicting with how this larger university was using the product. And I know there's some units that have Trello and Jira and they use that. All of that. We've been finding though that our process works beautifully because we can reduce emails and we can keep everybody, especially, you know, managers can stay involved with everything, even, you know, multiple, multiple projects.

And we do things that are not just web based. You know, there's some print projects that get involved with this video production can be brought into that as well. And a number of different things like that.

TIM ERICKSON:
Blaine, can you say you were enthusiastic about Asana? What is it about Asana that you like?

BLAINE CROSS:
It was better than what we have, what we had before. I mean, we were using a portion of Salesforce. Don't ask me why that is supposed to help you with project management. And it really that was like, that was like one of the worst experiences of project management I've ever dealt with. It was so awful. It just, it meant I had a shadow system in order to be able to make sense out of what was coming out of Salesforce as far as I was concerned. Anyway, I mean, Salesforce is great for what it can do, but it's not a project management or task management system in any way, shape or form. So, now Asana gives us some aspects of it, doesn't exactly have Kanban kind of things. You can, there's a way to set it up that way. It's very flexible. It's fast. That's one thing I really like about it. Trello can be too, but and others that I've looked at, I mean, I've used BaseCamp before. I've used a couple other things on different projects, but Asana is well, you know, and it's across all my devices, so I have it on my phone.

I have it on a tablet. I can keep it, keep track of things anywhere I am. It does the basics that you need for keeping track of things. My only regret is that it is being used as a reporting tool to some degree too, so they can keep track of what projects are going on, where and how money gets divided out. So from my perspective, it's a little more, become more complicated just in terms of naming conventions and things like that. But I knew that was gonna happen. That's how my unit works and they like to name things and subdivide them. And that can be a little bit of a problem. If I was doing it myself, I would, it would be a lot simpler, but you know, there's 20 of us or so involved with it, so.

TIM ERICKSON:
Anybody we haven't heard from yet that would care to introduce yourself and share a little bit about your process, Tony?

TONY:
Yeah. Hi I'm Tony. I work for a company that does real estate websites primarily, but we do some small business websites as well. I don't really have a lot to share here. I'm kind of looking for ideas. We're a pretty small team. And we all worked in the same office before the pandemic, and it was only during the pandemic that we kind of had to get a little bit farther apart. We've been using Microsoft teams internally for communication, and we do that a little bit with clients as well. But just internally been very helpful to stay connected with people now that we're not in the same place. And we use GitHub and some of the tools inside GitHub as well. But I'm mostly just looking for ideas here. So that's, sorry, I don't have a whole lot to offer on that.

TIM ERICKSON:
Do you have specific questions that might?

TONY:
Not really, I'm just looking for ideas, we could always do a little better than what we're doing in terms of keeping projects on track. So, I'm just kinda trying to get information wherever I can.

TIM ERICKSON:
Do you, if you don't mind me asking, do you have like a project manager separate from the developer that kind of like lays out the project?

TONY:
We're a pretty small team, so we all kind of share the parts of the hats around in terms of what we do. So we don't really have a centralized way of handling that. So, yeah.

TIM ERICKSON:
One of my questions as I moved from your style, which is just sort of in my head or with conversations with a colleague, just approaching things one at a time is now I'm getting into a situation where I need to plan this out better. And it's like, so how do I create tickets for a whole project? Like do I, how fine grain should the ticket be about like create this field or should it be this great, this content type? Or should it be creating a feature and even questions like that? It's like each project I do, it seems to be a little bit different and I'm trying to find the right mix.

TONY:
That happens to me as well, each project tends to be a little bit different. And I tend to do a bigger issue tickets and be very detailed in what goes into it. And I use it to take notes and keep track of things. So, I keep a lot of detailed notes in those things. And I use the issue tracker in GitHub because I can connect it to actual code commits and things like that. And the pull request as well to keep groups of code changes logically together. That's mostly what we do to try to keep track all that stuff. But just like you, every project has to be a little bit different and we refine it as we go. And sometimes we, whatever the opposite of refine is. (LAUGHTER)

BLAINE CROSS:
: In our unit with, we do have a project manager who is involved with most things. Although the problem can be that sometimes they're not as familiar with all the technical side of things. So, you have to sometimes just say, OK, I need this kind of a project set put together. What we've been doing though with Asana is using the templating tool that it has in it and creating a template for different kinds of projects so that you have, like, we have some that, you know, there's gonna be a dozen different steps that are probably gonna happen in a project. And you can create a template that has that set of steps not filled out with anything else. And then all you have to do is just copy that out, turn that into the new project. And then you've got essentially the whole set of tasks in order, or, you know, in one place that you'll need as you go forward. And that saves an incredible amount of time and thinking process, then you can plug in new tasks, new parts of the project that you need very easily.

But having that template makes really has made a lot of difference for how we do stuff.

TIM ERICKSON:
OK. There's a couple, we're getting some questions in the chat, but I'd like to see if anybody else wanted to jump in and introduce yourselves first and share anything. I'm going to mention some names, but you don't have to Michael, May John.

MICHAEL GRAHAM:
I can jump on. So, I'm a front end developer for a company that primarily is Drupal. And then I also run a business where we manage WordPress sites. So, you kind of have both worlds, more so the larger team piece, and then the smaller team. And I learned that for smaller projects, Notion is a huge help for me. I don't know if anyone has ever used notion, but it's kinda like every single efficiency tool that you could think of wrapped up in a one program and you can create pages and tables and all this stuff and kind of make your own efficiency tool. And I have learned that using that between my own business and also day-to-day work as a front end developer has helped me a lot. It kind of helps fill in the gaps there where typically there's a lot of misses because you forget, or you didn't write it down or you didn't send out the email, which kind of helps keep everything glued together pretty tightly, at least for me it does. But in terms of like tools yeah, my day-to-day, we use Jira, which is pretty standard.

And then for my business, we typically interface with what other clients are using. So, a lot of is Trello or smaller little things that people find on the internet. But Trello is a big one that we use day-to-day with other clients.

TIM ERICKSON:
OK. Thank you. Anybody else want to jump in? Does anybody else use Notion? Michael had asked about that earlier. This was a new one for me. I haven't heard of it before, so I'll have to take a look. One of the question I have, does anybody have clients or stakeholders in their projects use the project management tool or is that all internal?

MICHAEL GRAHAM:
Our stakeholders, I believe they use it just to look at where tickets are, typically when they just moving around it and see status, right, I think that's as far as they go.

LE'RHONE WALKER:
Yeah. Similarly, we have, it depends, like, it's always the answer. Right. But we have clients for the products where they are involved in the stand-ups, just so they have like a daily check-in to see how things are running and where things are. And then we'll try to schedule a demo after about every couple of weeks to where we can show outside of the tickets, you know, real working code. And I think that that helps put a lot of people at ease that maybe don't understand the specifics of what's happening in a stand-up or when you read your Jira tickets, but they can tell when, you know, the homepage is put together or the footer has been updated, all that.

TIM ERICKSON:
So, when the client, oh, go ahead, John.

JOHN:
Really, I don't know that I even qualify as a novice, so (INAUDIBLE).

LE'RHONE WALKER:
Sure. Again, it may depend, but for a lot of our products, we try to schedule 15 minutes every morning where everybody who's working on project can just give a quick update as to like what you worked on yesterday what you're working on today. And if there's anything that's blocking you from moving forward, and that's just a quick way, sometimes you realize, well, this person doesn't have access to the repo. Like that could be a blocker that you may not notice until days into the project. And you find that out, hopefully if the first day by having meetings like that. And we try to keep in the 15 minutes so that, they're short you're not going into detail. It's just a quick update.

TIM ERICKSON:
This is a common, we've thrown around a lot of terms, if there's anybody else that has any terms that you'd like to explained, please ask. So, cause there has been quite a bit of jargon. One of the things that John and I have been, so a lot of our projects right now are with small nonprofits. Usually we're dealing with one or two people in the organization you know, projects are lasting two or three months. And one of the questions that John and have been debating a little bit or experimenting with is like at what point to start showing these clients our work progress, because there's the risk, especially at this level. If showing them things too soon and then they sort of panic because they don't understand that where things are at on the other hand, you don't want to wait too late in the process and not get their feedback, right. Because it's, so does anybody have any insights on like when you how frequently you engage, ensure to show progress to clients or things that really didn't work that you wanna cautionary tales?

Nothing to add there.

BLAINE CROSS:
I was gonna say, this is maybe related to it. Being able to prototype things really fast is crucial. I mean, we've been, we've tried a couple different things Adobe XD actually working really well for just showing, you know, you can copy out a chunk from an existing site and just plop it in, or you can create some, you know, components, cause there's just huge libraries available. It's super easy to change colors. You can even turn it into a work kind of a semi working model showing, you know, movement from screen to screen, things like that. And on different platforms, you know, on different viewpoints. And what I found it was really good for was I could show something and say, do you mean like this? Because a lot of times you don't actually get a good spec for what it is they mean, and they have an idea in their head and you show them a thing and they go, no, not like that. And then they'll come up with their own example and you can, they can, you know, you can see it and they can see it and you can then incorporate things like that.

So, having that kind of quick turnaround, I found very, very helpful. And then I didn't have to code very much either. And I don't actually have to build all the things that they don't want beforehand. So doing that as well, super helpful.

TIM ERICKSON:
So Blaine, you're not a designer, right? So you're not designing the site, or are you?

BLAINE CROSS:
Yeah, sometimes. I mean we had a design, I had a full actual full-time graphic designer and she retired. So, I've got another one maybe, but she doesn't do a lot of web stuff. She's more print. So I'm, so I get to do some of that too. And I mean, XD is a great tool for it because it, I mean, I'm not a great, I'm not great at Photoshop. And I don't really like how Photoshop produces those kinds of things. This worked really well and it had a great sharing feature too. So, it works nicely for that. And then they can comment as well. Cause it has a great interface for doing common comments on you know, on an ongoing project. So, it saved us a lot of time.

GWEN DANIELS:
Yeah. I use a similar tool, I use (UNKNOWN) which I get to do rapid prototyping. And for me it's really important to when I share anything with our staff is to preface it with this is ugly. I'm a developer, not a designer. I'll give it to somebody else who will make it look pretty. So don't comment on things like my font or my color choices. We're looking at this for the functionality of, is this what we meant to do? And then after the designer gets a hold of it and makes it pretty, then I can go back to them and say, and this is what it might actually look like if you liked the aesthetics. But to make sure that I've got the requirements down, I will do the quick prototype share it. They can comment on it similarly to the Adobe XD thing. And I can answer all the 500 questions I get from my boss. And then I can hand it over to the developers and say, this is what, this is how it should work. Not what it should look like, but this is how it should work.

TIM ERICKSON:
Right? So, you're suggesting that you are doing development and then having a designer look at it afterwards. This is, you know, I mean, I went through as a freelancer stage where I would just sort of build things out and then make them look pretty afterwards. But now I'm working with John and we've kind of reversed that where he does most of the design before we build anything. And that sometimes, you know, that has a lot of pros, but it has the con that sometimes John doesn't know how we're going to build it or what the easiest way to build it is. So, his design might not like it might be more complicated than we could have done it. And that's one of the things I'm trying to figure out and working with how do we balance that?

GWEN DANIELS:
Yeah. And I don't know that I have a good answer. I mean, when we did the last bill, when we did our Drupal eight update, and we did a whole complete new design, we did the design work first. But now we're at a point where we're adding new features. And so at that point, I'm doing more the functional work first. And then when I have money for designers, I can get the design work done to make it pretty. Otherwise I just use what I've got. And the developers know enough to keep it pretty.

SPEAKER:
I think there's a third component to that, which is what I was alluding to, that we kind of struggle with is content. Like you can, you have the structure, you have the, you know, the ideal design when people follow the rules of, you know, word counts and like following each item in the structure of the page. We've yeah, so we, the most difficult thing is that the client is the developer of content for our project. We don't, you don't have a budget for us to, you know, take on writing like a large site, let's say, or pretty much any site, nobody has that budget in our world. So, we do GRAYBOX wireframes as to get like the feel of going through the site. So, we can actually have, we actually I've requested it a while ago. And we finally got, it took us like five years to get it done, but we can do GRAYBOX wireframes in Drupal now, which is just a great, it's really fast for my designer to put together. And then the sequence of pages, the interaction can be experienced, which just, we were just running into.

So they would commit to something. If we couldn't do that, they would commit to something, we deliver it. And they were like, no, that doesn't work the way we thought, you know, there's that thing. So, I would say content though, I wonder if anybody has issues related to content that way, where you can do the engineering, you can do the design, but then when you actually put the real content in they managed to blow it up. Right.

LE'RHONE WALKER:
We try to push for content as early as possible. And I'm not claiming that this is solved because even though we'll put in the kind of planning guide, we need content by this date just about every product blows it, but where it is helpful, I think to everybody's point is if we're prototyping something, we are trying to use real content or content that could look like this. And so you're sticking that big reveal where maybe you mock-up something that's perfect and it has the perfect word length of text wraps, the best way ever. And then you drop the real content in there and it just looks ridiculous.

SPEAKER:
And Le'Rhone, are you saying a hundred percent of the time the client holds up the content? (LAUGHTER)

LE'RHONE WALKER:
Like we will most likely not be the reason this doesn't launch on time.

BLAINE CROSS:
Go ahead. Sorry, go ahead, John.

JOHN:
GRAYBOX, is that a platform for the mock-up wireframe?

SPEAKER:
It's just an approach where we would say we can just very quickly block in a three column to column image with followed by text. We just have some kind of foundational components. We're building a page component by component, and those components tend to follow conventions. So, we have maybe a toolbox of 20 components or something, or maybe it's more than that. So, it just it's GRAYBOX because the text isn’t text. It's just gray. You know, it's gray lines filling in space, or the resolution is that you can visually detect this is the resolution is Lo-Fi. So, the client can say, oh yeah, this is the page. I understand. The content that we had talked about is all there, but nothing's really there, you know.

JOHN:
Sure. Thanks.

BLAINE CROSS:
I think I need to have content in order to make things maybe not out of the very first stage, but really soon in. So, that's one of the things we really have been trying to get our users to understand that they've, we've got to have a lot of content. We've got to have really good examples because a piece I just did it, in fact I was making course tiles out of out of data that we were importing into the system and they had more sections than I thought they were gonna have. So, you know, I built it with, OK, we'll have four sections, probably that's the max number of sections, any course would have no, no, eight, 10. They just keep pushing in. So, suddenly your very careful design doesn't look like it's supposed to anymore. And figuring out how to deal with that when it goes live is lots of fun. It worked, it worked out just fine. But yeah, I wanna see as much real content as I possibly can right early on.

TIM ERICKSON:
I don't think we've formalized this in any way, but I think in the projects where John and I have collaborated John, I think you seem to do a pretty good job at trying to extract or create content early on for your designs, which we can then use in our, and it's not necessarily final content, but it's like at least a rough graph. Right?

JOHN:
Yeah. And you know, a number of the projects Tim and I have worked on are taking and listing sites and considering an update or a refresh. And I'd say as often as not there's really not a significant restructuring or redevelopment of the navigational scheme, but you know, some of them are more significant.

TIM ERICKSON:
OK. (INAUDIBLE)

JOHN:
Does this end promptly at 1:45?

TIM ERICKSON:
Le'Rhone can share, how promptly are you going to kick us? Are you going to drop the hammer at 1:45, or how does this work?

LE'RHONE WALKER:
No, I mean, if we go a little over it doesn't, the meeting won't end, but we do want to be conscious of the people coming in after us. So, we should probably.

TIM ERICKSON:
OK. So, there will be another, the same room as reused?

LE'RHONE WALKER:
Yes.

TIM ERICKSON:
OK. Well, that'll give us a hard stop once we start seeing those people show up. And there is something there's a whole there's other things too, right?

LE'RHONE WALKER:
Correct. Yep.

TIM ERICKSON:
OK. Good. One of the things that I think John and I on each project sort of re-invent and we'd love the magic recipe is that the whole discovery phase and figuring out what the client wants and needs. And I would say we we've been fortunate again, we're like rebuilt updating the site, moving a Drupal seven site to either backdrop or Drupal eight means that you have that existing site and it's like, OK, what do you want the same or what do you want different? I think I might've been most strongly interested in this topic right now because John and I are probably doing our first completely new site. John, wouldn't you say, this is one coming up where there's nothing, there's really nothing. There it's a large project, a multi-year project at the university that we're building a website for. And you know, there's no content, there's nothing to work from and we've already started the process a little bit, but that is really like, wow, this is gonna require a little bit more planning than we're used to because we don't have that existing site to sort of start from.

So, any buddy have tips for us? No, you're all struggling with the same problem.

GWEN DANIELS:
I would say anything that they've got in writing around the project, if they've in the nonprofit context, if they've submitted a grant proposal to funding your website development or similar, make sure that anything that they've promised other people you know about. Yeah. So, any internal documents that they have that they can share with you.

TIM ERICKSON:
So, one thing that we did in sort of the part of the discovery phase of this project that might be useful to other people. I went to a session a few years ago on writing Behat tests for websites and Behat tests are like human readable tests that say things like user logs in, and, you know, pushes the order button. Right. And you can write a test like that. And at some point during that presentation, it might've been at MidCamp. The presenter said you know, even if we never implement these tests just the process of writing them is a great process early on. And I have never, I have one client that I've used Behat tests with, but on multiple projects, especially if it's a site where there's multiple roles and people logging in I pretend like I'm writing my Behat tests like these. These are all the things that I use, an authenticated user should be able to do X, a site editor should be able to do Y, the site editor should be able to do. And I write out those tests and I find that to be one helpful way of communicating with the client and setting expectations and something that we can come back to at the end of the project and say, well, these are the tests or the, and this might be very similar to user stories, right.

Does anybody use user stories with project, with clients? OK. So any other ideas about how you'd do that part, you know, setting really clear expectations with clients? I mean, mock-ups, we've talked about that. That's a big one, right? But mock-ups, don't capture some of the especially internal or the editorial futures, right.

SPEAKER:
There are some project management, like project plan. You look at it like a project plan document that you might find. There's some kind of like open source versions of that, that aren't free, but they're open source. I got my hands on one of those and it just was super eye opening about every way that you should be pinning a client down compared to how many ways we're painting a client down. Like essentially anywhere we're not matching the super doc, we're exposing ourselves to being accountable for making changes later on the project or anywhere like having to readjust expectations with the client.

GWEN DANIELS:
We also, with our really large projects, we'll do RACI charts.

TIM ERICKSON:
What charts?

GWEN DANIELS:
RACI, responsible, accountable, consulted and informed. So that it delegates responsibility across the development team, the external stakeholders and the internal project management team of who is responsible for what decisions, who is expected to implement those decisions and who just gets to know about it, but doesn't really get a lot of input.

SPEAKER:
OK. Yeah. That would be, that's really helpful. We still don't implement that very well, but you can have, like in an organization, you could have 50 people mentioned in that document probably.

JOHN:
Gwen, what was the C in RACI?

GWEN DANIELS:
Consulted. I'll put it in the Google Doc.

TIM ERICKSON:
Thank you.

LE'RHONE WALKER:
I think one other thing that may be helpful is, you know, we try to outline our assumptions in a lot of detail ahead of time, too, with what we're not gonna do. So, there's a lot of alignment on these are the tasks we're agreeing that you're paying us to do. But also assumptions on what we're clearly not gonna do has saved us a number of times. No, we're not gonna migrate a million records of A, B and C out of your proprietary system, you know, or if it's included, here's a scope for that now that can make or break a project.

TIM ERICKSON:
Sure.

LE'RHONE WALKER:
Not to be the party pooper here, but I believe the next host is gonna sign in in about one minute. So, we probably have maybe a minute or two left for this discussion.

TIM ERICKSON:
Yeah. Well, does anybody have any other final questions or insights they want to share? John, I hope this has been helpful to you. It's been helpful to me.

JOHN:
Yeah. Very much. Thank you all of you.

TIM ERICKSON:
I encourage everybody for those of you who are new to this whole format, tomorrow is an un-conference here at MidCamp. And there's going to be a lot of discussions like this, and I highly encourage you to submit things you want to talk about and learn about a little bit like John and I did, which is just sort of take something that like we wanted to get better at and not, you know, not come in as the experts necessarily, but something we wanted to get better at and share information and exchange. So, I think the way I MidCamp is doing it is that the schedule for tomorrow, doesn't get built till tomorrow morning, right? But I think there is a place where you can submit ideas today and look at other ideas that other people have submitted, but I love this format and I love that you guys were all willing to share your experiences and tools and hope that this was helpful to other people. So, thank you.