Why my project failed.

Last year I worked on a project called weproudlypresent. Below is the story of how it came about and why it failed. I will talk about the lessons I learned.

Origins

I have been a member of a variety of forums over the past few years and quite a few people have me on their list of contacts. I first heard about this project by someone asking me if I was interested in working on a project. I never commit to anything immediately and instead sought some more information.

The project was to create a music site for unsigned bands. We would showcase their music, allow them to market their music, create and sell merchandise and generally build up a fan base. I thought this had some potential, especially if marketed correctly so I agreed to come on board.

The Problems

There were a number of problems to begin with. The person who came up with the idea had contacted a lot of people through various instant messengers. Some were simply not up to task. I do not mind working in a large team of skilled people but there is little point in working within a team largely unskilled. To better understand this, their are professionals, hobbiests and people who know a bit of HTML and call themselves a designer. We had quite a few of the latter. In a long e-mail I explained why the project would be better off without these people and the first problem was solved. Our team of 11 dropped to a skilled team of 4.

The second problem was the brief. We all had grand ideas and the brief grew very big. It was a massive list of wants. This was one of the problems that we struggled and ultimately didn’t solve. We didn’t want to scrap any features as they were all good. At the same time we knew version 1.0 couldn’t have all of these features. Half would have been a good achievement. As we never all agreed on a 1.o brief there was no defined end point and this was a problem.

The third problem and by far the biggest was the lack of management.  If you want to get a side project done you cannot treat it like a side project. You need to set time aside each day to work on it. This will ensure the project gets the proper attention it deserves and actually gets done. This philosophy didn’t exist in the beginning and the general consensus was ‘if we say we will do it, it will eventually get done’. The person in charge did not set goals, instead he set vague aims and kept pointing towards the launch date. If a person has 4 months to do something where is the urgency? The lack of management also meant some poorly scheduled and controlled meetings which lead to half our time waiting for everyone to attend and the rest of our time getting off track and everyone leaving none the wiser.

I did eventually solve this management problem but it was probably a little too late. I took over the project. I set a weekly meeting time. With each meeting I listed the things we needed to resolve in advance so everyone came prepared. I set everyone a task with a deadline. These tasks were just small sections of programming and design that needed to be done. Slowly the project started to grind into action.

Then it failed. The final nail in the coffin was a lack of motivation by 2 team members. There is a very big difference between wanting to do something, saying you will do something and actually doing it. They talked a good game and there were a lot of promises but when week after week they had nothing to show it got a bit tiring and leached the motivation of other team members. This was ultimately the reason why the project failed.

Lessons

The lessons learnt are as follow.

1. Creating an ultimate feature list is fine but the most important thing is to create an achievable v1.0 feature list.
2. Make sure you have the right team together, if someone isn’t up to it, let them go. It will be better in the long run.
3. If someone cannot manage very well, spot it immediately then help or take over. A successful project is a well managed one.
4. Ensure that everyone knows that while the project is built in their own time, they need to set time aside each day to work on it. If they cannot agree to this then you are going to have problems.
5. From day one look at creating a very limited Alpha. You then will have something to show for the hours invested.

I haven’t been put off working on projects and I hope to work on some more this year.

If you have been working on any projects that haven’t quite panned out feel free to post why.

This entry was posted on Wednesday, January 13th, 2010 at 4:05 pm and is filed under General, Observations, Web Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.