A list of useful project management rules could be a mile long. But what good is a list that doesn't help you remember the truly immutable rules? You know: the ones that you shouldn't be ignoring, bending, twisting, breaking. In this article I give you the rules that we use in our digital agency and the exact explanation how they help us manage our web development projects better. I also mention what happens when you go around these rules.

One of the most useful tiny rule books on the planet is the famous Joel Test by Joel Spolsky. It's a list of twelve simple questions which help companies rate the quality of their software teams. The list is now fourteen years old but most of the rules still apply. 

My list is inspired by Joel's Test. I was thinking: which rules have a great impact on the success of the projects in our agency? Where do I see other people make mistakes, so that my experience would help them? And which rules will withstand the test of time? This is is my answer.

Here's the Slideshare Presentation

Let's see what each of those rules means for your digital agency business.

Document your project management process.

'Documenting your practices' in project management means two things:

1. you must answer the question 'How Our Agency Manages Projects for Clients' and
2. you must do this in writing.

All digital agency business owners know they should document their business practices, but almost nobody does that. There's never enough time to stop sawing and sharpen the saw.

The agencies that do stop to sharpen their saws, however, reap the following benefits:

Less time spent on ramping up new employees to established business practices.

When we hire a new employee, the first thing we do is that we give him access to a special Google Drive folder called "How Our Company Does Business" and tell him to read everything there. Documents in this folder are our company's operating manual. Without a manual the company managers must spend a lot of time with all employees just to teach them the basics.

More order in the trusted project management system.

I care a great deal about organization of company information. I cherish orderliness and the results my company gets from it. I believe that the time spent on consistently maintaining orderliness keeps paying dividends forever. When company employees work with a project management system, they're actually crowdsourcing company documentation. You need to manage the crowdsourcing process if you want your company data to make some sense. That's why I make sure that all people in our company know the basic conventions about procedures such as storing and naming files, documents, projects, assigning and resolving tickets, logging actions etc. When I sign into Simpfinity where we manage our projects, I see years worth of well-organized information, starting in 2008. I like what I see because I know I can always rely on that information.

Fewer dangerous, expensive and embarrassing mistakes.

Imagine what would happen if your new support guy fell victim to a phishing scam and gave away sensitive client information to an unauthorized person. A client could lose his whole online business just because your newbie sent an innocent email to a wrong person. This, luckily, never happened in our company and luck had nothing to do with it. Experienced companies have protocols in place to prevent serious damage. Somebody needs to document these protocols and make sure people use them. If you're the boss in your own company, it's your job to either create the documentation or organize its creation. You need to teach your employees that protocols exist and you need to point them to a trusted central place where they can find training material. Such a central trusted place should be accessible 24/7.

Documented processes are a trusted reference.

People in your company can't keep all the little details in their brain's 'RAM' all the time. You need their RAM occupied with creative thought processes essential to doing their best work. They don't need to remember all the rules all the time, but your employees do need to know that the company maintains a searchable reference which they can consult when they need it.

For example, our company uses a third party application essential to a part of our business. Not every team member uses this application every day and people forget how to do stuff in it. Simplest mistakes, which are easy to make in that app, create enormous annoyance to multiple people inside and outside our company. That's why the person in charge for introducing the app to our company wrote an extensive documentation about it. I consult it regularly.

One project manager per project.

The project manager (the PM) is the glue between your agency and your client. She acts as a knowledgeable router of information and decides what gets done first, second and last. She acts both as your client's and your agency's advocate.

Being a PM it's a tough, tough job. Having two different people with the same tough job on the same project is a recipe for disaster.

You can't have multiple PMs at the same time on the same project. It sounds like a no brainer, but the practice is different and projects often end up with two or more acting PMs.

This happens on complex projects where the PM needs continuous assistance from another person on her team. This person, i.e. the developer, has the required technical skills which the PM needs to make important decisions. So the project starts with one dedicated PM and with time the role gradually shifts and splits to another person.

It's also not uncommon to have multiple people on the client's side talking to multiple people on the agency's side. If all people in all teams do not work in perfect sync, some vital information and requirements will be lost and the project will get out of hand.

That's why I flag these kinds of projects as high risk. The PM will have to manage the project more tightly and make sure she keeps control of the project.

You keep control of the project by always having an overview of all tasks the team works on. If multiple members of your team are talking to the client directly, they must log every conversation. They must store every document they receive in a way the PM has organized it. The PM must be informed about everything that happens between the client and the agency.

Your development team members also must know whom to go to with their questions and requests. If two people are managing a single project, sooner or later one project manager's instructions will start colliding with the other project manager's instructions. This confuses and annoys the developers. Chaos is rising and projects get delayed.

One project manager per team.

