Delivery of Projects

Software development life cycle methodologies were developed over time to help project managers reduce software development failure rate, and improve the quality of developed software as well as its productivity. The principles of software development in specific and project management in general help the humankind to produce more reliable piece of software, this happens by following a process model with multiple phases. Regardless of the SDLC methodology adopted, it is necessary to understand and analyze the requirements before the implementation starts. In the presented case, we have multiple aspects that need to be taken into consideration; those aspects are senior management requirement and the impact of not demonstrating this software at the show. Another aspect is the system analyst feedback on the current and projected time required to complete requirements gathering phase. I will start by analyzing each of those aspects, its consequences and how to overcome its drawback if possible. I will start with system analyst feedback as it provides the current update about the project.

Requirements gathering done by system analyst(s) shows that it requires full eight weeks to complete this phase, and two weeks of those have passed. Requirements gathering phase differ based on the SDLC methodology adopted, waterfall process for instance requires full requirements gathering and analysis be completed before moving into the next phase of the project and that being software design. In this process each phase has to complete and only after that the project manager can move to the next phase, it require lots of time. On the other hand, if a more agile SDLC methodology were adopted such as XP, requirements gathering take place at multiple places during the project lifecycle, and multiple releases are produced until the final version is accepted and only after that the final version is implemented. Since requires gathering process requires sex more weeks to be fully comprehensive the XP SDLC method would help in building multiple releases each depends on the set of collected requirements, and new requirements can be assumed in new releases. It is important to mention that for the requirements to be relevant and accurate, requirements analysis should be conducted to identify the risks at early stages of the project, as well to identify contradicting requirements and find solutions to overcome those limitations.

Another important aspect to consider is the senior management’s requirement to complete this software to be demonstrated in august because it has a great impact on the organization’s existence and future. Due to the high impact the software demonstration could cause, this requirement should be analyzed and possibilities of delivering a bugged software should be considered, sometimes the impact of not demonstrating the software could be less that demonstrating a buggy release that affect the organization’s reputation. a meeting with senior management should be held to explain the current progress to manage their expectations, as well explain to them the consequences of delivering a bugged version and how this could affect the organization’s reputation. It is important as well to explain to them that full team of developers is not the ultimate solution to problem in hand, as for example ten developers will not able to code two times faster than five developers. As the team expands, communication problems become more frequent and communication management becomes more difficult. Software development is tricky and unpredictable, and because of that adopting a SDLC methodology would reduce risks and increase project success rate, it is easier to develop an identified and known requirement, that start developing without a clear roadmap.

As a conclusion, I would manage senior management expectations by explaining project difficulties and make sure they are fully aware on the effect of increasing number of developers and that won’t guarantee project delivery, on the contrary it could delay the project even more. As well I will not ask my team to start coding directly, as this is a guaranteed project failure from my point of view and based on my experience. I would ask my team to start developing gathered parts of the requirements to develop a first release, and try to get a priority list from management on the features that need to be demonstrated to concentrate all efforts to deliver a stable partially ready software. XP methodology would be followed to insure that my team works on parallel streams to try to meet the deadline as this is very important to the companies reputation.

Reference:

Wells, D. (2009) ‘Extreme Programming: A Gentle Introduction’ [Online]. Available from: http://www.extremeprogramming.org/ (Accessed: 04 May 2012)

Paulk, M.C., (2001), ‘Extreme Programming from a CMM prespective’, IEEE Journals & Magazines, [Online]. Volume 18, Issue 6, pp. 19-26. (Accessed 5 May 2012)