I’ve been running my company for about three years now. I don’t have an exact number now (unlike earlier, when I knew exactly how many projects we had done), but I would say that in general we would have completed over 200 projects on both the web and the mobile. This also means that I have worked with loads of different companies and people.
Usually when a project starts, everybody is on a high and it’s difficult to say if the project will go out on time or if will rot with delays from both sides. However, by the time that you reach the middle of the project, things start getting much clearer. A couple of times I have tried to write down the warning signs, which might tell me if the project is going out on time or not, but the number of cases are so many that there are still cases when things go wild.
So, this post is basically a list of all warning signs which tell you that the project is going down.
1. Non-specific specification
Specifications are supposed to be specific. If they are not, it is usually a strong indicator that things might go wrong. If you think that this is obvious, you have never really worked in a services company before. The problem is not having a spec, there always is a spec. You can ensure that before you start the specifications are complete before you start. The problem is that the client has the authority to change the spec as time progresses. The reasons for it are many. There are always features which weren’t thought out before, some other website does the same thing in a better way and you want to do it.2. The wrong people on the project
Another important reason for delays is putting the wrong person on the project. Each developer and manager have their own style of doing things and you need to assign them appropriately. Some people require specs set it stone to work really quickly, and some are really fast at improvising whatever was initially discussed. Both of sets of people are really helpful, and putting the wrong person on the wrong project gets everybody in a mess.3. Getting most of the payments at the end of the project
This one is slightly tricky. Most clients believe that if say it’s a 3 month project and we charge 50% upfront and 50% at the end, we will have a lot of incentive to push towards closing it. This sadly, isn’t always the case. Most of the time, if a 3 month project, pushed to a 4 or 5 month project, even if you don’t want, you need to move developers to another project after the first few months because somebody has to pay that month. So, the incentive to work on the project is always higher, when the payment date is closer.4. Late Engagement of the Client’s Testing Team
The client usually doesn’t put in the the complete testing team on the project until the very end. This means that many of the things which we were sure about suddenly are counted as not done when their testing team comes into play. It not only makes it impossible to define timelines, it plays havoc with the team’s morale. You need to push them to start testing as early as possible.5. It does take a few months to create the spec
Most of the clients assume that they know exactly what they need and that specifications and mockups will only take a couple of weeks at most. Sadly, this never happens. For a project which will need three months to get developed, it doesn’t take less than 6 weeks to prepare and finalize the specifications and mockups. Even then, there are always modifications to it as soon as the project starts, midway during the project, and at the end. So the total time required for mockups and specifications is approximately equal to 2/3 of the time required to develop the project (for new products).6. Unstable External APIs
Most mobile products require to connect to an external API through which it interacts with the world. If the API that your product needs to work with is not stable, life’s going to suck for the developers, managers and the clients. This is because everything that starts working once, will fail when the API is changed even slightly. There is nothing which kills the morale of the dev team faster than writing against a changing API.These are some of the reasons which really derail the speed at which the project runs. If you seem to run into some more, do let me know.
No comments:
Post a Comment