There are good programmers and there are good testers. But in 99% of cases good programmers are not good testers and in 100% of cases good testers are not good programmers. Whats exactly would stop a good programmer to be a good tester. Three years back I wrote a post on this titled ”What stops a Good Programmer from being a Good Tester – 8 Reasons.
That was my first post on ITKnowledgeExchange.com. The topic and contents of the article came right from my heart as this pain I was facing for many years during my exprience as a developer in my early years and then later after becoming the head of QA/QC.
The post talks about eight activities if done by a developer can turn him into an as good tester as a developer he or she is.
Success of a project depends on many factors. To name a few would be Team composition, team size, project management methodology, benchmarking, optimization, time management, resource management, monitoring and so on. The list may go endless. Besides all mentioned above, some simple techniques that are easy to adopt and adhere to can change the life of a project manager or for that sake any of the team members who adopt these techniques.
1. Take Lead: Move forward to adopt a tougher task rather than waiting for someone else to grab it and hoping for a simpler task to come into your pocket. Sometimes reverse may happen. And moreover without moving forward you will never be able to bring yourself into limelight.
2. Grow Taller: With each problem and solution, grow your inner strength to handle such situations in a better way in future. Fighting with same situation again and again in same manner is not at all a wise decision. Find out a better solution every time you face a problem.
3. Learn From Mistakes: Who says I work and never make a mistake. Only one person can never make a mistake – who never works. Anyone who works has always a chance to make a mistake. Best thing is to keep learning from your mistakes. Failures and mistakes are the best teachers. Keep one thing intact in mind – never repeat a mistake.
4. Share Onus: You might be smart to handle any situation but in a team never try to take credit alone for any win. Do it only if you want to grow alone and keep all others in team as still as they are. A small piece of appreciation and motivation can do wonders. Try it and see miracles happening.
It is not actually Test Environment Detail Template. It should be termed as Test Environment Template. Let us first understand some terms first as below.
Test Environment: An environment in terms of hardware (server, end user, networking, LAN, WAN), software (client app, browsers, any other) and security environment (firewalls, antivirus, etc.) is decided to be as close to live environment so that no misbehave goes unnoticed during test phase.
Real or Production Environment: A real time scenario when product (software) gets launched at customer site (live environment) after completing all development and testing phases. In this environment, it is the end user that starts working on software in real for business benefits.
A real environment scenario with complete specifications gets frozen right in the beginning of development process (during high level design preferably and may be some part during low level design). Though some changes might occur in the final specs during development or implementation phase but those can’t be major in nature. Otherwise the whole project gets shattered.
A test environment should be as close to live/ production/ real environment in all aspects so that this environment is as good as a simulated environment as it is going to be in reality. Though it may not be possible to create a 100% same environment as it is going to be in live conditions because the same environment may cause a big amount of money and lot of efforts which may practically not be possible.
The template of test environment should be prepared at micro level covering all requirements of live environment with three main sections – hardware, software and security. A parallel column must be there to record deviations and next to that should be a column describing software behaviour and its reasons.
1. Proactive And Intuitive: Alternatively imagine of a team that wakes up only when the water has reached till neck height will take four times of efforts to resolve the same issues. That means a proactive approach is always good with a good flavour of intuitive power. Being proactive and intuitive is worthless unless you have courage to cross the line of silence and inactiveness.
2. Break Silence: Many a times a members keeps mum on a perceived disastrous situation in wake of two fears – one, he will become victim of it; and two, he would get laughed at if situation does not turn out that serious as perceived by him. Nothing will harm even if both probabilities become true. At least it gets shared and evaluated well in advance. Remember that if you understand a problem beforehand and keep silently waiting for someone else to understand and raise the alarm, it may happen. But suppose if it does not happen, it is going to harm the whole team and you are part of the team.
3. Crack Iceberg: The bigger is the iceberg, the higher the disaster it can cause. It is always better to crack it down to smaller pieces. Team must break down a complex problem or situation into simpler parts so as to assign and delegate it in a better way and results start skimming in faster. Someone among the team members must come forward with a courage to demonstrate how to break an iceberg and to share its pieces with everyone rather than few members taking the responsibility of bigger or whole chunk.
Positive of negative traits of a project do not happen on its own. Every act has a reason and every reason has a cause. It is quite important to understand the cause and reason behind any act that occurs during a project lifecycle.
Any deviation from a regular trend must go under investigation be it a positive or negative deviation. An unexpected or unstipulated/ unplanned finish of a task much beyond it was perceived to be definitely requires an introspection and brainstorming so as to understand certain facts behind what is apparently visible:
1. Whether actually the task has finished or is it a misjudgement.
2. What factors made this calculation go wrong.
3. Will it get sustained in future or this deviation was just for this very instance.
4. Can those activities triggering as catalyst to boost completion of task be imbibed permanently in process for similar tasks in future?
5. Has it been a situational benefit or a procedural one?
Such brainstorming will definitely give ample evidences to understand the core logic behind the abnormal activity. Many a times tend to stop finding a reason behind any abnormality beyond certain limit of time or effort. Probably and may be rightly it appears that wasting more time and effort on going into the depth of this issue may not be worthy and justified. It is also assumed that if same situation arises again later in future, more time and effort will be put into it to understand the main cause of it.
Sole purpose of team formation is to manage a tough task collectively and finding out success paths collectively. A team shares success and failures together even if few among all members are responsible for it. Each member of team is supposed to benefit project progress in one way or the other. Otherwise presence of team members in a team is just a formality. Team members have to acquire following specialities so as to be a spearhead of success for their team. Such team members even if are moved from one team to another, remain success generating pillars for their team.
Understanding any complex situation is always complex in nature. it is said that any simple situation can be turned into a complex situation by the way it is understood and handled.
The team should have a capability to understand a situation that is prone to create a complex situation if not addressed to in a timely manner. A proactive approach is quite important for team members to understand the break even point for any problem or situation and manage it well before that point is reached so as to avoid crisis and disaster.
It is said that if a person (or team) has a capability of understanding a problem well in advance before it breaks out, half of the battle is already won. This is because by the time problem actually raises her head, the team is in a good situation of handling it. A team waking on the last alarming bell or first alarming bell always
Best part in a team versus an individual is that a single person will think only with his brain having no discussions, brainstorming, alternatives and different perspectives. A team comprises of different heads, having different ways of thinking and tacking situations. In a group of people a big problem gets small as it gets shared among every member of the team. Such miracle cannot happen when a single person is handling a problem.
But this does not mean that larger teams have more chances of success than small teams. Team size is totally a different ball game depending on the workload and resources available viz-a-viz time available in the pocket to handle the project. Team optimization, resource optimization and time management are different subjects that need to be covered in different details. Currently we are discussing about a group or team and its benefits.
More people are definitely bound to give different ideas for a problem handling and hence optimized ideas can be picked to give a solution. But on the negative side – more heads also mean more chances of conflicts, path crossing, barrier generating and pushing/ pulling. These negative traits of any team if managed smartly can overturn any team into a productive and progressive team.
A team has a power to convert any complex situation arisen during project to a manageable situation. Team can bring any tough situation into comfort zone thereby making bigger achievements easily attainable. It is said that if all team members become compliment to teach other in a team, that team can do wonders at any moment of time. The same project managed under same situations by different teams produce different results.
Imagine that you start your new venture. This venture has no scope of any recruitment in the beginning and there is only a small office with you to start your operations. Gradually there is an ample scope of expansion of business, more office space, recruitment of staff etc. during early stage you are to open your workspace in the morning, clean it, get your desk clean and equipped with water etc. That simply means that with just you in your venture, you are everything, right from peon to managing director. That is simple to say but difficult to perform. But it is not impossible. I have seen many people starting like this and later going beyond their expectations in terms of expansion of business or earning revenues.
If the same attitude is applied in a team then it may bring in a dream team in place. Imagine a project where each team member is required to be equipped to do any task at any moment of time. Imagine about a team where each team member is capable to perform any other member’s task. Count of team members is not for the sake of fulfilment of a gap in terms of quality and requirements but in terms of position only. If that dream world becomes real, it means in absence of any team member nothing gets stuck or delayed in a project.
In absence of a team member another member will take his place and fill the gap. Though this will definitely increase that person’s load but in such scenario where everyone is capable to do any work, the absent team member’s work can be shared in parts by four or five team members instead of putting the complete load on a single person.
A fight between customer and vendor related to requirement keeps going on till the project finish stages starting right from the requirement study phase. Whatsoever methodology or standards you adopt to capture customer requirements, there will always remain a gap between what customer said, what you assumed he said, what you understood and what you built.
But more important is the ways it is covered up by project manager in front of his management. Some of the most prominent reasons he gives to save his neck are:
1. Customer availability: A very common excuse used very frequently whenever there is a point of confusion over customer requirements or lack of information issue arises during a follow up or review meeting is lack of customer availability during the system study phase. Some more relevant excuses would be that the main person concerned about a business process was quite busy/ unavailable/ away and the person deputed in his place had not much knowledge.
2. Customer clarity of business: Same as mentioned in point above. There will be complaints about not getting the right person. The person who was assigned to interact did not have sufficient knowledge. The assigned person was quite new to organization and hence had not much of business knowledge.
3. Customer awareness about technology: Customer has demanded irrelevant things in the application without even knowing about technology and its limitations or power. Customer wants it do be done this way whereas it is quite easy and better to do it that way. These are some dispute points that keep bubbling up at later stages.
4. Customer expecting too much: We started the project with a limited scope but customer keeps adding irrelevant requirements now and then. Customer had initiated a business application but now he expects a full fledged work flow embedded in the application. May be customer would demand proactive/ intelligent part in the application with mobile alerts etc. which was never part of initial discussions.
5. Customer refusing to accept what he told earlier vis a vis what is being delivered: Reasons could be many but a good relationship maintained throughout can force customer to ignore small gaps in the delivery. The same small gaps may erupt as dangerous as Tsunami in case of no good relationships maintained.
Project Manager can never be a quality cop because if he becomes a quality cop, he will never be able to finish his job. For quality manager it is very difficult to become a project manager as having a critic’s mind he will have more than hundred percent chances to have conflicts with customer and his own management over certain issues where he might be forced to compromise but he may not like to. It is very important therefore for a project manager to be a strong stance to manage his project and teams whereas it is better for a quality manager to have a mild or soft stance to keep things going.
Many a times it happens that a bug or defect that gets identified at a later stage after his has crossed quality barrier puts quality team in a tight corner. At such moments it is the QC team that comes under total fire and blame game which is absolutely wrong. To avoid such instances a quality manager will always prefer to keep his tight grip across the product to ensure no leakage remaining unidentified by his team.
It is always better to have heated arguments regarding quality issues between quality head and project head within the building and before the product is launched rather than making a mockery of the whole manager at a later stage in front of customer when those defects or bugs get exposed thereby exploding the situation. Under no circumstances Quality team alone be blamed for defect leakages at a later stage; the whole production team should stand shoulder to shoulder with their quality team under such circumstances.
What happens if a requirement wrongly understood during study phase gets resulted into a mess at a later stage. Minor gaps can always be fixed at any stage of the project. But a requirement if changes 180 degrees after it has been built in the software application and then if customer totally disagrees to accept it, it could lead to a disastrous situation for development team. It could also shatter the whole implementation plan and the overall project plan.
Negative impact on costs and teams is unavoidable in such situations. Though it is the whole project that requires QA/QC engagement but following areas would require QCs engagement most and these are the areas where they are ignored most.
1. Requirement Study: It is not important to have QC persons involved in requirement gathering process. But the moment requirements are finalized and documented well, a copy must go to QC department for them to do two things. One, understand requirements well and start preparing test plan/ test cases. Two, to check any loopholes, ambiguities or shortfalls in requirements or documentation.
2. Development: QC team is usually kep away from development team during development mainly because of three things. One, it is not QCs ball game right now, this court is only meant for developers. Two, what will QC team do to be here till the product is not ready; let product be ready to handover it to QC for testing. Three, the earlier QC is engaged in project, the more problems they will create. So better engage them for the least time.
3. Documentation: This area is usually not given to QC for examination and validation. As a critic they must check all documentation especially the manuals that have to be handed over to customer users.
4. Implementation: QC is not engaged during implementation and that becomes a major cause of project deterioration due to on-site customer requirements not being analyzed properly and admitted to be done thinking that this way will save time whereas this causes delays and problems.
When customer places an order to a vendor for procurement/ development of software application, intention is to get enhancement in business by way of process optimization/ improvement. Of course the finalization of a vendor has gone through a proper scrutiny and analysis process so as to arrive at a conclusion that the finalized vendor is going to cater to the requirement building in application.
Software application must meet with all standard norms of usability, fulfilment, ease, speed, features and results. Let us elaborate these customer expectations as below and try to understand them:
1. Usability: Product must be usable if expressed in simple terms. Why do we use anything in personal life? – To get certain output or result as per expectations. That is what is in business too. These expectations are nothing but a set of requirements (business or personal) meant to be met by the product when used to draw out in form of results. That means there is a deep relationship between any product, user’s expectations and results got by using the product.
2. Fulfilment: Product should meet a factor called completeness. Business requirements, design, ethics and aesthetics are the sub components that lead towards fulfilment.
3. Ease: Product must be easy in terms of understanding, usability and getting results. Screens, reports layout, navigation, terminologies used must be optimally compatible with the local language, management and users.
4. Speed: Working of product should be comfortable enough to cater to business, management and user expectations. Performance of product should be able to enhance overall performance of business, management and users rather than doing it otherwise.
5. Features: Product should have an extra edge over other products in the market to win over customer confidence and get is maintained and sustained for a long period. Product should be capable enough technically to cater to customer’s future requirements with least hiccups.
6. Results: Product above all qualities should be result oriented. Beauty, performance, efficiency, efforts, hard work, technology – all go hay wired if desired results are not produced by the product. Two main factors in case of results are – time and accuracy. Product must be able to produce results timely and accurately.
We have seen many software touching sky heights even with quite a less number of features and functionalities. We have also seen lot many software falling nosedive having bulk of features and functionalities. Is it the difference of simple and complex that makes any product successful or failure? Or is it the combination of some factors that make any product successful.
A simple calculator application can become as big a hit to fetch revenues more than expected by its developing company where as a high investment driven business application say an ERP can lose grounds even if it perfectly at par with other applications in the market.
What makes a product success or failure is a topic on which series of books can be written. Is it the product that creates the name of a company or is it the name of an already well established company that makes a product hit? Can a company sit on its laurels after making a product hit in the market or does it require an organization to be always on its toes to keep its market share intact for years to come.
A good product that fits in market demand today may not be fit tomorrow. Customer expectations keep changing with time depending on change in technology, other products, competition, risks and introspective or innovative ideas.
This is definitely a never ending discussion with more useful points coming with inclusion of more heads in the discussion. Please throw your opinion in comments section.
Customer will always be hesitant in declaring software project as complete by means of talking about more and more to be done in the software. This ‘more’ could be anything like functionality, requirements, confusion, frustration, appearance, performance and what not. Some of these ‘more’ can be addressed to easily if possible to take in objective manner. Sometimes this tactics is intentional arising out of many reasons.
A lot is said about customer – customer is never wrong, always listen to customer, your customer runs your business; and so on; which is not wrong. But there are times when customer may become adamant on some non realistic issue keeping in mind to not release some payment or not issue a project close letter/ certificate. If this is the case, it is happening intentionally on customer front. Basically such a situation should not arrive under any circumstances.
If a proactive approach is maintained, project manager can always foresee things going out of hands. An emergency meeting is required to be called immediately involving all stakeholders including top management members from both sides.
Customer may have a large list of concerns on the table in that meeting. First lesson is listen carefully and attentively. If you do that, you win half the battle. Keep jotting down those points or ask customer for a copy so that while he is sharing those points, you can keep marking your points against each of the issues raised by customer. After the list is completed, start with points where you agree to customer and accept the concern with a commitment to settle it ASAP.
Then start discussion of those points where you disagree to customer – put your contra-points and tell customer since you have agreed to so many points above unconditionally, these valid contra-points must be agreed by customer so as to close all issues.
A tester has to look at a product for testing purposes by getting into different modes (or rather I will say by being different avatars) to ensure his mission got completed successfully in terms of time, efforts and results. Though both – tester and developer work on same product but have different roles to play. Developer, on one hand is builder and admirer of his produce. Tester on the other hand has to ensure whatever was expected to produce has been produced as per the parameters decided. If both work on the basis of parameters then how come what a tester can see in that product is not known to developer or that gets ignored by developer. What differentiates between a tester and developer is the way they look at the product.
A tester needs to work on the product in a different way than developer so as to arrive at a conclusion (not arbitrarily but objectively) that the product meets desired standards and capabilities. How can he do it by being in the same frame of mind? He can’t. To achieve that he has to get into different frames of mind as listed below:
Perception: Tester needs to perceive business scenario in which the product is desired to perform efficiently and perfectly.
Physical: Check your perception existing or getting satisfied in real by way of the software produced.
Intellectual: Check out the business benefits out of what is being desired and getting performed.
Exceptions: Don’t forget to test out the exceptional business scenarios or cases that may be having a rarest of the chance to happen in real.
Customer: Think yourself as an end user to see if you really get satisfied by the way software appears, looks, feels, works, performs, gives output, etc. by logically covering its functioning, behaviour and aesthetics.
It is said that howsoever confidentially you keep information about what you have become, why and how it gets revealed at sometime or the other during your career growth. There are three stages mainly during your career as far as failures and successes are concerned. They may happen in a different order for different persons. One stage is when your failures overpower your successes thereby keeping you in a sublime stage. Second stage is when your successes are higher than your failures and then the failures get masked by successes. Third stage and the most important one is when you start performing without really bothering about the FEAR of failure or OVERWHELMENT of success.
The same three stages appear in any software product also. A stage where product is evolving will see more failures and less success. Gradually with increasing amount of handholding, research and experience; the product starts maturing and reaches a stage when SOME failures get overshadowed by LARGE amount of successes. Between these two stages there comes a crucial stage of ‘keeping hope alive’ or ‘leaving hope’ depending on which the further growth of product gets dropped or carried on.
With the same perspective if the life of a tester or developer is scanned they underpass a similar sort of trajectory. Initially a stage is not fully set for them to demonstrate. Rather it is a period of their acid test and learning. They tend ot make more mistakes though unintentionally while learning about their profession and professional world. Gradually a maturity level comes when they start getting more hits than misses. This is a stage when the performance comprises of more successes than failures as they have already burnt their fingers during the practical learning phase.
It happens in a professional lifespan too when a person out of fear loses hope to survive in their stream, surrenders and walks out silently. Professionals who are able to keep themselves away form this feeling, or are brave enough to fight with such situation are able to cross this barrier to brighten up their career.
Six Sigma focuses on defect analysis and measurable improvements in any process of the organization. Six sigma deployment does not talk about a model that needs to be deployed once that starts doing magic. It is more of a mindset and acceptance at all levels of the organization. Merely a separate set of people working away from the process seeking improvement can bring out any improvements by deploying six sigma. It requires involvement of all level of teams with a high level of involvement, commitment and engagement.
Six sigma focuses on financial improvement of the organization by means of implementation of it in any process or project. Nothing is subjective in six sigma project. Each and every step is objective and measurable in six sigma project. It does not demand use of high level of tools or resources. Objectives of six sigma can be achieved in monetary terms with very low investment. What is needs more importantly is a high level involvement and engagement, clarity of mind about problem, what you want to achieve (very important) and accurate volume of correct data to do the analysis.
A senior person from management need to get engaged on a regular basis in a six sigma project and must form an appropriate team of persons who are really part of that project for which the six sigma project is being undertaken. Any six sigma project must not go beyond a stipulated period to complete. Normally it should be three to six months but the period may shorten or lengthen depending on the problem and desired solution.
That is why it is always suggested to run six sigma for say one project rather than starting for all projects. Success of one project can boost confidence and the same/ similar process/ methodology can be deployed horizontally for other projects by making small team for each project.
Business world is quite familiar with this buzz word today known as “Lean”. Organizations all across the globe want to acquire this framework known as Lean be in sizing of organization or its working style. Lean mainly talks about optimization, high yield production, robust resource planning and utilization. Earlier it used to happen that for any new skill requirement in the organization, hiring of new employees in that skill set was prominent.
The concept has changed worldwide now. The same set of employees are planned to acquire multi skills over a period of time after recruitment so that on demand the same set of people can work on different project demanding different skill sets.
Probably the concept makes sense in terms of building a repository of skills in the organization without increasing the headcount. The same set of employees acquires different skill sets and depending on the requirement of project work accordingly. This strategy pumps in an extra amount of agility in the organization.
Time management, team organization, resource planning, and process optimization helps organization in advancing towards a higher level of result achievements. Chances of failures reduce under such circumstances. Basically business growth improves substantially with organization becoming highly proactive in managing disaster or risk, reducing fire fighting situations and achieving higher levels of satisfaction.
Project management involves budgeting, planning, execution and implementation. With help of Lean, a substantial increase in resource utilization helps organization in managing and maintaining any level of dynamic situations.
If process quality is in good shape it can put all sort of checks required to maintain project health and progress intact. A good process quality acts as a booster or catalyst to drive project in right direction without losing direction at any moment of time. Now, this can happen only if quality remains prime in mind of every member of the team and processes are coherently adhered to in a self disciplined and self monitoring manner. There are chances of missing something inadvertently but if processes are intact, this miss will not remain hidden for long.
And that is why wise people always say that even before the project starts, the process quality job begins much prior to that. Process quality is really very good in making everybody’s life smooth and hassle free. As said before, process quality job starts much before the start of project and goes on till finish and rather continues after completion of project.
If a question arises who maintains process quality, the answer should be everyone in the team. If everyone is part of process, everyone is equally responsible for its quality maintenance and sustenance. Definitely someone has to take a lead in establishing the processes and a regular review audit is important to enhance the quality of processes.
It is not necessary that process design and monitoring is done by the same team or manager. More important is placement of well defined processes in place and a QMS or quality management system to take care of it. Processes do not remain constant all the time. At times they need to be tailored as per requirements.
Most of the times the software delays are because of no proper requirements are gathered. Reasons of this could be many like lack of business knowledge of Requirement Gathering Team leaders, lack of experience, inappropriate allocation of time, wrong choice of customer representatives for understanding of business process and requirements and so on. In such cases the level of documentation remains below standards howsoever good may the expertise in documentation be.
Documentation of requirements apparently may look very systematic and structured in first go but once project teams start working for development and testing etc. they start finding out so many gaps and holes in the document showcasing a bumpy road ahead calling for repeated sessions of business understanding from customer and rebuilding of documentation.
Biggest fear in such cases is that if this stage crosses development and testing phase without any hiccups, it definitely does not ensure a healthy situation ahead. Rather it ensures that a volcano or tsunami was in the making during earlier stages is definitely about to erupt or break out soon during rest of the stages. And it could happen anytime.
UAT and implementation stages are most vulnerable stages in such situations where the hidden volcano bursts out when customer business process owner shouts out a flaw in software built to address to their business requirements. Those hidden major gaps unaddressed properly during Requirement Gathering Phase now spell out wounds badly on project.
That is why most of us agree that the most crucial phase of any project is Requirement Gathering Phase. If this phase is not addressed to in a micro level analysis manner, it may cause harm later to project, teams and managements.
Best way would be to vet and validate user requirements twice or even thrice spending a little time extra in beginning rather than asking for a higher amount of critical risks at a later stage.
How many of us will agree that whether it is project development team, testing team or implementation team, the title line applies to all. On road we all sort of people. People who are so disciplined that they never violate any traffic rules can be termed as category one people.
People who when under surveillance demonstrate themselves as the best followers of rules though in actual they may not be. Such people can be categorized in second slot. And then the next category is of people who are inherently violators of rules without caring about anyone or anything and these can be called as number three category people.
Similar are the team members in any team. It is better to have more number of team members who are self disciplined and systematic under all circumstances without bothering to demonstrate it to anybody. Higher number of such members in a team will definitely help in inculcating the similar culture among other members falling in the other two categories. Higher number of category two and three in any team will always call for higher amount of defects, bugs or shortfalls in their output thereby calling for more rework and more reviews.
And with focus shifting from project progress to addressing of reworks and reviews. This is definitely not a healthy position for a project and neither for the teams responsible for project. Another drawback under such circumstances is that those in the team who are otherwise consistent good performers start losing their focus and energy as they do not feel things going in the right direction. This in turn becomes another showstopper in overall project progress thereby deviating whole project to wrong direction.
Test Plan is a basic and fundamental document of quality department. It is project based document so has to be made afresh for each new project. It has not to be very thick document so that it does not become just a record purpose document in office in your drawer or shelf. On the other hand it should not be too thin to lose its sanctity and purpose.
Test Plan needs to be prepared as soon as the requirements study is completed and signed off from customer. Once requirements are there clearly on the table two parallel activities start immediately after respective team’s formation. Design and development team can start working on system design, database design, coding structure and so on.
Sideways based on the finalized requirements Quality department can start working on test plan. Test plan is a broader coverage of product testing at various stated that includes detail of various test methodologies and variants to be adopted or discarded and their basis of selection or rejection.
All testing may not be relevant for all sorts of products. Depending on whether it is server client architecture or web based product (which is more popular these days), test plan is prepared.
Usually it is QA head or lead who should be the owner of this document. Test plan clearly states various testing activities to be performed during various stages of product development. These activities have to be assigned to various team members along with a stipulated target date set to complete those respective tasks/ activities.
Quality Control as is evidently clear is a post facto exercise. It is something like finding faults or shortcomings in a product that has been built, manufactured or designed in its completeness. Drawback of QC is that it does nothing more than a post-mortem of the product. Whatever be the case, the number of defects identified in a product demand for exponential efforts thereby reducing margins, profits and time with an increase in input costs.
If effort estimations are calculated, the amount of efforts increase manifold with the development stage at which a defect is found in the product. Early stage defect identification calls for a minimal amount of efforts and will not have any substantial impact of delay in delivery. The later a bug or defect is identified, the worse it becomes for product, team and customer. It is quite clear that disassembling of a product for a defect rectification and then assembling it back to original always leave some gaps in terms of quality and productivity of that product.
The more number of times a product is fiddled with for fixing of bugs or defects more are the chances of it going downgraded in terms of quality and integrity.
And moreover QC or quality control generally is focussed only on end product, but pays least attention to the processes and procedures involved that drive product development. A very lenient or weak control on methodology, process and procedure of product development have higher risk of producing software with more number of bugs as compared to a situation otherwise.
There are ways to address the issues and there are ways to produce excuses for not doing certain set of jobs. The higher is the engagement of a process head in his/ her department’s day to day issues, the least are the chances of his becoming a Newton for his department or organization. A manager once was asked how he was available all the time with a sweet smile on his face seemingly having no tension and workload. His department was doing quite well as compared to other departments where the respective manager’s had higher amount of engagement in department affairs.
The manager replied with a smile on his face that he has three friends always to help in running his department perfectly well. Who were those three friends, he was asked back, that keep him happy all the time. He replied his friends are – empowerment, trust and well defined process.
The manager said his main focus remains more on timely results rather than scrutinizing of following process all the time for his team members. A steady flow of desired or planned results well in time speak well for process being in place. But that doesn’t mean that he never reviews processes. A frequency is set to review the processes in place and mostly it has to be an interactive session because feedback/ suggestion for improvement can come from any level.In between if there is any deviation in results, then also processes are reviewed.
Empowerment to subordinates is very important. Unnecessary questioning them time to time is not a good sign of a boss. Recruit sensible people under you, give them a leverage to settle down and then let them flow on their own.
Top sheet of a test plan must specify the project name, ID, detail etc. for which it is being prepared. At the bottom of cover page of a test plan do not forget to mention the creator’s name, usually it would be quality lead or head depending on the organization structure of quality department. Table of contents must segregate different important sections very clearly and precisely.
First constituent or component of a test plan would be Introduction. In introduction give a brief
summary of the product being tested
. Also outline the
functions at high level to be covered
. Next component would be objective and tasks. Objectives must be clear, crisp and bulleted. Tasks should be well defined, with target dates to achieve each one of them and assigned to whom.
In the next section define scope of testing, tactics to be followed, what is covered and what is not covered under the scope of testing. The next section is to be quite interesting, elaborative and can be termed as the heart of Test Plan. It is Testing Strategy. List out all types of testing you plan to cover, who will be conducting it, and what will be the methodology followed for each.
Then come two more important sections as Hardware Requirements and Environment Requirements. This information should basically come from the product head. Tester’s test bed preparation would solely depend on these specifications and therefore these specs should be as realistic as possible.
Next section would be about Test Schedule. This test schedule basically is a sub component of project schedule. Next to it would be Control Procedures which will take care of change requests procedure, problem reporting and solving procedure etc.
Next two sections will focus on Features to be Tested and Features not to be Tested. To avoid any ambiguity at a later stage of the project, specify very clearly these two sections. Next section takes care of Description of Resources involved in all above mentioned exercises with their roles and responsibilities.
Then comes the schedule of deliverables as far as testing is concerned. Mention all departments having backward and forward linkages to testing activities in the next section of Test Plan. In last three sections define Dependencies, Risks/ Assumptions and Tools list/ description.
Final section will contain the names of approvers that will include development, project heads along with any other heads concerned. It is important to keep everyone in sync throughout.
One fine day, Project Manager sitting in country X gets a call from his client in country Y. Customer’s Business Manager told Project Manager over the phone about their new requirement of over two dozen reports, the list of which he has just emailed. He requested project manger to go over the list in which he has clearly mentioned the detailed requirements for each report so that in case of any doubt project manager can get back to him. Next day morning, Project Manager ensured his customer’s Business Manager that requirements are clear to him and he will get the reports delivered in a stipulated timeframe.
There was no process in place for an instant recording of customer’s requirements in lack of which the things remained in the mailbox and mind of Project Manager only. Before he could take action on it and allocate it to his development team, he got engaged in certain other headaches and forgot to initiate this process. Gradually as few more days passed, this important mail from customer got buried over a pile of many other mails and lost its attention and visibility.
After more than the committed timeframe lapsed, there was a call from the same Business Manager to the same Project Manager asking about the status of reports. Project Manager was lost as it was more than a couple of months old story. He asked for sometime to get back to Business Manager, searched for that mail and was in a dilemma what to do as he had not taken any action on it.
He called his production team and thrashed over them over this issue. Production team was blank as nobody was aware about this requirement. In a state of emergency the reports were allocated in parts to half a dozen developers for finishing them in 2 days time. A commitment was given to customer that the reports shall be delivered within 2 days. For development of reports some were engaged in this project for the first time in order to tackle this emergency situation.
As expected, due to developers fresh to this project, shortage of time, lack of appropriate testing and unsystematic approach of Project Manager, the reports could not be delivered upto fourth committed date by which the customer was already losing its patience. And even the reports that were sent to the customer could not pass real business scenario due to wrong results produced.
Whom to blame? What lessons should be learnt? How to ensure this not be repeated again?
What Kind of Quality can you manage In your project if you don’t know well about your customer’s business and their expectations from the product your are going to build and deliver to cater to their business needs. Project management is very easy to perform as long as you have two close associates named ‘IGNORANCE’ and ‘LACK OF BUSINESS KNOWLEDGE’. But then the reward at the end of the project will be nothing but FAILURE.
Customer running his business successfully would decide about going for any software with a clear cut intention in his mind. The intention would be nothing but to streamline his business, ease his employees and associates on their efforts in managing and running their respective activities related to business.
Unless and until a project manager understands the intricacies of business and technology in regards to project development, he would not be able to do any justice to either project or to his role. Some of the indications in such a scenario would be as below:
2. He will be a dummy project manager on top of various teams without contributing much at team and individual levels. Things will be happening on their own thereby decreasing the possibility of success chances of such project.
3. Management would not be having a full confidence in such a project manager. Rather somebody else in the team would be performing his role thereby confiding with management in critical matters.
4. He himself would not be quite confident and satisfied even being howsoever smart to hide out his weaknesses.
Logically in such a scenario, if Project Manager feels he has reached to this extent, he must either upgrade himself overnight else quit. it appears to be an extreme situation which should be avoided at any cost.
Three major components that lie in people who build a strong product meeting business requirements and user’s expectations could be termed as – business knowledge, product knowledge and quality sense.
Quality as such is a subjective term unless you define it, measure it, drive it, sustain it and improve it. Let us see what all this means in simple terms:
Define it: Defining of your quality is as important as defining your project. This primarily should cover your broad vision of quality parameters defined for project, process of monitoring and measurement and course of actions in case of deviations fro set parameters.
Measure it: Defining is very easy though not simple but adherence or sustained adherence is difficult. Adhering to what is decided is painful though not for everyone in the loop. Without adherence there can be no monitoring and measuring. What was decided, what is happening in actual, how vast is deviation, what is the root cause of deviation and how to ensure that the same causes do not occur again to create deviations.
Drive it: Defining and measuring for one time is easier as compared to having a clear cut drive in the whole group or organization towards common goals related to quality approach. Unless and until things go into the blood of each and every individual, quality can be achieved on the basis of few.
Sustain it: People come and go, get shuffled in various groups, advance in career with change in responsibilities and perspectives; but quality drive is something that needs to be sustained as a culture in the organization. It is not time bound or limited to certain set of people of projects. It is an organizational goal that needs to be driven, groomed and flourished to a level where difficult things seem simpler to everyone.
Improve it: Nothing is ultimate, supreme, and best in this world. There is always a scope of improvement and excelling in any process of the organization. A regular monitoring, metrics, follow up and analysis process provides ample scope of improvement if taken seriously.
Most of the project managers would agree that it is not practically possible to adhere to written procedures and processes by hundred percent under all circumstances. Even if based on situational analysis and past projects experience, those procedures are updated on a regular basis, every new project brings out a new situation not met with so far in previous ones. For that reason most of the project managers agree to the point that it is important to be proactive and innovative during any project lifecycle.
Though life doesn’t stop even if a project manager strictly follows written procedures without any deviation provided those procedures are so well written and are matured enough to manage the complete project lifecycle. A project manager working in this pattern does nothing bad and it does not call for his project failure. Rather it is always better to follow well defined procedures in disciplined manner rather than defining them and not following them thereby making a mockery of them.
But it is well proven and experienced that project managers who have these two assets named proactive approach and innovation, and in case they fully utilize these assets, it is always giving them an extra edge regarding project progress and success. It is interesting to note that in a survey done among project managers, percentage was enormously high who agreed that being innovative is very important for winning over customer during a project. But the percentage fell drastically when it was asked how many of them actually deviate from their well defined procedures to explore an innovative approach thereby winning over a situation when it has come to a halt.
If you don’t know where you want to go, in which direction, to what destination; probably your sitting on wheels is useless. Equally harmful is if there is somebody else sitting on wheels and you are sitting beside taking charge of directing him to reach the right destination. If you have taken that charge and lack information about starting point, directions, road conditions, distance, how much petrol is there in the vehicle, where are you heading for; your motive is as useless as other person’s.
Same is applicable to Project Lifecycle. Whether you are a project manager or quality head or both; gasping about any of the relevant information or knowledge will drive your project to a disaster rather than a happy ending. One important question that arises many times is who actually drives a project. Is it the project manager, or the quality section, or management, or customer, or who? Is it really dependant on a single personality, somebody like a project manager, or is it driven by the whole project group comprising of different teams.
Ideally a project should not feel a single jerk with the entry of exit of any person on the train, how so important that person be. But in practical it really matters if the project manager vanishes for a substantial period during an important phase of a project. Something more to analyse is – are all moments during project lifecycle equally critical and crucial. Answer would be – NO.
If all phases and activities are equally critical then it could indicate a low maturity level of the organization as a whole who is managing this project. As the maturity graph goes upwards the management of different phases of a project also becomes easier.
Project base hiring of people or project based outsourcing of job is all dependent on project type and product life. An existing or a new customer may come out with a unique requirement requiring altogether different skill set other than existing in the organization. Depending on product and its fulfilment of business requirement, it will decide in due course whether the organization needs to hire a new breed of employees expert in those skill set or outsource this unique requirement development to a third party without bothering about the whole recruitment and retaining process.
If it is decided to develop the product in-house, probably as an alternative, existing bunch of some sharp employees can be thought of to be trained on this different technology to cater to customer’s business requirements. What factors will encourage on organization to outsource the job will depend on certain circumstances or factors. Conversely organization may go out for a new team building which also will depend on a set of circumstances and situations.
Factors defining outsourcing could be listed as below:
2. If the product is not too repetitive in demand from other customers
3. If organization has a good command and experience on outsourcing and getting the best output based on their past record
4. If there is already a shortage of high skilled persons in organization
5. If all highly skilled persons are already engaged in other critical projects and cannot be spared out for this new project
The factors to decide on doing it in-house by means of hiring new people or development of existing people will be more or less vice versa of points listed above.
There are three types of companies that exist in today’s world. First is having a great work culture but less growth prospects. Second type has good growth prospects but work culture may not be too attractive. Third type has both at its best. The fourth type with no work culture and no growth prospects will find it difficult to survive and hence no point in discussing those companies mushrooming for short tenure and then vanishing out of blue all of a sudden.
Logically it doesn’t make sense to say that an organization has least or no scope of growth but has a great work culture. And the same holds truth for vice versa too. That is it would be a misnomer to declare an organization as having great growth prospects but having worse work culture. Practically it may hold truth as exceptions and such companies do exist. But most of the organizations worldwide understand that if a good work culture has to be sustained for long, there has to be good growth prospects for its employees and vice versa holds equally weightage that an organization having a great scope of growth for its employees has to have a good work culture too.
The same holds truth for software projects too and the teams involved in those projects. If a good work culture is maintained during project lifecycle, chances of success of project increase. More successful projects means more growth prospects. The chain doesn’t stop here. More growth will automatically enhance the work culture further. And the same loop keeps going on and on.
Size and age of an organization does matter in certain key areas related to employee’s retention, growth, satisfaction, attraction for new good candidates in time of requirement of recruitment and so on. Though these two are not the only factors that matter for above points mentioned here but definitely these two points play a considerable role in that. In software industry there are two ways of running your organization. For example for development of a one time different technology product you will have two options – one, to recruit skilled developers and get that product developed in-house; second – outsource it to another company having matching skill set.
Recruitment or outsourcing is a crucial matter and need a deep introspection within an organization before arriving at any beneficial conclusion. In fact based on various types of projects that are being carried out within the organization, a proper policy can be put in place clearly defining a demarcation in case of any job to be carried out – whether by route of recruitment or by an alternative course of action of outsourcing to a third party.
A diversified short timed project requiring very different skill set than that exists in the organization will definitely call for frustration among team recruited for that project at the later stage after the project is over. The team, howsoever talented will find least scope thereafter to demonstrate their skills and hence will have lesser scope of growth as compared to the teams involved in regular projects in the organization.
Best way is to outsource such jobs but even if some high skilled manpower have been recruited they can be well rotated in other skill areas after the completion of their current one time project. Some organizations do recruit under those circumstances on project basis something like a contract. The person hired will stay in the organization as long as the project continues. Renewal of contract will certainly depend on similar project’s existence in the organization or other skill set in the hired person so that if being extraordinary may be absorbed in other projects.
Recruitment is something that always keep HR department engaged in any software company of any size, location or standard. Employee turnover is a continuous pain for that matter for HR that compels HR department to keep their database abreast based on the inputs from development and deployment departments. A requirement raised last time is of no value as compared to the current value in any department or organization.
Hr department is required to be well equipped with the data regarding current level of all employees existing in the organization, their profile, roles and responsibilities, experience, growth pattern etc. Not only that, they need to be proactive in terms of estimating appropriately about the employee behaviour on the basis of which they can very well judge about the commitment level of any employee towards his/ her job and/ or organization. The profile of an employee who has never spent more than two years in any organization in past will call for an alarm when his/ her tenure is reaching to that level in your organization.
HR needs to have a good network in terms of social networking site, media, some active relevant group networks, online and offline job portals etc. For that sake an internal survey about existing employee’s acquaintances becomes handy if maintained to initiate an internal referral recruitment process in case of a vacancy. Some organizations do not mind rewarding a nominal amount to referee.
Many organizations go for next level of maturity when they start rotating their employees internally on a regular basis. That acts as a two level benefit for organization in return. One – no situation becomes too critical in case of any key person’s exit as there is always a backup for that profile and second – it increases the confidence level of employees by gaining exposure, experience and learning in areas where they need improvement.
While standard process and procedures in place by project management committee at most times may overcome any hiccups but at times even a small disruption during project may tend to impede project progress.
During these testing times project committee may feel a need of the revision of existing processes in place so as to revaluate them rigorously to ensure project continuity in such happenings in future. Purpose of review meetings should always focus on strengthening of process and procedures related to project management methodology.
One of the prime purpose of a project review meeting is to ensure that overall progress of project has improved, which can be achieved by participation of maximum number of project stakeholders in such meetings.
Though time is important but equally important is wisely spend of time on important project issues during these meetings. Some burning issues may require extra review and extra spend of time which should not act as a constraint. Every review meeting should act as a catalyst for project and its progress.
Improvement, as wisely said, has no end. Improvement is a continuous process and at any stage of maturity there is always a scope of improvement. When I say maturity, it could be in terms of maturity level of an organization or maturity of your process and procedures for project management. As stated in my previous post, there is no need of panicking in case of any exit of any senior person taking care of project during running of a project.
Though it becomes more crucial if the exit happens at a later stage of a project but if there is some set of standard process and procedures in place, the situation can be managed with a small addition of attention.
During any software project, resignation by a project manager really becomes a regrettable position for whole organization. Someone is immediately required to react towards working to coordinate matters so as to designate his successor as the new project manager (ad-hoc or permanent) at the earliest possible time. No project can afford any discontinuity in its progress.
Irrespective of circumstances, there would be a number of processes running simultaneously in different phases of the ongoing project within same or different teams. The reviews and discussions need to take place on a regular basis under circumstances or even under all circumstances.
The approach of reviewing of project, on a regular basis, need to be carried out in an uninterrupted manner. This is important so that teams working on project do not lose their rhythm and momentum at any point of time. Segregation of tasks that need immediate attention in terms of technical assistance, extra resource, revision in targets, or anything else from the tasks going smoothly with no extra punch required is quite important.
Especially having arisen form such circumstances, there is truly an enormous significance in the process itself in which further directions are decided in view of the running project. This could be achieved through streamlining of running procedures that can be achieved well via smart documentation, regular reviews and proper distribution of responsibilities.
Equal engagement of all team members in project is important so as so is their involvement in reviews rather than discussing about project by a few top chairs behind closed doors.
Prime skill that a business or an organization requires in today’s scenario is a new way of thinking for their existing set of problems. The same thing is terms in many ways – a new way of thinking, an innovative thinking, an out of box thinking, or thinking beyond. Barriers are not set in problems or their solutions, barriers lie in our minds.
The same set of problems if given to different individuals is handled in different ways. This is the same way organizations work too. A project team can also be termed as a mini organization as a sub set of their overall organization.
No individual, no team, and for that sake no organization carry out their operations without facing problems. Recurring problems act as a pain in the neck of any individual, team or organization. It is merely a foolishness to keep getting recurring problems and wasting energies to fight them out again and again.
Energies that should go into new growth charters get consumed into removing the hurdles in path of that growth, which is not a good sign. It becomes daunting for project thereby leading it to a death trap rather than providing it with a spacke to flourish and move towards success flawlessly.
Every organization strives for increase in productivity and profit which is the ultimate goal and a reason of their prime existence. To achieve these two most trusted drivers are better quality and better service to the customer. Sustenance of good quality and good product does not suffice the purpose in today’s business scenario. The word ‘good’ needs to be replaced with ‘better’.
First delivery of a good product or service becomes bare minimum expectation for your customer the next time. Next time delivery of service of product has always to be something extra than the previous delivery in your project.
Every organization has a maturity level. This level defines or controls a level of that organization to acquire a capability of solving problems. No organization at any level of maturity is strong enough to tackle all problems, every organization faces two sets of problems in their agenda – one that are solved immediately for which the organization is capable enough to manage, control and solve; another set of problems is that organization is not able to solve easily.
To manage such ‘not too easy to solve problems’ the organization needs to be innovative, daring and bold enough to carve out new path to find out an optimum solution to such problems. The same applies to each of the teams existing in that organization which further applies to each member of those teams.
Maturity level or capability of solving higher level of problems in an organization is nothing but the collective maturity level of each individual of that organization. After all organization is nothing but a group of teams comprising of individual members.
Merely on the basis of a strong management with high maturity level, an organization cannot boast of having a high maturity level. Every task is not done by the top management but most of it goes further down to an individual level in different teams.
Therefore, the most valuable asset of any organization is the minds of their employees. This is where the role of top management’s role comes into picture – to harness, master, control, drive and empower these individuals.
A lot of juggle has to be an expertise area of any project manager during managing a project. Project without specifications has no meaning. But even if there are well defined specifications which are not adhered to also becomes as meaningless as running a project without specifications.
Specifications are required to be defined for any project. Specifications in terms of project requirements, customer and business needs, team formation, technical requirements, budgets, targets and milestones, and so on. Once these specifications are there in place, they need to be adhered to ethically without any fail or deviation.
Deviations do happen in any project and nothing goes as straight as planned or thought of. There have to be specifications on how to manage those deviations. A proper risk assessment and management has to be in place to manage change, deviations and failures.
This all comes under compliance. What if your customer gets something weirdly different from what he expected from the product you built? How frequently in your project do you face a blush off situation in front of your customer for a large amount of variance in inputs and outputs consistency as compared to the specifications?
Testing coverage specifications is another area that can overcome all these sort of blush off situations. An ad-hoc testing is always a blunder as compared to a well planned testing taking into account the complete coverage of product in question. Testing coverage is nothing but quantification of the areas of system to be tested with how much rigorousness. Serious areas of product having high impact on customer business need to be tested more thoroughly with no scope of leverage.
a perdurable a day, helps you sleep, work and play
Your project dashboard is very important during project management and equally important is its visibility. Purpose of dashboard is not merely for the sake of its existence. Purpose is much more beyond its purpose of merely existence.
Your dashboard must be a report card of your project at each stage of the project. It should be showing metrics of your project performance highlighting the red areas very clearly that need immediate attention. Project dashboard also must have a capability of drawing performance trends – activity wise, individual wise, task wise and team wise.
Take care that your dashboard must update regularly, should run faster, and quicker. It needs to be maintained less expensively with least complexity involved in maintaining and updating it. Don’t forget to have a count of failures on your dashboard.
Technical and functional team’s confidence in any ongoing project depends heavily on their past performance and performance trends in previously closed project and also in the closed tasks of the current project.
A good performance trend in the past always acts as a booster in their morale and confidence at any moment of time. Habit of failures goes less that way thereby mitigating any upcoming risks in a project.
Adopt smart and innovative way of decision making during project management to enhance your team’s capability. Put your team in a position where each team member is dedicated towards a rapid response mechanism. At each step of your project check out the factors that may lead to project interruptions due to any level of functional and performance issues.
To manage your projects across their lifecycles, a project manager needs to learn and adopt a well managed and integrated project, demand and portfolio management methodology.
Is QA, or for that sake QC, an expense or an income for an organization engaged in software development commercially. A step further would be to ask if software development itself is an expense or an income for the same organization. No software is built for charity purposes by any organization for a longer period.
It can be done only in a hypothetical situation for an organization having a regular funding from some other source or another group of the organization. Otherwise an organization having infrastructure and people in place to run a business cannot afford to keep developing software applications without any sales targets with stipulated time frame in mind.
Coming back to our point if QA/ QC costs being incurred for software application development and trying to find out how these expenses are accommodated. To ensure that the right product gets launched in market with least negative impact on organization’s reputation due to application failure, its thorough testing becomes prime goal for any organization prior to its launch in the market. Formidable reputation jerks at a later stage after launch of product in the market cause much severe damage as compared to the expenses incurred well in time to ensure perfect quality of a product before it is launched in the market.
If quality of a product is achieved by any organization for their product to be launched in the market as a signal of obligation to their customers, it is a fake call. It is actually for their own sake that organization spends on ensuring best quality product getting developed in their process of development lifecycle.
Costing of a product must be done accordingly to accommodate expenses incurred on quality of product during development and deployment phases.
A good quality product always brings back hike in reputation of organization and increase in order booking from further new customers. It is overall quality of product that returns back higher organizational income in terms of high volume sales and more orders for their loyal customers. Trust and loyalty go hand in hand. Organizations that are able to build good amount of trust with their customers get their loyalty in return. This all pays in manifold that sometimes goes unnoticed by the organizations.
If there is a choice between mitigation of expense of running Quality department in your software development centre versus risk of service interruptions; later is always carrying a higher amount of risk as compared to former. Spending few extra bucks on quality to ensure an extra amount of product stability is always beneficial over the later stage service interruptions caused by higher volume of bugs getting encountered thereby causing more frustration at customer end.
Let the pain be shared internally before the launch of your software than getting the drums beaten outside by your customer after its launch and deployment.
Well planned initiatives related to achieving higher quality of product during development in an organized manner is always better. This can be achieved well with the help of continuous micro level monitoring and inspection of product during its development to ensure desired integration and quality of product. This will automatically reduce the risk of service and product interruptions at later stage after and during product deployment.
One of the best ways to reduce product downtime is to launch a bug free product. More bug encountered at later stage after product completion and its deployment at customer site will demand large volume of bug fixing, testing, re-testing and down time. This will automatically reduce downtime costs thereby giving a boost to developer and tester productivity.
Proper synchronization among your team resources into a test that enables you to delivers best quality product is always wise to do right from the beginning of project. This will help organization in getting development, testing, and other teams to work together towards a highly reliable product.
In today’s scenario there is no life on this earth without its dependency on any software in one way or the other in professional or personal front. This is what technology and its advancement does, it makes us more dependent on it by providing us more accuracy, comfort and satisfaction. We do something only because we have some trust in it towards the desired results. Same thing happens with our customer also.
When customer buys or orders for a software to us, there is a essence of trust and loyalty hidden behind it in wake of a timely solution that works properly, accurately thereby giving a high level of comfort to customer.
Software that helps customer in getting desired business results definitely increases their satisfaction level. Some points need to be followed while building software for your customer that can be listed as below:
2. It may happen that something unique for the first time is being developed for a specific customer need. But that may not be the case always. In case of horizontal deployment of your software to a new customer, ensure to produce a detailed list of your installation of the same product. Claiming all installations as 100% successful would be something easy to raise customer’s eyebrows. Start with your most successful installations depicting most satisfied customers but do mention some failed installations and their reasons so as to raise an alarm in advance.
3. Ensure to understand your actual efforts involved before submitting a commercial proposal to your customer. Understand customer business and their requirement/ expectations from the software you have to build/ supply very clearly before any getting into any commitments. Ensure about the flexibility limits required in the software as per customer’s expectation. Understand the difference between plasticity and elasticity.
4. Listening to your customer about their business process, pains and expectations is more important than boasting about your product and its capabilities. Before you understand first what customer expects or address to his which business pains, your songs may be irrelevant and may go unheard totally.
5. Demonstrate by way of doing. A well designed presentation about your product and its capabilities may win customer’s hearts but will never be able to run their business and address to their requirements. That can be achieved only by way of software application.
With technology changing every minute, it looks as if we have covered galaxies of distance in last decade or so in terms of advancement in development tools and features. Definitely hardware need to be advanced accordingly to support the resource hungry features built in development tools. Specializations are a defining factor in today’s software development world.
It is not that any development tool will fit in for any software requirement from customer. It requires a complete mapping of hardware, software and peopleware in current scenario to arrive at an optimum solution heading to a win-win situation.
To develop specific software, there need to be a right mix of technical team members. Database administration, database configuration, software development, technical documentation, software testing, software implementation, database and application installation, customer training, customer support and so on are all a mini project in their own spheres.
All these mini projects size up together to build a complete project. All projects are divided into different phases. All phases cannot be started or finished together. Some would be possible to run parallel while others would be sequential in nature. For example software development, server configuration, database configuration, technical documentation can all be started together. While training to customer cannot be imparted without actual software to be implemented at customer site be in place.
Team formation, team coordination, monitoring, follow ups, target setting become prime important to achieve project success and build a strong bonding within teams, with management and with customer.
During different stages of project management, training is an important tool that is used to gain best results of the effort put in project. Be it customer requirements, development, quality, deployment or support; training remains integral part of each phase of project management.
Training contents and appropriate tool/ methodology to be adopted for training depends on various factors such as:
2. depth of subject,
3. knowledge of speaker,
4. volume of audience,
5. time allocated for holding training session,
6. mix of audience
7. and experience of trainer.
There could be many more factors too as per different trainers around the globe.
Methodology to be adopted for a particular training depends on above factors. Various methodologies commonly used in a structured manner for imparting effective training can be listed as below:
2. Lecture: /lecture and presentation are different in the way of more emphasis on speech and by way of writing on his own by trainer during the training on a black or white board to keep his audience alert and interactive.
3. Group Work: This is something like a workshop where learning is done by way of doing in an actual manner.
4. Case Studies: A very non interactive way of training where material is handed over to the trainees to read and learn from there.
5. Feedback Session: This is not actually a complete training methodology but a post training session to gather feedback regarding the training imparted to trainees.
Running a business is nothing but a composition of certain processes in place taking care of all elements important for the purpose of business. Growth of business happens with maturity of processes in place. It does not mean that to run a high level business you required complex processes. Even with the help of simply drawn processes you can establish a high level business. In fact sometimes more complex processes defeat the reason of running a business and become a cause of disaster of business.
To control well defined processes in place, a top level body is called in the organization that is termed as management. Management has to ensure two prime and foremost factors to establish and run a business for long term. First objective is to have well established processes in place and second but more important factor is to ensure those processes being followed all across the board. More control on business processes makes more efficient management; and vice versa. To have good processes in place and to ensure their adherence you need a good management. On the other hand to have a good and efficiently result oriented management you need good processes in place.
Effective and efficient go hand in hand that way. More effective business processes result in more efficient management and organization. More efficient management will always seek more effective business processes taking into consideration some world class benchmarks to set their goals for further optimization. As it is well said – improvement is a never ending process, the same holds truth for business process too. No business process is optimum or 100% efficient. It always has some scope of improvement.
As a new project gets into project initiation phase a formal project strategy is important to bring on board. Team size, team members, financials, operational and all other planning need to be worked out based on project strategy. It clearly signifies that a wrong strategy would lead to wrong direction altogether heading to a big mishap at a later stage.
Team size and team members’ selection is something that needs a very in-depth analysis before finalization of the two sections. This is important because all other factors like capital investments, operational cost and planning etc would depend at large on these two sections.
Although team size and composition changes in between during different phases of a project. But the change is mostly not major one so as to impact highly on initially planned numbers.
Generally organizations that perform at an optimal scale like to analyze multiple scenarios with the help of latest technologies so as to have a smooth ride at a later stage. Different scenarios and their results if analyzed initially help with a quick and rapid change at a later stage with a change in scenario.
For a multiple location implementation in an organization, it is recommended that to do it in a smarter way, an enterprise wide integration planning process right from the beginning would help in a bigger way thereby decreasing start up and deployment costs. An integrated way of planning, budgeting and forecasting helps a lot.
Budget and plan forecasts may be avoided to go haywire at a later stage if uncertainty is removed with the help of latest technologies and large number of scenario modelling.
Total involvement is something which is not visibly tangible but there are ways to do so thereby spearheading any project towards higher rate of success. For example same software being implemented in different organizations has different rate of success. At some place it may be a very successful implementation leading to very high rate of drawing of targeted results while at other place the whole implementation may become a disastrous failure.
Only differentiating factor is ‘total involvement that makes a big difference of success and failure of the same product implementation at two different locations. In between the two – hundred percent success and total failure – lies different success (or failure) rates depending on the degree of ‘total involvement’.
On top of different level of teams in any project management process, there need be a team named as Leadership team on top of all teams. This team may comprise of members from all other teams or may have a different set of members altogether. But the main task of this team remains same – spearheading all others by being fully charged and motivated all the time.
A transparent accountability process also plays a major role during project management during all phases especially implementation phase. Exact deliverables during implementation phase must be clearly defined so as to treat it as a checklist for both teams. Deliverables break down further to micro deliverables that lead to each team’s charter, customer engagement, scorecards, process mapping etc.
Customer feedback is another important tool that not only keeps you aware and alert but also tied up tightly with customer. Just a word of caution here is that never let feedback be too formal or too informal. Let it be realistic and transparent rather than just a formality activity.
Change is generally not welcomed in any system and is treated as problem. Change management is full of obstacles some foreseen and some unforeseen somewhat similar in nature as that of project management. Project manager need to overcome a number of obstacles and hurdles while project development and implementation. Software implementation is also a part of change management as it requires a number of changes in the organizational culture and its business process.
Ownership, commitment, motivation are three major obstacles that come in way of project manager in terms of the organization where project implementation takes place. Everyone in organization welcomes new software to be implemented for easing out business process functioning but there are equal intensity of resistance too which is sometimes not visible openly though has a full existence in place.
Changes in terms of technical environment are easier to impart during product implementation across an organization as compared to the culture changes. Total involvement with a top down approach works better in any implementations as compared to a bottoms up approach where top management is not engaged in the process.
‘Learning by way of doing’ and ‘Demonstrating by way of doing’ are two important tools for managers to confide their teams during an implementation phase. Just do and demonstrate rather than demanding the same set of action from employees down the line.
This way of implementation increases trust factor across not only among different levels of management and other staff but also in the product being implemented. That way it automatically increases the level of commitment and engagement.
A good writer is one who pays equal weightage to proof reading or editing of his work besides being focussed on content quality and writing style. For every new work that a good writer produces, he doesn’t mind spending some more time on it and getting some different opinion on what he has written. The great author Hemingway always had his books edited and proofread before giving it a final nod for publishing.
Similar approach must be inculcated in a tester too as far as bug reporting is concerned. The way a bug is reported may not be understood or interpreted in the same manner by a different set of eyes reading it with a different frame of mind.
In bug report, a tester knows clearly what is intended to be reported from his end. He might explain about a bug thinking it as the best way to communicate his purpose. A developer on the other hand as a different entity may understand differently to what tester intended to communicate and thus may take a different meaning that may lead bug fixing to a different direction.
Definitely in case of a doubt, when developer seeks clarification from tester about a bug, things would get clearer removing out all gaps in intention of report and its understanding. Bug reporting is always an interactive process. Logically after reporting a bug a tester must leave report as it is without sending it to development team. After sometime tester must come back on the same report that he left, read it as a developer would read it. This way of editing with a virtual different pair of eyes a tester would be able to seal any leaks in his bug report.
Rereading and editing of report is in no way a waste of time or effort comparing it with the time or efforts required later in wake of unclearly reported bugs. In a broader way, it can be treated as a quality check of bug report.