1–10 of 15 posts
Do you guys always meet your deadline? Any suggestions, advice, or pointers? Thanks!
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.
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.
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.
Thanks. I guess the key point is to manage clients expectations. Any reference about tools/formats that you use in reporting your progress?
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.
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.
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.
Thanks. I guess the key point is to manage clients expectations. Any reference about tools/formats that you use in reporting your progress?
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.
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.
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 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.
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.
- 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.