Come gestire un progetto di costruzione di un sito web aziendale (con Rich Butkevic di Project Zendo)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Ben Aston

Thanks for tuning in. I’m Ben Aston, founder of The Digital Project Manager. Welcome to the DPM Podcast. Whether you’re a seasoned project manager, a digital producer, or something else entirely, maybe you just found yourself somehow in charge of managing projects, just know that today in your headphones, you’re joined by thousands of others in the same boat, trying their best to start, plan and deliver better projects.

We at thedigitalprojectmanager.com are here to help you become more confident and skilled as a project manager, and we’re here to connect you with others who are managing and leading projects too. If you really want to level up and take your PM game to the next level, check out our DPM School, and be sure to sign up for our pro membership to get access to all our curated resources.

Finally, while you’re listening to the show, please subscribe and join our mailing list on thedigitalprojectmanager.com to stay up-to-date with all that’s going on. So if you’ve ever done a corporate website build, you’ll know full well, that they’re incredibly hard to get right. And partly, that’s because it’s something that doesn’t get done very often, but it is more than that, its unclear objectives, it’s a fuzzy brief, it’s that tangle of stakeholders, and lashings of politics.

They all make getting a corporate website done at all, yet alone right, incredibly hard. Throwing some technical challenges, and that bright shiny new website projects can turn into a complete disaster. So in today’s podcast, we’re going to explain how you can do corporate websites builds right and keep listening to get the lowdown on how you can plan, manage and control your upcoming corporate website projects and get it done right.

Thanks for tuning in. I’m Ben Aston, founder of The Digital Project Manager, and welcome to the DPM Podcast. Whether you’re a seasoned project manager, a digital producer, or something else entirely, maybe you just found yourself somehow in charge of managing projects, just know that today in your headphones, you’re joined by thousands of others in the same boat, trying their best to start, plan and deliver better projects. We at thedigitalprojectmanager.com are here to help you become more confident and skilled as a project manager, and we’re here to connect you with others who are managing and leading projects too.

So if you really want to level up and take your PM game to the next level, check out our DPM School and be sure to sign up for our pro membership to get access to all our curated resources. Finally, while you’re listening to the show, please subscribe and join our mailing list on thedigitalprojectmanager.com to stay up-to-date with all that’s going on.

This podcast is brought to you by Clarizen, the leader in Enterprise Project and Portfolio Management Software. Visit clarizen.com to learn more. So today I’m joined by Rich Butkevic-

Rich Butkevic

Perfect.

Ben Aston

Have I said that right?

Rich Butkevic

You’ve said it perfect.

Ben Aston

Oh, there we go, I practiced. So Rich is a Project Management Consultant, and he’s author of the blog, projectzendo.com. So go and check that out, and he also runs project management workshops all across Texas, and check out artofpmo.com if you’re interested in that. We’ll touch on that in a minute. But Rich possesses this unique combination actually of leadership positions in project and product management, QA, business analysis, marketing, and training. He uses Agile and Scrum, and he’s got all the letters and certifications that you could possibly want, PMP, Certified Scrum Master, he’s got IBM Rational Unified Process, he’s an Amazon and E-Marketer Certified person. He’s got it all.

So hi, Rich, and thanks for joining us today.

Rich Butkevic

Hey, Ben, thanks for having me. Appreciate it.

Ben Aston

Well, I just want to start by kind of digging in actually to all of those qualifications, and letters that you have after your name. So, some people kind of adopt that idea of, hey, I don’t really care about certifications, you’ve obviously gone the opposite route and got every single one under the sun. So is that based on a particular passion for learning? Or what made you decide to go out and be certified in everything?

Rich Butkevic

I don’t know about everything, but I mean, I do have a passion for learning. It’s just something that I really like to do. But I think getting a certification just in project management or really, in anything in general. I think it just demonstrates an overall seriousness in which you take the profession and keeping up to speed with things. So really, besides the PMP, the other certifications I kind of just acquired more or less as needed for projects.

So, for instance, with the AWS certification, if I would be on a project that would be utilizing Amazon Web Services, I always like to really get into it and dig into the technology so I can do a better job as a PM. And as I did that, I just found out that I liked it and wanted to learn more, and if I’m going to be learning more anyway, it’s nice to have a goal to shoot for. So I just kind of make it my goal to get a certification, and so that’s kind of how they [inaudible 00:05:30].

