Save Your Project With A Project Initiation Document (with Maik Stettner from FCV Interactive)

Ben Aston: Thanks for tuning in. I’m Ben Aston and this is The Digital Project Manager podcast. This podcast is brought to you by Clarizen, the leader in enterprise, project and portfolio management software. Visit clarizen.com to learn more.

If there’s one thing that you can guarantee about a project, it’s that it’ll never go to plan but why do projects go off the rails? Sometimes, it’s simply because we jump into projects too fast and we see the deadline for the project edging ever closer and so then we end up starting the project in a bit of a blind panic; but then, when things start to go wrong, we wonder why that is.

While we’ve usually got all the project background, the strategy, the details, the requirements, success metrics, tucked away in the back of our head, we can often make the mistake that therefore, everyone else should know about it all too but the reality is, if it’s not documented, chances are, our team just don’t know.

So today, we’re going to talk about a tool that we can use to get everyone on the same page at the start of the project. It’s the Project Initiation Document, or perhaps more commonly called in our world, the Project Brief. And so, we’re going to give you today the inside track on how you can create a PID and use them to make your projects more effective.

Today, I’m joined by Maik Stettner. One of my friends and colleagues. Maik’s one of our resident DPM experts at The Digital Project Manager. Welcome, Maik.

Maik Stettner: Hello. How are you?

Ben Aston: Yeah, good. It’s great to have you with us and so, Maik, let’s talk about you first and let’s tell everyone a bit about your story because we obviously work together and we’ve been working together now for, is it five years?

Maik Stettner: Yeah, it’s between four and five years now.

Ben Aston: Yeah. So, when I hired Maik though, I remember thinking, “Oh, I don’t know if this guy is going to be able to do it.” Because you come from a slightly different background. Not the traditional agency background. So, tell us about your story. How is it that you became a PM in a digital agency?

Maik Stettner: Yeah, so all in all, I have round about 10 years of experience in various fields. I originally started out in gaming and publishing, managing releases for games in Europe and North America, and then moved into other fields like medical databases but generally always software development and things that have to do with project management, a variety of teams, and so forth; and within my career, also gathered some agency experience with app development and some initial web development too. Yeah, basically, when we had that initial conversation about working together, I pretty much made the switch to full-on web development and agency.

Ben Aston: Yeah.

Maik Stettner: And yeah, been working with my current company, FCV, now for around about four years and I’m leading the Project Management Team now for the agency and I’m basically responsible for the overall delivery of projects and ensuring that clients are happy with the results that we put in.

Ben Aston: Good stuff. So, for those people who are listening and thinking … well, perhaps they might be in a similar situation in as much as … and I think we get this quite often, it’s people who say, “Okay, well I’m a Project Manager, I’ve got experience managing software but now I’m considering transitioning to an agency and being a Digital Project Manager.” For you, what were the kind of … how was that transition experience for you? Transitioning from more of a software world to an agency digital project management world, what were the key differences perhaps in the way that you have to manage people or projects? I’m keen to understand more of the contrast and what people who are considering that move might want to think about in preparing themselves for that.

Maik Stettner: Yeah, first of all, there are a lot of parallels. So, things that you encounter in other software development agencies, or in other project management related fields, you will encounter in an agency as well. So, you will have diverse teams, projects will go off the rails for a variety of reasons and you can apply the same tactics to catch those things.

One of the main differences for me, when I started, was to understand and apply the whole idea of being very focused on time and materials and smaller increments of work versus bigger deliveries; because clients, especially in the field that I’m working in, they would like to have more transparency and more control over smaller chunks of work that are being done. So, that comes with more intricate reporting and overall just more effort in being transparent and explaining to the client exactly what you’re doing to generate that level of trust. Which is always a little more effort and needed a bit of adjustment on my end versus when you’re working in a product company and you’re working towards a launch, that might be internal.

So, that was really, for me, the main difference but it was very interesting to see that when you’re working, even in a completely different field, it doesn’t really matter whether you’re working on a database project or on a game or on a website, you’re kind of running into fairly similar issues that can be transferred from one field to the other; and if you apply the same learnings that you’ve maybe had in your previous job, for example, good communication and some of the standard best practices as a Project Manager, chances are you will be successful. No matter what you’re building.

