In November I gave one of my favorite presentations so far. I was at WordCamp Berlin, and I wanted to talk about something near and dear to my heart: project management. This time I wanted to strip it down to its basics and speak to designers and developers as a project manager to say: “This is why we do what we do. It’s not because I (as a PM) want to know or micromanage your every move, it’s just that your specific move might be impacting every other thing in the project.” I wanted to talk about critical paths, communication, and dependencies to clear up what project management is all about and how every person needs some elements of it in their life.

And it meant I got to talk about spreadsheets.

And give a nod to a site I ran several years ago about spreadsheets (documented forever in this 2011 Tweet), no longer online:

I’m going to share the speakers notes for the presentation, but feel free to skip down to the video below to hear it live or to scroll through all the slides on Slideshare.

I’m currently director of marketing but my unofficial title is someone who get stuff done. I’ve taken several project management classes and run a lot of projects so this presentation isn’t really about making you an expert, or having you run your entire project by yourself, but it’s a way for you to better understand who a project manager is, what they worry about, and how that can affect your work.

Last year I give a talk about WordPress agencies scaling up and I included this little quote in the presentation from Matt, from a WCEU speech. The reality is a lot of WordPress agencies or individuals contributing to WordPress don’t have all of the skill sets needed to work a bigger projects.

I talked about marketing and business development in the other presentation but on this one I wanted to focus just on the project management aspect of things.

What is project management?

For me, “Project management is problem solving on a deadline.” There’s a lot more to it but that is the essence of project management for me.

Earlier in the fall, I was at the Webdagene conference in Oslo where Mike Monteiro was presenting, and in the presentation he said designers are problem solvers. They’re not artists. And I think most of you probably embrace that meaning, but it’s a good thing to remember that everyone’s trying to just solve a problem.

But we use different tools to get the job done. For many project managers, one of those tools might be a spreadsheet.

I have a problem with spreadsheets myself. And when I say problem, I really mean love.

I am actually such a big fan of spreadsheets that at one point I had a website dedicated to them called The Spreadsheet Warrior. Running on WordPress naturally. Here’s what the Internet Archive remembers of the site. I replaced parts of quotes with spreadsheet and they all made perfect sense. Like this one which says “Great works are performed, not by strength, but by spreadsheet” and Samuel Johnson definitely did not say that.

So the spreadsheet love is real. Cells and rows make my brain calm.

Another best friend of the project manager is a Gantt chart. If you’ve never heard of a Gantt chart you’re probably pretty lucky but they look like this, let’s get a closer look.

Let’s just take a minute to look at this beauty. So many different cells to fill-in and from little cascading deadlines and items to do. I actually enjoy a good Gantt chart, but that’s not what I want to talk about today.

Instead I want to focus on the project management triangle. It has some other fun names like the iron triangle or the triple constraint, too, but I’m sure you’ll remember the project management triangle.

Cost, Schedule, and Scope. These three things are what put pressure on the project as it’s moving forward, and the project manager has to constantly balance these things. In the middle is quality because of course the goal of the project is to deliver a quality project.

Some of the best information you can have when doing a project is to understand which of these your client is most sensitive on: cost, scope, or schedule, and adjust accordingly.

I’m going to focus on only two parts of this triangle: scope and schedule. For cost, if you’re lucky as a designer or developer you won’t ever have to deal with profitability on projects, and for quality, that’s absolutely part of your job but I am going to assume you’re getting that information from other resources or your own expertise.

As a designer or developer, the two things that you can have the most impact on are schedule and scope.

So let’s talk about scope.

The project scope is about the entire project: what needs to get done, how, and by when. 

Is there a business motivation behind the project? “Redesign the site” is a super vague goal. Better ones might be: increase sales, make products easier to browse or discover (increase viewed products by visitors), or time spent on site. Something that’s measurable are even better reasons that you and your team can orient the project around.

A part of the project scope is scoping the product, and this is where most designers and developers have visibility and input.

There can be a lot of things that are peripheral to the actual product or site that’s being built. For example you may need to find a hosting provider or buy a domain name or file a trademark before site launch, but those would not be part of the product scope.

The product scope can take the form of technical specifications, the design guides, and other information.

So in an ideal world…

In an ideal world you have a discovery process, you’re part of a strategy, and you can help architect a solution which has project specifications and those can be easily translated into milestones and deadlines. You collaborate with your team and others to do the work, and you deliver the project.

In reality, many projects skip steps, some things are decided before you get the project, or by the time you get involved the project has already started (or been abandoned by someone else).

