project methodology

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.

Oct 21 2009   10:00AM GMT

Performance Management has nothing to do with the Project Size

Posted by: Jaideep
Software Project, Project Management, project organization, project methodology

Be it large organization or small performance management is the key concern for any size of organization. Every organization has a goal to achieve their goals bound to be for a stipulated period, gain profits, enhance, and set higher targets. Growth is important for every organization.

The same applies to project also. Irrespective of its size, client, and customer requirements, each project has to be a success if in turn the organization has to achieve success. For that purpose performance management becomes a great tool. There has to be a performance management methodology clearly defined for that organization so as to assess the performance of each individual of the organization involved in the project directly or indirectly. A performance methodology should very clearly define the process of measuring performance. The process should be transparent, acceptable, measurable, and simple. Any cumbersome process is good for document purposes for difficult to adhere to.

The methodology should be universal for all the employees at all levels as it is very clearly evident that a project is like a relay race. The overall performance is highly affected by the weaker links. Even if there is a weak member in a very strong team, it is high risk for the overall project. As each member has to perform their individual task, in today’s scenario of recession, lean and low costs, each member’s performance keeps overall organization’s performance at stake.

Jul 15 2009   10:00AM GMT

Who owns the Q-Tag in a software development company?

Posted by: Jaideep
Quality Assurance, Q-tag, quality control, Software Project, Project Management, stakeholder, project methodology, project management framework, project implementation, software build, software implementation, product approval, Quality-tag, project team, development team, implementation team, testing team, team, QC, QA, business analyst, re-testing, testing, Bug, bugs report, test report

In any software development and implementation company there is always a need of quality assurance and quality control people who own the responsibility of setting the right methodology and framework for development and implementation (QA), bugs identification and product approval (QC). Usually everyone in the organization has an inherent feeling that the quality is the responsibility of only these few persons belonging to this Q-department of the organization. Business analysts understand the customer and business requirement, hand it over to development team for building the product. Development team develops the product, and hands it over to QC team. QC team tests the product, finds out the bugs, and submits the report to development team. Development team fixes the bugs and returns the product to QC persons for re-testing and verification. After few exchanges between development and QC team, the product is declared as defect free and is released or launched for implementation.

If top management, development team, business analysts, implementation team and all other stakeholders think that quality is just the responsibility of only the persons belonging to quality department, they all are wrong. If Q-tag is limited to only a limited persons belonging to Quality department among all stakeholders, a product can never be built with great control on quality aspect.

Q-tag has to be on each of the stakeholder in a software project. When each and every person wears a Q-tag – the analysis, building, testing and implementation will be more justified. Otherwise there will always be a big question at the time of failure of a product build – that who is responsible?