Ben Aston: Yeah. That’s good stuff. So, tell us then … I mean, you talked about some of those … you kind of run into similar challenges. So, can you tell us, in your role now as … I mean, you’re not just managing projects but you’re also managing teams, so in terms of the Project Management Team. So, in terms of that project portfolio management, managing a whole suite of different projects with conflicting requirements in terms of resources, what are the typical challenges that you deal with in that role, heading up the PMO team?

Maik Stettner: My role is more holistic at this point, so I’m basically ensuring that everything keeps moving and one of my main focuses is … you kind of already said it, it’s usually resourcing and ensuring we have the right people for the right job and for the right duration.

Ben Aston: Yeah.

Maik Stettner: Because oftentimes, you have to compromise when things take longer but you have another project already lined up; and then mitigating some of those adjustments that need to be done and ensuring that clients have an open line to me because the risk of being in a more holistic, higher-level role is that you’re just basically the only other person that is responsible for escalations, which is not a role that you only want to be in because that’s basically when you only get the calls when people are mad.

Ben Aston: Yeah.

Maik Stettner: But it’s always good to play a more of an active part in various projects to kind of develop this trusting relationship but still ensure that, within the organization, things are set up properly. Whether that’s for resourcing or from an operation’s perspective, or just yeah, from a general, across collaboration … because we have a few offices.

For us, it’s important to ensure that folks from our Toronto office can work well together with our Victoria office, for example; and so forth. So, that’s really the majority of my focus. That said, I still … I have some clients that I worked really closely with and I’m just still doing a fair amount of project management because it’s still where my passion lies and I just really like working for people, so I’m not going to give that away.

Ben Aston: Yeah. So, tell me about then … so just kind of going back to that resource management challenge and this is something that anyone who’s leading a project management team, or who’s a resource manager, is going to face but how do you … or what’s your approach then for … you’ve got conflicting projects, you’ve got two Project Managers on the team and they both have deadlines for Friday and they both need the same resources. What’s your triaging process? Or what’s your project portfolio management approach for deciding who wins? Because this is something that loads of PMs will constantly talk about it. They haven’t got the resources for their team, so how is it that … it’d be good to get an insight from you on your perspective as someone who’s making that call on which project goes forward and which doesn’t. How do you … what can you share about how you make that call between what goes into resourcing and what gets pushed out or dropped?

Maik Stettner: Yeah. First of all, I typically look at the priority of the project. Are we running against any kind of deadlines, or did we promise something to the client? Does it have to go live by a certain date? Basically seeing if there’s any wiggle room when it comes to timings.

The fact whether something is finalized in the contract, for example, plays a role as well; and so, ensuring that everything is done. Does the project just want to get ahead and do the client a favor? Which is good and we’re happy to do that if we have time but if the other project is going live in three days, we probably can’t pull anyone from that project.

So, that’s the baseline. Ideally, it doesn’t happen because the Project Manager should anticipate certain overages and build in buffers and this might sound weird but I do expect from my team to fight for the resources as well.

Ben Aston: Yeah.

Maik Stettner: Often times they are too nice and they are kind of, “Oh no. You can have this person for a day.” And ultimately, this leads to everyone’s stuff being pushed out. So, while I don’t like poaching and just stealing resources and that’s an absolute no-go; but in resourcing meetings, I would expect that someone stands up for the time that they need and to push the problem to the resourcing manager to sort out, to get the help in, or to figure out how this can be balanced.

Ben Aston: Maybe it’s a Canadian resourcing problem.

Maik Stettner: Canadian standoff for sure.

Ben Aston: Canadians are too nice and as Europeans, we can say that I think. Or is it only Canadians are allowed to joke about those degenerates.

Maik Stettner: Exactly. I definitely see them differently as well in Europe.