On WordPress.com VIP (my former team), and I’m sure this has happened to everyone, often we may have been introduced on the project past the planning & strategy phase and the execution has already started. If you’re lucky, you can take the client back to rework some parts before you move forward with the execution.

Agile project development is a lot more circular, but for many of you if you’re doing project work, you won’t have the opportunity or luxury to actually do Agile development unless you’re working on a site for quite a long time. If you’re doing product development, perhaps.

Agile is closer to what we do at Automattic / WordPress.com, as we’re continuously improving and tweaking the platform, and sometimes we release things in milestones, but the codebase can be changing several times a day.

So that was an ideal world. And I wish for all of you ideal clients with a lot of organization and time and documentation.

I find the real world can be a lot messier. And that depends on the client, and sometimes the project manager, or account manager who’s wearing more than one hat. Often on the VIP team as much as we like to think we were essential to the project, several clients would show up with a deadline already approaching and little to no opportunity to be involved in the strategy.

And that’s when scope is in danger. Skipping some of the steps means there is a potential for scope creep either on the project or the product side.

Scope creep is the worst disease that exists in projects: it’s hard to predict and resolve, yet scope is something which drives the project sometimes more than cost and schedule. I’ve seen more concessions on time and money made for functionality reasons than the reverse.

Sometimes if they’ve made an external commitment to a launch date, schedule will win out but you’ll still have to make concessions to get it launched on time.

So you may not have an ideal situation. You may not have the specifications or a clear picture of what’s happening so whatever’s being told to you, this is a great time to stop and reflect as a designer or a developer.

These five questions I think are great tools for you to figure out with your team, by yourself, or with your project manager. Some of the worst problems and projects I’ve seen over the years have been assumptions. It’s a miscommunication but really it’s an unvoiced miscommunication, which is the worst.

So ask yourself what do I know? What information have they given us?

What do I not know? Is there something that you expect in every project that you haven’t been given?

These two next questions are pretty tied each other: What are their expectations and what are we not expecting to do? And am I assuming these things or have I actually asked or documented them?

One of the best things I think I ever started doing was outlining the things that would not be covered in a project. In the right situation the client looks at the list and says “oh, of course.” But in other situations it’s a great time to make sure that those are documented assumptions and avoid problems later, or increase the scope to include those features or functionality from the start.

The earlier you can bring this into the project the better. And hopefully you can work with the client to agree on project and product specifications before you get too far into the project.

So now let’s turn to schedule. This is usually my favorite part of a project, trying to figure out all of the pieces and how they will fit together on a timeline. That’s when my beloved spreadsheets and Gantt charts can come into play.

Let’s get another look at this, shall we?

GANTT charts are most effectively made in project management software, though I have re-created them in spreadsheet form and don’t really recommend it, but the important things to extract from the Gantt chart are two: the critical path and dependencies.

(not a real project I’ve worked on)

But first let’s back up to our project. Remember our scope? You probably know vaguely what it’s going to look like at the end, since we already talked about product scope. Perhaps it’s a site launch or a new plug-in or redesign.

At first the project looks like a big blob with no definition.

Pretty much every big task can be broken up into smaller pieces. And something that I’ve applied to the rest of my life whenever I’ve wanted to do something. Something that feels unattainable just needs to be broken up into smaller attainable pieces. If I’m moving to another country I need to buy plane tickets, I need to find housing, I need to contact friends who might know someone there, I need to look online for a job, etc.

The same goes for most project work. If you’re doing agile development or or some other waterfall or other method, there is a point when something is completed and something else is started…it could be a feature, functionality, or testing phase, etc.

From there you can start to group them and put a little order to them.

To keep things simple in this example, larger tasks are depicted larger and smaller tasks are smaller.

You know more or less which things have to be done first, and can put them in order.

If you can think of time as running at the top, some tasks can be handled earlier and some might have to be handled later in the process.

And then between the bigger things you can create dependencies. For example I can’t move into an apartment before I actually arrive, and my arrival is dependent on choosing a date of arrival or booking a flight, and I have to have a ticket before the date I leave, so moving into the apartment is dependent on that in terms of time.

And WordPress projects and plug-ins have their own dependencies; you may not be able to do the data migration correctly until you set up the custom taxonomies and custom data structure beforehand so the import process maps that content correctly. So the correct migration is dependent on the data structure being correct and before you can finalize their structure the client needs to give you a list of products so you can set it up.

So once we’ve figured out our dependencies…

We can start to understand which tasks are going to take the longest and factor in which are dependent on others.

The critical path looks at the longest path of activities and determines that this is the path which has the least amount of flexibility. The critical path are the tasks that must be done in a certain order to complete the project. If one of the activities on the critical path is delayed, it will affect the entire project’s timeline.

