stakeholder

Jul 17 2009   10:00AM GMT

Why hit the people? Hit the process if there is a failure in a software project

Posted by: Jaideep
Quality Assurance, Software Project, Project Management, people management, HR, QA, QC, Q-tag, developer, quality, quality control, quality culture, quality building, product, stakeholder, business analyst, project manager, project team, development team, testing team, implementation team, product build

People are not wrong, processes are. People in an organization do what they are told to do. Organizations who hit on people at the time of failure are not doing the right thing. It is the process that is to be blamed not the person with Q-tag. As long as quality is considered to be the child of people with Q-tag in the organization, and the culture is so around, the non Q-tag people will keep themselves enjoying building a product without quality. Why not blame the developers for developing so many bugs along with the requirements building. Why not blame the analysts who could not understand or translate the requirements correctly. Why not blame the management for not putting the right people and process at right place. This blame game itself is merely a scapegoat in any organization until the focus shifts from people to process enhancement.

Analyze the failure as a team involving all the stakeholders. Management, business analysts, project managers, project team, development team, testing team, implementation team have to sit together and brainstorm. Failure is to learn and not fail again. Mainly failure can occur due to following three factors:

Teams do not work and deliver in desired fashion – required innovation, awareness, training, cohesiveness, team building, and collaboration
Wrong people in the team – HR and management has to play a major role and look into the recruitment process.
Failed to build right product – needs training, demonstration, pairing, indentifying right people for right job.

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?

Jul 2 2009   10:00AM GMT

Fifteen Checkpoints for project managers - if your commitment towards project merely a Pretence?

Posted by: Jaideep
project manager, Project Management, Software Project, pretence, stakeholder, commitment, checkpoints

You, as a project manager are most crucial factor of a project being the key driver. Your commitment matters most as it can do any wonders. Your real commitment can put fire in your team member’s belly to run the project full swing. But if your commitment is merely Pretence, it can wipe off the energy and zeal of others in the team. It can trigger on the pace by acting as a catalyst or adversely trigger off the pace by decelerating it.

There have to be certain checkpoints in your thought process that may ascertain if your commitment is in right direction or not. Let us see what those points as mentioned below are (against each I am mentioning if the commitment is PRETENCE or REAL).

If you

1. Believe – “All stages of a project are crucial and important as far as the overall success of a project is concerned.” – Your commitment is REAL.
2. Believe – “Each milestone matters and need to be converted to win-win for all for a smooth sailing towards this bigger goal.” - REAL
3. Believe – “All stakeholders have a stake and a part to play in the project. Overall every task and success has to cross ‘mine-yours’ barrier to reach at ‘our task’ and ‘our success’ stage.” - REAL
4. Are – “Intentionally creating conflicts.” - PRETENCE
5. Are – “Avoiding ‘important to be resolved’ conflicts.” - PRETENCE
6. Are – “Unnecessarily trying to prove your point (imposing your point) (putting yourself over the project). - PRETENCE
7. Have – “Lack of knowledge and understanding.” - PRETENCE
8. Are – “Giving more importance to emotions and feelings over logics.” - PRETENCE
9. Have – “High level of actions but poor planning.” - PRETENCE
10. High level of planning but with poor actions. - PRETENCE
11. Framework is not important – people, tools and management are. - PRETENCE
12. High performing teams are different from highly organized teams. - PRETENCE
13. Best practices do not require improvements. - PRETENCE
14. 100% test coverage means correctness. - PRETENCE
15. Automated testing is a silver bullet - PRETENCE

Projects do happen with the beliefs and actions mentioned above. Whether they end up in good or bad state, I am not sure. PMs do exist with these beliefs and actions. But they have to change themselves over a period of time, I am sure.

Jun 25 2009   10:00AM GMT

Five Reasons of outsourcing

Posted by: Jaideep
Project Management, project outsourcing, stakeholder, Software Project, offloading, third party

Outsourcing is neither bad nor good. It is a strategic decision based on certain parameters taken by an organization to offload some projects or part of a project to a third party. Offloading certainly comes with many boons and many banes. Offloading should be managed very carefully as the project delivery ownership still remains with you even if you are offloading complete project. Insertion of seriousness in the outsourced vendor regarding the project, requirements and its timelines is very important. There are many parts of a project that can be outsourced and as said above, the decision is purely management’s to decide what part of project is to be outsourced and to be awarded to whom.

Definitely in offloading the vendor-customer chain becomes longer depending on number of components of a project outsourced and the number of vendors involved. Even for a single component of a project there can be more than one vendor. And for a number of components of a project there can be a single vendor.

Offloading or not will depend on many factors that can be listed below as:
1. High number of projects
2. Shortage of skilled manpower
3. Shortage of right skilled people
4. High engagement of required persons
5. Lack of resources (in case of testing tools or otherwise)

Jun 22 2009   10:00AM GMT

Role of Vendor and Customer in managing User Manuals

Posted by: Jaideep
Quality Assurance, User Manual, Project Management, Software Project, project manager, stakeholder, project team, project quality, quality, project walkthrough, build phase, project phase, quality control

As already has been discussed, User Manuals play a crucial role in any software project and are the solid bonding between product, users, customer management and vendor project team. The stronger this bond is the more comfortable and happy each stakeholder will be. Each player has to play a crucial role during the game of building of User Manuals. Both Project Management teams have to work hand in hand for that.

The quality of User Manuals has also been discussed in my earlier blog (Six Pack User Manual – how to build).

Let us discuss below the role to be played by the respective project managers in this regard:

Vendor Project Manager has to ensure that the user manuals are built along with the product development and are vetted/ approved by their QC team via a walkthrough. If need be they should as for draft manuals in build phase. If there is a foreign language issue, the Project Manager should also ensure that the user manuals are required in their local country language.

Customer Project Manager has to check that user manuals are complete in all respects, and checked thoroughly before handing it over to the respective key users

Jun 17 2009   10:00AM GMT

Why User Manuals are so important in Software Project Management

Posted by: Jaideep
User Manual, Software Project, software project management, key user, stakeholder, project implementation, post implementation, user feedback, usability, reliability, stability, durability, report, analytic, feel and look, product support, project support, live run, product training, software training, training team, implementation team, project team, project sign-off, sign-off, business scenario

The product owners or stakeholders might be many in a software project, but the real frontrunners who drive, run and use the software product post implementation are the key users and other users. It is their feedback that matters most. They must be the most comfortable lot on usability, functionality, reliability, stability, durability, resultant outputs in terms of reports and analytics, feel and look of the product. They are the one who are going to matter most in the success or failure of a product during and post implementation. The best tool to give them comfort, satisfaction, confidence and support is the User Manuals that they refer to most of the time during post implementation live run.

Even if the product is excellent and trainings are most rigorous ones, in absence of the project implementation team, every now and then the key users will be seeking help from User Manuals. User Manuals are the supporting agents for them at all times. That is why User Manuals have to be perfect in all aspects.

Infact a user manual prepared for product users should be such treated as a replacement of implementation and training team right from the moment the project is signed off and users start using the product in real business scenario.

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…