Ben Aston

Nice, tell us how you got into project management in the first place then. So, clearly, you’re technically orientated. I don’t think there be many PMs that I know that have a technical certification like AWS-

Rich Butkevic

Sure.

Ben Aston

But how did you start out and get into project management?

Rich Butkevic

Well, kind of through college, I was a technical support person, so I would answer the phone right when broadband was coming out. So I kind of got really in on the ground floor technically in a pretty exciting time, and then, right when I graduated college, I became a business analyst for a large telecommunications company in Chicago where I was living at the time. And then from there, it just kind of I went into QA and started managing QA and then getting into project management, that, that company and then I got my certification and kind of things went on from there.

Ben Aston

Nice, and so I’m curious, obviously, you kind of went through that. Yeah, kind of technical support QA and then into project management. Your first day as a project manager, you obviously learned lots of lessons, but what would you tell your younger self now on your first day in project management, knowing what you know now-

Rich Butkevic

Sure.

Ben Aston

And thinking about where you were on that first day when you first had that job title, project manager, what would you tell yourself?

Rich Butkevic

Well, I think the most important thing would be that it’s not about the tool. I think a lot of project managers get very focused on really knowing all the nuances and ins and outs of whatever project management tool they might be using to aid them. But in my view, everything that you do, the tool is really just a way to streamline and automate and assist with managing a process that you really should be able to do with a pencil and a piece of paper.

So if you’re not comfortable managing a project with nothing more than a pen and a notebook, not saying that that’s really what you should do. But being a good project manager isn’t about being the most knowledgeable on Microsoft Project or any other PM tool or software. It’s a lot more than that. A lot more of the softer skills, and really just having a good understanding of what it is you’re trying to accomplish as a PM, rather than being an expert on the software.

Ben Aston

Yeah, definitely. But talking of tools, because I do like tools.

Rich Butkevic

Yep, yep, me too.

Ben Aston

So what is in your PM toolkit apart from the pen and notepad that you mentioned?

Rich Butkevic

Sure. Well, I think what has made the biggest difference in my toolkit besides for the project management tool that we’d actually be using would be some sort of collaboration tool. So, I love Slack. I just find it really simple, easy for people to use, but I think that makes just a huge difference, as opposed to trying to manage things by a flurry of emails and Excel documents stored, strewn throughout the company on shared drives that no one can ever find.

So, I like Slack, but really the tool itself kind of like the project management tool, the concept, and the idea is more important than the tool that you pick to use it.

Ben Aston

Yeah, and do you use and have you got any integrations with Slack that you find particularly useful to help you with that? Enabling that collaboration and enabling you to actually leverage those softer skills more?

Rich Butkevic

Yeah. I mean, nothing’s popping into my head besides what you know, sometimes tracking integration that I might be using as a consultant. The companies that I’ll work for usually have some sort of standards that we need to adhere to. So although the time management, for instance, software itself that you would integrate with Slack might change. Again, having that integrated somehow is good but what really I found beneficial in Slack is understanding the keyboard shortcuts that’s just made such a world of difference knowing.

Ben Aston

Give us your favorite shortcut.

Rich Butkevic

Oh, boy. See, Now you’re putting me on the spot. I don’t know. It seems like I know them instinctively like my fingers know them-

Ben Aston

I know you probably do.

Rich Butkevic

But my brain doesn’t.

Ben Aston

You can’t quote them but you do know the hand gestures, yeah.

Rich Butkevic

Yeah, yep, yep. It’s kind of like my phone number. I have a hard time sometimes telling people what my phone number is but not hard time dialing it because I need to.

Ben Aston

Yeah. No, that’s funny. But going back to your point. Your point was though, that it’s not about the tools, and we’ve now started talking about tools. So definitely let’s get back to your point-

Rich Butkevic

Sure.

Ben Aston

Which was, hey, good project management isn’t about the tools. Tell us more about what for you, then you’ve discovered, that art of project management being and how you leverage those soft skills to deliver better projects.

Rich Butkevic

