The customer project manager has to take the lead and ownership of product as soon as it is launched at customer site for implementation. The UAT, training and implementation process can only be effective in case customer project team gets fully involved into each and every activity of the implementation phase. Infact the implementation plan prepared by vendor project manager should be the responsibility of customer project manager to execute.
Customer Project manager and management has to clearly understand the risks involved during the business study, implementation and post implementation phase as highlighted by the vendor Project Manager and to act thereupon to overcome those risks with suggestions from vendor project manager.
These risks could be in terms of consequences involved:
the involvement of users and process owners during business study, implementation, UAT, masters creation, transaction entry, reconciliation etc.,
if sign-offs not happening in time, etc.
Even if the sign-off is given and product is not put in use, there is a chance of project failure at both ends.
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.
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.
No project manager can claim there was not a single problem in any of his projects. But then he is to tackle them. To tackle them he should be aware of them. To be aware of them, he has to have an ability to foresee them than to overlook them. The earlier he envisages those problems, the more time he will get to dig into and find out a countermeasure. No software project is problem free, but then… the project manager has to be alert and have a perfect vision to oversee them, accept them, plan accordingly and win over each of the issues.
Problems will definitely be there, in all phases of project lifecycle. It is the vision that you envisage them in advance and prepare yourself to overcome them.
The deficiencies do not get so highlighted during in-house development and testing phase of the product. But it becomes prominent any problem that arises at customer site during the implementation phase, or say post implementation period.
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…
A risk is a bigger than its size if it is not identified well in advance. An identified risk is as risky as unidentified if its assessment is not done. Risk assessment is useless if there is no impact analysis. Impact analysis has no worth if its countermeasure is not identified.
Let us understand the different stages of risk in software application development and testing phase:
2. Risk identification
3. Risk Assessment
4. Risk Analysis
5. Impact Analysis
6. Risk Classification
7. Risk Plan
8. Risk Plan Analysis
9. Risk Plan Execution
10. Risk Closure
Similar to SDLC (software development lifecycle management), there is RLC or Risk lifecycle management in a software application in which there are different stages involved. The different stages could be risk identification, risk assessment, impact analysis, countermeasure identification, countermeasure assessment, risk plan etc. There are certain facts about Risk:
2. All risks have an impact: All risks have an impact – large, medium or small, but they have. It is the impact that makes its severity high, medium or low and accordingly a plan is prepared to handle the risk, when it happens.
3. Same risk in different circumstances will have different impact: The same risk will vary in terms of its severity under different circumstances of usage, user base, geographic location, type of application etc.
4. No application is 100% risk free, whatsoever countermeasures are taken for it, and only thing that gets done with the countermeasures is lowering of risk: A risk plan to countermeasure a risk never fool-proofs a risk’s impact, only it helps in lowering its impact to a certain level.
5. Risk Impact Cost vs. Countermeasure cost: It is very important to have an analysis of both before deciding on the plan. Some risk may be very severe but its countermeasure cost could be unaffordable.
6. The biggest risk in any application is identification of wrong risks, impact, and plan: Identification of wrong risk with right estimation of impact and countermeasure is useless. Equally useless is identification of right risk with wrong impact analysis (thereby underestimating or overestimating the impact) and arriving at a wrong countermeasure. Right risk identification with right impact analysis but with wrong countermeasure also is a waste of efforts.
Any activity is never without risk involved in it. Risk could be classified in different categories like – low, medium or high depending on its impact, software’s requirements and purpose, software usage, and software user volume. Accordingly the risks are identified or rather perceived. Their impact is measured or assessed, and based in the category in which it falls into – its countermeasures are designed or defined. The right identification of risk is as important as its classification or category.
A classic example could be a bank application being used by all its customers for their account maintenance, for transactions and for various other purposes. The risks involved in this sort of application could be: availability of application to all its users all the time, the speed of the application, the security of transactions, the ease and comfort of usage, the user account vulnerability of hacking and so on.
Some applications required all time availability whereas other demand high performance and high availability at peak time. Say, for example there is a website of a university where the peak usage is only at the time of admission or enrollment, at the time of fee payments, and at the time of release of results. At these times the volume of this site usage will be extremely high. So not only it demands availability of application at critical or peak times but also to be ensured is that it does not crash down due to high volume of use.
So it is very important to identify the right risks, to understand the right impact size, and to derive at a right countermeasure.
Once upon a time there was a programmer, a very good programmer. Good here means skilled, learned, experienced, and serious. He was appointed by an organization for a large project for a job to write quality programs. He was doing it well and was able to prove his point that he is good for the purpose he has been appointed for.
All of a sudden the large project was required to be closed. Now, the good programmer had to be absorbed in some other project, as company was in favor or retaining him. He was moved to another project requiring different platform development skills. The development platform is different than the one on which he was working in the previous project. He was master of this platform also and assured the management that he is fit for this new requirement and would be able to deliver well as he was (in his earlier project).
But somehow, his new project manager started feeling that – he needs lot of spoon feeding, he is not very productive and is quite slow in delivery, he is not self driven, he is not enthusiastic enough and does not report well.
Would someone like to share – who needs to do what in this case?
Let me start with the classic story –
This refers to the team of a Project Manager. The team size may vary from project to project and organization to organization, but the story remains the same. Story is quite short and interesting. A Project manager assigns different set of tasks to his team on 5 members individually. Each member has to start the work on Monday morning and finish it off by Friday evening. One member finishes her all assigned tasks on Thursday evening (without compromising with the quality of work), goes to her project manager, reports about the completion of task and requests for an off on Friday with a genuine reason. The project manager refuses although he admits that the work is complete, it is quality work, and the reason for seeking off is also genuine. The reasons for not sanctioning her the day off given by him were – it will spoil the culture and discipline and it may lead to non-quality work production. He was more into favor of her sitting with other team members and helping them in finishing off their individual tasks.
Well said, but this is only one side of the coin. Although project manager trusts all team members but out of fear he is not ready to do a favor to one member as it may spell out wrong signals for others.
But has the project manager understood that there are always HARE and TORTOISE in a team. All have just one responsibility – finish their task in assigned timeframe and produce quality work. It is not HARE’s responsibility to help others. If HARE is able to finish off her tasks earlier than stipulated time, it is a credit and she deserves a reward for that. And above all what about her trust getting hurt and she getting demotivated by not getting a reasonable favor.
I am sure, the reader would have their individual opinion on this – would love to hear!!
Due to recession, there is scarcity of business and projects for software organizations. In such a situation, the projects in hand (and the forthcoming ones) have to be handled very carefully for a win-win situation. To attain that, there are certain smart weapons that a project manager needs to be equipped with which will not only make him and his organization a winner but would definitely have an edge over the competitors to acquire more projects. The weapons are well tested based on experience, knowledge and wisdom.
The 20 most powerful and smart weapons can be listed as:
2. Be Sincere and frank in your meetings of all levels
3. Maintain and demonstrate a sense of mission
4. Work hand in hand with your peers – quality manager, development manager etc.
5. Be convinced of the trust between your product and quality
6. Let your team feel the weight of responsibility
7. Plan your course of action on all issues to avoid a crisis
8. Listened attentively to every word of your customer demonstrating great sincerity towards product and customer
9. Have strong interest in quality issues
10. Be highly knowledgeable about your product
11. Your Product and Quality (with your technological prowess and their quality strengths) must work together
12. Higher is the rate of dependence on Quality, higher is the success rate
13. To avoid major problems never leave a problem unresolved for tomorrow
14. Thinking, Innovation, Brainstorming are good tools if used regularly
15. Always have common awareness of all issues, so that your discussions are of highly substantive in nature
16. Be a linchpin (A central cohesive source of support and stability)
17. Consider customer requirements as “cornerstone” throughout the project. (The fundamental assumptions from which something is begun or developed or calculated or explained)
18. Build a culture of putting fullest sincere effort by everyone in the team(s) (vertical and horizontal).
19. Maintain a continuous gently-ascending approach (act of changing in an upward direction)
20. As a bearer of the highest level of responsibility reaffirm your determination to safeguard the organizational interest and ensure the best of the results
A new entrant at any level should never be burdened (leave aside “overburdened”), and an ample time should be given to him to prepare himself for the forthcoming project(s). If already there is a load of work, the minimum should fall on the new entrant, rest should be shared among the existing team members. This is to avoid any shock states for the new entrant and moreover he should be given ample time to groom, adopt, accept, learn and understand.
Simple theory is that a plant that has to turn into a tree later can not bear fruits in its plan phase. No wonder if extra burden is put on the new entrant – either he will run away, or will break down. The plant will require proper care, protection, air, water and atmosphere to grow, which becomes the responsibility of the team leader, project manager. A guideline for this should already be there in place through the top management which gets into the culture of the organization and in turn in the heart and blood of the existing team members.
Usually during the period between first project close-out and next project initiation, most of the team members of project have not much to perform except utilizing their time in non-visible activities. This could include personal web browsing, social sites, pending emails, thinking about improvisations, learning from past etc.
In an organization, management has to understand that if some of the teams of team members are sitting idle that does not mean they are useless. That means that they are undergoing revitalization phase. Surprisingly you will notice that by allowing teams/members to sleep at job when not at the peak of a project will generate an extra bounce of energy which can be utilized at the time when they jump into a project, especially when on a remote site during implementation phase. During this phase most of the team members don’t bother about time and pay their full energy into completion of project in as best possible manner as they can. And probably that energy, zeal and feeling comes from that period when they are allowed to relax.
All project managers depend on their teams working on the project and in turn the persons who form the team. Teams could comprise of project leader, module leaders, functional consultants, technical consultants, database architecture, system designers, developers, programmers, testers etc. To keep working towards excellence a project manager has to focus continuously on people management, grooming of teams and team members.
If project manager’s has this as one of the top priority in his list then his performance, the results related to his project, and his team’s momentum are always improving. The top management and the project manager have to clearly understand that what it makes to run a company and project successfully is not anything else but the people constituting various teams.
In software project there are two key agencies involved – customer and vendor. Both have to own equal responsibility in managing, monitoring and completing it successfully. In my earlier blog I have mentioned 6 mandates for Vendor Organization on Software Project Ownership. Here I would like to highlight 7 mandates for Customer Organization on OWNERSHIP in a software project. If both these mandates are followed, there is not doubt about the success of a project.
Mandates can be as below:
1. Involvement of top management during specifications finalization and implementation is mandatory: Most of the times customer management thinks their role only in signing off the project initiation documents and after that they feel it is the responsibility of the vendor team and their organization team managed by respective project managers to run the show and make it a success. This is a wrong concept, as the top management has to play a lead role in defining their expectations and requirements during specifications finalization phase of the project. They have to keep monitoring the progress of the project in later stages too. Generally what happens is that the top management do not define their requirements and expectations during this phase and at the final stage of implementation they feel robbed off as they realise that they are getting nothing or something they did not require or expect.
2. Project Manager and Key users should be identified well in advance and should be spared from all other responsibilities during requirement freezing and implementation phase: The top management should identify the project manager and key user well in advance based on their business knowledge, process ownership and commitment towards the organization. They should also ensure that this team’s top priority is now this project where they have to define specifications of requirements, UAT, implementation, reconciliations etc. And if they are engaged in their day to day routine activity or in any other critical program, they would not be able to do the full justification to the project.
3. Management has to ensure all milestone sign-offs – like requirements study, UAT, Implementation close-out etc: The management has to ensure that they mutually identify the milestones of the project. Proper sign off after each milestone achieved, monitoring of milestones progress etc. The persons understanding the gravity and seriousness of the matter should be authorized for signing off the various stages.
4. Project Manager has to ensure about the specifications completeness and validation during requirement freezing phase. Also he has to ensure his own and the key users’ availability during the project implementation, training and UAT phase: The project manager chosen by the top management has to ensure that accurate and complete requirements being documented validated by respective process owners. Since top management can not be involved in day to day activities of the project, he, being the project manager has to raise an alarm to the top management as and when he foresees any deviation from the plan or unavailability of key persons of his team who have to define the requirements or have to vet the validity of software meeting those requirements defined.
5. Project manager has to ensure the adherence of implementation plan timeline and any non-adherence has to be escalated well in time: As said above, Project manager has to be very careful and serious in this regard, and should be empowered enough to raise the appropriate alarm to the right person at right time at any level.
6. Top management has to review the progress of the project regularly as per schedule (weekly/daily): Top management has to have a process to monitor the progress of the project. The metrics could be plan vs actual or anything. Their involvement in monitoring the progress will definitely keep everyone in the team on their toes.
7. Persons dedicated for requirement freezing should be well aware of business practices, processes and statutory requirements of their organization and country: This is very important but not critically analyzed often. The persons identified for defining the process, requirements and business rules should be well aware of the business practices and processes of their organization and any statutory requirement of their country.
Ownership is a big issue in a software project. Customer organization assumes that since they are spending money, it is the sole responsibility of supplying organization to make the project a success. Vendor organization on the other hand assumes otherwise. Who is right? I think both are wrong at their ends. A Project can never become a success while the two agencies involved act as separate islands. Both have to take the equal ownership to make it a success.
The six important mandates that a vendor organization should follow in that regards can be listed as below:
1. Involvement of top management is mandatory: Involvement of top management of the organization engaged in development of software product for an external customer has to be involved in the complete project lifecycle to make it a success. This does not mean a day-to-day involvement in monitoring the progress but there should be some metrics to monitor the overall progress at any moment of time. Another aspect is involvement of top management gives a serious impact on the progress of the project.
2. A dedicated project manager should be nominated for the complete project lifecycle: Right at the Project Initiation phase, a dedicated project manager needs to be assigned for the project. The selection of project manager should be very carefully done, keeping in mind that not only he should be expert in managing a project but he should have ample business knowledge also related to the project he is being assigned to manage.
3. Role of project manager and team has to be well defined at the start of a project: The roles and responsibilities are important to be defined well in advance to clear any ambiguities and to smoothen the progress path.
4. The project manager will act as a consultant to the customer regarding project plan and its adherence: It is the sole responsibility of customer project manager (and in turn their top management) regarding availability of customer project manager and key users in various stages of the project as agreed upon. Project Manager and the supplying organization have to act as a consultant. The responsibility to gear up the progress falls on the customer team. Vendor team can help them in support and educate them on how to achieve it.
5. The management has to ensure that the project manager and the team chosen for the customization/ development have to have enough business knowledge (of their respective domain) apart from technical skills: As mentioned above regarding the project manager, the same holds truth for developers, and testers too. Without reasonable business knowledge, even the expert developers and testers will not able to do the full justification to the product being built/ developed.
6. Project Manager has to ensure during the project lifecycle that the person who is signing off the requirements, UAT, and other stages from customer end is authorized person from customer management to do so: Many a times it happens that in a very busy scenario or with some other top priorities in hand, the customer management instead of releasing appropriate person for the relevant job, ask some junior person to do so which creates lot of issues.
20 points for organizational self evaluation to check where it stands in Software Project Management
2. Are you using some metrics to check if this is the right methodology?
3. What is the degree of improvement required in your current methodology to meet your customer expectations?
4. What are your organization’s primary and secondary goals?
5. Do you agree that there is always a scope for continuous improvement in everything we do – be it process, method or skills?
6. Do you agree that a product developed without any pre-defined procedure has varying chances of success?
7. Do you have a culture of performing development and testing as separate activities?
8. Do you assure a bug-free product at the time of its release?
9. Do you see all your processes integrated going hand in hand?
10. Do you get your payments from customer in time?
11. Do you have a process to capture customer feedback and request?
12. Do you have an innovation process in place?
13. Do you have a post implementation review in place?
14. Are your project managers and their teams aware of their roles and responsibilities – on-site and off-site?
15. Do you have project overruns often?
16. Do you have a risk analysis and planning process in place?
17. Are your employees delighted in doing whatever they are asked for?
18. Do you have empowerment process in place?
19. Are you certain about success in your projects or is it by chance/ by luck?
20. Do you have a repository of code, test cases etc. for re-use?
Why software testing effort estimation is important after functional specifications finalization phase?
If we go by quality standards the sizing of software testing effort has to be done before the tester(s) start writing the test cases for the purpose. The estimate will clearly draw out of the functional specifications signed off between the customer and vendor. Without sizing the Testing manager can never create a testing plan based on which he will decide the number of days and persons required to write test cases, perform testing, draw out the testing results, submit the result report to development team and get the reported bugs resolved. The plan will comprise of time-line and no. of persons required for each of this phase in the sequence mentioned above.
To calculate a reasonable testing time-line estimate based on functional specifications there are certain guidelines that need to be followed: the person who is planning has to have ample business and testing knowledge. Unless (s)he has the right business knowledge (s)he will not be able to select the right persons for writing test cases, or able to guide them on the critical business rules and processes written in the software to hit upon. In that case the best of the test cases will lack the complete coverage and accuracy in testing. The software may lack bug-proofing at the end and customer will be the sole sufferer. Ultimately it is going to effect the software, and the organization that built it.
1. Quality Goals are meant only for Quality Department: No department other than quality (project management, product development, documentation, general management etc.) has to read, understand and learn about the quality goals of the organization. It is only the responsibility of quality department and quality staff. So keep performing without ‘quality’ in it. After all the quality has to do its job.
2. Don’t define your quality goals: If quality goals have such a low value in the organization, don’t document it. Because even if it gets documented, it will be never read or adhered to. Why waste efforts and paper.
3. Give least time for testing: In your project development plan, keep least time between the release time and development finish time so that quality people get least time to test the product and thereby least burden to the production/development team.
4. Have a highly versatile and flexible project plan: Build a scope of huge flexibility and versatility in your project plan/ development plan/ testing plan/ implementation plan to make it a never ending project.
5. Don’t focus on customer top management requirements: Just focus on the user’s and department’s requirements while freezing customer requirements in requirements freezing stage. Discard top management in all briefings, findings and their requirements analysis at any stage. This may make you success in all stages except the final project close-off stage, which will never come in this scenario.
6. Adopt no methodology: Don’t try for any world class standards or methodologies in your project management even if you have any world class projects in hand. Be assured that both situations will go hand in hand for a long run. So no need to worry.
7. Learn the art of converting inadequate into adequate: Project in your review reports at all stages that situation is under control with an art of projecting inadequate efforts, planning etc as adequate.
8. Never change: Have a firm belief that priorities have no meaning. Keep working on your pace as per your desire. Don’t prioritize and re-prioritize anything, ever.
9. Risk: If your trust yourself, be firm that there is any risk to assess. There is no requirement of risk assessment and risk planning in your projects at any stage.
10. No Repository: Who says – there has to be a library of codes and test cases for instance? Why create a repository? You have enough time to work and re-work on anything.
10. Document with complete and clear requirements is as important as oxygen in the air: Requirements based testing is purely based on the requirements specified by the customer or software sponsor during the business requirements study phase. Documentation of all requirements (user level and management level) at micro level is very (Very) crucial. Missing out any requirements or unclear requirements can call for a big problem at the implementation and project close-out stages. Getting the sign-off to freeze all requirements is equally important.
9. Requirement freezing does not mean “No Change”: You can’t close your doors for a change in requirements after initial business study phase. The business and business rules keep changing thereby meaning that the CHANGE in REQUIREMENTS can happen at any stage after requirement freezing till the project close-out. The impact of change on time and cost is a different subject altogether.
8. Start building test cases” along with the development: The moment after requirement freezing as discussed in the first point above, the project manager’s first job is to do the resource management, requirements break down in tasks and task allocation for development. At the same time, the testing team has to start understanding the requirements and build their extensive test cases based on the requirements.
7. Business Knowledge is as important as the testing knowledge: The rule of 50:50 is applicable for both – the developers as well as testers. It has to be 50% technical knowledge and rest business knowledge for developers. Similarly the testers should have the same ratio between the business knowledge and the testing knowledge to write down the sensible test cases.
6. Confirm complete coverage of requirements in your test cases: Ensure that the requirements are completely and exactly covered as per the business need built in the software (or being built parallel). Incomplete coverage of requirements in building test cases will again result into a disaster for the project and product.
5. Change your test cases alongwith the Change in Requirements: For the purpose of requirements based testing, you have to keep modifying the test cases after understanding the exact changes required (documented and signed-off). Don’t forget to vet for the change coverage in your test cases re-built or modified as per the need.
4. Build a repository of your test cases: Building a repository will always help in saving of time writing the test cases afresh in case of similar (or same) requirements scenarios. So keep building your repository with clear documentation of the coverage a set of test cases is meant for.
3. Start testing as soon as one unit is ready: Don’t wait for the product development to complete. Start your testing as soon as the smallest unit is done, so at least the unit testing is over alongside the development (and most part of integration testing too as the units are increasing during development).
2. Re-test to confirm: Re-testing of your test cases with the business requirements is as important as the re-verification of test cases built.
1. Measure the benefits of Requirement based testing over the post development testing: Don’t forget to build a small metrics to measure the benefits drawn out of your requirements based testing in comparison to the complete testing being started post development. This analysis will definitely reflect great results in terms of time, efforts and money.
The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.
In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.
In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.
The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.
Certainly and obviously, every business has a set of objectives. Every business strives for survival, growth, revenues, profits, satisfaction and maturity. The clearer the objective are, the easier it is to achieve them. To achieve the objectives, if the destination is clear, it becomes easier to set the direction of the business, to set the milestones, to chalk out the roadmap, to set the drive, to decide the pace and to achieve them. The top 20 end objectives of any software project can be listed as below (note that the hierarchy is not as critical as the understanding of the gravity of each of the objective):
2. Standards and Methodology
4. Stakeholders rights
6. Pro-active approach to avoid post-mortem
7. Universal approach for similar projects
8. Timely completion, sign-offs and payments
9. Customer satisfaction and delight
10. Customer requirements and both end clarity on objectives of the product
11. Team building
12. Roles, responsibilities and accountability
13. Continuous Learning from failures/ overruns – no repetition of same mistakes to achieve continuous improvement overall
14. First time right approach
15. Quality right from start – ongoing – every step
16. Increase in revenue
17. Avoid revenue loss
18. Reduce costs
19. Avoid cost increases
20. Improved service
Following are the top 15 pain areas of a software project. All points listed below appear somewhere or the other in a software project lifecycle. The ratio of pain from a particular below listed item may vary from project to project within an organization, and also from organization to organization. So although the hierarchy may vary, the pain areas somehow remain the same. A lack in addressing any one of the issue listed below may call for a big hiccup in the smooth running and closure of a project. The project size (and in turn the time and team size also) will vary depending on customer and customer requirements. Although all points listed below are self explanatory, but the understanding and perception may vary from individual to individual.
In that respect, I would like to take each of the points below one by one in my forthcoming blogs to explain how much impact each of the instrument listed below will have on the project and how to overcome this pain not only for that projects but for all the projects in that organization to come in future. The most important activity for each individual is, now, to re-arrange the points (with any additions/ or replacements) according to the ratio of pain it is giving, and then learn how to convert that pain into pleasure once for all (in my future blogs for the later part!)
3. Customer requirements understanding
4. Measurement of Overrun is in money terms immaterial of time overrun (time is not measured in terms of money)
5. Frequent Status review in a forum
6. Status of project movement is person based
7. Role clarity to project manager and team on site
8. Risk analysis
9. Team building
10. Customer clarity in terms of milestones and payments
11. Project Repository
12. Learning from Past
13. Post implementation support
14. Quality – man, methods, approach and deliverables
15. Version Control
Recently a US passenger Airbus had a serious problem just after it took off from the Airport. The plane suddenly lost power in both engines, and pilot Chesley Sullenberger judged that it would be too difficult either to return to the airport of departure or to land at a nearby airport. Instead, he decided to land on the Hudson River, which in the middle of winter was frozen over. With hardly any time to think, Sullenberger drew on all his professional experience and self-confidence and made a snap decision. His decision saved the lives of all 155 people aboard the plane. Sullenberger was the last to leave the plane, and did so only after making sure that everyone else had been rescued. He did everything he had to do right through to the end.
Some learning points can be drawn out for the project manager who is the pilot of a project. The problems and failures can be part of any project, but the project is not dead till the Project Manager raises his/her hands against those problems and failures. A good project manager will never give up till the end and apply all his inherent skills to overcome those problems and failures to make that project a success. The learning points from this incidence can be summarized as below:
Don’t lose hope
Use your professional experience to overcome any crisis
Keep your self-confidence up always
Be ‘quick’ in taking ‘right’ decisions
Take responsibility to rescue all on board – your teams, your organization, your management, your customer and your product
Let others cheer individually on their successes/targets achieved but your cheer moment is only after the successful end of a project
Dear Product Manager don’t cheat your customer by bypassing final ‘testing’ of the product before launch
When work pressures are too high, deadlines are on head, we tend to bypass our own standards, procedures and policies. A product manager if affords to skip testing for that purpose, that means he is committing a crime which is quite serious offense. Any management supporting this idea becomes part of the crime. Testing on ‘wish’ of a person (the product manager), depending on time availability or delay in development clearly states there are no plans in reality. If development of the product is delayed, the implementation can be delayed, whatever be the pressure from customer. If customer is befooled by declaring that the product is ready to launch (which has in actual not been tested properly, and customer is unaware of this), that means the customer is being cheated.
The whole scenario calls for a delay or failure, but who cares – there is no discipline being followed and the confidence is – “we will handle any situation”. Had the product launch been delayed by clearly stating to the customer (or to the top management, if pressure if from there) that the testing and fixing of bugs will take some more days, the customer (or top management) would have always welcomed the decision and would surely have understood your compassion (and passion) towards product, organization and the customer. Definitely it is a call for troubles during launch and implementation stage if the ‘testing’ has been bypassed.
If this is so, we still are the same as we were, have learnt nothing from the past and are betting for failure in success. That also means that QA is being displayed as a ‘showpiece’ to customer or to top management.
Endnote – if you have an opinion that ‘testing’ or QC of the product is a useless activity, if you believe most of the bugs reported by the testers are useless, you are as right as your highest level commitment towards the product, development, yourself, your customer and your organization.
During one of my initial management trainings (years back) I learnt the different between hard worker and smart worker. This example I could never forget even after so many years. Example of a hard worker is a person who comes to office in the morning, puts off his shirt, start pushing a wall, and keeps pushing it throughout the day, keeps sweating, keeps management happy that he is working very hard, and goes off tired and weird at the end of the day with no end results. The wall is there as it is where it was in the morning.
The example of a smart worker is who comes to office, smartly dressed, hardly do any work himself, but still the results keep pouring in, the management remains happy with him.
In harsh words – there is a difference between a donkey and a horse.
Every project manager has a project charter, plan and schedule. Every project starts, but very few end in time with complete satisfaction of customer, management and project team members. Why so? Efforts are put in, in all the scenarios, but all do efforts do not fetch good results. Where lies the difference, is an important point to introspect. In most cases, even if the project fails, the project manager do not let the axe fall on him by proving n no. of reasons mostly situational and saves his skin. But at what cost and who is the loser? The management and the customer are the biggest losers in any project failure.
A project manager has to be ‘smart’ all the time to manage the project and for its successful timely completion. Major issue during a project is to be pro-active and smell the issue before it gets out of control. Second major issue is managing everything on your own, and hiding some bottlenecks from the management or customer. Infact by raising your voice and informing them about your problem related to the project will get you the solution faster and better. Taking the problem where you alone are not able to find a solution will enhance your image in their eyes. Similarly tracking your team is equally prime. Managing project is simple if your thoughts are not complex.
Dear Project Manager – your “faith” in 5 pillars of project can get you miraculous success in any Project
I remember a small inspirational story read somewhere recently. A small girl took all the money she had in her piggy bank and went to a nearby drug store. The drug store owner was busy on a phone, and the girl was waiting for him to get free at the earliest. As she got desperate she interrupted the owner – “excuse me – I want to buy miracle, how much it costs?”. The owner kept on talking over the phone with giving an ear to her. She repeated the same again, this time in a raised tone. Owner told her as he is busy talking to his brother staying in a far country after a long time. The little girl literally had tears, helpless as if she wanted something urgently. Another man was standing inside the shop. He got curious by what the girl had asked for. He asked the girl – “what do you want?”. She said I want miracle, and I have money for it. “But what do you need it for” – the man asked her. “My brother is very seriously ill, and my mother says only a miracle can save her” – she replied. The man was the most senior neuro-surgeon of the country. He accompanied the girl by saying – ok, I have the miracle, let us go to your house to see your brother. The boy was operated free of cost and got well. The total cost of operation was “FAITH” of the little girl and some dollars she had in her piggy.
Like the little girl, the project manager has to have this tool with him all the time to win over any situation and to gain success in any project. The 5 pillars of the project where a PM has to put his total faith into are:
5. Customer: The customer is the on whose money your organization, management, your teams, and you exist. Your faith in customer has to reflect in all your discussions, communications, deliveries and product. Chose your words very carefully when you are in front of your customer or even when you are having an off-hand communication through phone conversations, emails etc. Your actions speak louder than your words. So take care of your gestures and bod language too.
4. Management: Your management is banking on you for the building and delivery of the product. Don’t mingle facts with over-enthusiastic assumptions when you present the project report to your management or to your customer. Be realistic and conservative in presenting the facts and projections.
3. Team: Don’t divide your team into doers and non-doers, slow and fast runners, perfect and imperfect. Labels regarding the individuals once set in your mind will drastically and adversely affect the project. Trust them in the same volume as you want them to trust you.
2. Processes: Whatever processes and procedures you adopt for project management, follow them ethically, trust them and they will deliver you the best.
1. Self: This is the prime factor. If you don’t have this, if you don’t trust yourself, you will not be able to adhere to the 4 points mentioned above. You can (deliver your best) only if you think you can.
Miracles do happen but only buying coin is TRUST.
A new project is always divided into small tasks and based on the resources available, the task(s) are allocated to individuals by the project manager (PM). A simple metrics is important to follow to monitor (and manger) the completion of tasks and thereby figuring out at any moment of time – the progress of the project. Completion of all tasks automatically declares the completion of the project.
Customer and management will never be interested to go into the detail of each task, PM (you) and your team may be and should be. But your one of the major task during a project is to keep customer and management updated on what is happening, regarding the progress of the project.
Your team of individual developers, programmers, coders or other technical related functions, although have accountability for the tasks assigned to them in individual for which they put in all their efforts to meet your/their completion plans as per the targets set.
So far so good, but as far as satisfaction, and feel of achievement is concerned, you need to group a set of tasks (the important ones that really give sense of achievement) into milestones. The customer and management will be interested in milestones achieved instead of tasks completed. Your team members will feel motivated, inspired and cheerful on achieving these milestones. And above all you will have time to appreciate and celebrate your team’s achievements that you can not do rightfully in case of tasks.
Milestones have more visibility as compared to tasks.
It is not important what metrics you (the project manager) use, because unless and until you understand the meaning of “task” and “task completion”, you can’t get into the mode of monitoring and measuring it. The progress (or completion) project as a whole is measurable only if it is broken into pieces termed as “tasks”. Based on your resources you can allocate different tasks to different developers/ technical guys. But again the questions arise are – “what do you want to measure?” and on top of it, “do you really want to measure?”. If the answer is “yes” for the second question, then you will start thinking about “how to measure?”.
Metrics or method of measuring is not critical, it is the “what” that matters most here. So when you break up your software project into tasks, those should be measurable and the person doing it has to be accountable for it. Before making your programmer (or the technical person) accountable for a task, you have to evaluate – “is (s)he is fit for the task being assigned?”.
Your method of measurement will decide the clarity of progress of project to you, your team, the management and to the customer. Don’t accept a report from your subordinate declaring a task as completed unless you yourself are convinced. For your conviction you can get it checked by another coder, technical person or quality person, or you can check on your own, depending on the criticality of the task. Since you are going to report to management and the customer about completion of a task, it is important to confirm beforehand.
Transparency about the project progress is as important as the authenticity to both – the management and the customer.
Integrity of task completed is another measure that you have to take into account for your project completion.
Regression testing comes into picture in “re-testing” of a product. The purpose is very clear – a thorough testing. Regression testing has to be as rigorous as possible, for this reason. And regression testing never happens once, it has to happen again and again till the product reaches at a maturity state of release.
The purpose of a regression testing is to manage the risks occurring after the changes done to a product. Changes happen after the bugs have been reported to the development team or if the customer has asked for changes (or a new requirement) in the developing product. In an effort to entertain them many changes are done by the developers. The changes could result in following:
A bug fixed by the developer not actually fixed
New bugs built while taking into account the new requirements or changes from the customer
Earlier fixed bug re-occurring
To handle all this, an extensive and rigorous testing is required to be done by the testers for the good cause of releasing out a “bug-free” product at the end of regression cycles.
The most wrong statement from a Project Manager to the management during a project can be – “Everything is as per plan”. This is never, never possible during a project where a software development is required. If this is the statement from the Project Manager, there could be two realities behind it – one, either he is being cheated, or two, he is cheating the management (and in turn himself!, phew!). This could be due to (again two reasons) – either he is unaware of the facts, or he is trying to hide the facts. The first factor (being unaware of the facts) can be overcome with the help of some discipline and procedures, but if the second reason is surpassing the first one, then organization (both – the customer and vendor) are in trouble.
To overcome the first reason i.e. not to fall in the category of “not being aware of the facts”, the project manager has to follow certain guidelines, the prime could be:
1. Keep an updated project status report with you. (the frequency of updations could be in hours or days, but not in weeks or months).
2. The components of your project status report have to be –
Planned vs. Actual Efforts (mind it, there is a difference between the monitoring of tasks and efforts, and both play a major role in a project. Monitoring of both is essential)
Tasks requiring no “re-do” or “re-look”
Tasks requiring a “re-do” or “re-look”
Efforts/ hours “over spent”
Open bugs, risks, issues
List of customer requirements pouring in after clarification from the customer (during development). (and don’t tell me that there are no clarifications required from the customer during the development phase)
The balance efforts, with time, resources allocation and concrete plan. (this has to be as crisp and realistic as possible)
The young inexperienced or short experienced budding testers are the one who will determine the future of testing. This is the prime thing that the QA head has to keep in mind while grooming and mentoring them. The testers have to have a firm belief that the future of testing is going to be brighter than today and that is why the QA Manager and the testers have to deliver their best efforts to all their endeavors. They have to exert their utmost efforts, contributing to the building of a software product (built by developers, being tested by QC team thereby delivering the best of it!) that properly reflects your spirit and drive in testing.
The key aspect is not to compromise with your fundamental values of Testing, such as clear Testing Mission, Policy, Plan, Procedure etc.
Testers have undoubtedly a strong affinity towards testing that makes them close to the product, development team with a joint mission to deliver a bug-free product.
TDD is test driven development in which the developers coding efforts become manifold. It is not only the development coding that developer has to write. Along with the requirements coding, the developer has to write code for the testing of each of the logic he has built in the product. It is more or less a unit testing where each small unit is tested individually by the developer as soon as he completes writing the code for it. All this is not easy to perform. It requires a different mindset to perform TDD. The developer has to be in a different frame of mind to accept first the extra work required from him. There is no extra technical skill set required in the developer, it is the mental preparedness that matters more. They have to overcome the resistance from within to do some extra efforts in coding. Although this could be a little painful but only in the beginning, afterwards, when the results start speaking loudly in lieu of the extra efforts done, it gives a different level of satisfaction to the developers.
The extra effort done by the developer in return saves a lot of time that is required for testing later since in TDD, the bugs reduce tremendously in such a manner that once matured, the later stage testing can be totally avoided.
TDD can be compared to Japanese companies environment as on-line QC in sub-assembly production instead of having QC of the product in the finished stage.
Sync is very important between a developer and a tester. The confidence and ease of the both has to complement each other and ultimately create a bug-free product. The prime goal is same for the whole organization – to deliver the customer what he is expecting – a totally bug free product. Both have to perform well in their respective areas to achieve the common goal.
Small breaks in-between can do wonders during the high work loads. An open platform where each member from development and testing share their current tasks with the status will cover two areas – update each one about others, and keep them synchronized.
Sometimes it is good to be a little casual and the tester can go straight to the developer with a problem and get it resolved even without waiting for a formal meeting for the purpose.
On the lighter side the equation goes like this:
Let us assume that the developer is developing in such a manner that there is no bug in the software, that means developer is actually developer and tester both.
The equation would look like: developer = developer + tester.
Which can be written as developer – developer = tester
Hence tester = 0.
But the serious aspect is that this is a purely hypothetical state. Tester’s existence evolved only because developer was working only as a developer with less quality embedded in the software. That is why tester has to evaluate the developed product on all quality fronts.
In an organization engaged in software development, usually each software goes through testing process by a separate set of team in the organization know as Testers meant exclusively for the purpose of testing. It matters most what this process is being thought as by the development team, project leads and the management (and also the customer). Testers are taken for granted as Bug Filters and testing as bug filtering process. If that is so, the management is at mistake, more so, if testers or QC department also thinks the same. This sort of culture is good for testing purposes, but is not so for the purpose of improvisation in the development process. Testers are safe as they are able to dig out a good amount of bugs every time. Bug removal time is substantial. Even the targets of product hand over to customer are met.
Isn’t the testing team’s result decrease every time even after increased efforts! That means the development team in maturing with each round of testing and development. This can happen only in case testing is not merely thought as the bug filtering process.
Bugs are often invincible during development, especially in large projects when multiple sub-teams of developers are working on development of different sub-modules of the project. The software developed (or during development) will always appear innocent and bug-free to the team of developers. It is the tester’s tough task to puncture the software and find out the hidden bugs. If bugs during testing phase are not found completely, it may lead to disastrous consequences, depending on the severity of unfound bugs. That is why, for developers and testers it is very important to understand the complete flow, sequence, modules, sub-modules, functional sequence to build accurately by developers and verification by testers.
Testers have to exercise the testing process and they have to ensure that they are following the right process to identify as many bugs as possible.
You not only have to understand the customer but sometimes you have to make customer understand what exactly he requires to enhance his business. Many a times, a customer is not able to chalk out clearly what business requirements he wants to get embedded in the software. He is not clear about what exactly he should get embedded in the software to get the optimum out of the software and business mix. He might be having a broad idea about what he wants to see as a final product, but may not be able to define what the core components of this product are. Customer would say the team to study their business as they are doing it, without getting involved in it. This could be serious and the seriousness if not understood rightly in time (emphasize on ‘understood’, rightly’ and ‘in time’), would lead to disastrous results.
Customer is not for experimentation. Clear and crisp ‘Requirement freezing’ is the right start. Customer may be required to be educated on what business, requirements and rules can be built in the software. A simulations or scenario generation is important to make customer understand how the software will work once completed. Customer needs to understand very clearly at the initial phases – What ease or comfort will the software bring out to business processes by giving out certain set of business results. Customer has to understand very clearly the other part of the story too. The software definitely will require certain extra skill sets, enhancements, or extra efforts once it is completed and implemented at customer site.
Past is not to be buried. It contains a treasure called EXPERIENCE. In software development this treasure is of ample importance for acquiring skills required to handle the unwarranted turns and twists during the development (and implementation) period.
What we can learn from the past is the hiccups that caused delays and stoppages in a development project. We can use that learning as a tool to tackle the problems occurred during the project life cycle. The learning could be in the form of:
1. Handling customer
2. Freezing customer requirements
3. Preparation of documents
4. Selection of a project manager
5. Development Team formation
6. Key users committee formation at customer end
7. Management committee formation at customer and development end
8. Team coordination
9. Tester’s involvement in the development
10. Choosing a right methodology for project management
In software development project what matters most is the timely accurate delivery that gives the benefit of defect free product, customer satisfaction, profits, market edge, growth, motivation across the organization etc. All this is not easy to achieve having so many enemies in and outside the organizations that mars the development progress or a sub-standard product. These negative factors or enemies lead to a low in quality product that faces a tough time at customer end resulting in rejection. To name top 5 quality killers in a software product, I would list them as below:
5. Requirements: customer requirements or product requirements is the foundation of software. Any sort of compromise in this would lead definitely to a disastrous product.
4. Management: Intensity of management’s involvement in the product development throughout spells out the success or failure of a product.
3. Documentation: Development plays an important role during a product lifecycle and so does the documentation.
2. Customer Involvement: The involvement of key users at all levels of development and implementation is quite crucial.
1. Testing: ‘When’ to involve the ‘testing’ team defines the earlier successful completion of a project.
Software development is the easiest task and requires no development or quality standards, provided you are ready to manufacture software which:
– Is full of bugs
– Has no buyer
– Is never ready to launch
– Has success-failure ratio as 0:100
– Is ready for unlimited budget inflow
– Is only for the purpose of keeping teams busy
Top 10 reasons to prove that software development is the easiest task on this earth provided you are ready to follow the guidelines mentioned as below:
10. Develop the software with no requirements in mind
9. Follow no standards
8. Keep the customer away during development and testing
7. Don’t select a good team of developers and testers
6. No follow meetings
5. Keep your developers on their toes. Let them not stick to their work. Keep giving them new work in between, or moving them from one sub-module to another before they completion
4. Involve testing team only in the end that too with too little time in hand
3. Keep top management happy by reporting to them about the happy state of development
2. Don’t divide the work proportionately among developers. Let them chose what they want to do
1. No owners of the product
A reference model is a non-arbitrary model of software that is to be referred to when a new software requirement comes from a customer. The reference model will suit and fit most of the requirements given by the customer. The model is the most ideal scenario befitting the technical and functional requirements. Although the new architecture built may not (and will never) match point to point with the reference model but still it has to be as near to it as possible. Infact the reference model has to be capable to address all technical issues that may arise during the software development. During the development if a new problem is encountered, it becomes the part of reference model too. For development also the different components of the repository of the reference model are picked and absorbed wherever found suitable. So the various components are picked and fixed as it is in the software or are reworked with minor changes keeping requirements in mind.
This process not only shortens the development timeframe but also brings in more accuracy and stability in the product. It also helps the project manager to present the near to exact time and cost estimations. The reference model acts as a block of utilities or functions meant for the software being built. The best suitable blocks are selected and placed as it is. The most suitable blocks are selected and placed with a little modification. This increases the reusability as well. Reference model works as an outline sketch of the new product being developed.
The main tools of a project manager are communication, partnership and guiding his/her team towards success. As long as the project is going smooth, there is no problem. But as soon as there is a crisis, it is the project manager who has to rise to the challenge and seek out the vacuum to be evacuated. Every project manager has to have something in him/her that has brought some time or the other his team out of critical situations and sailed the project successfully.
The key skills required in a project manager including those mentioned above can be summarized as below:
3. Guide the team
10. Right Approach
12. Roles management
13. Capitalization of experience
14. Prepare for transformational technologies
15. Change Management
16. New Business Models
17. Deep understanding of methodologies and technologies
18. Drive business
19. Operate in interconnected world and global economy
20. Work together
21. Leverage each other’s knowledge and experience
23. Be well organized and well equipped
24. Work with extreme ideologies in your sleeves
25. Apply innovation to traditional problem solving
26. Keep analyzing and organizing
27. Have a critical eye to assess the situation
28. Find and place most significant people in your team
29. Recognize the difference between management and leadership
30. Be visionary
31. Drive strategy
32. Market yourself and your product with full heart
33. Think Strategically
34. Do effective delegation
35. Reward performance
36. Develop individuals to their full strength
37. Be transparent
38. Build trust and relationship
39. Measure effectiveness
40. Be influential
41. Understand and overcome holes or flaws in technology you use or the product you make (before your customer finds it out for you!)
42. Don’t believe in product, get it tested by you testers extensively
43. Always believe that when developers and testers work together, with the combination of technology and strengths, the resultant product will be always better
44. Anticipate a problem and find out a solution
46. Provide opportunity to your developers for career development which is a key for job satisfaction, retention and succession planning
47. Be a consistent leader
48. Incorporate best practices
49. Be a role model
50. Don’t accept anything on face value. Question, examine and introspect
In an organization engaged in software development business, timesheet is filled by all developers and testers working on any project. Timesheet a sheet of pre-formatted fields in which daily tasks performed by each person are filled in their individual sheet. The intent of timesheet varies from organization to organization. Some organizations use it for raising invoice from the customer whereas others use it to study the developers pace and engagement with the allocated work. The sheet usually comprises of person’s name, date, project name, plan for the day, and the tasks actually performed against the planned activities. It is not a complex format but it returns valuable information. It can also be termed as daily task sheet of each individual.
Filled timesheet is sent by each developer or tester to their respective leaders routinely. Besides sending it to leader, as per organization directive, a copy may be required to send to HR and/or Accounts department. The frequency may vary from daily or weekly to monthly. It may also be used by accounts person to allocate the resource (developer of tester) to the respective cost centre. In positive sense the purpose of timesheet is not to track the person but to prepare a repository to refer to immediately or later for various purposes. The purposes could be the calculation of total man hours spent on a project, the cost incurred on a project, the engagement/pace/% time of an individual in a project, backlog analysis at any stage during the development, re-allocation of task, requirement analysis etc. It becomes a good tool for HR to find out the vacation trend of an individual. HR or project leader can also schedule the trainings and vacations for each individual based on their timesheet that clearly tells their workload level.
The charter of a project manager or development manager at the start of a new project which requires extensive fresh development comprises of many pitfalls or showstoppers. To win over them, the project manager or development manager requires a well defined charter to adhere to.
The key points of this charter can be:
Software project management plan
Team members with their skills and job allocated
Allocation of resources – hardware & software
Schedule of execution
Risk Analysis with how each one is being addressed
Technical layout and approach
A guidebook for each process
Role of any other product being embedded in this product
Role of product in the overall product line being carried by the organization
Lead the team by way of demonstration in all aspects
Define the purpose and limitations of the software development process
Sensibly tailoring or moulding the development lifecycle standards wherever required with proper documentation and justification
A chart for mapping requirement vis-à-vis the development
Embedment of statutory requirements in the software
Development and implementation in most effective and efficient manner
Trainings at all levels and stages
Measurement of progress
Sign off at various stages
Review, review and review at all stages of progress
A large software development project can become scary for the development manager who is handling the project provided (s)he is lacking the experience and ability to manage people, machines, requirements and time in appropriate manner. A balanced control is the call of the time at this juncture, to give the project a right start by understanding the requirements well and selection of right people for the job. The development process needs to be planned and executed well for which a root level monitoring and control is mandatory. Having good knowledge and skills required to lead the development team goes haywired if these skills and knowledge are not executed timely and properly. The project manager or development manager has to understand the core relationship of software development with overall software product engineering, the estimated time and costs, and above all the software process being followed.
On the basis of the project requirements, the project manager has to decide upon the right life cycle model, requirements analysis, environment in which the product is to be built, control of configuration (both server and client level), development team management, and quality assurance. This is not at all easy, and can be achieved only by winning over each situation.
The goal of any software organization is to develop software applications in-house, or co-develop with an external agency, that meet and exceed internationally accepted quality standards. Every one knows it, that the key role in this is of QA department. With this intention, a dedicated QA department is structured in the organization, for the purpose. But most of the time, the move towards the objective mentioned above is limited or missing at all. Although the development managers too agree that in the software development business software quality is the key to their success.
In view of the above, the development managers need to revisit this area which mostly has not received all the necessary attention it deserves and which is something so crucial that the organization can ill afford to overlook.
Mostly, even if QA is in existence in the organization, it is used to test poorly designed and developed software. The reasons for this are well known, and the major one is that the QC is misconstrued to be a mere testing activity rather than looking at QC from a more holistic perspective. To this extent, the QA/QC department needs to be invited and involved at all stages of the software development lifecycle (SDLC).
To fulfill organization’s expectations and business goal in this regard, the development managers need to have a fresh discussion with QC/QA head to prepare a charter on how they plan to achieve it.
A Testing Certification is an individual tester’s asset rather than the organization’s asset as it increases the employment chances of the individual without apprehensively adding any substantial value to the tester’s job requirement. Definitely, the tester’s skills are enhanced (a bit) with this certification, but there is more increase in his expectations from the organization. Why a tester who is doing well at his job would go for a certification thereby compromising with his performance at job as he will be required to pay attention to studies and learning to acquire this certification. The certificate that is attracting him is for his own sake. Ofcourse, when it is an organization’s requirement to train their testers or display on board some certified testers, the initiative and drive for certification to the individual testers will start from the organization itself.
Certification is not bad. It is an exposure to a new learning. But the testers who get attracted to acquire a certificate have a different goal than a new learning or for the sake of organization. But if the intention is merely to acquire a relevant certificate for a tester, it can be examined by the organization by offering him a course relevant to his job with no certificate at the end of it. This step will display the real interest of a tester, whether he is individual oriented at this juncture or organization oriented.
At the time of recruitment of a tester, the biggest question in front of Quality Manager is to decide on certain factors related to the qualifications, certifications and experience of the candidate. The balance of all three is important. But if there is a demand to sacrifice one (or two) amongst three of these requirements, which can that/those be? Let us take them one by one in the perspective of Quality Head.
Qualification do matter, so the candidate must be having the basic IT degree (or if degree in some other stream, then that degree has to be relevant to IT, and the prospective candidate should be holding an advance IT diploma). When we are talking here of qualifications, we are talking about IT qualifications and not specific Quality/Testing related qualifications, which we would be considering in Certifications.
So, qualifications being the basic criteria, now there is a battle between the certifications or experience. Let us assume here we have three sets of resumes of the candidates. All sets have similar qualifications, and are differing on the basis of Certifications and Experience parameters. First Set of resumes is having Certified testers with no experience, so they are fresher certified testers candidates. Second set is certified testers with good experience in testing (say 2 plus years of experience). And the Third set is group of experienced testers with no certifications. Experience with this group of testers may vary from 2 to 5 years. Definitely the first set expectations in terms of salary would be lower as compared to second and third set of people, whose expectations would be almost at par.
In my view, appointing a tester with basic qualifications and some experience will be better than taking a tester with basic qualifications and certifications but less experience. Certifications, if any required, can be acquired by the tester during the job at a later stage.
When a new project lands into the hands of a project manager for development, he converts the whole project into smaller units and allocates it to different developers. Developers are divided into the groups based on the work allocated. These teams prepare their plan to develop and start working accordingly. Once the development plan is with the project manager, and the developers are tuned into development, the project manager should make least interruptions in their schedule (none unscheduled) thereby helping them in meeting their targets. Different ways in which a project manager can interrupt (which he can and should avoid) can be listed below. These are not in any hierarchy and all lines carry equal importance. The interruption points are:
1. Unscheduled review of the progress of development
2. Discussion related to any past project
3. Discussion related to any future project
4. Allocation of any other task other can the ongoing one
5. Shuffling of developers from one team to another
6. Re-allocating a developer to another project
7. Inviting a new member in a team for development load sharing
8. Approving leave to developer (unless it is too urgent or critical)
9. De-motivating even a single team member of different development team (remember – it spreads like a virus among other members)
10. Don’t forget to appreciate them at each small achievement