≡ Menu
Pawel Brodzinski on Software Project Management

Project Management in One-Man Project

One man

Recently I came across a very interesting question on Project Management Stack Overflow. The question is how to organize project management in tiny projects, where everything is done by a single person or just a couple of them.

The interesting thing here is that when we think about the point where organization introduce formal PM role we usually see at least a few dozen people. So how about startups, where just a few people are working in the whole organization?

Let’s consider one-man project. I leave aside all tasks directly related with software development, so for the sake of this article I don’t care about version control or bug tracking. Which leaves us with a few of basic areas.

  • Scope management

You actually need to know what you’re going to do. At least on general level. Actually in startups it’s not a good idea to have detailed plans of development since, well, what you start with is wrong and you’re going to change the course along the way. However if you don’t know, even roughly, where you’re going and you can hardly tell what is your goal then you might look for another project or another job instead because you’re not succeeding. So yes, a bit of scope management is crucial – you have to know that you’re building a tower and not, say, space ship.

  • Task management

You already know where you generally are going. Good. Now you have to figure out the next step. Or the next feature you’re going to build. Then you build it. And you repeat the process. I mean from the point when you figure out the next step, not from setting the general direction. Of course you don’t have to be so short-sighted to plan only a feature ahead but you do need to break the scope down to smaller tasks and start building your tower brick after brick. And of course you need to know which brick goes first and which goes next.

  • Product management

This is kind of tricky. Actually if you know the scope and you dealing well with tasks you pretty much have this one covered. Given that you’re building the right thing that is. Product management in such small project is all about making sure that you’re building the right thing. It’s not on brick level but you need something more than just a picture of tower pinned over your desk. You actually have to know that you want to keep bad people in hostage there so you need cells, torture chambers and such. Then you need to figure out how these things should work so clients… I mean hostages are served… I mean tortured well.

  • Communication with users and/or clients

Finally, you need to verify whether your dream about best of the breed torture tower is something people actually want. You need to regularly confront your ideas with clients or users or both (depending on your target group) to make a sanity check: are we still going into the right direction. Yes, you need to talk with those tortured poor souls to learn whether they’re happy with the service. You might also check your butchers – they do use your product as well. If the tower isn’t ready, go find potential customers and potential users and get their feedback. Since you’re running one-man project you don’t have clearly defined requirements so this part is even more important than in typical projects.

Now, I’m well aware these areas aren’t strictly connected with project management as some corporate PMs out there know. In big teams PM can be isolated from product management and from end users, scope can be thrown at the project team in huge specification before the project starts, but well, we don’t discuss big teams working on boring BDUF project here, do we?

By the way PMSE (Project Management Stack Exchange) site is awesome not only in terms of inspiring blog posts. You will find there a lot of great stuff so what are you waiting for? Go check the site.

in: entrepreneurship, project management

11 comments… add one

  • Mchl April 14, 2011, 3:15 pm

    Oh boy…
    I’ve been working as a single-person development team for three years now, and how I wish I never got into that position in the first place :D
    The thing that seems to be most difficult is that managing myself takes time from my production time. I’m constantly looking for some ‘lightweight’ practices that help taming the inevitable chaos while not consuming too much time.
    Recently experimenting with kanban ;P

  • Pawel Brodzinski April 14, 2011, 3:34 pm

    @Mchl, If I was starting one-man project at the moment and it was anything more than something you can do with gung-ho I’d definitely go with Kanban. But then, Kanban alone isn’t enough. You have to build Kanban on something.

    In terms of engineering practices it will be your programming toolbox – whatever you use to build high-quality code.

    In terms of project management it will be covering areas mentioned in the post, this way or another.

    By the way: for me it’s neither engineering nor project management part which is the most difficult. The hardest thing in one-man venture is marketing and sales. But then, since we discuss one-man ventures it’s always about our personal strengths and weaknesses. Mine are there. Maybe yours are somewhere else.

  • Mchl April 14, 2011, 11:31 pm

    I’m doing internal development, so sales and marketing don’t really concern me. Thanks for pointing out bright sides of my situation ;)

  • Victor Alonso Lion April 15, 2011, 4:14 am

    Hi Pawel,

    Great post!
    One of the other interesting things even single person project teams can apply is Risk Management. One of the things I advice, is to always at least consider a small risk that you want to mitigate or avoid. Putting in place baby steps will make the process be safer and safer and would put the provider or service quickly ahead of competition.



  • Pawel Brodzinski April 15, 2011, 12:13 pm

    @Victor, I actually kind of thought about that while writing the article, but do we really manage risks consciously in such tiny endeavors? I’d say we don’t do it as a part of our project management effort but as a sanity check or something.

    But well, since I generally treat these definitions loosely I guess it should go to the list either way, so good catch on this one.

  • James Mortensen April 16, 2011, 11:56 am

    Hi Pawel,

    Great article! What you were saying about torture chambers and how you have to constantly do sanity checks to make sure you are serving your “customers” can even apply to products that involve more than 1 person.

    Also, in software development, we regularly try to do hallway testing, but I think that same type of user testing could be used outside of software development to some extent.

  • John L July 8, 2011, 5:33 am

    Hi All,
    Why not to use project management software like workforce track?

    Just comfortable and affordable.

    It is mainly specialized for small organizations. At the same time such kind of software enables managers to save time working with HRM, CRM and etc.

  • Brenda July 15, 2011, 12:08 pm

    This one man show perspective is a clear negation of the project management principle/philosophy that highlights the importance of cross functional team, roles and responsibilities.

  • Pawel Brodzinski July 15, 2011, 11:31 pm

    @Brenda – Actually I don’t see things this way. It is more about merging different roles into one person in projects which don’t really need anyone besides this one man.

    Would it be better to skip specific areas of project management instead?

    Well, I think we’ve seen enough projects which were excellent in terms of engineering but died because of no product management, e.g. building the thing right versus building the right thing, or complete chaos in task management.

    I don’t see it as negation of project management principles. I see it as wise use of the principles.

  • Sinuhe December 2, 2011, 9:19 am

    I think one particular issue of any one man project is the fact that you try (must) do too many things at the same time: setting goals (aka product backlog), work out the task list, time and cost estimation, programming and researching, refactoring, do this about architect and do that about UI design etc… Find the right balance and don’t get distract to keep you at top productivity is IMO the key because you don’t have any change otherwise. So sometimes a optimal configured development environment with the right toolbox can already save your life. Because in one man project you are in general not very disciplined so some formal practice is often helpful. But on the other hand, you have the advantage of all-in-one communication hence no need for lengthily communication protocols or documents. Of course it can save you a bit time or it can be your doom depends on your perspective. I believe here still can be a lot more written about these stuff.

  • Pawel Brodzinski December 5, 2011, 2:49 am

    @Sinuhe – Actually, since it is one-man project the right set of tools can be perfectly adjusted to this single person. One would prefer more formal approach while another would get best results in creatively chaotic environment.

    I agree though that some level of organization is needed, although we usually do much of that pretty intuitively. I mean, we rarely think in a very conscious way about product management or scope management, yet to some point we do it in each and every case.

    My point here was more to make people realize what is being done in one-man projects rather that pointing specific practices you need to adopt in such situation.

Leave a Comment