Sure. Well, I mean, when I say soft skills, certainly, soft skills like communication and things like that are important. But really, I guess besides soft skills maybe a better way to say it would be to understand at a conceptual level, what a project manager is there to do and how a project is supposed to run ideally at least so that you can focus on the things that are essential and not things that are really just a waste of time.

So, really when you go through the course of a project, there’s a few big buckets of things that I think you should be focusing on. And then there’s tasks that you would have to do or you should do underneath those or at least you could do, but really, you need to identify what your requirements are, and you need to make sure that both the business and if it’s an IT project or a website project, that the technical team, that there’s a mutual understanding with the requirements and what they are and what they need, and you need to ensure that testing takes place and that defects are managed in some way and just a lot of the more higher level, what would usually be represented as summary tasks in a project plan, that you’re really understanding what the greater goal is and why you’re doing those things.

I mean, I kind of say that if you can’t write a tweet about why you’re filling out a document or why you’re doing what you’re doing, you should probably stop and get clear on why it is you’re doing that, because oftentimes, if you don’t know why you’re doing it, you can’t do it well, and you might not need to be doing it at all.

Ben Aston

Yeah, definitely. I mean, let’s dive into this topic about managing corporate website builds and we just published a post on how corporate website projects go wrong. A cheat sheet for project managers said check it out if you haven’t read it yet on thedigitalprojectmanager.com and here’s the reality, it is tough. Corporate website projects are really difficult. So corporations hire agencies, consultants, they need outside assistance, whether or not that’s to make a significant update, maybe migrate to a cloud, implement a new CMS, integrate with some digital marketing tools. But due to the nature of these projects, corporate websites normally don’t happen very often because by very nature of a website build maybe every three to five years people do these big projects, and that often means that the people involved in them aren’t very experienced at it, and maybe they only managed this once or twice in their career.

So it’s challenging and as I mentioned, right at the beginning, there’s lots of stakeholders, unclear briefs, politics, and then technical challenges too. So yeah, if you haven’t checked out Rich’s article, go and have a read. But I want to talk about this process, how we can streamline the process and building on what Rich was just talking about there with knowing, having this awareness of the things that need to happen in order for this to be a success, but let’s start though by kind of digging into why this is so hard, and maybe you can share an example or a horror story of how this has gone wrong for you in the past, and maybe I’ll do the same.

Rich Butkevic

Sure. Well, as far as how things have gone wrong, I think one of the big lessons that I took away more early in my career was to, I guess I’ll say, trust but verify. So, there were a lot of times where project resources would say that they had completed a task when really what they meant to say was that they planned on completing the task or that it was on their to-do list and then as happens, other things would come up and it would get forgotten or swept under the rug and some of these items aren’t very evident until you might go to production, unfortunately.

So, I think that’s probably one of the biggest lessons that I learned early on, and then going back to how I mentioned Slack before. Collaborating well with large teams, especially on big projects or on projects where the resources are geographically distributed. So we’re not all in the same place. That’s really been key to me, especially knowing that the larger a project is, the less that you can rely on one or two people having heroic efforts that pull things out in the end.

So, like you said, on a corporate website project, someone, a consultant like myself, I might go to a different company a few times a year or what have you and work on projects like this. And so, I’ve probably worked on a couple dozen of these types of projects. But when you think about a system or a network administrator at a corporation that has been there for 15 years, they might have only done something like this once, maybe twice tops in the decade, decade and a half that they’ve been there.

So even though it’s something that I might do a few times a year, it isn’t something that they do hardly at all. So even though it might seem rather routine to a lot of people, to many corporate resources, it isn’t routine at all, so.

Ben Aston

Yeah, yeah. I’ll share one story of it going wrong. I was working on a corporate website project a few years ago, and the challenge that we had was just a really comes down to alignment in the brief and it turned out… And this really comes down to stakeholder management, and I think this often happens with a corporate website project, where the person who has been tasked with managing the project internally didn’t necessarily collate all of the insights that they should have done from their team.

So basically, they’d written a brief, they hadn’t got it signed off, or if they had got it signed off, it hadn’t really been reviewed properly, and so we went ahead. We designed the website, we built the website, and then we’ve discovered just before we’re about to go live, that there was a part in the process, in the governance structure of the project, there was an additional layer of approval that we weren’t aware of at all throughout the entire project. And so it came to be, we were told, “Hey, well, we just need a founder and president to approve it now before we go live.” And we were like, “Oh, oh, you didn’t really mention that before.” And it turned out the founder and president was the real boss.

