Effective Project Management: Setting up for Success

NORAH MEDLIN:
Here in Effective Project Management. My name is Norah Medlin, and I live in Joliet, but I've lived quite a few states across the country in the last 15 or 20 years of my software development experience. Depending upon how you look at it, I actually did start more in the software development side of things and moved into project management here at Mediacurrent within the last couple of years. And I really love to work with great people and that's why I work with an agency versus corporate environment. That's how good, passionate drive of mine. And one interesting fact about myself, I'm not practicing right now, but I do participate from time to time in an organization called the Society for Creative Anachronism, where a medieval re-enactment organization. So think Ren Faire, but not actors. It's real people gonna camping and doing what we call wars where we beat each other up with sticks. So it's a really good time, good time. I would say a skills go. You know, we're here at Drupal mid camp and so Drupal is definitely on the top of the list.

I also have a strong background in Linux bash coming from the development side of things to do with rest APIs. And I also have a drive for entrepreneurship in general. I was a freelancer consultant for seven to eight years prior to coming to Mediacurrent. I really tried to do my own single owner agency for a while and I just didn't have a lot of people around me. And that's why I'm here at an agency today. So that's me. I will go ahead and turn it over to Eric, our senior technical project manager.

ERIK SCHWENKE:
Hey guys. I've been with me for two years now and I've been PM space since 2014. Recently got my CSM which is pretty cool. And today I'm gonna give you some stories from some different build projects that I've been on in the past, but my bread and butter at the moment is actually managed some of our largest retainer clients that we have with me, current. And nerdy fact about me, I love to play card games and if you ever played Magic The Gathering, I once won a tournament 20 years ago. And shortly after I joined Mediacurrent, I don't know why we never did this again because I was too good, but we had a speed typing contest and I came to find out that I was the fastest typer at the company. So sometimes people will be in meetings with me and they'll hear me ta ta ta ta ta. So, yeah, we're here today to talk to you guys about just some tips and tricks that we've collected from managing projects. And I wanna give you examples where I can. And Norah is gonna get us started.

NORAH MEDLIN:
Sure. Yeah. Yeah. I would say that a big part of the success of a project is setting up the overall structure, but also getting started on the right foot. So one thing that we've been working on at Mediacurrent and I've seen that most agencies do a really good job at is getting things done, but it's sometimes that getting started that's really difficult. So some key areas that we've found essential to this focus is on initial communication with the client and your internal team. So we'll go over that first and then we'll dive into some different ways to think about how to run projects in a way that will reduce overages, improve efficiencies, limit frustration. I think the frustration part is really the thing that I'm mostly focused on, honestly. Oop, I do apologize. Let me make this bigger if I can. OK, here we go. Periodically, though, through the session, I just wanted to mention this, that we will be going over some Q&A instead of waiting until the end. I think that I'd like to speak more interactive if possible.

So I'd love to hear some experiences that you've had as well. So getting started. Come on now. Getting started, when talking about the business and team client building, we also want to include some understanding about inclusion and transparency during that initial kick off process. We're gonna go over that a little bit. But many agencies are getting great at contract signing. Like I was saying earlier, that we're good at signing and implementing. However, often these delays can cause overruns, and when you're building the team itself and or getting kicked off. So we're gonna go ahead and talk about some of those issues there. As far as the resources are concerned, I just wanted to make sure to mention that, Oh I do apologize. I'll just look at my notes again. So for producers and production managers, we wanna make sure that they're involved as soon as possible in the project as well. I think that that's something that we'd like to see all of our teams work towards is having more of the team members involved earlier in the process.

And part of that next step is going to be getting synced up between the project manager and those primary stakeholders. So I'll go ahead and turn it over to Erik.

ERIK SCHWENKE:
Alright. So for those of you who do manage projects, does everyone feel like they have a pretty good sales handoff process with your account team? Could it be better? Yeah. So one thing that I like to do that I found that really helps a lot. And if you think of a project starting, it's kind of like the Big Bang. All these events happen in the tiniest amount of time, but it's so important to making things successful going forward. And what I like to do is instead of having jumping right to the kickoff call with the client and the team, I actually like to schedule an initial sync with me and the client because, you know, in most agency environments, at least in my experience, like use the PM, you're coming in, the project's been sold and you're just giving some kind of like brief heads up or preparation from your account team. And it's kind of like, here's the client, here's two sets about what they do. There you go. You're ready, right? Do it. So for having this initial sync, it lets you form your own impressions and perspectives about the client which you can use as you prepare your kickoff presentation that you're gonna have with the team.

