Categories
Puzzles

Project Management for One

Read an interesting post by igor_nav the other day, describing his newly-devised methodlogy for tackling one-person development projects — specifically, dealing with the problem of not being able to finish things, by breaking down the tasks remaining. Take a look at his explanation!

The problem he describes doesn’t really apply to me, because I have a strong “implementer” personality element (in Belbin terms). I have a load of projects that are sitting moribund at the 20% stage, ie. the interesting ideas have been had but I realized it would be a load of work or rather boring to implement them. But for the few that I get past that point, I tend to be quite driven to get them finished. I’m psychologically incapable of leaving something at 90% done, because the anticipated emotional reward of doing the last bit is so great for me, it overcomes any pains along the way.

Which are you more like?

I should also point out that the particular project that igor_nav is talking about here is a fun puzzle website, which you should definitely check out. My own peek at it suggests that so far there are about half a dozen puzzles that are easy / quick, a couple that will need time and research, and a handful that I don’t understand at all. But maybe you can do better?

8 replies on “Project Management for One”

If I were to use that methodology I’d want to add another action:

* Declare a task to take irreducibly longer than 30 minutes and schedule a slot in which it can be performed.

This is pretty much essential for some programming tasks. Although perhaps people with a better memory than me might be able to split any task between multiple slots without dividing it into conceptually distinct parts, I simply can’t do it.

He has, in essence invented another version of agile development, and one which looks quite well suited to the solo programmer. He’s got an iteration where the length is defined by the outcome, not the time spent which got him into trouble. But he has got simple granular requirements, a clear prioritisation mechanism and so on. He’s also got a nice way of recording his progress, and the ‘list getting longer’ and ‘negative progress’ phenomenons are both accepted in most agile methodologies. (They happen on all projects, but until you accept and manage the problem it’s, well, a problem)

The interesting thing is where he hits the wall. In a traditional agile process he’d have reached the end of that week and said ‘didn’t get task x done, it was way more work than I thought.’ Then you’d say ‘given that its way more work – is it still worth doing?’. This is why having your iterations bound by time rather than whether the work is done is a good thing – it makes you assess whether the cost/benefit of a given task has moved as you learn more about it.

I’d say the most useful bits for the solo developer would be writing requirements as user stories, and applying a ruthless business value driven prioritisation.

Things like test driven development are going to be a matter of personal choice, but the focus on having releasable product as soon as possible could be very handy for the one man business.

See

http://www.amazon.com/User-Stories-Applied-Development-Addison-Wesley/dp/0321205685

and

http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415

for more.

I reckon I need one of these plans for scientists. Exploring ideas is fun. Writing them up (which necessitates a story to tell, and thus extra bits beyond what I’ve done) is deadly dull. And keeps me out of the lab where new shiny projects are bursting to be started.

I’m a terrible finisher. Which is an issue.

That seems to be the pattern with quite a lot of scientists of my acquaintance. Which either says something about the kind of people who become scientists, or about the kind of people with whom I become acquainted. Or both.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.