Rich Butkevic

That’s right.

Ben Aston

They had some very clear ideas about what they wanted and didn’t want, that were foundational to the entire project.

Rich Butkevic

Sure.

Ben Aston

And of course, then we had a really sticky conversation, where we had to say, “Look, I’m sorry, but this wasn’t in the brief. You signed off, all right the way through this project, and now the founder and president is not happy, and so everyone else is not happy.” And, yeah. Well, it ended up we had to issue them a massive change request, but then they were upset. I don’t know they were upset with the fact that they had to pay more money, and obviously that kind of soured the relationship.

Rich Butkevic

Sure.

Ben Aston

But it came down to us maybe being culpable in as much as we didn’t push hard enough about that kind of governance structure right at the beginning of the project. So that as it went through, we should have been pushing to take the project more slowly and get it approved right the way up the chain to the very, very top.

Rich Butkevic

Sure.

Ben Aston

And I uncovered that, okay, what needs to happen before we go live and really understand all those steps, I think that was the big learning for me.

Rich Butkevic

Right, and that can be really difficult, especially in a larger corporation where you might have a dozen or so stakeholders identified on the project, but all of those stakeholders, they all have a boss, and usually those bosses have a boss and so on and so forth. And when a big enough boss sees a website change that they don’t like, they can override decisions that were made before. So, that can be something that can get a little tricky.

Ben Aston

Yeah, and I think one of the lessons for me was explaining the consequence of that. So now, I’ll say, “Hey, okay. Well, lets kind of map out the stakeholders, and we’ll do a racy based on the different milestones of this project. But just so we’re clear, if we’re saying this person, really is the person who’s going to be the one who’s signing stuff off. If they have to go have the final say, and then we find out later that we have to go back, then there’s going to be an impact on costs, on the timeline. So, say it now or we’re going to have consequences later.”

So just being really clear about, you could just play… And I think this is what often happens. It will be the marketing team who’ll be responsible for it, and then they’ll assign it to a junior marketing person, and then that person will be like, “Okay, well, I’ll just loop in my boss.”

Rich Butkevic'

Sure. Right.

Ben Aston

I was like, “Well, probably we should loop in some more people here.”

Rich Butkevic

Yep.

Ben Aston

But talk us through that high-level process. So how do we go from a corporate client saying, “Hey, I need a new corporate website.” To ta-da, “It’s done.”

Rich Butkevic

Sure.

Ben Aston

What for you, I mean, you were talking about these kind of major buckets, those summary tasks in your project plan. So what does that look like for you? And I know, you’re a big proponent of Agile, you’ve got your Scrum certification. How does your awareness of that play into a corporate website project when a more gated approach maybe makes more sense because of the approval status?

Rich Butkevic

Well, I think at the highest level, really, the first thing that I want to make sure that we do is identify what the actual goals are of the project or the website. Sometimes there is a merger or an acquisition and you’re integrating two websites together, sometimes it’s a redesign or a rebranding, sometimes you’re implementing a new content management system, and depending on what those goals are, that’s going to drive a lot of the subsequent tasks on the project. But once that’s identified, then I like to move on to user stories, and I think this is something that a lot of design or website projects overlook. But most companies aren’t going to be serving everyone under the sun.

They can usually identify there’s a few different customer avatars, we call them. So different types of people that will be viewing the websites. Maybe there are people that are going to be making a purchase or people that are there for information or their existing customers, and they want to do a reorder or whatever the case may be. But each of those types of users or user avatars are going to have different goals on the website. They’re going to be looking for different information, they’re going to have a different level of knowledge, they’re going to take different paths to the website more of them likely, and what the ultimate goal is for the user, and the company will vary depending upon what that user avatar is. So identifying those-

Ben Aston

Cool.

Rich Butkevic

