We are back from a 3-day trip to Seattle, where we met our client, AT&T.

It is so refreshing to meet clients face-to-face! With a web-based business and communications at the level they are now, we tend to forget how much more we can get out of meeting with someone in person. There is so much to learn from someone's non-verbal communication: attitude. facial expressions and reactions, gestures, etc.

Now that we have met the team we work with at AT&T, we have a better understanding of who they are as persons, and this will help us serve them better. We have a feeling that wen now them as persons, and so do they. When we talk and email, we'll be able to imagine the person we are talking to. 

Meeting clients puts the human back in customer relations. 

Who makes decisions in your project management team? Do you have a dictator, a group of decision-makers, or does eveyrone on the project participate in the decisions?

Democratic project teams: the quicksand trap

Taking everybody's opinion into account is a great idea, it opens up new avenues of thinking. It's good for creativity and solving problems. However, if decisions are put to a vote, there is always the risk of taking the wrong decision, because not everyone in the group has a 360-degree view of the problem. For example, if the team is composed of a majority of developers and only one person who represents the interests of the clients, should the client representative's vote weight heavier in the balance?

Another issue with democratic decision-making is the quicksand effect: discussions can end in a stalemate. Where does the team go from there?

Autocracy: distribute blame, dilute merit

This is project management by committee, where only a select few take the decisions, not the whole team. While this decision-making style can be more proactive than a democratic style, it is […]

It seems to me marketing is about convincing people to buy a product. In so doing, should it not tell people something that makes sense?

Especially in business-to-business marketing, I don't want to insult my reader's intelligence by telling them a bunch of nonsense. Do they really care about how great I think my product is? Maybe they do.

I think what they care about is what my product can do for them, for real. How much time will they save? How much more money could they make? How much easier will their life be with the product?

I understand that it may be difficult to make precise statements in reply to those questions. But in the end, that's what most of us want: more time, more money, less difficulty.  Which translates in more happiness.

I firmly believe we can market products concisely, clearly, without resorting to complicated statements.

Marketing should make sense.

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 […]