So another subtle benefit here is this actually reduces tension between both parties. I mean, if you think about meeting somebody for the first time, like it's gonna be awkward, it could be uncomfortable and it might still be that way after a few times meeting that same person. But the key point here is it's gonna be slightly less awkward. So by having this little conversation first with your stakeholder, it's really gonna help set you up for success when you do have that kickoff meeting. And this can dictate how formal or informal you wanna be going forward in a project, and then you can relay that to your lead technical contacts or whoever is gonna be client facing on the project going forward. So if we think about this like a happy hour versus formal dinner like this does not have to be a long call. I would timebox this to like 30 minutes. Prefer the happy hour analogy about two beers. So your sales team spend all this time warming up the client and you know, you wanna get them warmed up to you, what your personality is like, what their style is like, gauge their comfort level and kind of find out like, are they a power user of their own site?

Do they have a development background? Are they a non-technical person who is gonna meet a lot of high level breakdowns? You can kind of suss all of that out with this first conversation with them. And then another key element here is keep the audience size small. So if you're on a bigger project that has a ton of stakeholders, try and limit this to whoever is gonna be your primary day to day contact, or if it's a smaller project, you could just bring in all the stakeholders that the audience size is like one to three. I found that to be most comfortable when having this call. And yeah, once you have this, you'll be set up to whether you're gonna send an email which Norah will talk about next, or just immediately jumping into and scheduling dates for your kickoff team and getting that presentation put together.

NORAH MEDLIN:
So, yeah, speaking of that email, you know, I would say that if you already have a relationship established with your client, let's say that you are in a previous engagement or you're in a support contract and you're moving into a build engagement, you don't necessarily need to have that sync 'cause you already are familiar with that client. But it may be useful if it's a change of worth PM, so still it would be valuable there. Otherwise, you might just send out an email to just get things kicked off. It's signed. You know, we're gonna go ahead and kick this off, when should we meet, who should be involved? And this is the bit to do with inclusion. So we also recommend that you go ahead and include in a statement or may be a good idea to do so just to double check to make sure if there's anybody that might have some needs could be just as simple as needing to take a break every 30 minutes or something like that. But generally, it's a good inclusion there as well. Just make sure I covered everything.

Yep. Yep. OK. So next, I do apologise. We just wanted to open this up. You know, I wanted to ask the room what do your initial communications with your clients look like? Do you have anything in specific that you like to include or that you like to think about when meeting your clients for the first time, when it's the sales hand-off and now you're meeting that client for the first time? Something like that.

SPEAKER:
So we have like a document that we have them fill out, which is all of the details of everything that we need access to, right. So instead of having to try and figure it out along the way, but that's part of that email that we set.

NORAH MEDLIN:
That initial email, I usually ask for that.

SPEAKER:
OK, here's all our questions that we have and then also fill out this document as well, which is really helpful.

NORAH MEDLIN:
Yeah. Yeah. I can definitely see capturing some of that access information is essential as part of that initial communication. Anybody else have an item? Sure.

SPEAKER:
I tend to do an initial kick off with that. I call like a coffee chat where it's like a little bit more informal, but my style is a little bit more informal with my clients. As you mentioned, like kind of like a happy hour, just like where things are. Get to know who's who in the zoo and then...

NORAH MEDLIN:
Coffee chat.

SPEAKER:
Yeah. So like we'll literally just grab a virtual coffee essentially.

NORAH MEDLIN:
Or if we're getting back to in-person, maybe it is in-person.

SPEAKER:
Yeah, exactly. If it's an in-person kickoff and it's like a physical coffee.

ERIK SCHWENKE:
Nice.

NORAH MEDLIN:
Awesome. Awesome. Thank you. Thank you. So in speaking of kicking off, that kickoff workshop, especially what we're talking about is on the client facing side, this can be a more formal workshop where we're getting all those stakeholders together and we are doing that kickoff meeting with all those particular key contacts from the client side to include at least the leads on your side as well. There may be other individuals that you do not include from your side. It really depends, again, on the size of your team, on both sides. But this kickoff workshop can be a really great way to not only, you know, break the ice with all of your team members are gonna be working together on both sides, but also get some better feel about what the stakeholders are looking for to get out of the project. And it may be more you know, we're talking like there's department leads on potentially on the client side. They're gonna be involved with this workshop as well. So it's good to sometimes let them voice their needs out in the open.

Maybe those department heads haven't worked together before, have the opportunity. So it could be an opportunity there for them to get to know each other. So you might have some exercises within that workshop like that icebreaker, but you also probably want to talk about their goals and what they're looking for there. And it will help to feed into the next steps around meeting cadence and things that we may not have covered quite yet in the stage of the process. So there's that kickoff workshop. Now, speaking of the kick offs, not only wanna have a kickoff for your external client facing, but you also wanna have an internal kickoff. So similar. You know, we're gonna have our project team, though, on the internal side that we are going to have maybe what you wanna call like more of a rah rah meeting that we're just getting together, getting to know each other. You know, again, in an agency especially, you might not have worked with all of the team members that you're going to work with on that particular project previously.

