Ask YC: Project Management?

https://news.ycombinator.com/item?id=186616

by ykristiawan • 18 years ago

4 14 18 years ago

news.ycombinator.com

I never deliver any custom software that I develop on time. The clients never complain about the result, though. But they are unhappy because I miss the deadline.

Do you guys always meet your deadline? Any suggestions, advice, or pointers? Thanks!

Hates_2• 18 years ago

I've found that since moving to an agile approach with weekly/fortnightly deliverables, my estimates have become better and clients expectations are managed nicely. Clients can constantly see progress and can easily see how my time is going to be spent week-by-week. If new features are requested or problems hit, it's easy to communicate how that's going to effect the current timings and next deliverable.

ykristiawan• 18 years ago

Thanks. I guess the key point is to manage clients expectations. Any reference about tools/formats that you use in reporting your progress?

ra• 18 years ago

One part of Agile that may help here is continual incremental delivery.

If you can deliver new functionality to your client each week, a little each time, then they should be happy to see progress, and each week you could re-evaluate how many weeks there are to go?

Just a thought.

mooneater2• 18 years ago

When I was getting started, I would often obsess over the "right" formats for different types of communication with clients.

Ultimately, I decided what clients really want is to know you are doing everything reasonably possible to take care of them, being courteous, keeping them informed, yet not drowning them in detail.

So, the simplest format that covers these points is a good start. You can then ask for feedback.

Hates_2• 18 years ago

Acunote is what I use to plan out my sprints. It does all the stuff of creating charts (which clients always like) and predicting how much work you'll be able to get done with each new sprint.

neodude• 18 years ago

I have a similar problem. A lot of the time I merely find myself developing infrastructure instead of developing features. Part of the problem is writing in PHP without a framework (or, rather, a semblance of my own); a more significant part, I believe, is that I just really, really like building architecture. In that way, I'm probably being an architecture astronaut.

The key, as you've said already, is managing client expectations. At some point you must have given a timeline, given a prediction for how long you thought something would take you. At some point you must also have deviated from that timeline/prediction; mine, as far as I've identified it to, is being an architecture astronaut. Hence, the first step, I think, is to narrow the problem down to those deviations, and question why you're deviating so. The deviations may even be something useful or necessary. Rather, figure out what is breaking, then step back and look at the whole picture to see what needs to change.

Agile might be the answer here. At the very least, there are several very good ideas you can steal from agile to build your own approach to engineering.

babul2• 18 years ago

Usually, but that is because I have learnt to...

a). add a little extra time to projects to buffer myself.

b). not take on projects I cannot do (beyond my skillset).

c). interact with clients regularly with updates so they are in the loop, know what is going on, and constantly happy.

mooneater2• 18 years ago

Seconded.

On a): More than a little. Plan to be "90% done" by halfway through the schedule. Remember that "the last 10% takes the other 90% of the time". This is entirely true, and its due to unknowns. When this 90% at halfway approach becomes instinct, you will miss very few deadlines. This has become my internal Golden Rule for non-trivial projects.

On b): My business would never have launched if I didn't constantly stretch my skillset past what I thought I could do. But there is still a limit.

On c): Clients never like unexpected surprises. But they hate them even more if they appear late in the game. Keep expectations in line with reality.

babul2• 18 years ago

on b): yes, but do you do it on client time? I try not to, as it causes uncertainty in deliverables, unless the client is happy with experimenting. I learn/expand in my own time on "fun" projects :)

notauser• 18 years ago

Setting client expectations is really the core of project management. Everything else helps with the first part.

- Have a plan and share it, including progress updates (so they know when to expect things).

- Have an agreed statement of work (so they know what to expect).

- Think about your risks, write them down and agree them with the customer (so they know in advance that things can go wrong, and can be ready for the consequences).

- Bring up issues early, as with all the information above they will be able to make trade offs. They might be more interested in an early build with less functionality, for example.

This is just as important on a fixed price contract - although the customer doesn't carry the financial risk, they do carry a reputation risk. Every time you are late without sufficient warning they have to go to their organization/co-workers/clients and suffer the consequences of your delay. That's much easier to do a month in advance than a day in advance of a deadline.

izak30• 18 years ago

Break each part of a project down to what you can do in one sitting. If any item on your list is longer than 8 hrs, you're probably going to miss it. Also, figure out how many of THOSE thing you can do in a week (unlikely to get 40 billable hours / week for me)

As a general rule, if I'm unsure of exactly how long something will take, I double it, and I'm usually very close, or over the high end. (I'm down currently to only adding 40% more time per each unsure item, which has been very close lately..not that I'm getting faster, I'm just getting better at estimating)

Plan time to make their edits (10-20% or more of the project, depending on the quality and robustness of the original spec).

Don't take on a project with a hard deadline you can't meet, you will make yourself crazy.

bridgetroll2• 18 years ago

I work on DoD projects with varying project reporting requirements. There are many methodologies and processes one can follow. I've experiences success with Capability Maturity Model Integration and Agile (others here have mentioned agile too). There's an ongoing "meeting of the minds" of merging CMMI with Agile in the defense space.

For estimation, learning a bit of earned value management system (EVMS) can be useful. There is COCOMO II for estimation, but I don't think you need to go there for small projects.

A book I've found useful is "Software Estimation: Demystifying the Black Art" by Steve McConnell. Its helped me.

The secret sauce is to find that knife's edge balance of infrastructure (accountability and management) versus flexible productivity.

Then there is always the Scotty Principle.

mattjung• 18 years ago

Extreme programming offers a number of tools to manage your projects. Some important points: imply the customer by giving him access to the project state and to let him change priorities whenever he wants, focus on completing and testing the most important use-cases ("stories"), frequent "micro-releases", do regular demoes and acceptance tests to avoid bad surprises and integration issues at the end.

Ask YC: Project Management?

Related Stories