Colouring In The Project Lines (With Maik Stettner From EA Games)

Read The Transcript:

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, the founder of the Digital Project Manager. So, let’s be honest, are you set to deliver your projects on budget? And on schedule? Are you set to deliver the scope that you promised too? Are you not sure? Well, how do you know and how do you do it? And that’s really what today’s podcast is all about. Project controls.

They’re really just the lines that we draw around our projects to help us know the parameters of the project. Where we should be coloring in. And help us know when we’re coloring outside of those lines on our project.

This episode is sponsored by Resource Guru, the resource scheduling tool used by teams at companies like Apple, Ogilvy, Deloitte, and Publicis. DPM listeners can get 20% off for the lifetime of their account with the coupon code DPM2018.

Learn more at Resource Guru

Today, I’m talking to Maik Stettner. And Maik is a newly appointed development director for EA Games, formerly at FCV, and he manages the team there. He’s also one of our resident DMP experts at the Digital Project Manager school. And, when you’re managing a team of PMs, really one thing that you get very passionate about is project controls. And Maik’s got plenty of experience of that. You really want your team to be delivering on budget. You really want your team to be hitting those timelines, those milestones otherwise things start unraveling and you have to get involved. So, today we’re gonna talk about how we can manage our projects better and the controls that we could put in place. So firstly, well we know that we’re on track. And secondly, it really just gives us some options for when we start heading off track.

So, I hope that sounds good. Maik, hello and welcome to the show.

Maik Stettner: Hey, Ben. Thanks for having me.

Ben Aston: Good to have you back. So, Maik, tell us a bit about … You’ve actually now kind of moving or changing roles from FCV where you were heading up a team of PMs to development director at EA games. Do you know what that means yet?

Maik Stettner: Well, I’m gonna find out very soon. Focus is still on project management. So, obviously, moving from an agency background into games with Electronic Arts, I’ve actually in my career, worked in different industries in the past so games is not entirely new to me. And I’m looking forward to diving back into it. It’s pretty complex from a project management perspective. So pretty challenging and dynamic and probably gonna use this whole project control thing for that as well.

Ben Aston: Good stuff. And have you … Thinking about kind of moving to a new role and learning different tools and different ways of working, is there anything that you’ve found recently or been using recently that you’re like, “Hey yeah. I definitely wanna take this on to my new role.” Any kind of new tools or approaches that you’ve used?

Maik Stettner: I feel like I kind of learnt that in any position that I’ve been in, I’ve always learned new aspects and new perspectives on how to tackle problems. Because especially when you work in software or digital project management, you encounter similar problems but there might be alternative ways of solving them. And that could be through tools like issue tracking tools, that just get better over time or also, potentially, tools that spit out the analytics that you need in order to make impromptu decisions. I don’t think I can really name a tool. Other than basically the usual suspects. But, it’s actually quite interesting from my perspective just to … Like how you realize that a lot of the problems, like no matter if you build an app, a desktop software, or website, a game or whatever it may be, a lot of the challenges and the problems that you run into are quite similar. And the approach of how to solve them are quite comparable as well.

Ben Aston: Yeah, I think one of the interesting things that I’ve found now that I’ve begun doing some contracting, is that even when … You think you know the way to do things and whether or not it is something like resourcing, you can use a tool like Resource Guru, or there’s other tools out there as well, one of them’s, Harvest, has a tool called Forecast. And you think you kind of know how to run the ship and how things should work, and then you try using a new tool, or you start trying to use a tool in the way that the other agency is using it, and you find that it’s actually a whole different kettle of fish. The same tool can be used in so many different ways, actually makes it quite tricky sometimes.

But, I think what you’re talking about in terms or data and analytics is so important. And I think one of the things kind of leads into the article that you’ve written in terms or project controls. When we’re kind of heading up a team of project managers or when we’re working with project managers, we want to be sure that actually, we’re not just relying on our intuition all the time or whether or not something feels like it’s on track or feels like the project’s running right or not. Data is so critical, isn’t it?

Maik Stettner: Yeah absolutely. And especially from me and my roles as a manager of PMs, I don’t always have the full exposure to the detail level as the PM who is working on the project. So, I’m actually quite reliant on looking at those data points and seeing how the budget is tracking, seeing how the burn rate is, and so forth. And that typically allows me to make decisions based on that in collaboration with, for example, the project managers or the team who’s working on it.