Maybe those team members have never worked with each other, so it's good for them to get to know each other, have some space to also talk about what their needs are, their ways of work, their specific preferred communication, that sort of thing that might be needed. So now we've gotten through the kickoffs, we're ready to go, right. But what's next? I mean, you know, I think that one thing, one fault or one thing that can happen a lot in projects is, yeah, you've started, you know what the project's about, but where do you start? What's next? You know, you really need to keep that drive going and not lose that steam. One way to kind of get in that direction, one tool may be to use a RACI analysis. Now, you don't necessarily have to formally do this every single time. I think on larger projects, especially if you have a larger project management team on the internal side or lots of leads that are gonna be communicating with the client, it may be useful to go through an exercise like this to determine how frequent and what level of communication that you're going to need to include which individuals from the client side.

This may also and I think you might have a story here, Erik, about how this has worked for you on workshops in the past or in kick offs this past.

ERIK SCHWENKE:
Yeah. So admittedly, I am not an artistic person by any means. So oftentimes, I don't even create a formal graphic like this. What I've found that works best for me is I like to maintain some kind of accessible note page or confluence page where I can note down my stakeholders kind of talk about who's who, what do they do, who needs to be contacted in what situation and that can really help, especially when you PM are gonna be out or if there's a transition of PM. So you don't have to go through that awkward transition with your stakeholder and the new PM or your backup person. They can immediately just refer to this page. They'll know exactly, hey, Barbara's out today. I've got this thing that needs to get done for UAT. I have to contact Tiffany instead about this, makes your life a whole lot easier. So one thing I can share, I have a higher ed client and they fit all around this matrix here. And it's kind of crazy because my day to day client is an extreme schmoe. Like she's the kind of person on her Drupal site.

Like she'll check the error logs daily and ping me on teams if something seems awry. But on the flip side, you know, she needs to be, she's actively engaged and she wants to be informed. But our actual decision maker on this project, the head of marketing for this university, she falls me far left of the top corner for keeping satisfied like this person, she will actively cringe if I mentioned JIRA ticket numbers. So I have to remember to never do that with her and explain everything just in terms of how does it affect the bottom line for their marketing department or their registration department, but being able to have these notes and then share them with my internal team is super helpful, especially for anyone else that's gonna be communicating with the client. So like I'm here today at mid camp and my lead technical director is acting on my behalf while I'm gone. So he knows exactly who to reach out to in this case.

NORAH MEDLIN:
Awesome. Thank you, Erik. One other last bit is that what is the next step? So I think it's always good practice in general after any sort of meeting, any decisions made that you follow that up with a summary. I think that it also just keeps it going. You know, I think that we're saying, you know, if we're thinking what's next all the time, it keeps the team not only external and internal focused, but just thinking about what those next steps are and getting along in the project. So this may include, this email if you did wanna formalize it may include what that next specific milestone is or a top level timeline of the entire project. So that may be some exercises that you would do again internally prior to sending out this summary. Now we don't have a Q&A quite yet, so I do apologize a little bit more talking here, but I think this is like the real interesting part that you may find valuable for this session here today. One thing that I found, especially in the freelance consulting that I did previous is there's always this lead up time to implementation where you really have to capture that information in that email that you were talking about with the form to fill out, of access information.

That's one part of it. But sometimes, it's more than that, right? It's about how is their system really working the way that does it work, the way that they think that it works? Are their goals in alignment with what they're looking for in the technology? There's lots of questions to be asking, and sometimes you can't make the best recommendation until you do this discovery piece in general. So you may have a situation where, right, where you have like a cart before the horse sort of syndrome going on that you also inadvertently may subject your clients to like the sort of smoke and mirrors sort of phase of the project where you're promising a lot of big things, but you're not necessarily really showing them anything of particular value just because you're trying to get through maybe a sales proposal or something like that can be a very uneasy portion of our phase of the project is this initial sort of phase. And to avoid this pitfall, I think that it's imperative that we set clear criteria as far as the goals are of the project, for sure.

A scope that's always a big thing that we wanna be focused on, but we also want to think about this discovery first to help bridge that gap between strategy and implementation. So let's take a quick look at what a world without a discovery first approach might look like. We might get that proposal and sign off here first, and then we move into some design and proof of concept on the technology side potentially, but we found out some things. So I think we might have to go back and get a change order. I think we might need more money. We already know that we might need more stuff in order to attain the goals of this project. If we go back, OK, we're gonna continue now into the next phase. Let's see if we can go ahead and build this thing now. Well, what do we have? Maybe again, during build, you get to dig in with all the knits and grits and everything and you find out you just need more stuff. You need more time, you need more resources, you need more, something more. Anything we forgot about on both sides potentially.

