A Tiny Listof Immutable Project Management Rules

For Digital Agencies

by Visnja Zeljeznjak

Simpfinity.com

Based on This Blog Post:

simpfinity.com/blog/tiny-list-pm-rules/

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.

Inspired by The Joel TestThe Joel Test is a list of twelve simple questions which help companies rate the quality of their software teams. Read it here: joelonsoftware.com/articles/fog0000000043.html

The list is now fourteen years old but most of the rules still apply.

I was thinking:4 Which rules have a great impact on the success of the

projects in our agency?

4 Where do I see other people make mistakes, so that my experience would help them?

4 And which rules will withstand the test of time?

This List is My Answer.

★ The List ★Document your project management process.One project manager per project.One project manager per team.Never assign a single task to more than one person.Person estimating a task is the person working on it.Review all tasks you've assigned to other people.Log your every action.

#1Document

Your Project Management Process.

This Means Two Things:1. you must answer the question 'How Our Agency

Manages Projects for Clients'

2. you must do this in writing.

Stop Sawing. Sharpen the Saw.Reap the benefits from documenting your processes.

Spend less time teaching new employees the basic stuff.

1. Give new employees access to a shared location where you keep your company's operating manuals (a folder in the cloud with a bunch of documents).

2. Tell them to read everything they find there.

Maintain order. It keeps paying dividends forever.When people work with a task management system, they're crowdsourcing company documentation.

Manage this process: teach people basic conventions (storing and naming documents and projects, assigning and resolving tickets, logging actions.

Fewer dangerous, expensive, embarrassing mistakes.

Experienced companies have protocols in place to prevent damage. It's the boss' job to organize a creation of a trusted central reference, accessible 24/7, which they can search and find training material.

#2One Project Manager

Per Project.

Being a project manager is a tough, tough job.Having two different people with the same tough job on the same project is a recipe for disaster.

It Happens on Complex Projects.The project manager (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 slowly shifts and splits to another person.

When Several People on the Client's side Are Talking to Several People on the Agency's Side......some vital information and requirements get lost and the project gets out of hand.

On risky projects the PM manages the project more tightly to make sure she keeps control of the project.

You keep control of the risky project by always having an overview of all the tasks the team is working on.All members of your team who are talking to the client directly must log every conversation and store every document they receive the way the PM wants it.

#3One Project Manager

Per Team.

Two PM's Will Fight Each Other for Limited Resources of One Dev Team.As a result, all projects will be delayed.

Not even the boss messes with the PM.

Want something done? Schedule a new project with the PM and wait for your turn.

#4Never 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."

Don't impose needless communication and interruption.

One Person -> One Ticket.

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.

#5The Person Estimating a Task

Is the Person Working on That Task.

Don't let sales people, project managers and designers estimate how much time the developer needs to finish a task, and vice versa.

People working on the task must research the request and come up with their own educated estimate.

People not working on a particular task tend to underestimate the effort. The result it extra work you can't charge extra.

#6Review

All Finished Tasks You've Assigned to Other People.

If you create a task for another person, always follow up on the task after the person has completed it.

You want to double-check all or as many tasks as possible, even the ones that do not go through a formal QA process.

Benefits of the Review Process

Enforced Precision and Clearer CommunicationThe 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 TasksYou'll hear less of the "that's not my job" from your employees and colleagues.

Your agency's work will increase in quality if everybody follows up with every task they create and takes interest in how other people do their jobs.

That's how you teach company culture to new employees.

If a junior makes a mistake, a senior will notice the error during the task review process.

You'll identify flaws in your documentation if new people read your documentation and keep making errors.

Catch undetectable human errors.There are mistakes your agency has never made before: how do you prevent those from happening?

Solution: having a simple error checking mechanism - a simple convention - built into your task management system. The task review is one such mechanism.

#7Log Your Every Action.

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows

where you live."1

John Woods

I treat project logs the same.Having a complete, crowdsourced, timestamped log of every action of every person ever working in the company is invaluable.

Write a comment for everything meaningful that happens on a project.

Always think about other people.

The ten seconds it takes you to write a meaningful comment now might save a few hours to another developer (or yourself) in the future.

Leave a comment for all micro-milestones.I've snail-mailed the contract to the client.

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

The client called to report a bug, here's the bug report: (...). I checked, it really isn't working.

Log every substantial conversation you've had with a client.

'I called Mr. Client and his secretary said he was on vacation'.

The simplest piece of information can save your ass in the future. Sometimes you need to go back far in the past to reconstruct a chain of events.

When you're resolving a ticket, don't just click 'Resolve' - write a comment.

We teach people in our web development company 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.

Here's The List, Once AgainDocument your project management process.One project manager per project.One project manager per team.Never assign a single task to more than one person.Person estimating a task is the person working on it.Review all tasks you've assigned to other people.Log your every action.

www.simpfinity.comSales Proposal + Project Management

+ Client Support Software

For Web Development Companies

Presentation by www.simpfinity.comCreative Commons Image License

Portrait of a Saw Blade https://www.flickr.com/photos/csessums/9577384988/

Is it okay to click here? https://www.flickr.com/photos/theilr/9772325024/