Ben Aston: Yeah, so, these essentially are our project controls, right. When we’re thinking about program management, when we’re thinking about managing a team of project managers, this is the data that we’re looking at. And these are the kind of artifacts that the project managers on our team are producing. So, tell us about project controls. How would you define or understand project controls? They’re the things that we use to control our projects but what actually are they? Or what could they be?

Maik Stettner: It’s a bit of a daunting term. But, for me, project controls basically describes all of the tools that you need in order to get the right information so that you can make informed decisions. So, anything that, in terms of data points that you can gather to make decisions on things like cost, time, scope and so forth. And obviously it ties in directly with client interactions and any of those dynamic decisions that you have to do in a project. Like is the team big enough? Do I need someone else? Are we on time? Are we on budget? And so forth. So, it’s really, basically, a high level framework for managing the projects and making informed decisions.

Ben Aston: Yeah, so what’s the actual documents that you think are the most useful to do that? Because there’s a whole array of different documentation that we can produce. So, if we kind of stripping it back to the bare essentials, what do you think … What are the most useful, or what do you find the most useful as a PM managing the project yourself, and I guess maybe from a program manager, or delivery director managing teams of PMs?

Maik Stettner: The most standard one that I recommend to everyone doing, is basically, the creation of an honest status report. So, pretty much a report of the project that contains all of the relevant metrics of the ongoing project and pretty much capturing things like total project costs, budget remaining, what the burn rate is, what was achieved in the past months, and high level action items, risks, blockers, and decisions. Typically, in cases where, and other projects that I’ve been working on and with the teams I’ve been working on, we created status reports weekly. And we ensured that they were always exposed to the client as well. To ensure that the client can make decisions based on having a transparent idea of where the project is at. So, it’s a very, very essential and easy tool for the project manager as well to …

Pretty much self control too, for example, at the beginning of the week, creating a status report, checking in how the metrics are doing, how’s the budget going, where are we in the timeline. And just from a high level, pulling that together. Running it past the clients, for example, scheduling recurring meetings that often don’t need to be longer than half an hour. But act as a regular check-in and help establish a relationship with the client. It doesn’t only need to be remote, it could also be in person, it’s actually always good to do stuff like this in person, to create a relationship with the client. Basically, creating this level of trust and transparency, so that opportunities, but, also issues and blockers are discussed in those regular meetings.

Ben Aston: So, you create the documentation and then you try and have these regular check-ins with the client. In these status meetings we produce the status reports. But, what else are you sharing? So, it’s one thing to internally try to control the projects ourselves, but, it’s another sharing that data with the client. So, apart from status reports, what else are the fundamentals for you? In managing and controlling the projects with the client.

Maik Stettner: One essential tool to keep the overall control over a project is … It might be also a change request, or basically the change request process with our change request forms. So, basically any time that the defined scope veers off, you have to end up, for example, putting in additional effort, or the project team has to pivot in order to accommodate time expectations, it should be documented. And, often times in projects, change requests is like the forbidden term and you’re a little worried to use it because you’re afraid that the client gets upset. But it’s actually a fairly normal thing to do.

Change requests don’t necessarily need to have any impact, just for the sake of documenting it, and it’s still within budget, it might not have any timing implications. But, it is definitely a good idea to still document it and to get the client used to the fact that there is such a thing as a change request process because if there is a decision made at some point in the project that will have a budget impact, it is good to do that thoroughly and to document that and have everyone sign off on a change request like this.

Ben Aston: Another bit of documentation that you talk about, I guess another project control, is the RAID log. Which, again, is another important aspect of controlling the project. But, if you were to do … If you were really just to choose one piece of documentation to control the projects, what would be the thing that you would use to do that?

Maik Stettner: The number one thing is a good, solid status report. A RAID log dives more into an into details and depending on your project complexity you might not even need it to that degree. But, a status report is supposed to capture elements of this. So, if you have risks, if you have blockers or certain things, just make sure that you have space for that in your status report to ensure that everyone has an eye on it. But, regular meetings with the client and exposing the key KPIs and metrics to the client, and then walking them through the current process and progress, that is the number one key metric to me.