So I think I do wanna ask here right away, like what are some challenges with this process beyond maybe even what I just mentioned? One thing that I might suggest is that you aren't really getting paid necessarily for this discovery portion of the process. Sometimes this comes before sales is even signed off, right? Sometimes we're preparing this sort of information about what to expect. So you may not even get paid for some of this. That's a risk. But you also just don't know what you know, don't know. And you can be easily caught up in this change order sort of cycle. It could be way more than these loops. It could be, you know, five or six before you're really in the meat of the actual build implementation. You have a clear line of success towards that launch. So have you experienced this? I mean, I feel like I've experienced this a lot in the past with consulting and especially, but also in agencies in general. Any particular stories that you'd like to share that were kind of, I guess, in a way a disaster?

I don't know, maybe it worked out really well, but you didn't have any idea what you were doing at first.

SPEAKER:
Not a detailed story, but I could share the recent experience that we are right now going through.

NORAH MEDLIN:
Yes, please.

SPEAKER:
So (UNKNOWN) was their. And we agreed on specific set of scope. So wireframes were finalized. When we started designs, they kept on changing things. And we did a lot from what we were finalized in the wireframing and discovery stage.

NORAH MEDLIN:
Sure.

SPEAKER:
So now currently we are in conversation on what was the purpose, the very purpose of that wireframe, the discovery phase where my frames were being prepared based on the two way conversation. So we are still trying to figure out the way of how we could hit the balance and stay on track rather than deviating too much from the defined scope of work in the WI-FI discovery phase.

NORAH MEDLIN:
I was wondering, during your discovery phase, did you have anything like a stakeholder interview type process or anything going on? Like how involved were you? How much did you kinda do in that discovery phase?

SPEAKER:
So it took us about two weeks to complete the discovery phase wherein they were a project lead from client side and the business owner and from our end, a tech lead and a business analyst. Total four people were involved. And that they were having constant conversations.

NORAH MEDLIN:
With the client specifically? Yeah.

SPEAKER:
The documentation was prepared. They agreed upon it. This more or less covers everything. Let's finalize the wireframing now.

NORAH MEDLIN:
Sure.

SPEAKER:
The user flow. Let's complete that flow now with certain sketches, which obviously are not the final designs. So until then, it was fine. It all happened in a matter of two to three weeks. I mean, we just barely two weeks, but last for three weeks, which is OK times I believe the feedback so understandable. Now, recently we started designs. The actual UI interfaces in Photoshop and now they're like, OK, can we do this, can you do that? So we kept on agreeing to that and eventually we realized that we have started deviating from-

NORAH MEDLIN:
-the original scope. Yeah.

SPEAKER:
So now we are showcasing that, OK, it's not something that you want to argue about, but we just showcasing that this is what the wireframe was. This is what the documentation was. And this is, here we are clearly deviating in designs. You are completely.

NORAH MEDLIN:
So you kind of going through that sort of discovery phase. You found that maybe it was making it clearer what that agreed scope was and you had something to point to and kind of facilitate that conversation.

SPEAKER:
That is purpose of discovery is single source of truth.

NORAH MEDLIN:
Right.

SPEAKER:
So, thankfully, we are still in the design phase. I imagine if we are in the development phase, how much rework?

NORAH MEDLIN:
So you were able to catch it earlier?

SPEAKER:
Yes.

NORAH MEDLIN:
Oh.

SPEAKER:
You're able to catch it early in a tricky situation.

NORAH MEDLIN:
Well, then you're leading right into the next section here. But go ahead first.

SPEAKER:
I've got something that may be relatable for all of you guys, and you can stop me at any time. I can keep going on this. So we'll start two words fixed bid project. Next D7 to D9. Client had a front end developer on their side. They wanted to do decoupled with Gatsby. They would own all of the front end development work. We got all the requirements up front. We start this project, we come to find out that they had built all their content in D7 using analyzer and there's no simple.

NORAH MEDLIN:
And we're moving to the layout builder, was it?

SPEAKER:
There's no simple like migration path for us to migrate this content. So we're kind of stuck in this hole and you know, you have to have the uncomfortable conversation and tell them, hey guys, you're gonna have to rewrite all of this content on the new site. And because of all these stipulations and the fact that we didn't take the discovery first approach that Norah is suggesting, we had to end up compromising where our team allocated some time to helping them build some of the content on their site, which is, you know, super fun, right? Me is the PM in the hot hours of creating lots of pages and then actually using that to set up training videos for the client. So in some ways it ended up being a positive thing. But you know, it's like situations like that, you could completely avoid that if you were able to sort of separate discovery out of the process and have this separate engagement where you can get the client to to buy in and pay for you to do all this research and come up with a plan that you're gonna execute.