And this is where you fit in. The critical path is something that everyone on the project should be aware of, and even if you’re not managing the whole project timeline you still may be a part of the critical path.

If someone is waiting on something from you that is part of that critical path it’s really important that you make sure your item is on time, or if it’s not then you can let your PM know as it could affect the whole project.

An easy example is getting the data structure set up so content can be migrated, and beta testing or review can’t start until actual data is in WordPress, which means if you’re setting up the data structure, you’re part of that critical path.

Some of this may seem super obvious but it’s always a good idea to take a step back at the bigger picture. This is what the project manager is doing on a continual basis.

If there’s one thing that I’d like you to take from this is “just pick a date.”

One of the most frustrating things for project managers or working on a project in general is, if you’re lucky enough not to have a client telling you when something needs to be ready, often it’s up to the team to decide when something will be ready. This can be frustrating because without the sense of urgency and sometimes things don’t get done. In non-client or non-deadline kind of work it’s actually really important that you still pick a date, no matter how far into the future it is.

Some of the biggest projects that we’ve done inside Automattic or a new project that we don’t know how to estimate have started with picking a date semi-far into the future, so we can work backwards from there. One of the things I commonly ask people to tell me is when they think things will be ready, and this is something that’s very important in a distributed company like we are because we ask people to set their own deadlines.

If you’re having trouble picking a date on something you might want to ask yourself why. Perhaps you need to go back to looking at your assumptions and identify any missing information, or  perhaps the task is actually too big, and you need to really separate it further into a lot of smaller pieces and understand the dependencies.

In software planning I know that a lot of people like to pad software development time by three so if someone says something will take two hours they budget for six. If you can’t come up with a date on something by looking at your planning materials and this safe way of budgeting time then you need to go back and look at what you don’t know and why you’re not able to pick a date.

If you’ve been picking dates and consistently missing them, you need to go back to drawing board.

That brings us to blockers. One of the frequent things I’ll ask someone is what’s blocking them if they’re unable to deliver the work. It’s pretty self explanatory isn’t it? Most of time blockers are external, and a lot of times you’re waiting for information for parts of the project come to you, so you can’t start the work.

It’s easy to look at a project from a high level and see potential blockers, such as the client not preparing their data in time, but it’s a lot harder to look at the individual level, especially in ourselves, and figure out what’s blocking us.

So if you’re not delivering on time, step back and ask yourself why. And tell your project manager.

And that brings us back to communicate. Most good project managers pad time into their schedules, and they may not even tell you that. They ask for it Tuesday, but on the critical path, they really need it Wednesday. If you have knowledge that something is going to slip, or be faster than schedule, this could be critical information.

Managing expectations is probably the most important of these items because it affects everything else you do.

And that brings us back to scope creep. So now we’ve understood more about schedules, about scope and how you can be a part of the solution and moving forward.

If your scope is well defined there still may be cause to worry and that’s where developers and designers actually impact scope.

Who’s heard of gold plating? Gold plating is adding features which are nice to have but unnecessary, and not requested by the client. That doesn’t mean you can’t add or propose new features but a good rule is to think about is the business reasons for the project. If these features are directly related back to those reasons, they’re probably a good thing to put in the project. If they’re not, it’s probably gold plating.

Gold plating actually has good intentions behind it, but often it’s unnecessary.

Another way you can help avoid scope creep is by making sure the project has phases of rollout where features can be prioritized and others can be de-prioritized in order to meet deadlines.

And that comes to documenting everything. As you make decisions, as phases or scope changes, make sure to document and get sign-off on things which move it from being an assumption that things are clear and/or approved into actual approval and acknowledgment.

A few more things which aren’t less important but hard to cover in such a short time:

Resource allocation is something that becomes important when you have many projects, many people, and concurrent deadlines. If you’re lucky you won’t have to deal with the scheduling part of it but you’ll have the end result which is you have to work on Client X for two days to finish something, and then switch tasks to Client Y because that part of the project needs to move forward. These scheduling details relate back to the critical paths of each project and making sure that people are working on the things which are most urgent in the right order. 

Risk planning can take many forms in projects but probably the most common in your situation is when you’re the only person who knows how something works. This is a big risk to your team, especially if you want to do something like get sick one day or even take a vacation, so making sure that you document your code or make your designs available somewhere where other team members can get to them is important.

Approvals relates back to document everything, if you can get a formal approval for things you’re going to save time and make sure that things can move forward.

So go ahead and fake it!

Here’s the video of my presentation:

And here are the slides: