Yesterday I wrote about how agencies can't use typical project management methods. Those methods fight interruptions. We have to build interruptions into our work style.
Here's the real meat-and-potatoes stuff. This is the set of rules and guidelines I wrote for the Portent team, nearly un-edited, plus examples. I talk tools, rules and exactly how you should set up and follow project milestones and tasks.
Note that I use BaseCamp throughout, but these principles should work no matter what you use.
I'm going to use the BaseCamp milestones page as the example, but I feel any document that tracks a project must have the following:
That's it. There are lots of other features, but at its heart, this is what a project is: Milestones. Tasks. Communication.
Tools I use to try to make projects easier are:
Explanations of milestones. The explanation is supplemental text describing any details or additional information about that milestone. In BaseCamp, use Milestone comments as the explanation area.
Messages record all communication within a project. Worst case, all e-mails and phone conversations should be cut-and-paste into a text file as a project record. In BaseCamp, you can use the Messages tool. Any e-mail involving the project should be sent via or stored in the BaseCamp Message tool. If you have a phone call, record the notes from the call as a message. If you send a file to everyone, again, use the Message tool.
Collaborative writing is part of almost any marketing project. If you are writing something that will require review and revision by multiple people, use something that facilitates that. If nothing's available I use Google Docs. BaseCamp has the Writeboard tool. Use either one.Sometimes you want to have an
asynchronous discussion about a design, a recommendation or similar. E-mail may work but it can be clutzy if you're sending 1-2 sentence messages between team members. A discussion forum can be better, since you don't have to remember to 'cc' everyone. Or, use Campfire - it's the Chat tab in BaseCamp. I prefer Campfire because, again, it records everything, and it's super-easy to use.Finally,
file management can make-or-break the project. Make sure essential files get stored somewhere besides your laptop hard drive. An online service like DropBox can work. BaseCamp has the Files tab - if you attach a file to a message it's automatically stored. If not, you can upload the file from the Files tab.
The ground rules:
A milestone is anything deliverable from the agency to the client or vice-versa. 'home page first design' is a milestone. So is 'site SEO recommendations report'. However, 'site crawl' is not.Every milestone has a responsible individual. Don't assign milestones to groups or teams. Assign them to one person. That person is on the hook to get the work done. It's possible a team will do the work, but that one person is accountable, no excuses allowed.The responsible individual must control the result. I used to see projects where the account manager was responsible for every deliverable. That's a terrible precedent. The account manager is responsible for directing traffic between the client and the team, and facilitating communication. They have little control over on-time delivery of a home page design. That's the designer's job. The AM can pester and beg, but in the end the designer has to get the work done.Every milestone has a deliverable. "February SEO recommendations" isn't good. "February recommendations report complete" is.Every milestone has a status. In iterative projects (ie all projects), saying "February recommendations report" isn't helpful. "February recommendations report 1st draft" is.Every deliverable has an individual recipient - a single person, somewhere, who will receive the final product. You can call out the recipient in a supplemental note/message for the milestone. It doesn't have to be in the milestone title.Every recipient has a follow-up milestone, like "Approve February recommendations report".Tasks are the things you do on the way to a milestone.No task takes more than 2 hours. This is kind of arbitrary, but I insist that my team create tasks that are atomic - that are definable, achievable things. So 'code administration site' is an awful task. 'Set up authentication for administration site' is a lot better. Doing it this way has three benefits: It lets everyone track progress day to day, and prevents the deadline ambush.You're less likely to get interrupted mid-task if tasks are shorter.You have far more between-task times to handle all the other stuff that inevitably comes up.Each person controls their task list. It is not the account manager's job to create task lists. We had to do this in Celoxis simply because not everyone could create a task list. BaseCamp allows anyone to create a 'todo' list (a task list, really) and record time associated with to-dos.Every task has a verb. "Keyword research" is a lousy, overbroad task. "Write initial keyword list" is good.Only the project/account manager can mark a milestone as complete.Only a project/account manager can reschedule a milestone.
If you get interrupted:
Find out if the interruption is an emergency.If it is not, check to see when you'll be done with your current task. It should be less than 2 hours, remember.Let the person who's asking for help know when you'll be able to help them.Mark down their request as a separate 'to do'.Complete the current task.Complete their request.
Oh, god. Some agency named Portent has hired us to rebuild their site, and to conduct ongoing SEO afterwards. You just know they're going to be second-guessing us every step of the way. And have you ever met their CEO?!!!
Ahem.
Regardless, they threw a lot of money our way. The scope of work is split into two major projects: Site build and SEO. Here's the necessary bits for this example:
Note that deliverables and timelines are utter fiction, by the way. Use these and you could end up in a world of hurt.
The site build lists milestones, but some need to be broken up into smaller chunks. for example, the Design milestone needs to become 8 individual milestones:
Note how each milestone follows the rules outlined above: They have a defined deliverable that's passing from agency to client or vice-versa; include a handoff, etc..
For the mockup, the account manager needs to explain what 'sent to Portent' means. You can't really send a bunch of HTML pages, stylesheets and graphics to a client. So, she adds a comment:
That comment further explains the milestone. It'll sit there for anyone who needs it.
Portent's SEO work is trickier. It's cyclical, so it's tempting to enter broad milestones like "April SEO" and leave it at that. The better way to handle it is like this:
Figure out which of the bolded items involve deliverables to the client in some form. In this case, everything except 'site crawl' is a deliverable. Directory submission counts, even if we don't literally send directories to the client, because we're delivering something for the client.Make each item into a milestone, scheduling out recurring items on a regular basis for the duration of the contract.Create a corresponding to-do list.
Here's how the biggest recurring milestone - site review - might look:
Note that I associated a task list with the first milestone. I used a to-do list template, so I can associate the same thing next time if I want, or modify it, or do something different. What I did not do: Apply the same basic to-do list for six months of milestones. That will cause us to get mechanical and never adjust our tasks according to changes in the client's SEO profile and goals. So I'll create the remaining task lists when I need them.
Always put together your to-do/task list for a given month at the start of that month. That way, you can focus on current tasks and better address client needs.
Here's the task list:
That's the high-level look at how we handle projects. Is it perfect? Of course not. It's only as good as the people involved, and it only works if everyone's comfortable with this style.
But in ongoing, campaign-based work, where interruptions are the rule, it's kept us on track.
View the original article here
