I was hired by a marketing company a year ago initially for link building / SEO stuff, but I'm actually a Web developer and took the job just in desperation to have one (I'm still quite young and just finished 2nd year of University). From the 3rd day my boss realised that I'm not into that stuff at all and since he had an idea of a web based app we started to plan it.

I estimated that it shouldn't take me longer than two months to do it, but as I was making it we soon realised that we want to add more and more stuff to make it even better.

So the development on my own lasted for about 4 months, but then it became an enterprise size app and we hired another programmer to work along me. The guy was awesome at what he did, but because I was assigned to be programmer/project manager I had to set up milestones with deadlines and we missed most of them, because most of the time it was too much work, and my lack of experience kept me setting really optimistic deadlines. We still kept adding features and had changed the architecture of the application twice.

My boss is a great guy and he gets that when we add features it expands the time frame in which things should be done so he wasn't angry at me nor the other guy. But I was feeling bad (I still am) that I suck at planning.

I gained loads of experience from the programming side, but I still lack the management/planning skills which make me go nuts. So over the last year I have dedicated probably about 8 months of work to this app (obviously my studies affected it) and we're launching as a closed beta this month. So my question is how do I get better at planning/managing a project, how do you estimate the times? What do you take into consideration when setting goals.

I'm working alone again because the other guy moved from the city. But I'm sure we'll be hiring to help me maintain it so I need to get better at it.

Any hints, points or anything on the topic are appreciated.

4 Answers 4


Here is an excellent article by Joel Spolsky: http://www.joelonsoftware.com/items/2007/10/26.html

It's a very simple process that basically advocates estimating how wrong your estimates are going to be by keeping track of how wrong they have been in the past. Over time you'll end up with much better guesses at the time it takes to do things. It's not an instant fix but, then again, accurate scheduling of software projects is very hard.

He also advocates breaking projects down into very small (and theoretically easier to estimate) parts.

  • It's also worth having a broader look at his site as he has lots of interesting articles on project management and related issues.
    – Scroog1
    Jun 7, 2012 at 15:10
  • Also look at construx.com. Particularly consider the information about uncertainty and project progress. The only time you can accurately predict a software project is af
    – mattnz
    Jun 8, 2012 at 0:56

The only way to get better at estimating is to do it more, less experienced developers are generally overly optimistic. From what you wrote it doesn't look like estimation was your issue, it was scope creep.

You will probably have a class eventually about project management, but as a quick overview the PM is responsible for a lot more than setting the schedule and keeping it on track. They are also responsible for ensuring that the project that was defined at the start in the project charter/other documents is the project that gets worked on. In your case t seems you ended up doing a poor job of this because you went from a small app to an enterprise wide app. This is a hard thing to manage though, especially when you are also a developer on the project. Developers tend to always want to add to and improve everything they work on indefinitely and never really get to the release part. As a PM sometimes you need to tell developers their plans are out of scope or X feature is good enough already start working on Y.


Part of knowing how to plan out timelines, dependencies, etc., will come from experience. However, that being said, it's a very different skill set than web development and programming. Part of that experience you're gaining is that project management probably isn't your thing, and there's nothing to be ashamed in that. To be honest, I'm surprised they expected a full project manager out of you, knowing that you are still in the middle of your studies. I've known people that have been doing project management professionally for many years who still don't quite get it!

Unless you are really in need of the money, I'd encourage you to place an increased emphasis on your studies over this work. If you really enjoy doing web development, and you want to succeed in it, then you should focus on improving your knowledge and skill set of that type of work and step away from this project management role. There's no shame in telling your boss that you've come to realize that you bit off more than you can chew and that you've run into personal limitations that might hurt your organization. Tell him that you'd like to keep working with him but strictly in a development role. If he's a great boss, he'll recognize how that will benefit both of you, and you can push your career farther than you could otherwise.

  • Well TBH I want to own my own business and I think this is essential at least when I set it up as I don't think I will be hiring a PM straight away. I'm also very keen on getting this project right because I own part of it and from what the market research can tell us it will be profitable. So I just need to figure out how to improve my skills. But thanks for your opinion. Appreciate it.
    – Ignas
    Jun 7, 2012 at 14:58

One thing that helps us a lot is to have a standard estimating template that we use for every project. It forces us to include time for things developers might forget in their estimates like meetings and client communincations, project managment, unit testing, support for qa and UAT testing, documentation. When you add in all the pieces that 8 hours of development time can easily turn into 22 or 23 hours.

Scope creep which you also suffered from means a new estimate. Every time without exception. When you decide to add a new feature (or are requested to) they need to know how many additional hours and how far that will push the deadline. It is best to push the product and move scope changes to the next iteration much of the time.

Get a product out and add features rather than continually delaying to add more cool stuff. And make sure the scope creep doesn't come from the developers. Scope changes should come from the clients or stakeholders in the organization not from the devlopers. There really is no excuse for that. If you think of something you want to add, then add it to the next version after vetting the idea with the stakeholders instead of delaying the current version unless something is actually so broken it won't work without the new thing. Shipping the product is a critical skill to have. Every piece of software ever written can have some additional shiny new things added to them before realease. Resist the temptation and plan for your new features in future releases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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