How do you "project manage" when you are the only developer?

Question

Targets in a one man developer team?

When you are the only developer on a new startup, how do you think the project management should move forward. Because I am the only person with a technical background I am really the only person who is monitoring my progress. I'm not a slacker and would really like to enforce some kind of accountability and target based expectations on myself, but I don't know how this is really possible?

The new start up has other team members, but at the moment their role is purely supervisional and advice based (when it comes to the software development).

I'm concerned with finding techniques to accelerate my development. The industry that the software is designed for is seasonal so timeframes are of importance.

• Maybe I should consider using software?

---

In response to the first answer, I see that I should provide more information to my question. This is the situation.

• I am going to continue to be the only developer for the forseeable future and I will be working on this start up for several years.
• The project will see me develop software which will be used as a service.
• The service will care to the needs of many clients
• The "needs" of these clients is where the other people in the team comes in. They have been operating in this industry for many years.
• We have already done several months of design and brainstorming
• I have been developing for about 7 weeks now, and will hope to have a core prototype'd demo product in about 7 more weeks.

Answer 1

The range of tasks in such small projects depends much on what exactly you're working on.

In either case you probably need to cope with:

• Managing the scope. It can be very light-weight, so the scope can be just a general direction, which is pretty common in startups, and it can be split into coarse-grained tasks. As you work in startup you probably plan to change anyway, so there's no need for very detailed planning.

  UPDATE: Since you've already done a few months of planning the general scope should be known pretty well. I'd still consider it's going to change over the way, especially after you get feedback from early adopters. Anyway your focus here should be set on splitting the scope into smaller work items - features, user stories or whatever you feel comfortable with. I wouldn't go into very detailed level here as priorities will be changing, that's for sure.

• Monitoring progress. Again in one-man team it doesn't have to be anything heavy. However I'd try to have tasks not longer than few-day-long, which means you may need to split those coarse-grained features which you came up with when working on the scope of the project. Than it's up to you whether you only need to monitor progress by marking them as done once you're done or you want to have some more data, like real working time or maybe estimates as well. The latter two may help you to estimate future work if you're asked for that and help you to come up with some information when you're going to finish your work. You may consider Kanban as a very lightweight tool to manage tasks and monitor progress in such project.

  UPDATE: In terms of tools/software which can help you here, don't look for anything fancy. For such project Excel sheet would probably work wonders. However personally I'd go with some task board in your workplace. It nicely visualizes what's done, what's ongoing and what are top priorities for the nearest future. Not only would it work for you but also for other folks in your startup.

If it is more of a product, so you build something which is addressed directly to end-users, like web service, you should also focus on:

• Product management. In bigger projects that's not really PM's job, but since you work in one-man project actually every important responsibility is yours. In terms of products for end-users product management is very important - you need to decide which features are needed and which are not, you should gather some feedback about your plans etc. This is to some point connected with managing the scope, but here you actively create and change the scope and not only work on predefined one.

  UPDATE: It looks like most of that one is responsibility of other people in your organization. However you haven't clarified whether they're actively working with end-users to get feedback. If they do then fine. However experience you can get talking directly with end users (in some, I don't say you should publish you mobile number) is invaluable. So even if product management is covered I wouldn't isolate myself from communication with users.

If you work on a product for a defined customer you will also have:

• Communication with customer. In such a small project it probably be mostly informal (emails, calls) than formal (documentation, specification) but it's pretty likely some of communication will be required to keep the project aligned with client's expectations. In startup project you will probably want to demo your progress pretty often and get feedback how you're doing.

  UPDATE: It looks like your client is your users so pretty much the previous point covers the subject.

One last thought: even though it looks like quite a wide range of tasks don't make them any more complicated than it's absolutely needed. You may go with as simple tools as possible, just to make the work done. It's not the goal to have full-blown project management process - you just try to cover gaps, which in small projects are really small.

Answer 2

pawelbrodzinski's answer is excellent, but I feel compelled to add a bit more...

Even a 1 person project can benefit from the old Plan-Do-Check-Act cycle. Even though this is mostly about changing your processes, you can use it as a framework for how you approach everything you do.

Plan

Establish clear objectives and follow a plan, even if your plan is a rough release schedule, it will give you deadlines to work, setup expectations for your customers and provide a framework for tracking progress. It may be that the bulk of your plan is what you won't get done. Sometimes knowing what is out of scope for a particular release is the hardest part.

Do

Work in small increments. This applies to implementing change as well as to your regular work. Frequent releases in strict time-boxes creates a 'heartbeat' for your project that you and your customers will both feel.

Check

Verify that you are following your plan, whatever that is. Was you last release on time? Did it include the features everyone expected? You are considering adding some process to your work, but it still may not be working the way you want - don't be afraid to change - sacred cows make the best burgers.

Act

Learn from the checks you performed and refine your plan for the next release.

Answer 3

I agree, Pawel is close to awesome in composing accurate answers in the subject. I only want to add one more dimension to what was said before.

As long as you are your own PM you must remember it comes with responsibility for team's motivation and pace of work.

You worked on this project for 7 weeks now, and you know your worker for years already, so you also know what to expect next. Almost every writer has problems with creativity, motivation and joy taken. I think it will be a challenge to a developer as well. Prepare for it and try to overcome the problems.

Answer 4

I've found the OpenAgile framework lends itself to small projects that may or may not have a project manager. In an effort to prove this theory out, I mapped how OpenAgile would work for a project manager conducting a job hunt and detailed it in a blog.

This doesn't replace anything that Dave or Pawel has said. I think it just may provide a good, structured framwork to work from.