Ben Aston: Tell us, I’m always interested in terms of tools. Is there anything that you found recently, any kind of tools that you’ve discovered, or that you started using that you’re like, “Ah, this is awesome? Why didn’t we start using this earlier.” What’s been your toolkit that you think works well.

Maik Stettner: With regards to resourcing management or?

Ben Aston: Well, resourcing or project management tools generally.

Maik Stettner: Well, we actually use a fairly standard toolkit of time management and MS Project is oftentimes kind of overwhelming for the client. We’re experimenting a lot with cloud-based products now. Project for example has an Office 365 version. But we’re also looking left and right when it comes to time management and resource management software. I haven’t found the perfect solution because we have a fairly tailored process which is unfortunately partially manual too.

Personally, I think the ideal tool for what we need doesn’t really exist. My personal goal would be to actually build something or acquire something and then tailor it to the individual needs.

Ben Aston: What for you would be because there’s people who make tools out here listing as well. What do you think are the things that you don’t see in tools that would make it viable? Or is it just the process that is so convoluted or complex that yet the tools can’t accommodate yet?

Maik Stettner: Not necessarily. It’s actually fairly straightforward. But for me what I’m looking for is basically a tool that ties in from simple time management and booking hours perspectives, or people’s timesheets into like resource planning. Something like Resource Guru or other tools that allow you to map out what you need, but then also into the financial aspect of it. Especially when you’re working on time and materials the easy math is the number of hours times the billing rate. Then basically getting the whole reporting pipeline set up through that.

It sounds easy but there’s a lot of things to consider when it comes to the likelihood of projects that are being done and shift and how systems deal with that. That can throw off reporting and add so much additional manual work that the metrics just don’t line up. I haven’t really found the perfect solution yet.

Ben Aston: Yeah. Cool. Let’s talk about the article that you wrote on project initiation documents or the PIDs and as I mentioned in the intro, projects go wrong and I think often it is because we don’t start them properly. We make these assumptions about what the team knows or we give them a load of documents and say, “Hey go on the shared drive and read the documents. It’s all there.” We think that they’re going to go through, get themselves up to speed, and then when they spectacularly fail we don’t know why but really it’s because they don’t get the project. They don’t know it.

Let’s talk about how we can do this better, how we can write better project briefs, or yet to use this print to project management lingo, create this project initiation document. Let’s kind of set the scene a bit. If you can give us the background or your process for kicking off projects and then where this project initiation document or the project brief, where does it fit in? When do you create it? What do you do where you can get this point where you can write this project initiation document?

Maik Stettner: Typically, let’s assume you have a new client. You’re all excited because the overall contract is signed. It’s probably like a high-level master service agreement or something that says that your company and that other company is going to start to work together to do things. The next step for me is always to figure out how do we get this into more concrete steps and concrete terms.

Typically, a statement of work is what comes to mind for something like that. The problem is when you’re so early in the project everything is just incredibly high level and it’s just an approximation of what you’re going to end up doing in the end anyway. The project initiation document but also kick-off meetings are always a good tool to feel out the client and to hear if there’s anything else and if there’s any other drivers that might have not been considering in initial statement work briefs and so forth.

Typically, once the initial statement of work is drafted, and that might be a draft state as well and the team has decided within our agency and we do a bit of an internal kick-off to move everyone in what we’re doing and so forth and there is an external kick-off with the client on a more high level explains this is what we’re going to be doing. This is the team, this is how we collaborate and this is the scope that we have defined as is.

Now the project initiation document or the project brief is to me the next step in getting a little more concrete but at that early in the process we don’t really … You basically have to treat it as a bit of a living document anyways because it’s not fully clear where in all detail you will be going but it’s a very great tool to provide some business context and to ensure that the very basic project parameters are clear not only to the client but also the internal team.

Ben Aston: Yeah. Okay, you’re off to doing it as an overall statement of work that’s being created or there’s some kind of legal or some kind of agreement between yourself and the client and this is the point where it’s that foundation of the statement of work and the MSA have been set and this sits above that and defines more clearly or goes hand-in-hand with the statement of work to define a few things.