And kind of writing out why they’re visiting the website, and what they’re hoping to do, that helps drive the next part of the project, which is designing the site hierarchy and the structure. So you really want to limit the number of clicks that it takes a user to get someplace, you don’t want to have what they’re looking for buried 20 pages deep in the website, because they’ll never find it or they’ll get frustrated, and it’s just not good for a lot of reasons, SEO reasons and whatnot. So that’s kind of the next layer that I like to look at is taking the user stories and using that to drive what the site’s structure will be.

Then, once that is laid out, and you know what the hierarchy is, then we try to look at content and how that content will be managed on a smaller website that might only have, let’s say, less than 50 pages, it’s not really as big of a deal, and it can be managed pretty easily. But when you’re getting into a redesign or a CMS change of a enterprise-level, corporate website, they might have thousands of web pages, in which case knowing what content is going to stay, which is going to get updated or deleted or merged. That’s a significant undertaking, and that’s one of the places where tools can really help because you don’t want to have two or three thousand Word documents stuck out there in a folder somewhere.

Ben Aston

Yeah.

Rich Butkevic

And then only after those things are taking care of do I really start to worry about the technical aspects of the project, because those are fairly static. I mean, there are differences as you go from one company to another based upon infrastructure and CMS and all those types of things. But you can get all the technical stuff perfectly, but if those other things aren’t thought of in advance, and you’re not really reaching the goals and serving the goals of the customer, and you don’t have the website organized in a way that is user friendly, and that makes sense and the right content isn’t there, then the technical parts don’t matter if the higher-order items aren’t thought through and taken care of.

Ben Aston

Yeah. Cool. So for you, yeah, the important thing is right up front, defining that brief, defining the objectives for the site, identifying the key personas or archetypes and then creating that architecture, that site architecture, the information architecture, the IA to enable people who are using the site to be able to use it effectively, and then there’s a design phase where we’re creating those wireframes and the design components. Do you typically do that as a parallel workstream? I’m just thinking for people who are kind of listening thinking, okay, well, this sounds like it’s going to take a lot of time we’ve got this discovery planning, design phase before we get to build. What are your kind of hacks for running things in parallel, speeding things up, but also making sure that you do it right?

Rich Butkevic

Sure. Well, I guess I try not to use too many hacks because in my view, the planning makes such a huge difference on how quickly the project proceeds later. It’s one of those things where if you don’t have time to do it right, you’re not going to have time to do it over. But that said, you certainly can do a lot of it in parallel, and really, it all should be done in parallel to one degree or another.

So while you’re working through what the overarching goals are of the website in an existing company, you usually pretty well know who your customers are, and what types of people are going to be visiting the website and you can start doing those user stories, and as you go through that, you can start making some notes on what the site structure will be, and if you’re redesigning an existing site, it probably makes sense to use that existing site structure as a starting point and see where it might be able to be improved, and then there might be a content team where you might have different departments within the company.

Sales might have content and HR will have content and whatever other groups there might be and they can start going through and reviewing their content and deciding what they want to merge together or get rid of or update. So all those things, they can all kind of be snowballed together into one fell swoop. But I almost forgot the second part of your question there was, how do I utilize Agile or Scrum or iterative approaches, given all that and I think that what that really helps with is what we were talking about before and with the stakeholder management.

To me, you really want to get to something that the stakeholders and whoever the decision-maker is can see and actually take a look at with their own eyes as soon as possible. Because I found that there’s a lot of organizational leaders that might not want to be involved in the day to day of the project and it’s probably appropriate that they’re not. But when you schedule something where they’re actually going to be able to sit down and see progress and view the website up on a screen, that’s something that they’ll show up for. And that’s when you’re going to get a lot of your good feedback, and the earlier you get that, the better because you don’t want to make a design decision that’s going to cascade throughout the rest of the website, and then find out at the end that it isn’t something that a C-level person wanted. So, sometimes a more gated approach is better, but in my experience usually not.

Ben Aston

Yeah, and I think one of the things that can be really helpful as well is user testing. We’ve talked about this in the corporate website build. One of the key things we do is identify those personas right at the beginning of the project. Who are we building this for? And I think in a corporation website project, something that very quickly gets mixed up in this is okay, well, yes, this website has a role to play in stroking the ego of whoever’s ego needs to be stroked. And that is an objective of the project. It may just be implicit, but in some way, it needs to be codified in some way.

