

Ask YC: Project Management? - ykristiawan

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.<p>Do you guys always meet your deadline? Any suggestions, advice, or pointers? Thanks!
======
bridgetroll
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.

------
neodude
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.

------
izak30
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.

------
babul
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.

~~~
mooneater
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.

~~~
babul
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 :)

~~~
bridgetroll
In my experience, it is normal practice to factor time into the estimate (call
it risk factor if you want) to push your skills. You factor a profit margin
into your estimate right?

As long as the customer is satisfied with the overall quality, cost and
timeliness of the product, you've met your obligations as a business. Why does
the "profit" always have to be only cash? learned skills are a form of capital
reinvestment that the customers pay for just like they pay you a profit margin
to do the work.

------
Hates_
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
Thanks. I guess the key point is to manage clients expectations. Any reference
about tools/formats that you use in reporting your progress?

~~~
ra
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.

------
mattjung
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.

