I've worked a lot on projects by myself -- "one man" projects. These are typically small projects in the software domain. Many of them have no customers other than myself (who actually use the end product); some have other users.

The question that keeps recurring to me is what kind of project management practices should I apply, at a minimum, in these projects? Having no other developers or staff, things can move and change quickly.

At a minimum, I always have:

  • A vision of what I'm going to accomplish
  • A scope statement describing much of the work
  • A risk register with my top 5-10 risks to monitor
  • A place to list procurement items (graphics/sound)

Without getting too cumbersome, what are the other aspects that I should include in my projects?

Edit: On the technical side, I usually use a variant of agile/Scrum -- a product backlog and estimates per story in points, with no sprints, just releases.

10 Answers 10

up vote 42 down vote accepted

For software projects, even when you're the only developer and end user, I find it extremely important to have some kind of issue tracking. It might as simple as a spreadsheet, or something more sophisticated as dedicated software hooked into your version control repository.

You will forget things. The list is there to save you the time.

  • 1
    Excellent, I knew I forgot that one. That bit me before on past projects. It IS important to track issues, and separately from the "main" work. – ashes999 Feb 9 '11 at 15:31
  • 2
    For this I would recommend Trac. It is web-, i.e. browser-based, has a ticket system, milestones, subversion VC front-end and a wiki system useful for notes and documentation. It is free, should run on all platforms and easy enough to setup. In addition it has a nice plugin interface. – Martin Scharrer Feb 9 '11 at 17:16
  • I personally like to stick it onto the same spreadsheet and indicate that it's a bug for projects that are small. Cheers though. – ashes999 Feb 10 '11 at 13:42

Track your time on each task.

This will give you visibility into which parts take the longest so you can concentrate on improving those specific areas.

Use big buckets to start with, like planning, development, testing, bug fixes, deployment, etc. Each bucket should be something that will hold at least 20 hours.

  • Agile inherently tracks time via a more abstract measure (story points). I do this already. – ashes999 Feb 9 '11 at 15:29
  • 2
    @ashes999, story points is useful for velocity-related metrics but it's too coarse for process- and skill-improvement. Track the activities & their duration for each story. Once you have a few stories so tracked, look at the times for the activities. See if there's variation in each activity for duration per story point and if a variation in an activity technique or duration correlates to variation downstream in the story or later stories. – Huperniketes Mar 2 '11 at 6:27

I think your list is good. I will suggest you at a minimum do the following things, even for small one-man projects:

  • Plan (make sure you have a good list of activities that explain how to get to your vision)
  • Track your plan, make sure you go back to your list at least weekly and see where you are in terms of your original estimates.
  • close the books at the end, by archiving your project documents in a central place. This will help you in the future.
  • 1
    Not bad, but these are all generic activities -- planning, tracking, and archiving. I'm looking more for specific activities that bring me benefit. – ashes999 Feb 9 '11 at 15:06
  • 1
    Maybe I am not understanding the question. Could you add to your question your pain points? what is causing you wonder, if you are doing all the right PM activities for your self-manage projects. Thanks for your fast response. – Geo Feb 9 '11 at 15:15
  • If I knew my pain points, I wouldn't have asked the question :) I would've had a list of problems and devised solutions to them. I'm looking to flush out my practices with any best-practices from other PMs. – ashes999 Feb 9 '11 at 15:30
  • @Ivo, I really appreciate you pointing this out, since I have been using SO for over 2 years without ever getting this point presented to me. I do believe that using salutation and signature adds tone and personality to each member's post, allowing each discussion forum to have its own life. I think we will all agree that PMs should be masters of communication, and there is no communication without the right tone. Nevertheless, I appreciate and will take your suggestion in consideration. – Geo Feb 11 '11 at 20:56

As we are talking on software domain, don't start the development only with:

A vision of what I'm going to accomplish

Design a fast flowchart of your project functionality.

There are a lot of free flowchart software on the web like, gliffy or SlickPlan.

It saves you, time and problems even if it is a small project.

I always start with creating a WBS, also for home or private projects. I believe it is the single most important technique or tool a PM can use. All other stuff starts from the WBS.

  • The corresponding object for agile methodologies for software projects is the user story backlog. Since disagreements often arise because language can distance identical points-of-view, I point this out so those from a particular field can understand and communicate the same concept to another in the other field. – Huperniketes Mar 2 '11 at 6:42
  • Source control
  • Unit tests
  • Automated builds
  • Spec
  • Schedule
  • Bug tracking

One of the most important things when managing yourself, is to maintain focus.

Do enough planning to know what and why you're doing this, but not so much that it becomes unwieldy or an opportunity to procrastinate.

Not only in the sense of perseverance, but also in the sense of not taking on too much at once. For a single person, I think that a kanban board, and strictly limited WIP is the ideal for managing a single project.

The rest of my framework:

Limit the number of tasks that you have in progress, even if it's something you're waiting for.

Actually track your time. It'll give you a sense of your ROI.

Use Git.

Talk to other people when you're stuck.

Good list. One thing I would add is Change Management. You have to evaluate every change to your original concept. Every change introduces additional risk. You have to evaluate the change in terms of risk, budget, schedule, and scope. Once you have made an objective evaluation you can determine whether to implement the change.

Good Approach of your starting.

One thing I have to add is that daily backup and version control is important.

My experience is that I saved the project after modifying the source code from the workable version , it sometimes displays logical errors in the another day. It takes me a day to retrieve the original workable version. A week later, my computer is attacked by a trojan and I have to ask the technician to get back the file.

Always do backup and version control . The path of storage should be web server like dropbox , google Drive and your USB drivers if necessary.

A simple project plan that puts an ETA on milestones to make sure you stay on track would be my addition. It's too easy to overwork when on your own thereby decreasing your return on investment, e.g., your time. Is your project earning you $100 per hour or $10 per hour - something tech heads tend to forget.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.