1. A Tiny List
of Immutable Project Management Rules
For Digital Agencies

2. by Visnja Zeljeznjak
Simpfinity.com
@Simpfinity

3. Based on This Blog Post:
simpfinity.com/blog/
tiny-list-pm-rules/

4. 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.

5. Inspired by The Joel
Test
The 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.

6. 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?

7. This List is My Answer.

8. ★ 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.

9. #1
Document
Your Project Management Process.

10. This Means Two Things:
1. you must answer the question 'How Our Agency
Manages Projects for Clients'
2. you must do this in writing.

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

12. 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.

13. 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.

14. 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.

15. #2
One Project Manager
Per Project.

16. 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.

17. 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.

18. 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.

19. 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.

20. #3
One Project Manager
Per Team.

21. 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.

22. #4
Never Assign a Single Task
to More Than One Person.

23. 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.

24. 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.

25. #5
The Person Estimating a Task
Is the Person Working on That Task.

26. 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.

27. #6
Review
All Finished Tasks You've
Assigned to Other People.

28. 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.

29. Benefits of the
Review Process

30. Enforced 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.

31. It Promotes Individual
Ownership of Tasks
You'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.

32. 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.

33. 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.

34. #7
Log Your Every Action.

35. "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

36. 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.

37. 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.

38. 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.

39. 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.

40. 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.

41. Here's The List, Once Again
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.

42. www.simpfinity.com
Sales Proposal + Project
Management + Client
Support Software
For Web Development
Companies

43. Thank You!
Visnja Zeljeznjak, Storyteller
@Simpfinity

44. Creative 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/