But the point of creating these archetypes or these personas at the beginning of the project is that we really align with the clients on why we’re doing the project and the objective of it. So on most corporate website projects, what you’ll have is somebody saying somewhere, “Hey, well, on the homepage, the most important thing is for us to tell everybody about the great thing that our just CEO just did. He has been at the company for 15 years, and we want to tell everybody about it.” It’s like, “Well, okay, why do you need to tell everybody about that? When you are a,” I don’t know, “you’re a broadband company or whatever you might be.”

Rich Butkevic

Sure.

Ben Aston

But someone or for that will be the most important thing because hey, if they can make their CEO look good, then they’re going to get a promotion and a pay rise. So there’s explicit goals, and then there’s implicit goals, and the beauty of the personas is that it helps us channel some of that decision making as to why we’re putting things where we’re putting them. And then we have this second step, which is user testing, and one of the things that we can do to help mitigate against the risk of stakeholders making poor judgments is by having user testing.

So we say, “Hey, here are our personas. Let’s go and test what we’ve just created with our personas.” And we give them some specific tasks like, “Hey, so you want to get a new broadband package. How do you do it?” And then we show them the site and the IA and the wireframes and we say, “Now you go and try, and find the right package for you. You’re willing to spend 50 bucks a month, go.” And they’re like, “Hey, well, I can see this big thing about the CEO and how they’ve done 15 years. But I can’t see how to configure my broadband package.” And then you’re like, “Okay, well, now you’ve got something to go back to the corporate team and say, ‘I think we should probably change that banner on the homepage to be about broadband configurator, not the CEO.'” So, that’s a crazy example.

Rich Butkevic

No, no, no. It’s a great example, and that sort of thing happens all the time. And I think that when you’re going through user testing, something that’s really important is to make sure that the users that you bring in are really representative of those customer avatars that you identified earlier. I don’t know, if you’re selling homeowners insurance on your website, you don’t want to bring in people for user testing that don’t own a home or that are teenagers, you want to make sure that the people that you’re bringing in are actual good samples of who’s going to be using the site.

I see that in a lot of companies, they’ll use their own internal employees for user testing, and that’s usually just a terrible idea because people that work within the company, they’re much more familiar with how the business works, what the goals are, what the industry jargon is, and you don’t want to go through a bunch of user testing and think that everything is looking great, and the site’s easy to use, and then when you roll it out, the general public has no idea what the word broadband really means. So they’re not going to ever click that link in the navigation and they’re going to get confused and upset and click the back button and go to a competitor that used a word like high-speed internet, for instance. So I think that’s something really important to keep in mind.

Ben Aston

Definitely. So we’ve just spent a long time talking about the discovery, planning, design portion. But now let’s talk about build. I know you’re obviously have got a lot of experience in the technical aspects of managing a corporate website. And the truth is that designing sites, right? Is really tricky and getting them to perform on those objectives that we set at the beginning of the goals of the website. The design is critical, it’s really important that we get that right, and if we’re interested in increasing conversions, if we’re interested in hitting our KPIs, then the design has got to be right. But there’s obviously a gap between the design being right and the site working functionally as it should, as it was designed to be.

So talk us through your kind of your top tips for managing the build process in a corporate website project. What are the kind of things that you think a PM who’s managing a project like this for the first time? What are some of the big things that they should consider when managing a team of developers?

Rich Butkevic

I think the biggest thing to keep in mind is what we talked about earlier is that the developers on the project usually aren’t going to have a great deal of experience in this particular area, or at least in the migration. They probably have experienced in managing the website once it’s running, but in some of the other technical details, they might not. So I mean, there’s a couple things that I’ve just found through experience that these are really what I try to keep an eye on because if something’s going to be overlooked, or done a little bit incorrectly, it’s probably in one of these areas.

So one of them is with HTTPS redirection. So, almost all sites especially all corporate sites, now are going to be secure site so that the traffic is encrypted. But you really want to make sure that if a customer types in HTTP, or doesn’t type in the HTTPS, or doesn’t navigate to the site via a link, that that request is routed to the secure version of the page, and this is something that I’ve seen just messed up a lot of different times and a lot of different ways. And you really want to make sure that the URL is being rewritten the right way, because if it isn’t, you end up having, at least in search engines eyes, two different versions of the site. You have the HTTP version, and then you have the HTTPS version, and that can create problems with duplicate content, and then also, when you’re going to look at your analytics, it will almost always be tracking those two different versions of the page independently and it’s very difficult to tie conversion actions and everything else together when you’re not doing that right.