NORAH MEDLIN:
So leaning into that, you know, I think that this discovery first approach really is about empowering decision makers, not only on the client side, but also on the internal agency side as well, that what we're looking for here is, as you mentioned, we're talking about a separate engagement for this requirements and envisioning phase or discovery phase that it can definitely be a selling point that the client can take before the build happens and potentially go to another agency. You know, sometimes they're not always sure about you. They're kinda of testing you out and see how much you know or how much that you will be able to serve and partner with them. So that may be I've seen that as a good tactic. Now, normally if you do a good job, you know, you get the sale in that way, that final sort of build integration or implementation phase sell. But I would say that this discovery phase, like we were saying, it's all part of getting the nuts and bolts in order, in order to outline your objectives for development, help define the roadmap to implementation.

And having these objectives, like you were saying, helps to control scope creep. But also, you may find during that discovery process that your audience is different than what you might have initially thought, especially with that initial sync or even the kickoff. So there might be some stages in there where you want to go through some stakeholder analysis exercises and really dig into each of their roles and how they are using the site or what their expectations for their users are for that particular page or section. So you'll discover a lot. I think that really the point is here is that you really wanna be intentional with this discovery phase. One of the benefit could be in doing this is that your earnings could be larger due to this as well. It's not just about not knowing what you don't know, but you may find opportunities during this discovery phase that nobody thought about. And you may be able to take this into the initial implementation phase or into an additional supplemental phase afterwards at some point.

One other thing that I thought I might mention as well, this is more on the internal side. I think that by doing this, you increase the velocity and interest among your internal team members as well. I think that one thing I've found is that if you have a fixed bid situation, you might have to extend and that other sort of scenario and your internal team members might get fatigued and or they have their own expectations about what they're moving on to. So it's never a fun thing to have to kind of switch up teams in the middle or near the end before lunch. That sort of thing. So that might help to avoid those situations as well and increase your velocity and efficiency of your team. They feel like they have more confidence in that success marker with the launch. So breaking up phases into phases like this provides an opportunity for trading. Oh, I'm sorry. Just one other point. One other thing that you could do, though, that this might provide an opportunity is because that discovery phase is so well defined and intentional, if it is a very long sort of large project that we're dealing with, there is an opportunity, I think, clearly between the discovery phase and the implementation phase where you could trade up your team if you needed to.

And because you're able to package that up as a deliverable thing to not only your client but also your internal team, there may be an easier way to rebuild your team if you had to or if breeding new members for the implementation phase. But I would still think that in general, you wanna have most of the people, especially leads that are gonna be during the implementation phase during the discovery phase as well. So they're around to kind of carry that knowledge through the entire project. So one last section here and then we'll get into some Q&A here at the end. But I did wanna speak to this phasing kind of a general, more larger concept that found that I think if you look back like 15 or so years ago when Agile was really starting to kind of become a thing, people didn't really think about what that meant on a project. I think that you still kind of fell into this waterfall method with large projects for a long, long time. Then we started to feel like we had an idea about how we could still do sprinting and agile during a larger project, a larger implementation project.

So in that way, that sort of way I think is through this phased approach. So just to think about what this kind of looks like on a general sort of diagramming way is that you might have these phases here at the bottom and there's more of phases that are displayed here, but more or less that requirements and envisioning phase would be your discovery phase. It might include specific deliverables which is in the circles here of determining needs. There initially with requirements and visioning would be the tech validation, prototype and technical approach document. Those are like the deliverables that I was talking about that you would be able to send over to your client at the end of the discovery phase, and then your build phase might overlap. You might have some design happening in your discovery phase just to get some wireframes in there, at least some high level degree. But the bulk of your design would be in the build phase, including your implementation. You would have deployment that would go into that and part of the implementation and to testing as well.

And you have your rollout with the launch. So, you know, I think that what's kind of neat about this diagram, what I'm trying to display here is that everything kind of feeds into the next thing. So we're thinking already about an iterative approach of taking the information from the previous deliverable and or phase and feeding into the next. I think I covered everything that I wanted to say here on this slide. Oh, one other thing. The naming conventions here, they're just for discussion. Don't think of them as too prescriptive here. I think I just wanted to be a little bit more generalized with the sort of standards on the naming conventions. But please, as agencies rebrand for your own purposes and needs. But the bottom line here is that the communication and project management strategies like this are the idea here is to improve those partnerships in a way that you have a win win scenario between your client and yourself and your team members, you know, working with you every day.

So one other thing I kind of wanted to touch on here is the phased Agile, the agile portion of the phased approach. I kind of have a little bit of a graphic here that I can show you. So let's kind of focus in on a deliverable specifically and you can kind of think of any of these deliverables, whether it's the technical approach, documentation, the design, the proof of concept, whatever it is, even those initial requirements. And you can get people on both sides already starting to think about things in a sprint agile way. So what we're trying to say here is that it can still be valuable to break up even those phases that you typically wouldn't think of needing a sprinting. It still can be valuable because you can break up that work just like sprinting in general with Agile, but also you can have like smaller chunks that you can deliver to the client. So let's think designs. We're talking about wireframes or full designs that they have to approve. So you might have a certain number of things that you're gonna go ahead and deliver in that first, third, second or third sprint.