In your article, you outline some of the things that it should include. You talk about providing some context, talk about the project parameter specifics, project breakdown structure, the who is who on the project and risk management. Let’s talk about context first. In terms of the project team when you’re thinking about pulling together this document and providing context how do you provide context without just confusing people and overloading them with information? How do you work out what’s noise to the actual project and what’s actually going to be helpful? What are the key things within that context description that you’d be trying to include?

Maik Stettner: Yeah. I think it’s all about why is the client doing the project and what are the problems that need to be solved from a high level. Are there any business drivers behind it? Do they like to increase their sales or would they like to educate an audience on what they do? Is there a rebrand effort in there and the key question is how is success defined? How do we know in the end and keep in mind we’re still at that fairly high level here, how do we know if in the end we’ll have succeeded.

That might be as straightforward as better sales conversations or for example in your self-service website that pulls all content out of the… into content management. It’s fairly important to set the stage for the theme to ensure that they know what they’re working towards. Even though the steps might not be outlined in a great detail at this point, it helps you frame the overall activity.

If in the end, let’s say you’re working on a rebrand project and the goal is to reposition a company and at the end of the project someone asks you, “But why didn’t my sales go out?” You can go back and say, “Well this is not really what the objective was and the context of the project. However, there might be in spite of fact to work with that might affect that positively but it wasn’t really a focus of that.”

It’s always good to keep this as a track record of what was discussed initially and to align with the client on the overall objective.

Ben Aston: Yeah, I think that’s really helpful in thinking about how. I think that context to the project is always really helpful unless it really is really maintenance work where there is no, I mean you don’t really need to know the overall strategy of the context for maintaining something or fixing something. But if we’re creating something new, that context, understanding why the client is pursuing the project, what we’re trying to solve, the business goals, what success looks like. That’s key to providing the team that background information that’s going to help them shape the solution. I think providing that context in the project brief or the project initiation document is really key. Let’s talk about project parameters and you talked about this in the context is in one sense the project parameters. We’re framing how the project fits in the big picture of what the client is trying to do strategically. But then within that kind of brief itself, what are the parameters that you’re trying to frame out. Essentially you’re restricting the team. What are you trying to frame out and in what ways is it good to restrict the teams you see?

Maik Stettner: Yeah, you don’t want to restrict the experts. But the problem is if you give them complete free rein they might be working on a completely different project than you imagined. It is always really important to give them the frame and the basics, restrictions and always come with things like budget, timeline and the overall schedule that was laid out. Ideally, you’ve estimated this with part of the team anyway so it shouldn’t be anything new to them and people should know that the client has a certain budget. The chance is are you not going to be scolded for showing them a budget that the team is not aware of.

I think it is very, very valuable to go through those things. It’s important for the team also to understand that it’s not a restriction, it’s what was agreed that the you’re going to deliver to the client for a certain budget. Even if things changed, for example, from a team perspective when someone thinks, “Okay, I need more time to do this.” It is the team’s job to then sort out, “Okay, this is how we can still make it work.” It’s always good to make this high level team discussion and don’t give the team the impression that you’re making their life hard but enable them in what they need to do. Make sure that they understand that you’ve got their back when it comes to potential budget increases or potential risks that you might even see at that early in the game and timeline changes.

Ultimately the team needs to be confident in delivery and being excited about starting this project just as the client because they want to get stuff done too.

Ben Aston: Let’s talk about, you talk about other things you should include as well. We’re not going to spoil the article for everyone who’s yet to read it, but one last thing I wanted to talk about is including within this project initiation document or the project brief, you talk about including a project breakdown, work breakdown structure, and a bit of a resourcing plan. I’m curious as to at the beginning of the project when things are pretty undefined, how do you get to a plan, your straw man plan, how do you get to that rough plan before the project even started and you know really how the project’s going to go? How do you create that plan when you don’t know entirely what the project’s going to be? Any thoughts on how you do that?

Maik Stettner: Well, to be honest, it’s probably a best guess at that point. I mean you’re probably basing it off the statement of work or whatever is there already or the estimate that was created by the team. There’s so many things that are still up in the air. Is client-responsive? Do we need a number of revisions that we define enough and so forth? There’s a lot of potentials there. Whatever plan you put together might not pan out as it is.

