Why Software Project Fails?
The Producer Company developed the big analytical system for the nationwide client and do permanent support of the client. With time go the system starts looking bit obsolete and it was decided to create the new version. Company had growing ambitions and new project was announced to reach the International level. Long time of gathering and combining information ends up with software requirements specification document. Here comes the first disagreement between expectations of Major customer (having experience with old version) and potential customers. The Major customer had much strong influence on to the project and compromise point appeared very close to his position. Unfortunately the agreed compromise was not clearly stated with requirements and comes as bifurcation point, so it was international version as designed and customers’ version “as expected“.
3 dedicated teams are hired to develop separate project parts together with Producer’s Company team. It was planned to start with software design description, but in reality start with reverse engendering of old system as almost only source of technical information. Here comes the second disagreement: the roles and responsibilities of teams and players are not clearly stated. And as a result all 5 scene players do job following own understanding of the tasks … and all this in a dark room with personal lights. With “personal lights” I mean that each team has own internal business process with planning, issue tracking, source control, etc. Lack of centralized system do “overheating” of Producer team which in this situation was responsible for manual dispatching of planning, issue tracking, sources among teams.
Finally the fault situation becomes clear for all and after some traditional “witch-hunt” period it was taking initial steps to improve the overall workflow. First it takes only formal common planning-reporting tools… good try, but not enough. What’s next? Overall Roles and Responsibilities + escalation procedure. Escalation not working… Internal auditor… No result… External auditor (have good trust level from project manager/sponsor). Perfect shoot! Issue tracking. Yes! Common document and sources repository? … postponed
Process tuning is nice, but customer expected the product for the specified deadline. And it become obvious that system couldn’t be completed in specified terms. Hard negotiations bring to surface the next problem: tough discussions lead to tensions between Customer and Producer; and final acceptance of almost all requests of Customer makes additional pressure for time/budget of process. From two evils here was selected… both (relations come to bad, planning is not corrected). Extra consequence of the conflict was reorganization of management in Producer Company. More, it was done not in single shoot, but prolonged for some period (“witch-hunt 2”). Really not a good for the team climate, but the main processes are set and running, so custom software development on demand is continued and productivity strongly increased.
New management of Producer Company finally stabilized the internal process: working compromise between correct formal process and minimal required organization. And completely switched to management of Customer expectations… to late. It was some positive effect: works are continued, but anyway customer expected more and earlier. Final turn of hard negotiations with customer was finished with cancellation of contract. So practically ready for use product (beta version) appeared irrelevant for both Major customer and international customers as well. The dry essence mistakes, that leads to the project fault: lack of Customer expectations management strategy. Having a “hard” customer one should plan and do steps for controlling and managing customer expectation. The worth case is to escalate conflict to reject some change requests and finally accept all “as is” lack of distributed teams management experience when running big projects with international teams. Experience of running domestic “in office” projects not guarantee effectiveness of known methods for managing offshore teams. Local projects are more stable and have stronger trend to self organization. So in reality starting local project as “ad-hoc” one could expect the process level to be somewhere around CMMI level 2 – 3 after rather short period. With distributed projects, this “self organization” practically impossible and one should take care in advance on planning and implementing the process for managing distributed offshore teams special attention in the management process to teams and roles management. Having a clear picture of roles and responsibilities for each player extended with effective escalation rules could save a lot of time, especially at initial stages. In the opposite case one could face with multiple “input missing deadlocks” or duplicated work.
