requirement gathering

Jun 29 2009   10:00AM GMT

Outsource in a software project without losing control over it

Posted by: Jaideep
Software Project, Project Management, outsourcing, requirement analysis, requirement gathering, requirement freezing, software design, software development, software testing, documentation, project implementation, training, handholding, post implementation, Project Planning, project control, project execution, project component, project phase, project offload, project outsource

We learnt in earlier two posts about the strategic decision of a management to outsource a complete project or part(s) of a project depending on certain factors, and the factors respectively. In this post let us see at the various components of a project that are most widely outsourced or otherwise we can say these are the components of a project which can be outsourced. It is very less often that a project awarded to a company is totally outsourced.

We are talking about outsourcing an activity of a software project. The most important components of a software project can be listed as:
Requirement analysis, gathering and freezing
Design, development and testing
Documentation
Implementation, training and hand-holding
Post implementation support

These can further be broken into various sub-components under each component thereby creating a tree like structure to have a bird’s eye view of any project. Planning and execution for each phase or component comes next with control everywhere.

Outsourcing mainly is the resultant of constraints in an organization.

Jun 10 2009   10:00AM GMT

Ten Reasons of getting into pitfall of leaving a scope of software development at customer site

Posted by: Jaideep
Project Management, Software Project, change management, project organization, developer, project sponsor, project director, project manager, key user, implementer, technical lead, business requirement study, business analyst, business analysis, requirement analysis, requirement gathering, implementation phase, project phase

In the previous post we learnt what all could a software project could lead to in presence of higher scope of software development at customer site during implementation phase. Let us see what all factors are responsible of insufficient requirement gathering during business study phase of a project.

1. Incompetent team (vendor): Any project calls for a project team. A good team at both ends is important. Both teams have a substantial role during a project. If key users selected at customer site for delivering process knowledge to requirement analysts (vendor), there are higher chances of wrong information driven. The key users chosen should rightly be the actual process owners not essentially be at the higher level in the organization.

2. Incompetent team (customer): A right selection of project manager and analysts is equally crucial. The team has a short duration stipulated for gathering requirement information and understanding business processes. And mind it, this is not an individual race, it is a relay race, and weakest link will decide the overall result of the project.

3. Non commitment (customer): Well the process owners are the key users, but if are not serious or have not received the right message from their management may not be seriously committed to the vendor team. A non committed team will not be able to impart right knowledge, processes, practices and information required critically for a project.

4. Non commitment (vendor): A team of good committed project manager and analysts is equally crucial for gathering information. The previous experience on business domain and success factor definitely counts in.

5. Lack of time (customer): Key users identified if are engaged in other important projects running in the organization will be always short of time for providing right information to vendor project team.

6. Inappropriate discussions: In a limited timeframe of business study, there will be limited discussions. So all discussions should be crisp, purposeful, well driven and result oriented.

7. Improper documentation: Well explained requirements if not documented properly may lead to a wrong, incomplete product. Right people with right business and process knowledge have to acquire a good documentation skill also to lead the project to right direction and grand success.

8. Top Management involvement (customer): If customer management thinks that providing key users completes their job in the project, they are wrong. Their involvement in all important meetings is as important as the business is.

9. Project Organization: A right architecture of project team is very important. The project sponsor, project directors, project managers, key users, developers, implementers, technical leads from customer and vendor respectively should be the right mix of people.

10. Change in requirements: Any change in business or process during or after the requirement study phase has to be communicated to vendor team well in time, so that by following the change management procedure, the changes are taken care of properly.

May 20 2009   10:00AM GMT

Customer’s role in business study and requirement gathering phase of a software project

Posted by: Jaideep
business study, Software Project, requirement gathering, project sponsor, top management, software development, Software vendor, customer, project director, project agreement, project role, project review, project stages, project benefit, software benefit, project meeting

Usually it is the customer top level person who is project sponsor for a software development project, be it in-house or from a software development vendor. A Project Sponsor may presume that his/her roles during the project would be – sign agreement and papers, assign roles down the line for the project, monitor/review project at various stages etc. A critical and crucial role is overlooked that of getting into the project especially during atleast vendor’s business study and requirement gathering stage. It is not only important for project sponsor and directors to be part of this stage but equally important is to involve all top management in that.

In brief, Customer Top management has to fully understand the benefits being proposed by the vendor that will be produced by the software when it is in use. They should also participate fully in business study and requirement gathering meetings to define and freeze their own expectations from the project/product/software/vendor.

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.