And they can then have the opportunity to review during that particular period of time for that particular sprint. And you can kind of control like how much feedback that you're receiving at one time and for what. One of the projects that I had here more recently, we actually had a smaller budget, so we were able to put scope around. There's only one feedback period per sprint type situation, meaning that there's an urgency here that we need to keep the timeline moving along. Sometimes you may have two rounds of feedback. It really depends upon your project, but you could control that and you could say, well, I'm gonna break it down into this and I'm gonna say, we're only gonna do one round of feedback. We're gonna give you five days to come back from your team about anything in particular that you saw on these pages that we delivered to you. And if you have anything, we'll incorporate that into the next. So, you know, in that sense, as far as Agile goes, we're still incorporating into the next sprint any sort of those recommendations that we got feedback on that we do wanna take action on as well.

I think tha was a lot to kind of throw at you. Here for a second as far as the phased and agile. But I think one thing to mention here is the without. The one situation I found, especially on the developer side, is this situation where we don't want a situation where designs are created in a silo. They're thrown over the fence to developers. They have lots of questions, legitimate questions. But if you don't have that design, engage in those designers still engaged with the team or vice versa, you don't have the developers engaged with the team early on. You might have a lot of going back and forth and having to increase scope as well on your internal side with resourcing. So what's good about this phased approach? What I found here personally is that you're taking smaller chunks, especially with Agile. You're feeding into the next and you're keeping your team fairly consistent throughout the entire engagement. And we're talking multiple engagements here, the discovery phase engagement and your build implementation phase engagement.

So let's get into Q&A. You know, how does anyone, I think that's my big question here. Has anyone other than I think maybe one has mentioned discovery phase so far worked with a multi phase approach? Do you have any particular stories that you'd like to share about it working well or not working well?

SPEAKER:
That's all we do is sprint agile format.

NORAH MEDLIN:
Do you do like a separate contractual, like you sign different engagements for the discovery versus the bill? That's kind of my big question.

SPEAKER:
I just wrote down that our designs are created in a silo.

NORAH MEDLIN:
Yeah.

SPEAKER:
(UNKNOWN) biggest problem. And that it would be amazing if we could, actually design during our sprints instead of we do wireframes and we do all the designs and we don't even annotate them right now. So I went to the Figma one yesterday and like to annotate our design. And then we turn them over. And there's just always so many questions. So if we could just actually design and I don't think that we need to do like an agreement every single sprint because our discovery is so good that we usually cover most of everything in there. Like, yes, every once in a while we'll come up with something during our sprint, but it makes it really easy for us to go. This goes afterwards because it's not something that we agreed upon first in our discovery. So but...

NORAH MEDLIN:
But you may be just having the devs in the room, you know, to just see what's going on with those designs, right?

SPEAKER:
Still not enough? Yeah, it's not enough. Not with the big, huge, complicated sites that we do. Like we just don't cover enough detail in our designs. There's so much that they have to take on themselves and make decisions about that being able to do that during the actual sprint process would be so beneficial. I don't even know if it's possible because the clients are the hardest part because they are so visual, they cannot think technically the way that we're presenting things to them that they have to see the designs.

NORAH MEDLIN:
Oh, for sure. Yeah.

SPEAKER:
That's it. So it's like, how do you convince a client? We're gonna start building this and we're gonna design as we go. They're like, wait, what?

NORAH MEDLIN:
Yeah, I think what I've found to be is more focusing on what you're presenting during the design phase or the initial design phase during discovery, the wireframe sort of high level is that you're producing prototypes that you have demo ball to the client for them to see what that interaction is. But you probably right, I mean I don't think honestly that there's an easy way to start doing implementation at the same time exactly. Though am I thinking here? Proof of concept maybe some ways that you could get the devs to really start thinking about how certain things are really gonna work because it's like, well, I don't know how that would size this way when you go to different viewport widths or I don't know how that would look when you scroll down the page and this thing sticky. There's lots of different things that could happen. There is that kind of it gets revealed with implementation, right?

SPEAKER:
Bring in wireframes into our discovery because we don't do that right now. Right frames are always separate from them. We have all kinds of technical documents that we use in our discovery Phase, ERDs and all these other things, but we don't start wireframes until after that. So wireframes and science go together. So maybe that's something to consider is pulling our wireframes into our discovery phase.

NORAH MEDLIN:
We do a sprinted phased approach as well. We also do a full discovery that happens as like a bucket of ours before going into that phase. We've recently started implementing through running into the same issues where at the end of each phase, we do almost like a mini retro where we effectively just scope reassess at every phase. We also have I mean, I think this is more of a talent issue than it is anything else. But having developers that have design backgrounds that you then incorporate in that design process, like we have a couple people like that, but that's specific skill set which is like a culture specific skills, but it really helps ensure that there's a smooth transition from that wireframe to like design to (UNKNOWN)

