Software Project Lifecycle

May 18 2009   10:00AM GMT

Vendor’s role in involving customer top management while requirement gathering phase

Posted by: Jaideep
Software vendor, Project Management, Software Project, Software Project Lifecycle, business study, requirement gathering, customer, customer expectations, software product, top management, project stakeholders, process owner, end user, software development, project completion, user level requirement, top level requirement

The most critical stage in software project lifecycle is business study and requirement gathering. Vendor has to be very cautious and careful in understanding all levels expectations from the product they are going to build for the customer. Skipping top level at this stage could be disastrous for both. As a vendor, if you don’t involve customer top management while gathering requirements – you are inviting a mishap!

Customer top Management involvement is very critical during the business study and requirement gathering phase of a software project. The expectations of top management shall invariably be different as compared to other stakeholders of the software project at customer end. Assuming that the requirements gathering from process owners or end users will be sufficient for developing software will be a misconception. A detailed discussion for capturing requirement and understanding top management perception is critically important to lead to a successful completion of the project.

At the Vendor end – the Project Manager has to ensure that besides capturing user level requirements, it is essential to highlight the benefits to the top management being proposed for them from the product. It is not desirable but mandatory to freeze top level expectations at business study and requirement gathering stage.

Feb 23 2009   10:43AM GMT

Top 15 Pain Areas in a Software Project Lifecycle

Posted by: Jaideep
Software Project Lifecycle, pain areas of a software project, Software Project, customer requirements, software project management, software metrics, Methodology and Standards, documentation, Customer requirements understanding, Measurement of Overrun, Project Status review, Role clarity, Risk analysis, Team building, Project Repository, Learning from Past, Post implementation support, Quality – man, methods, approach and deliverables, Version Control

Following are the top 15 pain areas of a software project. All points listed below appear somewhere or the other in a software project lifecycle. The ratio of pain from a particular below listed item may vary from project to project within an organization, and also from organization to organization. So although the hierarchy may vary, the pain areas somehow remain the same. A lack in addressing any one of the issue listed below may call for a big hiccup in the smooth running and closure of a project. The project size (and in turn the time and team size also) will vary depending on customer and customer requirements. Although all points listed below are self explanatory, but the understanding and perception may vary from individual to individual.

In that respect, I would like to take each of the points below one by one in my forthcoming blogs to explain how much impact each of the instrument listed below will have on the project and how to overcome this pain not only for that projects but for all the projects in that organization to come in future. The most important activity for each individual is, now, to re-arrange the points (with any additions/ or replacements) according to the ratio of pain it is giving, and then learn how to convert that pain into pleasure once for all (in my future blogs for the later part!)

1. Methodology and Standards
2. Documentation
3. Customer requirements understanding
4. Measurement of Overrun is in money terms immaterial of time overrun (time is not measured in terms of money)
5. Frequent Status review in a forum
6. Status of project movement is person based
7. Role clarity to project manager and team on site
8. Risk analysis
9. Team building
10. Customer clarity in terms of milestones and payments
11. Project Repository
12. Learning from Past
13. Post implementation support
14. Quality – man, methods, approach and deliverables
15. Version Control