Ben Aston: So, I guess it’s a bit of a balance, isn’t it? In terms of how much control do we actually give ourselves and can we create through creating this documentation. And it comes back to this agile debate, to some extent, or how some people might perceive it. We don’t want to get ourselves tied up in documentation around requirements or controls because hey, it’s just gonna limit the project. But, how do you strike that balance of just spending your whole time monitoring the budget and updating your status report every week and having meetings. You’re creating a lot of work for yourself. So, how do you balance out how much is too much? And how much is just enough to stay control of the project, to keep the client in the loop? How do you strike that balance?

Maik Stettner: From my perspective, when approaching a new project I actually try to approach it fairly selfishly, in the sense that I’m gonna start with a project status update, or whatever you wanna call it, that is fairly … and that is easy for me to produce. And I can probably pull it through existing software that I have, for example, the resourcing software like Resource Guru, or timesheet software, whatever it is that the company uses. And that allows me to pull the base metrics. And that might already be enough to get started, depending. Some clients might need a little more and they expect to see a higher fidelity. But in order for you as a PM to keep an overview of the internal metrics and also to present something to the client, that’s already a really good starting point. It really doesn’t take that much time to pull that together on a recurring basis.

You ultimately don’t wanna create too much work for you because then, chances are you’re just not gonna do it and it’s gonna fall through the cracks when things get hectic or when the project needs all your attention and then the overall background reporting and so forth is not gonna be in your focal point at that point.

Ben Aston: Yeah, that’s a really solid point around doing just enough to control the project and actually what’s, I think, probably more important is the cadence with which we do it because it’s all well and good having the mother of all status reports and creating these awesome project controls right at the beginning of the project. And actually, it is creating those templates and deciding how you’re gonna put the data. That’s the first thing, but then if it takes you hours to pull out all the data to fill in all the different blanks that you’ve created for yourself in this project control document set, then it’s gonna undo you because it’s gonna take you too long to produce, you’re not gonna produce it and then you’re not gonna stay on top of your projects, right.

Maik Stettner: Exactly. And you also have to keep in mind that it goes two ways. On the one hand, you as the PM needs to know what’s going on to make informed decisions. The client wants to know what’s going on, but also the internal team deserves to know. Also, one of those decisions that you as a PM need to make, how … I don’t think I’ve ever run my team through a dry status report. I’ve always found other ways to expose budget restrictions or timelines and so forth to the team. But, it’s important to have enough knowledge and to have enough metrics to keep everyone informed so that everyone is working on the same project.

Ben Aston: Yeah, I think that’s a great point. This isn’t just for our clients, this is also for our teams. This is so that our teams also know they understand the constraints of the projects too. Like if the project is burning hot and we need to pull together as a team and try to find a more efficient way to do things. Having that data again, is good not just for the client, but also for the team in terms of saying, “Hey guys, we’re gonna have to pivot a bit here, maybe we’re not gonna be able to finish things as much as we had hoped we might be able to. So, come on let’s pull together and adapt.”

And I think having the data, like what you’re talking about here, having the data, this isn’t just you being a pain in the ass and you being the project manager, but it’s saying, “Look guys. This is the status report and it shows we’re burning hot. We spent too much time on UX, again. We spent too much time on design again. We’re not gonna have enough budget to QA this properly if we don’t wrap this up.” Something that’s really solid.

And you talked about, in your article, the kind of process for initiating project control, and then how you actually used them to control the projects. So, you talked about evaluating, planning, reacting, and then connecting. Could you just talk us through that process and how you make that work?

Maik Stettner: Yeah, sure. As a PM, you always need to be informed where things are in order to make informed decisions. So, these few steps are kind of based on that. So, basically you want to start with evaluate. So you’re gonna know where your project is at, where is it at in the project plan? Are you on track to get the anticipated output? Are you going to hit your goal? And not only from a KPI perspective, but as a PM you have to get under the hood, you have to ask questions, you have to understand what your team is doing. And basically become a high level expert of all those different individuals that you’re working with. As you mentioned, UX, design, development, QA. So that you can have an opinion if maybe you can cut corners on a project in certain areas. Or maybe you can’t. And you can only find that out if you actually dive in and you start talking to people and you understand what you need to do in more detail and on a more granular level. And then make decisions based on that.

And that kind of goes to the second step which is plan. So, as we know, often times we have to cross collect and there’s things that need to change, like timings change, scope changes, and so forth. Basically, planning that out and planning next steps with the team based on the knowledge that you have. And as a PM, you always get both sides. You get the client side, you have the internal knowledge of the team and pretty much coming up with that master plan of bringing this project to the finish line.

