Ask YC: Project Management?
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!
14 comments
[ 3.2 ms ] story [ 46.1 ms ] threadIf 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.
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.
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.
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.
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.
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.
- 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.
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.
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.