The way I approach managing projects is simple. Simple enough that I'm going to describe it right now.
-
We plan out what we think needs to be done.
-
The work is estimated conservatively so it's likely the actual implementation will be under the budget.
-
You (the client) then put the work in order from most important to least important.
-
I help rearrange the order to handle known dependencies or other technical factors.
-
I start working on the first item until it's done or I'm blocked.
-
Then I work on the next item (second most important). And so on.
I'll continue to work on the next most important item until something happens:
-
we're done and the project is complete
-
an item that was skipped earlier (blocked) is unblocked
-
you decide you want to re-order the remaining items (this would jump back into step 3 and 4)
-
we decide to add new items for any reason (jumping back to step 1)
This process is simple and works exactly the same for any type of work.
New features. Fixing bugs. Optimization. Training. Support.
It relies heavily on clear and open communication. Which is why that is such an important factor in what I look for in a client.
This process is also flexible enough to be personalized for you. I've changed it for clients
-
who wanted to manage the list of work every day by re-ordering it
-
who used Scrum in 1 week and 2 week sprints
-
who planned out a week's worth of work on Monday and then checked back in Friday
At all times I try to follow the golden rule:
work on the most important thing right now
Eric Davis
P.S. I have specific tools to help manage this workflow that we'll use. But the tools aren't that important as the process. I can (and have) used the same process with different tools, including ones a client required (due to decisions outside his control).
P.P.S. After using this process for awhile I found a similar approach published earlier called the Chaos model.