It seems to me that, while one can manage his/her time outside of a project, it would be difficult to manage a project without managing time.

I could not imagine a project with a set of tasks, and no dates.  How can one plan without time references?

On the other end of that spectrum, if a project is late, can it still be considered successful? In some industries, being late is part of the deal, it's normal and expected. However, in other businesses, being late mean penalties and a tarnished reputation.

So, what is the most important: doing it right, or doing it on time? 

My position here would be both. It's no use delivering something on time, if it's not fully completed and functionnal. There is nothing worse for a comapny's reputation than a beta-level product released. Clients will forgive lateness to a certain extent, but they will not forgive and product that doesn't work.

However, there is a limit to a client's patience. Sometimes, when trying no to make it right, but to make it perfect, we miss […]

As any software development company will tell you, there are always more features to add to a version than there is time to implement them correctly. Hence, we face a challenge: implement more features with limited functionnality, or implement fewer features will full functionality.

It may be tempting to implement as many features as possible: spread-sheet product assessments and feature comparisons would proudly bear the YES checkmark next to all the lines in the requirement list. However, being able to say "yes, we have reports" quickly followed by the limitations of the feature is no way to win your prospective client's heart. As they use the feature, they will quickly realize that, although the feature is there, it is stripped-down and not what he or she expected.

I believe that if we are going to implement a new feature, not only should it work, but it should also be complete. It should have all the functionnality that is expected. If you can import user data, you should be able to import all user data, not just […]

Sometimes, that new feature that took so much time and effort, that was so complicated to implement, is not important to the client. This can be heartbreaking for developers.

I've seen it often: my press release is sent for approval, and the project manager comes to me, asking why the new feature is not mentioned in the release. I see disapointment in his eyes. After all, they worked really hard to make it work. All that effort should translate into a killer feature that customers will flock to, right?

Not always. Sometimes the effort translates into something that is taken for granted by the client. Sometimes, the little-worked-on feature turns out to be the big selling point for a product.

The case of the one-client feature 

There was this product launch where the development team had implemented a very complex algorithm in the product, at the express request of a client. The client himself was very pleased with the algorithm. However, he was the only one in the market to use it: this client was such a pionneer […]