Jul 15 2009 10:00AM GMT
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?
Jun 8 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software Project,
software development,
Project Management,
project organization,
project team,
project delay,
project completion,
on-site development,
testing,
tester,
QC,
quality control,
project implementation,
software implementation,
functional lead,
technical lead,
quality,
software quality,
project quality
Ideally, in a software project, for an offshore customer, the requirement gathering phase should be given an extra care to understand to a maximum extent so that the product developed and tested when ready for implementation at customer site requires no development. Practically, it is very difficult to achieve. The more it is left open to be handled at customer site, the higher is the chance of customer and vendor getting affected.
So that means the higher scope of development at customer site will change the team requirement and affect the overall project. Let us see what major factors will get affected and where could those lead the project to:
5. Money Factor: The most important factor is money. Any scope of development at customer site will need extra developers in the team besides the implementation functional leads. This will lead to an extra burden in terms of cost of technical staff not only in terms of developers but also testers.
4. Time Factor: Delay in project is inevitable in these circumstances when
requirements will be clearer at customer site at the time of implementation and
thus will change the overall implementation plan to accommodate development
and testing in between.
3. Quality Factor: Poor quality will be a major concern. Everyone knows you can not
take a bundle of testers at implementation site. That means limited testers will be
in under a tremendous pressure to release the product at the earliest and hence
may not justify with their job. This may lead to lot of holes in the pot –
intentionally left or unintentionally skipped.
2. Exuberance Factor: Enthusiasm, tempo, momentum, pace will all start
diminishing and in turn start creating frustration and dissatisfaction at both teams
level.
1. Product Factor: Product Failure, if not, then delays and unpolished product is
always visible on the platter under these circumstances.
All these factors, being inter-related will have recursive effect on each other thereby increasing each by manifold and everything may turn into a complete mess in place of a successful project.
Jun 3 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
post implementation review,
project manager,
Software Project,
project completion,
project sign-off,
project closure,
software implementation,
project feedback
Both vendor and customer have to understand that the real journey of a product starts only after a successful implementation of software at customer site. The challenges get a new meaning once the project team leaves the customer site after project sign-off. Both the managements can celebrate the successful completion of project. But it is better to hold on this celebrations for a while, till customer really learns to live with the product, starts tasting the real fruits of the product committed earlier. Let the key users start managing the show on their own, run the complete process in live scenario and get satisfied with themselves and the product. The project team that comes at customer site for implementation has a role related to post implementation review prior they go back home after successful closure of project. Similarly the management (customer) have to clearly understand their critical role once the vendor project team goes back after the completion of project. It is the key users and management (customer) now to run and manage the show. No doubt that the vendor team is always at the back to support and assist them in achieving this. Let us assume that the project is over and team is about to leave the customer site. At this juncture it is the prime responsibility of vendor and customer project managers to shake hands and understand the importance of post implementation review in following terms:
The Project manager from vendor side has to hand over the post implementation review plan to customer at the time of implementation sign off and explain clearly each and every agenda of the post implementation review. The clarity in terms of product, managements, users, usage and product is very important for assessment purposes after a stipulated period.
The project manager from customer end has to ensure to get the post implementation plan for feedback purposes at the time of implementation sign off. This will not only leave the project open for another some time in terms of providing a lease for customer team to assess and experience the product in complete isolation in their own terms.
The purpose ultimately is to share the overall health of product, the key users, and the management.
Jun 1 2009 9:00AM GMT
Posted by: Jaideep
post implementation review,
software business,
Software Project,
software project management,
software implementation,
project effectiveness,
product usefulness,
product maturity,
product friendliness,
risk perception,
Risk Management,
key user management,
product acceptance,
project requirements,
product development,
product building,
team management,
project implementation process
What is post implementation review? When it should be done? Why is it required? All this has been discussed in last three posts. Let us now understand what ideally would be the components of a post implementation review. As discussed earlier, some components can be answered immediately at the completion of a project with a formal closure. But for answering some other components, customer needs some time for project to run in the absence of project team, experience it, feel it, see the user’s reaction on the way things are happening in the product when it is in use.
Infact before filling the post implementation review, it is advisable to use the software at its maxima, as extensively as possible, involving all key user’s areas, using all inflow and outflow procedures. The basic guidelines required while filling a post implementation review can be take up in my next post. Let us also understand that this questionnaire has to be quite elaborative and descriptive. Let us first understand the essential components of Post Implementation Review for a software project. The questions can be built as per the need of the vendor and product. The essential components to be covered are:
1. Effectiveness of the Project Team
2. Effectiveness of Customer management in managing Product understanding and implementation
3. Effectiveness of Customer management in understanding the requirements, building the product, selecting the right team and procedure
4. Change management during the complete cycle
5. Issues management
6. Preparedness of key users and management for accepting the product
7. Communication skills and management of vendor team and management
8. Risk perception, risk management
9. Product effectiveness, usefulness, maturity and friendliness
10. Customer management eagerness for future business to the same vendor
These are the core components based on which the elaborative questionnaire can be build to assess customer satisfaction over the product, vendor and team.
May 29 2009 10:00AM GMT
Posted by: Jaideep
post implementation,
post implementation review,
Project Management,
project board,
project sign-off,
project closure,
Software Project,
software implementation,
project acceptance,
software performance,
product performance
When is to perform a post implementation review? A witty answer could be – obviously after implementation. Ha! Definitely a successful closure of implementation could declare a project closure with a formal project acceptance report or project sign off. So shall we have a post implementation review as soon as we have a project sign off? Nah! That would not solve the purpose. Give an appropriate time to the customer team key users to settle down as the captain of the ship and sail it smoothly. One day or one week smooth sailing will not tell you the turmoil or undercurrent storm about to come in future. Correct. Then future is too long. That means keep waiting for turmoil. But mind it, all ships sailing in the sea do not experience storm. Similarly all products after implementation and project sign off do not guarantee a serious disaster.
Product performance in actual sense requires a certain timeframe to establish and to give confidence to end users. Some part of post implementation review related to team performance (implementation) can be answered quickly, maybe immediately after the project closure. But the other part needs a considerable amount of time to understand the product from different perspectives and accordingly present a right picture in the review report.
Certainly, then, atleast a period of minimum three months is required to experience the product and then fill in the post implementation report. Ideally, I would say, wait for six months, use product in all respects, aggressively, and then the top management need to sit with their key users and project board to evaluate, assess and fill the post implementation review.
May 11 2009 10:12AM GMT
Posted by: Jaideep
change management,
Software Project,
Project Management,
project cycle,
Project Development,
software development,
software implementation,
project implementation,
software requirements,
business requirements,
business study,
project manager,
Business Rules,
customer management,
customer requirements,
project team,
business critical change
Change management is a subset of project management. In any software project change is to be managed during the whole cycle of development and implementation. Requirements once specified by customer at the business requirements study phase does not mean that there will be no change in requirements later. Vendor who is not open to mange or cater to this change in requirements will not be able to deliver the product to customer upto his satisfaction. To mange these changes Change Management is essential and both have to play their respective roles in managing the project. Changes could be in terms of specifications, process being re-defined, or change in business rules. The two aspects for change management are – vendor and customer.
At Vendor level the Project Manager should accept changes only that are business critical and not cosmetic or wishful in nature. He should redefine the project/ development/ implementation plan in terms of time and revenues in consultation with his management taking customer management in confidence. He should incorporate changes only after getting it approved by customer top management.
The Project manager has all rights to challenge any change in requirements that is fanciful, not business critical and is impacting the software largely in terms of efforts and time.
At Customer level the Management and Project team have to understand the impact of any small change on the software thereby asking for a change only if it is a business critical change, analysing if the change can be avoided, and understanding the time and cost effect of the change.
Apr 27 2009 10:06AM GMT
Posted by: Jaideep
Project Management,
project overrun,
project implementation,
Software Project,
software implementation,
Project Plan,
Project Planning,
project manager,
project organization,
project monitoring,
overseas project,
domestic project
A classic scenario happened in an organization recently as told to me by a project manager of that organization engaged in software development and implementations.
It is related to project overrun.
A new project started with a set of requirements from a customer for development and implementation. It was an overseas project so project cost was comparatively higher than the domestic project. The respective teams for business requirements, development, configuration and implementation were formed. All went well till the implementation phase. The implementation team was ready to take the charge for on-site visit with the product to launch there.
The implementation phase planned was 4 months. Somehow due to a mix of reasons, it took 18 months to complete the implementation.
The team came back after successful implementation. The customer paid the full project cost as was accepted upon in the beginning.
The project was declared as successful without any overrun. For overrun cost was taken the criteria and since full cost was recovered, it was treated as not overrun project.
Is that right?
Throwing some points to ponder upon:
The cost that had to come 14 months back came now.
The team that has to return 14 months back arrived now.
In this period of 14 months atleast 3.5 projects of similar nature and size would have been completed.
The project manager is over-optimistic.
Project monitoring was very poor.
Etc.
Etc.
Etc.
Apr 17 2009 10:03AM GMT
Posted by: Jaideep
project manager,
software implementation,
project implementation,
Project Management,
project team,
project lead,
Risk Management,
Risk Plan,
implementation plan
The vendor project manager has to work as a consultant to the customer project manager rather than taking the full command at customer site during implementation phase. From vendor side, it is the responsibility of the project manager to highlight the risks (in terms of user’s availability, user’s understanding level, or about the product usage) to his and customer management and a plan to overcome those risks. He also has to ensure that the solution provided is in line with the business needs.
He has to make the customer management totally convinced that it is their product which they have to use in real life scenario and hence they have to be fully confident in that. The vendor management has to be with him all the time for this.
Apr 16 2009 9:40AM GMT
Posted by: Jaideep
Project Management,
project manager,
Software Project,
software implementation,
project closure,
implementation plan,
project lead,
project team,
software acceptance
Project managers (the customer end and the vendor end) have to work hand in hand during the implementation stage of a software project happening at customer site. The key responsibility of both the project managers working on the project is to ensure successful implementation and project closure.
It is the customer project manager who has to take the charge, be in full lead and command to drive the project and keep the responsibility and onus to him and his management. The implementation plan has to be his baby all the time. Unless and until he takes the lead, he will not be able to put the potential fire in his team to accept the product. And then only he will be able to ensure a fully hassle free implementation.