So that’s one of the things that I see done not right quite a bit. Another thing that I see is that when it comes time to launch the site, and we need to update DNS, which is really is the system that allows a website name like Google to be translated into an IP address so it can actually be found out on the web. So it’ll come time to go live, and the person that is supposed to be making those DNS updates doesn’t have access to the registrar. Usually that’s a really restricted information, because someone that has access to the root level domain for a company that should be held accountable, yeah, that should be held accountable to your mess.

But you want to make sure that the people have the right to access that they need to do that work, and then you want to make sure that the project team, especially the leadership, understand at least the basic concept of after a DNS change takes place that there’s going to be some period of propagation as those changes get reflected on servers all across the internet. So what I try to avoid is, going live and sending out an email to stakeholders saying, “Hooray, we’ve made all the updates.” And then we get a whole bunch of emails saying, “Oh, it’s broken. It doesn’t work for me.” And really, it’s going to work in 15 minutes. It’s just that those changes haven’t propagated yet. So, that helps cut off a lot of unnecessary panic on launch day.

Ben Aston

Yeah, definitely. So there’s always great kind of go-live tips that I think are so important that you think about well in advance of go-live day. And I think what can often happen is we have this we’re kind of immersed in the development process and we know okay, well, we’re going live in two weeks. And then the day before maybe you start trying to think, okay, can we actually redirect the DNS? Can we make these updates? And, then you find out, oh, no, no one knows what the login is, and the person who knows it is going away on holiday.

So thinking about all these kind of things, is really great advice if you’re thinking about launching your corporate website, but I want to go back to that development process, and in terms of managing developers where we’ve gone through the design process before we go live, obviously, the thing needs to be built out somehow.

Rich Butkevic

Sure.

Ben Aston

And in terms of managing developers. For someone who’s not technical, so their kind of project managers who are great at managing that kind of user experience design process might not be so strong at managing developers. So in that situation where, I mean, and you talked about this right at the beginning, where you said, “Hey, well the developer told me that it was done, but it was kind of, he meant to do it, but I’m not done yet.” How do you manage developers when you can’t really see what they’re doing?

Rich Butkevic

Sure.

Ben Aston

They’re writing lines of code. You’re the PM asking if they’ve done it. They say, “Yes.” What they meant is, not quite. How do you manage that?

Rich Butkevic

Well, that’s one of those things where I think an iterative approach comes in, especially useful, and that’s just because you’ll have the opportunity to actually see something working or not working in a demo right up there on your screen. So that would probably be my first recommendation because that’s going to help you get in front of any issues or problems or you’ll be able to very quickly see if things are progressing as they should be and how you’re being told that they are or whether they’re not. And then the other thing that I really can’t stress enough is not having big gaps in between meetings and updates.

I don’t want a meeting just for the sake of meeting. But I think doing at least, if not daily, every other day, just a five minute stand up meeting to keep things on track is really, really helpful, and that’s something that’s really common in the Scrum framework. But really, it’s not exclusive to that. There’s no reason why it can’t be used no matter what approach you’re taking to development, but just the more things can stay top of mind and frequently checked in on and issues resolved. Really that’s going to be your best bet to make sure things stay on track.

Ben Aston

Yeah, and I think there’s a really valid point. So momentum is important. Making sure that things keep going, that we keep on having demos, that we keep on seeing, okay, let’s try and build something. Let’s have something built. So by the end of the week, we want to do a build and see something working so that we can evaluate it. So having that regular cadence of builds, and you might say, okay, well… The developer might say, “Hey, well, it’s just the navbar. I’ve only built the navbar.” And okay, well, let’s see it working. And then when they demo it, you’ll say, “Okay, so it’s working, but I just tested it on my phone, and it’s not working. So we need to get that fixed.”