And based on that, the next step would be react. So, implement your changes based on the plan. And that includes letting the client know, for example, ensuring that the process is changed if it’s needed. documentation and issue tracking systems like Jira, for example. And updating timelines, and ensuring that the adjustments are all done.

The last step that I mapped out was connect. Because as a PM you are the glue that holds the team together. So, everyone needs to know ideally what you know from a higher level. So, make sure to distribute your knowledge to the team so that everyone gets the full picture. Client needs to be in the loop, the team needs to be in the loop. And basically just managing then those changes through so that you can actually deliver on them as well.

Ben Aston: What I’m hearing is actually … There’s kind of two different parts to this, I think what you’ve been talking about from a project management perspective, is the date is really important. Those data points give us the ability to assess where the projects are at. And from very quickly, from a high level, give us that ability to control projects in terms of working out, okay how do we prioritize resources? How do we prioritize projects in order to deliver the projects? And we’ve got that high level view that the data gives us.

But, I like what you’re talking about in terms of the other aspects of the project controls. Which is actually, this isn’t just about data, this isn’t just about us collecting information. This is about initiating a conversation and including our teams in this discussion and in this debate about controlling the project, about discussing the best way to deliver things and having that more agile approach to delivering our projects and adapting as we go and being intuitive. Rather than just locking things in, letting things … Running our status reports, working out we’re over budget and leaving it there. I like what you say about making this a conversation.

But, for those people who’ve never thought about producing proper status reports for their clients or for their projects, you obviously just talked through that process. But, for you, what’s the first step in getting your projects under control? What’s the first thing that people … Even if they don’t get it to the point of creating a status report, or one of these project controls, what’s the first thing that you think PMs should be thinking about when they’re thinking about sorting out delivering it? And controlling projects. Is there any good starting point that you’d recommend?

Maik Stettner: To me, it’s really getting a good picture of what you need to do in order to get this delivered. Both from client perspective … And some of this might be very straight forward logistics. But, what is the client expectation? Are there any drivers? Are there any … Is there maybe a set date when you need to be done? Because a campaign is running or there might be an executive presentation and your contact needs to have it by then. And then also internally. Like getting a really clear picture of the team that you need and how it’s going to work. At least from a higher level, understanding how all those things will come together. With experience, and as a project manager you … That will help you gage from high level what the plan is going to be and what the rough checkpoints are that you need to have in the process.

Ultimately, status report helps you mainly also keep yourself on track, to not forget about those checkpoints. That’s, I think, the key. It’s a combination of KPIs, soft skills, and just generally keeping a level headed overview of the project and ensuring that you still understand exactly where you are. Even when the project is more complicated. And then making informed decisions also for yourself to find the tools that help you make those decisions.

Ben Aston: I like what you’re talking about there. Actually, data is nothing unless we can compare it against something. So, it’s all very well as pulling these status reports, but, if we haven’t got a project plan to compare them against, then that data is kind of meaningless. So, I think, I like that point of make sure you’ve got a proper plan, then you can measure against it. And I think, what I found actually when talking to PMs from other agencies, actually one of the things that seems to be absent a lot of the time is timesheets. And tracking exactly how much time is spent on different tasks for a project. So, I think, although time tracking is one of the most painful things you can ask someone to do, actually implementing time tracking if you haven’t got time tracking in place, making sure that you’ve got a project plan, then enables you to be able to track your time against the project. And that then gives you a bit of control around the project. So, I think that’s really solid advice. Thank you, Maik. It’s been great having you with us today.

Maik Stettner: Great, thanks Ben.

Ben Aston: And as one of our DPM experts, Maik is gonna be making an appearance in our upcoming course that starts in September. It’s called Mastering Digital Project Management. This is a seven week crash course in digital project management. You’ll learn how to manage digital, complex digital projects effectively. The course includes some video lessons, some assignments, group discussions, there’s the option of coaching sessions. So head to thedpmschool.com and get yourself signed up. There’s a few spaces left. But, the course starts on September 10th. But, if you’d like to contribute to this conversation around project controls, how is it we can control our projects better? What are the kind of documentation that you use? Well, head over to the resources section of thedigitalprojectmanager.com to join our Slack team, where you’ll find all kinds of interesting conversations going on there. So, comment on the post, talk about it on Slack, and let’s work out how we can control our projects better.

But until next time, thanks for listening.