Are you starting your projects off on the right foot and giving them the best chances for success? Project beginnings can be ambiguous and confusing—in this episode, Suze Haworth shows us her approach for getting clarity, setting expectations, and making sure the bases are covered, before the project is underway.
This podcast is part of an article published on The Digital Project Manager.
You can read the article here.
This podcast is brought to you by Clarizen, the leader in enterprise projects and project management software.
Related Links:
- Clarizen | Project Management Software
- How To Start Your Projects Right. A Complete Guide To Project Initiation
- What Is A Project Initiation Document? Why & How To Make It
- Agile Vs Waterfall
- How To Estimate Projects: The Complete Guide To Project Budget & Cost Estimation
- 9 Project Management Methodologies Made Simple
- 10 Project Management Software Tools
- Project Management Resources
- The Digital Project Manager School
- Join our project manager Slack team
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: Welcome to the DPM podcast where we go beyond theory to give expert PM advice for leading better digital projects. Thanks for tuning in. I’m Ben Aston, founder of The Digital Project Manager.
Now we all know that the beginning of a project is really critical to its success, but it can be a really tricky time. There’s lots of ambiguity. There’s lots of confusion. There’s stacks of disagreement and a whole lot of uncertainty. As PM’s, it’s our job to get the project moving and to keep it moving, and bonus points if we actually start leading that project in the right direction. But what can we actually do to make sure we do set sail in that right direction? That we start things off right. And that’s what today’s podcast is all about. So keep listening to find out how you can make your projects start right.
Today, I’m joined by Suze Haworth. Hi, Suze.
Suze Haworth: Hi.
Ben Aston: Suze is one of our resident DPM experts at The Digital Project Manager. She works as a freelance senior digital project manager in London. And Suze, why don’t you just tell us a bit about some of the projects that you’ve been working on recently?
Suze Haworth: Yeah. So I’m actually a freelance PM. I recently, a few weeks back, finished a contract, but it’s quite a long-term contract at an agency. But I had two key roles there. So one was more of a program director role across an account. So that was for Specsavers, which is a really big retail glasses brand in the UK, and they’re also in the Nordics and Australia. And that was managing a senior PM across all the creative and the UX, the digital Specsavers. So that’s quite big program of work. And then also I was working on a project for Ikea. So that was a project to design and build a prototype for a design system for the brand.
Ben Aston: Cool. So Specsavers, that’s more of an e-com and conversion optimization type project?
Suze Haworth: Yeah. So it really depended on the market, but they actually don’t tend to sell glasses online and just do certain regulations. So a lot of it was driving people to book appointments and go into the branches. But yeah, it’s a lot of conversion, optimization, as you say.
Ben Aston: Yeah. What was tough on those projects? What are some of the challenges that you were dealing with the project itself, or the client, or the team? I think it’s always interesting for people to hear that other people have similar problems. So what was tough?
Suze Haworth: Yeah. So with the Specsavers program of work, it was actually a really interesting time when I started that because I started that in March, which is the beginning of the new year, and we actually moved to a completely new way of working. So previously we’d been working as a design agency alongside their development agency and we’d been sitting within all their scrum teams, so we had a pairing of a designer and UX’s in each of their scrum teams across their workstreams. And we decided to remove all our designers and UX’s from those scrum teams and pull them out and set them as one team our side. And we then moved to more of a dual-track process, so we were running what we called a discovery track almost above the delivery track, which was more of the scrum-based development team.
And so we were doing a lot of … It gave us the room and space to do the user testing, the exploration, the hypotheses and making assumptions, and testing them with users. And a lot more research and data and stuff to feed into that, so it gave us a bit more room for maneuver in terms of actually delivering things that the users wanted. So it was a really interesting time to implement that new way of working and make sure that was up and running and getting that through. So yeah, that was quite a challenge as well, but it was really exciting.
Ben Aston: So was your role then as the … Whose role was it? The product owner. So you’ve got these two parallel work streams. One is for strategy, UX, and design, and I’m guessing they’re the ones that are user testing happening to identify user needs and then those user needs are then prioritized and then some of those get taken to a UX and design stream, and then they drop down into development. Is that how it worked?
Suze Haworth: Yeah. So what we were finding is with the design and UX pairing sitting within the scrum is that working in the two weeks … was really … And trying to deliver within them was actually quite limiting for them, and a lot of time was spent on the more technical aspects of it. So they ended up sitting on long sprint planning meetings where they’d be involved in smaller parts of it, or they’d sit in on stand up’s and meetings where they’re talking about bugs a lot. Rather than thinking about the actual customer needs, really it was becoming a bit more tech lead. So the decision to remove them from that and working on almost a track sitting above that, so that we have that adequate time, and it was still quick turnarounds, but we had that time to … We’d look at existing data or existing research or research that we’d done, and then we’d identify some assumptions and then hypotheses of where we could solve customer pain points, I guess.
And then we could start doing some quick, either UX design, prototyping, what suited that particular need, and then get it in front of customers very quickly. And then they can validate that before it actually goes into delivery. So that was a way to, I guess, streamline the build. So we’re not actually building things that customers don’t want. So we’re trying to update design decisions and UX decisions prior to actually going into the sprints. And so we were still involving technical people in the discovery track, but more instead of just validating from a technical feasibility side, once we said, “This is what the customer wants, and they liked this feature we’ve designed.” So yeah, it was in an effort to streamline the process, but also a real push to delivering what the customer needs rather than what can be done. Do you know what I mean?
Ben Aston: I think the souls, what is a challenge for many agencies who are trying to do scrum. Clearly, scrum is not the only way to do an agile project, but generally, it seems to be that’s the generally accepted rule that you have to do scrum. But I think one of the big challenges that you’ll find if you try doing scrum within an agency is, well, what happens? What are UX and design supposed to be doing in the sprint? And there’s one way to do it were either UX and design are a couple of sprints ahead of development, and then you’re like, “Well, hold on. Nothing’s being finished.” The idea of a sprint is that at the end of the sprint you’re developing something that’s shippable and that passes the acceptance criteria, and it’s really hard to do that within a two-week period. To go through strategy, UX design, and build off a feature.
So I like this idea of hey, well let’s just run them as two parallel work streams, and then as things are validated, then the product owner can then drop them down into the development backlog. So you have two different backlogs. You have a strategic where we’re asking these questions. Is this the right thing to do? And then we have a okay, we know this is the right thing to do because it’s been validated. Now let’s build it out. And I think that that solves some of the challenges for sure.
Suze Haworth: Yeah, exactly. Like I said, it just means that you’re actually building features that you have validated that customers want, so it produces a lot less waste. It’s a lot leaner, which can only be a good thing, I think.
Ben Aston: Good stuff. Well, let’s talk about project initiation and actually starting projects. And I’m curious to know for either the Ikea or the Specsavers projects. Were you involved at the beginning or not?
Suze Haworth: Yeah, with the Specsavers, this new way of working and it was a retained team so it was scoped for the year with a team shape. So I actually started once that way of working had been initially loosely defined, and also the scope of work had been written. So this is one of the, I think, one of the challenges I do talk about in my article is picking up something or a project that has already started or has already been scoped by somebody else. So that one I picked up quite soon after it had been scoped, but when the way of working had loosely been defined in a certain way and when it started to be implemented I found that it did need tweaking. It did need shifting around. And actually, it did evolve quite a bit from what was originally posed, because when you actually start working in a certain way you do find things that don’t quite work and that you need to tweak. You need to adapt as you go along.
And then the Ikea project, it actually worked in stages, and again, actually, I didn’t work on the stage one of the project and came in at stage two. So it had kicked off prior to when I started.
Ben Aston: And I think that’s often the case with projects that we’ll pick up as PM’s. We pick them up often, not quite at the start, but this … And that can actually add to some of the confusion, right? As a PM you’re brought onto the project someone … It’s been handed over from business development or the account management team or sales and you inherit something that’s been planned out but not fully planned out. There’s some degree of uncertainty. So I think we can imagine this. As we’re talking about project initiation, I think it is as much about when you’ve been handed over a project at some point in the project. All right, from the beginning.
So let’s talk about those things that you mentioned in your article about the things that you need to manage, and you talk about managing the people, the process, and the product and getting alignment and clarity on that. So that’s who, how, and what. So let’s touch on, firstly, as you’re picking up these projects, either you’re kicking things off for the first time or you’ve been plunked on the project. From a people perspective, what are the things as you’re initiating the project, what are the things that you’re trying to do from a people perspective? In terms of working out the lay of the land. In terms of initiating the project so things set off in the right direction.
Suze Haworth: Yeah. So as I say, there’s a few core groups you need to think about or people within a project. And firstly, it’s around your team. So who’s going to be working on the project? So at the project initiation stage, you’re defining … Obviously, you’re trying to book people into the project and defining who’s going to work on it. So it’s important to think about not only who’s available and who’s free to book on the project, but also who is right for the project. So looking at their skill set. Looking at the ways they work. Looking at the types of projects you have and the type of client you’re working with.
It’s really important, I think, just to … If you do know your team members, to understand who might work best and who might work well together on it. So I mean, obviously that can be a luxury and it might be down to who’s available, but it’s a good thing to think about upfront because even if you are having to use certain people on a project, being aware of how they work initially can help you down the line if there are any issues.
So yeah, it’s thinking about the team who are going to be working on it and making sure … I think what’s really, really important is making sure that people working on it are going to be involved from the start. So from working for years and years with their own designers and developers and QA, etc. People in projects is one thing I found most of them, if not all have hated, is if they’re not a part of the project from the start, don’t know anything about it and then they’re just handed something when it’s already been defined and decided on and then just told, “Oh, can you just design this?” Or, “Can you just build this?” It’s when any autonomy is taken out of it for them and they’re just told what to do that it becomes quite a problem.
So, obviously, with the luxury of having enough time and budget, it’s a really good idea to even just lightly involve them from the start. So after the initial internal kickoff meeting, talk to them about what they think about the project, how they want it to work, what are their expectations for it. Just so they get involved from the start.
Ben Aston: Yeah. I think that getting … And I think this goes back to the resourcing part of it. So as much as you can, upfront resourcing the team that you need and want and getting them engaged in the project as early as possible so you get their buy-in. Because I think people tend to react a bit when they inherit, as we do as project managers when we inherit something that someone thought about but didn’t really have enough time to think about it properly. And so, they’re like, “Hold on, why are we doing this? This isn’t what I’d do.” We want people to think, “Hey, yeah. This is my thing.” Because when they’ve got that sense of ownership, rather than reacting to someone else’s half-baked idea, we tend to get much better results.
Suze Haworth: Exactly, yeah.
Ben Aston: Yeah. So I was just gonna go on to thinking about the process, because that ties into it as well. As we’re thinking about, so we’ve got our team. We know who our team are. Now, how are we going to use that team to deliver the project? And you touched on this as you were talking about the way that things started out on Specsavers. But there’s typically some disagreement among the team about how the project should be delivered, about the process that you should be using, even the methodology and the tools that you should be using as well. So what do you do to align the team and to navigate through that disagreement that is almost inevitable?
Suze Haworth: Yeah. I mean, you’re never get to probably find an ideal solution for a process that suits everybody in every single way. You will get tensions around that whenever down the line of the project. So yeah, I think it depends really. Sometimes you inherit a process, your agency or organization already has a process that you need to use on a project, or the client might dictate it. If you get the luxury to set it yourself that’s great because then you can try and find something that really suits the project you’re working on and the client you’re working with. But yeah, so if you’ve got a project process, it’s good to get … At an internal kickoff meeting, if you’re talking through a project process that is already defined for the project, then talking it through and explaining it and why you’re using it to the team members is quite good. Try and get their buy in at least early on.
But also I think it’s really important to adapt process as you go along. So you should never try and rigidly stick to something if it isn’t working. You need to be able to adapt and move it forward. So making sure that your team understand that if there are issues that they have for the prices, with the tools they’re using, with the ways that you’re communicating, anything like that, that they should raise it and be honest about it and then you can look at ways that you can mitigate that and adapt and move things along.
Ben Aston: And I think that flexibility I think is what’s the key to success there, because I think often project managers or even teams, people on the teams can be like, “Hey, no, that’s not how scrum works.” Or, “No, that’s not agile.” Or, “No, that’s too waterfall.” Whereas, actually, it doesn’t really matter what it is or what it isn’t. What matters, I think, is what’s best for the team that works for the project, that works for the client. I think the key is not being dogmatic about one way or the other. But with the team that we’ve got, with the work that we need to do, what’s the best way that we can deliver this?
And in some ways, it is reinventing the wheel, but I think the reality is with the projects that we do, they’re all different and so trying to apply a single process or a method for everything is really, really tricky. Unless you’re doing some maintenance work or ongoing little feature updates, things like that. Then it makes sense to standardize things. But if you’re dumped on a new project for a new client, I think it’s fair game.
So thinking about then … So we’ve talked about who. We’ve talked about setting up the team and the stakeholders. We’ve talked about what we need to manage in terms of how about navigating around process and being flexible. But in terms of the beginning of the project, I think the what, what we’re actually doing and what we’re actually delivering, can be one of the trickiest things when there’s … You often inherit a very loose scope of work from a sales team or a loose set of requirements for the client. So what’s your process of, again, trying to clear away the ambiguity around the project or the product and actually getting to, “Okay, let’s agree that we’re going to deliver this thing.” How do you get to that point where you get to a place where things become black and white, or at least less gray over what you’re actually going to deliver?
Suze Haworth: Again, it depends on the type of project. Ideally, I think you don’t want things to be too strictly black and white at the beginning of a project because things change so much that you might end up with something completely different happening down the line. So I mean, I do prefer scopes that do allow for change, that do allow for the deliverables not to be completely fixed upfront. But you can get projects obviously that are very fixed upfront. But in order to determine that, you need to start having conversations and getting clear requirements from your clients. So talking to them, making sure that you understand what their user needs are, what the business needs are, and really understand the context for your projects basically.
And then you need to take all these requirements and start fleshing them out with your team. So again, it’s about that team involvement early on, and not just with one person, but involving a few either discipline leads if you don’t have your team set up, or a few members of your team and talking them through what the scope of the project is, what the requirements are, and setting out some parameters for what it could be.
Ben Aston: I found that in those early sessions where we’re trying to define what it is that we’re actually doing, getting people into a room and booking a half-day session where we have a whiteboard and post-it notes and lots of things. Just very high level trying to architect the solution, because I think what I try and do is get the team … Get this shared understanding and alignment because at the beginning of a project, people tend to have different understandings of what things mean. And as you start drawing things out and sticking things on the wall, it just forces these conversations where someone might say, “Oh, well I thought that meant this.” And someone else says, “What? No, it’s not that. It’s something else.” And then we begin to hash out, or at least identify, all these areas where the ambiguity lies so that we can then go back to the client and say, “Hey, here’s some different ways that we could approach this.”
But I think that big picture view of, “Hey, this is the project,” and getting everyone on the same page, and then taking a picture of that whiteboard and that picture of the whiteboard that session that you have at the beginning of the project becomes something that everyone’s like, “Oh, where’s that whiteboard picture again?” And was like, “Oh, this is this bit.” And it’s having that big picture view of how all these pieces connect together and what we’re delivering.
And jumping ahead, getting that overall architecture solution, at least putting a stake in the ground to say, “Hey, here’s one way that we could do it.” At least begins to close the circle on where the project begins and ends. Because I think often there’s just this ambiguity of, how far are we going? How much are we doing here? So beginning to block in the canvas with that and say, “Okay, here are the parameters for the project. This is our understanding.” And then going into that discovery process can be helpful when there’s some alignment with people as to what this thing could be.
Suze Haworth: Definitely. And also, I mean, workshops like that are great. Getting people in a room and discussing things and defining things. Even if they do change, at least like you said, it’s a stake in the ground. But also doing that with the client is really good as well. It’s a really good way to kick off a project, and you get a much better understanding of where their mind is at in terms of the project as well. And they can see where you’re at as well. So maybe having an internal one first, but then taking that to the client and working with them in half day sessions is really good as well.
Ben Aston: So I think one of the things … So we’ve talked about the things that we need to manage. The who, the people, the team, the how, the process and the methodology, and the what. Beginning to sketch out the solution and the architecture. And with that as well, I would say we can also begin to sketch out the budget, the timings, the success metrics. Having this all on one big whiteboard at the beginning, even if it is going to change later, is really helpful.
But often at the beginning of a project, it might be that we’re doing this project initiation part where we’re trying to architect a solution before the project’s actually been signed off. There’s this tension as to how much is too much? How far ahead do we go? I’m curious to know your point of view on this. Do you do as much as you can or are you a bit more cautious and hedge your bets and just do enough to move the project on a bit? Because there’s a bit of a tension, right? Where you often haven’t got complete sign-off, but we know that if we don’t do more work than it will never hit the delivery date. So how do you manage that tension of going too far at the risk of going down a rabbit hole and getting lost, versus being cautious and then potentially putting yourself in a difficult situation in a few weeks’ time when you’re not far enough ahead as you need to be in the project?
Suze Haworth: I think I probably tend more cautious side, but just being completely open. If the client is delaying on signing something off or they’re going back and forth on the scope or something like that, it’s just making sure they’re aware of any time delays and how that could delay the overall project. So just being aware of the risks of anything not being pinned down, and that you can kick off more formally.
I would still say, though, that starting to push things along and think about things is good. So even if it’s a cautious approach, like you said, it’s almost like doing just enough to keep the project moving a little. So there’s always momentum at the start of a project. When you’re getting your team involved and you’re talking about something and getting excited about what you’re going to build or design. And then if that slows down and stops, you can find your team members and even the clients sometimes become a bit wander off to something else. They’re not as excited. They get distracted. So keeping that momentum up is good. Keeping something going, I think is good.
Ben Aston: Let’s talk about some of those challenges because I think that is one of the typical challenges that we face is a lack of momentum at the beginning of the project, and when there is that lack of momentum when people are told about a project and then it doesn’t really happen. Or because of some ambiguity or questions that we think we need answered, the project stalls. What do you do in that scenario when things just seem to grind to a halt?
Suze Haworth: It’s a difficult one because you might have people booked on the project already and then you haven’t officially got the go ahead and so you can’t actually get them working for hours or something. But if you understand, if you do have some time that you can use against it, I think it’s important to keep a bit of time in there just for the project team to be kicking off things slightly. So like I said, doing just enough to keep the momentum up by keeping them slightly engaged. And if it is background research, looking at existing data, looking at competitors, anything like that, just start that thought process. It’s quite good to keep them involved on a lower level until you can actually officially start the work.
Ben Aston: Yeah. And I think even just having a meeting with the team. Just a quick meeting can sometimes help as well, where you like, “Hey, guys. I know that we thought this would be kicking off this week. It’s not kicking off this week, but here’s the latest.” And keeping the team engaged so it doesn’t completely fall off their radar.
Suze Haworth: There’s nothing worse, I think, than just going completely quiet on something and then three weeks later or a month later popping up and saying, “Oh great. Now we can start.” Keeping them involved in what you’re talking about with the client in the background is great. Telling them what’s going on, if there is a reason for the delay, when it’s going to start, what we can do in the meantime. So just keeping the conversation going.
Ben Aston: Yeah. And let’s touch on … I think one of the things that I think a lot of project managers will face, and that is picking up a project midway through. And so, this is where we’re inheriting somebody else’s plan for people, process, and product. But then it becomes our responsibility to deliver on it. What are your tips for making sense of the madness there?
Suze Haworth: It’s probably one of the biggest challenges because actually most projects you don’t tend to be involved in from the very start, which is more at pitch level or when the sales team are defining it. That often gets dealt with either by more of a head of project management or delivery or other members of the team. So actually a lot of projects that you end up working on do you come from somewhere else and do have certain expectations that have already been set. So often I’ve found, I’m working to predefined costs that have all been agreed with a very loose scope, but then having to retrofit that to the budget. So often you will find yourself picking up something that someone else defined.
But, so I think it’s about taking those parameters that you already have and working out where there is flexibility, where there is room to maneuver. So if you have got a cost already defined for you, then you look at the scope and you look at what you can deliver and make sure that’s realistic, even if it means the conversation about … If you think that it has been oversold. So if there is too much for that cost, you need to be realistic about things and what you can deliver, or else you’re not going to be able to deliver. So looking at where you can be flexible with things, where you might need to have conversations around scope or timings to make them work.
But yeah, if you’re picking up a project midway through, so it’s already been kicked off by another PM, I think the two core important things to do are just to get as much information as you can about the project, about what’s happened, about what’s been delivered so far, the client, etc. So getting as much information as you can and then almost resetting. So have another mini kickoff, even if it’s midway through the project. Get your team members together, have a meeting with a client. Make sure you’re understanding this is a reset point and you’re kicking off again with you. I think that’s quite important because even if people feel like they’ve already done this once, it’s still a great way to push with a project and to understand what’s gone on, and to understand what hasn’t been working, what … work a bit different meal or what should carry on. And it doesn’t need to take too long. So I think that’s quite important.
Ben Aston: Yeah, I think that reset … Having the confidence to have a reset I think is a really powerful thing, because I think sometimes you’ll come on to the project and really not know anything to begin with. But actually, you beginning to ask these difficult and potentially stupid questions will probably and nearly always open up a whole load of ambiguity about things that other people in the team also have. And so, there can be … As a project progresses, people start making assumptions again that aren’t often documented, and although you can start off … And we talked about this whiteboarding session. But people’s understanding begins to diverge again. So having that reset where you’re like, “Okay, this is going to be a stupid question, but how does this thing work? And how does that connect with this other thing we’re building?” You’ll almost undoubtedly open up issues and things that no one’s really thought of yet, or challenges that were latent that needed to be dealt with. So it can be a really useful thing to do.
Suze Haworth: And definitely never be afraid of asking loads of questions. I’ve always said that, and I say that to new PM’s, is just ask questions. Don’t be afraid of sounding stupid. It’s much better to ask those questions and find out what you need to know rather than sit quiet and then have a surprise later on. So just ask a lot of questions.
Ben Aston: I think that’s sound advice, I think, for project initiation as a whole. I think the art of initiating projects well really comes down to that communication part of it. It’s asking the difficult questions that no one really wants to ask and that everybody knows … It’s a difficult question, but it’s having the confidence to ask difficult and awkward and annoying questions because that’s where you begin to get to some clarity and that’s where if you can begin to define things, the project’s going to go a lot more smoothly and there’s going to be a lot less wasted work or effort as people begin to get this clarity around that north star that everyone’s heading towards. So Suze, thanks so much for joining us. It’s been great having you with us.
Suze Haworth: Thank you. It’s been great.
Ben Aston: Yeah. And as one of our DPM experts, Suze is going to be making an appearance in our upcoming course, which starts in February. It’s called mastering digital project management and it’s a seven-week crash course that includes interactive video lessons, panel discussions, and the option of coaching sessions too. So if you’re wanting to understand more about how to do project initiation better and kick off projects right head to DPMSchool.com and get yourself signed up before the course fills up. And if you’d like to just contribute to this conversation around project initiation and how we do that better, comment on the post, but also head to the resources section of the DigitalProjectManager.com to join our Slack team, and you’ll find all kinds of conversations about project initiation and managing projects there. But until next time, thanks for listening.