# Bits and Bytes # Methodology

What I took away from my DPM course

This isn’t to say that these are the six most important things the course had to offer, but rather what stood out to me most....

This fall I took a course on digital project management. As someone who is new to the DPM profession, it was incredibly beneficial for me to learn about the methodologies, tools, and processes behind digital project management. The insight and knowledge gained from the course has informed how I go about my daily and weekly tasks as I have a better understanding of the thought processes and steps that should go into each action and decision I make.

The 7-week long, entry-level course from The Digital Project Manager covered topics such as how to manage a project from start to finish, budgeting, estimating, creating a SoW, and project leadership. Below are the six most significant things that I learned from the course. This isn’t to say that these are the six most important things the course had to offer, but rather what stood out to me most and had the biggest impact on how I approach my job.

1. A successful project needs a successful start

Although I was aware of all the admin tasks and meetings required to start a project, I didn’t realize how much responsibility rested with the PM to ensure the project starts off on the right foot. That, and just how much opportunity you have as the PM to ensure a great start.

As the PM, you are many things, including the glue that holds the project together, the one thing that’s constant, and an ambassador for your team, the client, and the project. You have to create momentum and clarity. It’s your job to ensure everyone understands their role and what is expected of them. Creating a RACI chart and including it in the SoW is a good way to assign and organize responsibilities.

Front-loading the project is also a good way to solidify a successful start. This means setting up the tools, folders, documents, and communication channels as soon as it begins. Having a project set-up checklist that includes everything you need to create and schedule will speed up the process. A helpful tip I came across here is to have screencast recordings of any tools your client will have to use so that you can easily share them with new clients to provide them with an understanding of the tool.

2. Don’t plan beyond your planning horizon

The planning horizon is the extent to which you can predictably, realistically, and accurately plan a project; it is how far ahead you can see. It will vary from project to project but the thing that remains the same throughout is to never plan in detail beyond the horizon. You can’t properly see this area, so thorough planning here is risky guesswork. This was new to me as I would have assumed an approach more akin to planning in detail for the whole project.

However, I learned that it’s okay to tell your client, “We don’t know, yet.” You can plan in detail for what you do know and allocate time generously for the work beyond the horizon. It’s worse to over-promise or commit to a delivery date that you won’t be able to keep. You also don’t want to spend time meticulously planning the unknown only to have to go back and plan it all again when you do get clarity. What you can do is give a ballpark range based on your assumptions and the current velocity of the project. As the project progresses, the planning horizon will move further out and you’ll be able to fill in the gaps.

3.  It’s never too late to clarify

It’s possible that, following a communication with a client or after sharing a document with them, you realize that something you wrote or said may not have been as clear as it could have, or that you missed mentioning a clarifying detail altogether. It’s never too late to go back to the client and say something like, “Just want to manage expectations here, this is what we meant by X”.

This might seem obvious to some but it stood out to me because, as a junior, I wouldn’t have had the experience or confidence to know that this was totally okay. I would have worried that coming back to the client to mention something that (I felt) I should have remembered to include or specify the first time would leave them unimpressed or not confident in my abilities. I now know that this is not the case and that it’s so much better to be proactive in this regard to help mitigate against disappointment.

4. Always communicate the assumptions and risks

This in itself wasn’t new information to me; yes, you should let your clients know the assumptions you’re making and any risks you can foresee. What stood out to me here was the number of opportunities you have to identify and share this information with your team and client. And that frequent discussion of and reference to assumptions and risks doesn’t create a red flag for your client. Choosing to be open, honest, and transparent builds trust, and talking about risks regularly normalizes the conversation.

There are opportunities to identify and discuss assumptions in the internal briefing session, pre-kickoff, kickoff, discovery, scrum meetings, weekly status meetings, and other check-ins. Assumptions should be documented in your scope, SoW, estimate, and MSA. Having it in writing ensures everyone is able to refer to the same information, and clarifies how the assumptions will impact timing, budget, and other resources.

Regarding risks, effectively managing them entails having a conversation with your client at the beginning of the project on what their attitude and approach is and what warrants use of the contingency budget. A RAID log can be included in the SoW to ensures risks are identified, assessed, and controlled. You can even include one in your weekly status reports to ensure they are monitored consistently and to create and control a proper mitigation plan.

5. Communicate the anti-scope

It’s good practice to include the anti-scope, or negative assumptions, in your SoW or MSA. This means the work that you will not be doing. To determine what this entails, think of what the client could possibly think might be included in the project scope that is not. Examples could include sourcing image assets, writing/sourcing/translating content, creating other language locals, hosting, device/browser support, and many more.

Stating what the scope of work includes only implies what it excludes, leaving room for misinterpretation. Even though you may not have included task X in the scope, you didn’t explicitly state that you’re not doing it. This wasn’t inherently obvious to me as a beginner, but I think including the anti-scope in the SoW or MSA is simple step that can be taken to reduce or eliminate the possibility of misalignment on project expectations and responsibilities. It’s easier to have these specifications in writing for both teams to reference.

6. Eat your frog first thing each morning

This comes from the quote by Mark Twain, “Eat a live frog first thing in the morning and nothing worse will happen to you the rest of the day”. Which is to say (in this context, anyway), take care of your most important, most difficult task first thing each morning, ensuring it is 100% complete before moving on. I’m guilty of getting the smaller, less important tasks done first so that I can “get them out of the way” and “clear my plate” for the more important ones. Tackling your biggest task first ensures it gets done and means it’s not hanging over your head for the rest of the day, susceptible to being interrupted and put aside for other things that come up.

I’m still working on being more disciplined about this one, but creating my to-do list at the end of the day for the following day, rather than when I come in in the morning, helps me prioritize my frog.