Things that can hamper the success of a software development project.
In this blog I will talk about some issues that, from my experience, are detrimental to the success of a software development project.
1. Incorrect Effort Estimate – This is the one of the primary reasons of project failure. This generally happens because of one or more of the following reasons –
a. The sales or project procurement team gives a ballpark estimate to the prospect at the beginning of the sales process, when the requirements have been laid out at a very high and often superficial level. Though there may be disclaimers about how much percentage variation can happen in the SRS phase, this estimate sets the tone of negotiation and becomes the reference point for the Project Management Team, thereby having a strong bearing on the latter’s estimate of the project.
b. The estimate is created assuming a 90% to 100% efficiency of the engineers i.e. at a rate of about 36 to 40 productive hours a week. Practically, this figure should be somewhere close to 70% to 75% which converts to about 28 to 30 hours a week. Please note that these are the total productive hours spent on the project. A software company will have numerous companywide activities like corporate meetings, status meetings, trainings, performance appraisal and other HR activities, etc. Besides, engineers help each other when one is stuck with a technical problem. These activities and context switching generally take 25% to 30% of an engineer’s time, and for project leads or managers this is even more. Thus this basic foundation of the estimate makes the schedule aggressive from the beginning of the project.
c. The estimate is seldom created keeping in mind the competency and the skill set of the engineers, with almost no time given for any generic or specific trainings. Though this skill level might average out in a large team size, for teams below ten people this will have an impact on the schedule.
d. The estimate is created without a detailed, functional or user interface level understanding of the project. The requirements should be completely broken down into small tasks and each task should be estimated separately. This way it’ll also be easier to explain the estimate to the customer.
e. Often there is no buffer inbuilt in the effort estimate or the schedule, with weekends being considered as the buffer zone. This is non-sustainable and unethical. The person preparing the schedule should also have a company holiday list handy.
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Estimate is one of the reason, but i have seen other major reasons to fail projects, 1) Project Requirement. 2) Customer expectation
Some time, Requirements are not clear, or development team gets a working old application and ask to treat that as requirement. Project manager does not make SRS or get singoff for that as assuming working app as SRS. This turns out as problem later on, end client will come up with some requirement which was hidden in working application, or some security requirement or say browser compatibility. From customer point of view these hidden features or security requirements were obvious and for successful project these should be implemented, but these things are ignored by development team unknowingly. These issues can be sorted out before starting project with SRS signoff; and all the stack holder in projects are aware off what will be the outcome of the project.