Let's say that your agency has one dedicated project manager. She works with one development team consisting of one developer and one designer. The PM's job is to organize work on client projects. Everything goes smoothly until another person (i.e. the agency's boss) requires that the dev team does some work on an unscheduled urgent project. The boss bypasses all work that the PM has scheduled and all projects will now be delayed.

This happens in small agencies. The boss does not go through PM's schedule and the dev team suddenly has two project managers, each fighting for the resources of one dev team.

The solution is simple: either hire another dev team (unlikely) or always respect a project manager's schedule. Nobody messes with a PM, not even the boss. If other people want something done, they need to schedule a new project with the PM, stand in the line like everybody else does and wait for their turn.

Never assign a single task to more than one person.

If you don't want a certain task completed, assign it to two people. They will both wait for one another to complete it and the task won't be completed at all. 'I thought he would do it.'  'And I thought she would do it. She did it the last time.'

Here's a simple example of a simple task. You're launching a website for a client and before you do that, you want to install Google Analytics tracking. There are three people in the agency who are working on that project, they're all technically capable of installing Google Analytics and they have all been assigned a similar task on past projects. If you assign all three people to this task, every one of the three people will expect the other two to complete that task.

It's human nature. A person must believe that nobody would complete the task unless she does it herself. By assigning the task to only one person, you make her own the task.

If you assign a single task to two people, you're also forcing needless communication and interruption on both of them. One of the two people will have to interrupt the other person at some point to ask about the task.

If two or more people need to perform the same task (for example, everybody needs to fill out a timesheet at the end of the month), each person gets his own ticket for that task. A ticket for every task must be unique in your project management universe and everybody should be able to mark a single task resolved. Nobody's charging you money per ticket created, so why would you reuse tickets like that?

In 2006 we were using a bad project management system which allowed us to reuse tickets. Good task management apps technically prevent you from assigning a task (an issue, a ticket…) to more than one person. If your app allows you to do this, you will at least know the reason why people don't complete some tasks.

The person estimating a task is the person working on that task.

Don't ever let sales people, project managers and designers estimate how much time the developer needs to finish a task. The same goes both ways. People not working on a particular task tend to underestimate the effort.

Don't make a senior developer estimate a task for a junior colleague either (if the junior is the one working on a task). Estimates are hard even without people estimating other people's work. The person who will be working on the task must research the request and come up with his own educated estimate.

I used to work in sales and I also managed projects for many years. Every time I broke this rule, my team ended up working more than I estimated and we couldn't charge for that extra work.

Review all finished tasks you've assigned to other people.

Creative Commons Image License

Even if you have a formal quality assurance (QA) and testing procedure in place for all your projects, this rule can help you. You want to double-check all or as many tasks as possible, even the ones that do not go through a QA process.

If you create a task for another person, always follow up on the task after the person has completed it. If you created a ticket for a colleague, it must have been important enough. Why bother otherwise? If it was important to create a task, then it's important to verify that your colleague delivered the work well.

When the task management system notifies you of the task's completion, revisit the task you've assigned to another person. Take a look at the work she delivered and read her comments in the ticket.

This practice has many benefits:

It enforces precision and clearer communication.

The person creating the task needs to learn how to describe the work in a clear way. The person working on the task needs to learn how to follow the instructions precisely.

It promotes individual ownership of all the little things that happen in the agency.

You'll hear less of the 'that's not my job' from your employees and colleagues. Your agency's output will increase in quality if everybody follows up with every task they create and takes interest in how other people do their jobs.

Task reviews help your agency teach processes and company culture to new employees.

New employees are usually assigned tickets by their senior colleagues. If a junior makes a mistake, there's a fair chance that a senior will notice the error during the task review process.

This is also a great opportunity to identify flaws in your written process documentation. For example, if the new employee has read your documentation and still made an error, maybe your documentation is not clear enough.

Task reviews are sometimes the only way to catch human errors which couldn't be detected any other way.

When I was less experienced, I thought that it was possible to write protocols so good that they would prevent all future errors. But as soon as I documented one solution to a problem, another problem appeared. There are mistakes your agency has never made before: how do you prevent those from happening?

One way to cut down on the number of serious human errors is to have a simple error checking mechanism - a simple convention - built into your task management system. The task review is one such mechanism. Two pairs of eyes are better at catching errors than one.

Log your every action.

Write a comment for everything meaningful that happens on a project. You never know when you will need this information. I always comment as if the project depended on the accuracy of a single comment.

That's exactly how good source control systems work: they force you to write a comment with every code commit. It takes you up to ten seconds to write a meaningful comment, but your ten seconds might save a few hours to another developer (or yourself) in the future.

For example, leave a comment for all micro-milestones:

'The campaign has been launched.'

'The client has paid the advance fee.'

'I've snail-mailed the contract to the client.'

'The client has promised to send the project documentation by Monday.'

'I've sent the design proposal to the client.'

'The client called to report a bug, here's the bug report: (...). I checked it myself, she's right, it's not working.'

'I've installed Google Analytics and looked at the real time reports, the installation works fine.'

'The client has sent us access info to his server. The login credentials don't work so I called the client to tell her that, she said she would check it out. I'm waiting.'

When people log their own and their client's every move like this, you can always return to the project to analyze, compare and verify it. The best part is that you can rely on the sum of these logs to be 99,99% accurate.

Log every substantial conversation you've had with a client. 'I called Mr. Client and his secretary said he was on vacation'. Trust me: the simplest piece of information like this can save your ass in the future. Sometimes you need to go back far in the past to reconstruct a chain of events. We've started logging actions in 2008. Having a complete, crowdsourced, timestamped log of every action of every person ever working in the company is invaluable.

You're logging comments not just for yourself, but for your colleagues and for your company as well. Always think of other people. Think about what information might be useful to them in the future and write that down as a comment. You're not working in a vacuum.

When you're resolving a ticket, don't just click 'Resolve' - write a comment. Although my task management app allows me to resolve a ticket without a comment, I never do that. In our agency we teach people to always write a comment - even if it's only a short and sweet 'done'. It's like signing the completion of the work by hand.

Discuss this article on Google+

projectmanagement luckyisgood, returnnull