But then looking back to what I said earlier was what’s the most difficult thing for an agency, it’s also the reason why I say. Even having an approximation of a plan definitely helps the agency and also the other project teams to plan for securing your right resources and ensuring that the team can stay stable. Basically putting together even if it’s a bit of an ambitious initial plan that you might still need buy-in from the client for, and they might say after the first or second meeting, “We need more time. It’s not realistic.” Whatever. It definitely helps to map things out from your perspective and to also understand some of the intricacies that your team will have to go through.

For example, do you need a designer that you haven’t thought of. Right? If you get the team talking about some of those things early you, as a project manager, understand the intricacies of what it takes to deliver this project so it will help you to ask the right questions and to also steer the client accordingly. Like even a rough plan or even an approximation is better than no plan because people talk about it and chances are as time progresses things will become more detailed and more reflective of the real deal.

Ben Aston: I think that at least describes that perspective that having a plan over some plan is better than having no plan at all because you can always evolve the plan. I think when you’re starting a project and you sit down with a team for the project brief and there is no real plan for how you’re going to deliver it and no one’s really thought through the dependencies or the role that the client needs to play in the project. You start the project then with very little momentum when you’re like, “Okay, team how are we going to get this done?”

If you go to them with a plan and it’s something for people at least to react to and say, “Maik, you’re crazy. How on earth are we going to do that?” At least it gives a starting point for discussion rather than a blank sheet of paper where everyone is just looking at one another thinking, “How on earth is thing going to be delivered?” I think having some kind of a plan even if it’s the wrong plan it’s better than having no plan at all.

We’ve talked about this, the project brief, the project initiation document which sounds like a really serious document but I mean it doesn’t just have to be in a big serious document. Right? Essentially we’re providing context, parameters, plan. There are different forms that this can take strongly. How else would you, I guess what are the forms would the project brief take and how do you see it’s role evolving throughout the project lifecycle?

Maik Stettner: The guide that I put together is basically, it is an example of things that you can put in there. There’s definitely a minimum of information that should be in a project initiation document or project brief but there’s obviously other ways of doing that. For example, if you go into risk management and put forth and you pull that into something else. Or a racy chart that pulls into status reports and so forth.

It doesn’t always need to be super formalized. The important thing is that everyone agrees on it. Whether it’s posted on something like SharePoint or BaseCamp and even if it’s iterated on and there are conversations around it. If, for example, the project gets to a certain point and everyone agrees to, “Hey when we scoped this out we forgot the sales aspect so we need to include this and make sure it’s captured in there.” Obviously, it has some scope implications that need to change aggressive.

All in all, as long as it’s a document, even a formalized email, something written down that people can agree on and that is being acknowledged. I think that is pretty much sufficient. It doesn’t necessarily need to be signed and stamped by all sides but at a minimum it needs to be acknowledged and everyone needs to be okay with it because it’s what’s being delivered and what’s being worked against.

Ben Aston: Cool. The good news is if you are still thinking after listening to this, well this all sounds good but hey where do we get started? The great news is that Maik has created a really good template that you can use for your project brief or project initiation document. Check out the article to download it. But Maik, thanks so much for doing this today. It’s been great having you with us.

Maik Stettner: Yeah, thank you for having me.

Ben Aston: You’re very welcome. As one of our DPM experts, if you like what Maik’s been talking about, you’ll be glad to know that Maik is making an appearance on our upcoming course starting in September called Mastering Digital Project Management. If you’re not sure what I’m talking about but you know you need some PM training, check it out. It’s a seven-week crash course that includes interactive video lessons, weekly assignments, group discussions, the option of coaching sessions. Head to digitalprojectmanagerschool.com and get yourself signed up before the course fills up.

If you’d like to contribute to the conversation on project initiation documents or project briefs head over to the resources section of the digitalprojectmanager.com to join our Slack team where you’ll find all kinds of interesting conversations going on and do remember to comment on the article and share it too. But until next time, thanks for listening.