project sponsor

Nov 6 2009   10:00AM GMT

Ten cautions in case of a self sponsored project

Posted by: Jaideep
Software Project, Project Management, Development, software development, Risk Management, risk mitigation, risk severity, project sponsor, project methodology, Project Plan

What if you have chosen to develop a product for which you don’t have a customer right now? If you perceive that by the time you complete development phase and the product will be ready to launch if will not be obsolete as per technology or concept, go ahead but take care of following cautions to be a winner in the game:

10. Technology: Ensure that you are starting with the latest technology, as even the latest technology will be a little older by the time you complete the product.

9. Concept: Ensure that you do not start building a product that has several variants already in the market. Beat the drum to give the world a new beat.

8. Keep the air in your bag: Let the concept not leak out until you are ready to launch the product. Launch it with a bang. Advertise, blog, press conference, and whatever you feel appropriate for the launch. But ensure that your team confide in you in this exercise till you are ready to shout.

7. Convince, build trust: Convince yourself that you have chosen a right path even if it is risky. Demonstrate your management about your idea and the way you want to design/ launch it. Build trust among your team in giving a real shape to your dream.

6. Risk Management: It is very essential to jot down the risks involved, and ways to mitigate them depending on their severity.

5. Incentive: Let your team know what incentive they are going to get once the product and project is successful.

4. Project Sponsor: Mostly in such type of projects your management will sponsor the project, so all risk lies inside the house. Your stake is quite high in such projects. Equally important is the success of such projects.

3. Project Methodology: Adopt the right methodology and adhere to its requirements.

2. Project Plan: Ensure that such projects cannot tolerate much deviation in terms of time or money. Since in such projects all risk is yours, don’t let it increase at any cost.

1. Definition of successful project: Building a beautiful product in this case is of not any use if there is no buyer at the time of launch. Your total investment in the project can return only if you are able to find out a buyer.

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.

Apr 10 2009   9:59AM GMT

Application developed, tested and built well does not ensure successful implementation

Posted by: Jaideep
Application development, software development, application implementation, software implementation, post implementation, successful implementation, project manager, software project manager, project vision, project sponsor, project director, stakeholder, software testing, application readiness, Project Management

It is not only the project manager but all stakeholders who get affected by the project over-run or failure. It could happen due to any reasons. One of the major reasons that have emerged is the lack of vision of the project manager, project sponsors, project directors and other stakeholders to foresee the problems faced by customer during implementation or post implementation while using the product.

The product may have been developed well, tested well and built well to launch, but what happens if some soft issues that may arise during implementation or even post implementation period are overlooked. It could lead to a disaster…