So picking up those issues early is really important and then having that regular cadence of the sprint demo or showing the work in progress, and then there’s regular daily catch-ups as well. So you’re saying, “Hey, what did you go through yesterday? What’s the plan for today? Any blockers that I can help you with?” Those are ways that we can mitigate against. That kind of the fog of development when developers just go away and build stuff, and then we expect it all to be done six weeks later, and we find out that it’s not quite right.

So yeah, some great advice there. But for those people half-listening in the car, and they’re thinking, hey, okay, we’ll you’ve just talked through that kind of discovery, planning, design, development, we’ve talked about go live. There’s a lot here to remember and kind of get your head around. What’s one simple takeaway, or one piece of advice that you say hey if you’re about to manage or you’re in the middle of a corporate website build, what’s one thing that we should all remember? How can we make sure that these projects are going to be successful in terms of managing and controlling them? Because I think even if we do start them off right, we can plan them and things can be on track, but kind of keeping on track of the budget and the schedule, what’s your, I want to know, a tip for managing and controlling? What’s worked for you? We got taught about daily stand-ups, sprint reviews, but how do you kind of keep the team making sure that they’re on track and keeping control of everything?

Rich Butkevic

Well, I think it’s really a combination of a lot of what we’ve already talked about. So it’s having good collaboration and using a tool if you can to help facilitate that. The daily stand-ups are great and important and that will help get in front of a lot of issues. But really, that’s just another means of collaborating, and the tighter you can get that feedback loop the better.

So, the beauty of an Agile approach is that feedback loop is broken down into, let’s say, two-week chunks in-between of where you’re demoing something real. But then you can break that down into the daily stand-ups where you’re not demoing things, but at least you’re getting updates and feedback and tightening up that loop even more, and then when you’re using a tool such as Slack or another collaboration tool, now you can get ahead of those things instead of someone feeling that they need to wait until the next day or two weeks from now, to bring up an issue. They can bring it up right then and it’s a very low friction way to facilitate that.

So I think that would probably be my biggest thing. The other thing that I’ll just mention that we haven’t talked about yet is that before you go live, making sure that you crawl the site for broken links that identifies a lot of problems that people just don’t seem to catch. So that’s just such an easy thing for people to do, and I rarely see it done and I don’t know why but as a PM, the week before go-live, I just make sure I go and run a crawl on the website to see if there’s any broken links because then you can tell from that how the coding was done or whether there’s an organizational problem in the website or a technical issue and it’s a very easy way to uncover a lot of big problems.

Ben Aston

Well, have you got any tips on what do you use to crawl?

Rich Butkevic

Not really, they all kind of work the same. I would just go online and just look up a, yeah, yeah, link check or something like that.

Ben Aston

Check for something like that.

Rich Butkevic

It depends on whether you’re building a brand new site or a redesign and whether or not you need something that can run from inside the network or outside the network. So there’s some nuances, but those are kind of the smaller, smaller things. Just however you need to do it, just try and make sure that you do it because it’s a big win.

Ben Aston

Definitely. Cool. Well, thank you so much Rich for joining us, and I think the most valuable thing that I think we’ve been really talking about, we’ve spent a long time talking about that early part of the project, about getting the brief right, about getting the goals and objectives clearly defined at the beginning of the project, because everything else flows from there, and then what we haven’t talked about, but it’s an important aspect of the project is hey, after this goes live, there’s normally a phase where we evaluate how it’s doing, and if we’ve kept our eye on those goals throughout the project, it’s much easier. We’ll find that it delivers results, and then that it delivers ROI, it delivers value. So starting it right is really, really important. So thank you Rich so much for that.

Rich Butkevic

Thanks, Ben, no, it’s been great been here with you.

Ben Aston

It’s been great having you with us. So, I wonder what you think, what are your hacks, tips, and tricks for site builds? What have you found that works and what doesn’t work? If you’ve got any fail stories or wins, tell us in the comments below, and if you want to learn more and get ahead in your work, come and join our tribe with DPM membership. You’ll find in there all kinds of good resources including, we have project plans for big site builds in using different methodologies, using sprints, or using a more waterfall approach, so come and check it out, thedigitalprojectmanager.com/membership.

You’ll get access to our Slack team, templates, workshops, office hours, eBooks, and more, and if you liked what you heard today, please subscribe. Take a couple of minutes to leave us an honest review and thanks for listening. Until next time, take care.