The three factors of a successful project

In the last two weeks, under the invitation of two friends, I have taken over a development team in disarray. The planned release date of the project was set for April 1st (no, it was not a joke), but by mid April, less than 20% of the work has been done.

To be honest, I have been serving as a technical consultant to the team since last November. That was when the project started. My role was to help with the system architecture design, analysis, algorithm design, etc. I would go in one day per week, to attend meetings, or help with any problem, if necessary. Under the agreement, I was also to design and implement a special algorithm, due to  the fact that it would too much for the team to do. The second reason was that no one in the team was able to design and implement it. The third reason was that this component is more or less independent from the rest of the system, and it would be easy to just plug it in at the end.  But it could be plugged in only after we have an integrated system.

I had a first version implemented before the Chinese New Year (that was at the end of January), and our plan was to have a first integration before the national holiday. Well, the project wasn’t ready for integration. During the holiday, I rewrote the code, improved it quite a bit. I have waited another month, and the project still wasn’t ready for integration. The work I’ve done had never had a chance to integrate into the system.

During all that time, I recommended to hire a real project manager with leadership. It was obvious to me that each team member has his fiefdom, and the in-team communication is broken.

A few weeks ago, I accepted the invitation to take over the leadership of the project, and my major task is to push the release out the door. The first week of project status evaluation was a scary revelation. My initial estimation was 20% completed. I was so wrong.

I spent the first week sizing up the project, re-evaluated the work tasks, and got a better grasp of the project and team situations.

The conclusions are typical of a messed up software project. I can almost see the smile on your face now, for those who are in this industry long enough. Here you go:

1. Lots of developers are self-proclaimed rock star, with their own fiefdom. We only wanted to hire the smartest and the most experienced. As a result, we got a handful of cowboys.
2. Communication is broken, they barely talked to each other between team members in the same group, let alone team members between different groups.
3. The API specifications document is not fully published. Only a few functions are on the internal wiki. Parameters are not clear, return values not fully described, error handling situations not even mentioned. I mentioned about error codes, and I got a blank stare. What error codes? Calling the function will always succeed. That was the answer.
4. Developers who needed the API all had an excuse: the API was not ready, so they sat on their ass, waiting.
5. By mid April, which was already past the project release schedule, we had never had a single integration yet.
6. There was not a single design document of the system. All the discussions we had at the beginning of the project were done in a conference room, drawing was done on white boards. It was agreed on to have someone transcribe it into written documents. That was never done. So far, the only document is about the algorithm I have designed and implemented. Written by myself.
7. Most people didn’t even bother to read, and fully understand, the product requirements document.
8. A few developers who can’t tolerate the situation had left.
9. No one in the team had a sense of urgency of the issue, besides the company’s founders, obviously. And me, an external guy, to a certain extent. The company allowed flexible working hours, but the team kind of abused it. They came and left without providing a good reason.
10. There was a lack of discipline. The developers (most of them, actually) didn’t give a damn about reported bugs, they didn’t even look at it. Actually, bug reporting and management was not even on their radar. First of all, there was hardly any bug logged in the system, and the few reported were not followed up by the developers.
11. There was no performance evaluation program, and developer’s compensation was never tied to their work. Despite their high salary (very high compared to the industry’s standards), they have no incentive to perform.

I’m sure you must be smiling and nodding now. Yes, this is very typical of a failed software project.

From my contact with them lately, I have no doubt that each developer is great, and they can all achieve great works. However, putting them together to work is like trying to build a castle with dry sand. We got a dysfunctional team. There is no coherence and cohesion.

Page 1 of 3 | Next page