SPEAKER:
Cross-functional experience. Absolutely. Yeah.

NORAH MEDLIN:
And like, I mean, he's obviously a gold star like it's hard to get people like that but it does.

SPEAKER:
Protect him at all costs.

NORAH MEDLIN:
Yeah. Did you have any other stories you wanted to share?

ERIK SCHWENKE:
Not top of my head. Does anyone else have questions they wanna ask?

SPEAKER:
What's an ideal percentage of the discovery phase as compared to the project size? How much provision should, it's gonna be consumed.

NORAH MEDLIN:
Yeah. I don't. Know. It's kinda hard to really put a percentage to it. It's one of those it depends situate sort of answers where I think that a discovery phase would probably be larger if the client needs some more strategic direction, than, you know, some clients come to you and they know exactly what they want, that kind of client. So you may or may not have as much strategic work to do with that client, but you also on the other side may have some more work to do to convince them of not going in some particular directions that they're very hard set on as well. So there may be some more work about the prototyping and designs and this interactivity. You know, just to get an idea of how that actually feels from a usability perspective or whatever that may be. So I don't know. I'm not sure I can really pin down a percentage. I've seen anywhere from like 10% discovery to like 60%. Sometimes it's very heavy.

SPEAKER:
I think you also have to look at it a little bit as like an investment back project. The more hours that you have upfront in your discovery phase, the more money they might end up potentially saving them. I've had a project where we had like a 30% discovery which seems like a lot of discovery.

NORAH MEDLIN:
That's all I have. I don't know if you've had this, too, but I've also had clients that end up spending a lot more with you because you go through this sort of like, intentional sort of way.

SPEAKER:
You're starting a project when you know the least amount. So the client says, tell me how much this thing is gonna cost. You know, like, well, I can't because I don't know what this thing is. So you're asking me to tell you the most about your project when I have at least (UNKNOWN) So discover gets you to that place. In my opinion, there's no way to do a project without a discovery. Like even if you...

NORAH MEDLIN:
But to get paid for it, that's the big thing, right?

SPEAKER:
You're doing it without a discovery, your first two weeks of any project become a discovery.

NORAH MEDLIN:
Yeah, they do. You're gonna do it at some point.

SPEAKER:
Whatever you wanna label, if it comes to that, like we have to do the backbiting, we have to get the project set up, we have to do all this stuff. We have to actually figure out what this thing is we're doing because clients don't know, they just don't understand, especially when you're talking about like, a Drupal. Presumably we're talking about Drupal projects here which you don't know what it takes to do this stuff. Most of them. And if they do know, they probably come to you with one point in time and you're not gonna be setting up project management like this. You're gonna be throwing a support dev on it and (UNKNOWN)

NORAH MEDLIN:
And maybe they might be really good Drupal lists, but they just don't know strategically for their business where they really wanna take it to the next level and that's why they're coming to you as well or they might not even know that that's what they need and that's where you step in to help them. So I don't know, maybe I'm totally off with this. Does everybody do discovery first approach? And I didn't even realize? Are we doing it already, guys? I mean, like, I feel like this hasn't been happening for a very long time, you know, so not too long ago. And now it's maybe changing, but then, yeah, the question I think more is, are we getting paid for it 'cause I think I still hear stories where this is kind of this discovery, this audit kind of happens prior to the initial sale at all. It's part of the sort of initial proposal process and you might spend quite a lot on that internally before seeing a penny. Anybody have that situation right now? OK. So it still happens. Alright.

SPEAKER:
We do a bucket of our in there. So (UNKNOWN)

NORAH MEDLIN:
I mean, sometimes it's inevitable, right? Sometimes it's...

SPEAKER:
Inevitably, it's a way of rediscovery is (UNKNOWN) the market for everybody else. Don't ever do that. Always.

NORAH MEDLIN:
That makes me happy. Go ahead.

SPEAKER:
We're coming from different angles people in this room. I must wall throwing.

NORAH MEDLIN:
Yeah, sure.

SPEAKER:
With a very small team where I'm the sales and the project manager and a small team of developers. And our approach, I couldn't tell you what our approach is because it varies from project to project because I'm learning. So we don't have a fixed way of doing this. I'm trying to do better with things like this.

NORAH MEDLIN:
Well, I hope this might have been helpful to you for some degree. Yeah.

SPEAKER:
Yeah, I'm always interested in these discussions. I just wanted to sort of ask 'cause you're talking about discovery (UNKNOWN), I've heard theoretically about a model in which the discovery is almost like a product where there is a deliverable and it's almost like you're gonna pay us to do this discovery and we're gonna give you a document at the end that even if we you might take us to a different...

NORAH MEDLIN:
Right, right.

SPEAKER:
I've heard about that theoretically. Is that a mythical beast or is that real?

NORAH MEDLIN:
It's real.

SPEAKER:
That's the way.

NORAH MEDLIN:
Yeah.

SPEAKER:
So when you're charging for discovery, you're actually giving them a deliverable?

NORAH MEDLIN:
Yes.

SPEAKER:
Absolutely. It's a bunch of really super technical documents which is actually something that I wanted to ask everybody because ours is a bunch of super technical documents that the client goes. Sounds good. And then they're completely wrong. And we get into it. And I mean, just like where we had a 1,500 hour project and we are 1,500 hours over right now. And it's because we missed some crazy key elements to the site, and it's a D7 to D9 transition and it's somebody else gave us the designs and it was an absolute disaster. And we had to fire over it too, because it was such a mess.

NORAH MEDLIN:
Oh well.

SPEAKER:
You have the same project that I was on. And like that's my question. Is this like just to your point, like, yes, these discoveries, yes, we paid for them, but they're not necessarily helping us right now because the client goes, OK, cool, sounds good.

NORAH MEDLIN:
Well, yeah, you bring up a great point. You're kind of on the other side of things, right? That design has been done by some other agency. So what do you do in that situation, how much discovery can you convince your client to do again.

SPEAKER:
Is there like we're not like here's your designs, tell us how much this is going to cost. We went through a full sales process, but I wrote a note that I have to talk to the owner of the company and be like, we cannot do bills without a discovery anymore. We literally can't. It doesn't matter if you have all the designs. It doesn't matter if it came from somebody else. We have to do a discovery. But my whole entire point is this, that it doesn't. If the discovery also probably didn't really matter because I didn't know what they're looking at.

NORAH MEDLIN:
Yeah. Yeah. You know, I think one thing that I found to be useful during that discovery phase is to try not to be too technical about it. Like when we say technical approach, we're just talking about a general. We've done some proof of concept. We've done some high level designs that that should be like, this is where I think it probably should go. This is like general recommendations on the strategic direction of this or that from a technical perspective. But yeah, I don't think that you can really answer all of the questions until you get into implementation. I think this is more about like just easing into that a little bit more so that you're not completely out of line when you get to that implementation phase, right? So that's a difficult situation. Maybe you need to do a talk.

SPEAKER:
Can I give you a...

NORAH MEDLIN:
Come back, tell us how you solved that. Go ahead.

SPEAKER:
Don't go to your owner and say we can't do a project without discovery. Owners don't like that. She will listen. She's always there right now, she's pretty close. You can reframe it which is we have to build these checkpoints into a project which say we have to have a sprint zero. And it's just, you're calling Discovery something different without telling the client. Like, you have to do this thing you've already done again. So like think about ways to think. You're right. You have to do that. But I can tell you from lots and lots of experience. Your team will do audits and they're gonna miss something here and there. Like you might have the best audit process in the world and the clients like you get three weeks in and the client's like, well, what about this integration that nobody knows about that somebody built ten years ago. And it's, you know, my nephew's basement. It's like, Oh, that's like actually another 400 hours of migration work that we didn't know about. So I think it's easier to build in, especially if you're talking to clients that are 1,500 hour budgets or 2,000 hours budgets.

They understand like let's build in some checkpoints along the way. And I think I find that to be a little easier than like we have to redo what we already did, even though that's just it's just like a framing. It's that psychological. They have (UNKNOWN) Check point where it's like, hey, we're... Yeah, milestone. Analyzing. (UNKNOWN) And then framing everything to strategic goals. Like to your point like the clients can't understand we're gonna do this migration and it's gonna be this upgrade and they don't. Depending on where that statement, that stakeholder matrix you add up, depending on where they're sitting in that, Drupal seven versus Drupal nine means nothing to them. Now the developer or the marketing department chair, they might understand. But like, it's all about tying it then to like the strategic goals and the roadmap. So I think about the discovery is giving this giant roadmap that says, look, this is how we're gonna hit your strategic business goals and don't necessarily worry too much about the technical things.

We'll let you know from a change the budget along the way. That's just like the reframing. Again, it's like I get it because I'm the owner. I do sales and I understand. And I've been down all these roads. And so for me, things that trigger me even though I know what they mean. Like when my PM comes and says like, we can't do a project without X, it's like, well, we can. I've done a bunch of projects without X, Y, or Z. So how can we think about reframing it? It's like you might be able to say, tell me the exact same thing with a different word. And I'm like, yeah, that sounds like a great idea. And that happens with our clients all the time. Just my thoughts. Great point. Appreciated. Guys, thank you for coming in.

NORAH MEDLIN:
Thank you. Yes. Thank you.