Requirement Coverage: Requirement gathering and its documentation both need to be crisply and completely covered. Any lack in either of the activity is like a volcano in the making. In fact 88 percent of project failures worldwide are due to wrong or incomplete requirement study.
Team Selection: Development team need to be wisely selected keeping in mind – too many cooks spoil the broth. A mixed level of developers always keep better harmony in the team than having all of same level.
Development Plan: A proper plan with clear cut assigning of responsibilites along with target dates mutually agreed upon has to be in place without which no sailor will move the ship in right direction.
Quality Control: Each step testing is an important factor. Don’t wait for the product to complete first and then start testing. That will be a sheer wastage of time, efforts and resources. A side by side testing draws out better results.
Quality Assurance: Some benchmarking and standard processes need to be in place and to be followed to ensure a quantum control over the situation. Else nobody will be knowing what processes or methodology to be adhered to for ensuring success at every stage of the project.
Stakeholders/ Customer Engagement: Most of the time there is a wide gap between development team and other stakeholders/ managmeent/ customer representatives. This gives a big opportunity to development manager to misguide management about the progress of project or projecting the situation as per his comfort. This does not go healthy for project in a long run.
Software development comprises of various stages and components. As software development is a subset of Project Management; there are many similar components of Software Development Management. Some substantial components of Software Development would be –
• Customer Requirement
• Time Management
• Quality Control
• Quality Assurance
• Task Management
Covering these stages of Software Development Lifecycle following is the listing of some articles/ blogs for the purpose:
An extra mile of testing effort spent at initial level saves lot of efforts at a later stage. Minor hiccups passed over to customer too sometimes create big issues depending on their frequency and volume of occurrence.
Imagine a small fly in the sweet dish being taken by a customer after an n-course meal will create a big havoc for any good restaurant. It is different if customer acts as blind and ignores a small piece of hair found in the meal thinking that his own hair from head might have fallen in the dish while having his meal.
Similarly a user sometimes ignores a minor error encountered while using an application thinking it might have occurred due to lack of knowledge about the usage of product. User might think during initial phases of product usage that probably the problem might have occurred due to his non adherence to proper steps following.
A business comprises of different software. These software applications comprise of two business streams – business critical application and business supporting application. Usually business critical applications cover ERP like main stream application. Business support applications may comprise of legacy applications or side stream applications running standalone or interfaced with mainline business application.
The emphasis on level and type of testing solely depends on the nature of software under the scope of testing. All software cannot be put under the same frame of testing. It all depends on coding structure, interface, web based architecture or similar parameters that define the test strategy of a software product.
Testing during development, and at the end of product built too vary as per norms. The last testing phase prior to product release has to be extensive, elaborative and exhaustive in nature.
Tester is not the part of package of a team going for software product implementation. Probably that is wrong on part of project manager if he decided to send a technical team member along with implementation team with a sanction of development and requirement changes onsite.
Well actually there are two scenarios of catering to changes and development onsite. One way is all changes required are documented well and signed off, sent back to back office support technical team for development with a stipulated timeframe (which is definitely in hours or not more than 2-5 working days). This exercise of development includes testing in a proper manner.
Another scenario though would be less time consuming but more risky as developer(s) are there with implementation team but no tester(s). In this case the development (changes) part will be done instantly and onsite itself but the risk factor or vulnerability is higher as testing (if it has taken place) is done on site and that too by non professional testers. The product may behave ok in this case in first go and pass through UAT too by users. But in reality such extensions of development always have higher chances of carrying hidden bugs that may expose sooner or later thereby reducing trust factor in product.
I have not seen any implementation without a requirement of changes in the product to be implemented. But it all depends on so far well tested product management at this stage – if the changes take place offsite (back office) with same established way of testing (may be by consuming a little extra time); or catering to it onsite by developer (in a shorter time) with no proper testing.
Support comes after project completion. Project lifecycle but must treat support phase as a component of it. Prior to support the major project phases include – project initiation, requirement collection and freezing (though freezing is not actually freezing till the handover and sign off), product development, testing, implementation, pilot, live, sign offs and handover.
After the successful completion of above phases, implementation team leaves customer location in a typical situation.
That is the time when product is totally in hands of end users who start utilizing their product knowledge acquired so far. The practical phase is not that simple as lot of unexpected surprises start happening during this period. Some of the errors encountered by end users actually are not product errors but arise due to wrong or inappropriate usage of product. That is not unnatural. Since the end user start working on product on their own, it is something like a new player playing in his first match, or a person who has learnt driving afresh is driving on road for the first time all alone.
Support team has to be quite patient giving top priority to ‘voice of customer’. Technically and functionally, support team may know that a wrong complaint is being registered, but it becomes their prime role to guide end user about the right usage of product step by step without hurting his feelings or making him realized as wrong.
On the other hand if support team gets a change request in the already running product, at times, due to time crunch, it becomes important to handover the change developed without appropriate testing done by test team. But in the parallel line of action, the changes in product must be handed over to the test team with a stipulated time frame to ensure that the changes are done appropriately.
SDLC-I: Software requirements – This post talks about Software Requirements. Software requirements itself required a standard process or procedure to be followed and can’t be managed in a haphazard manner. The process must start with an initial discussion which may happen from a distance via any good communication media if client is far from vendor. Once the initial discussion gives comfort to both ends – that is – vendor feels comfortable on a broader scale to provide a solution to the customer and – customer feels comfortable that vendor is capable enough with a outline solution ready to cater to his solution.
A next level of meeting is scheduled only after first level of discussion shows some significant positive outcome. This next level of meeting is better result oriented if takes place at customer’s location. This meeting requires substantial time to be spent to gather customer’s business requirements that need to be catered to in the software application to be provided to customer later as an optimum business solution.
During this detailed meeting that is carried out by vendor’s business functional leaders along with customer’s respective business function leaders remains incomplete if the whole discussion regarding business discussion and business requirement is not documented properly.
Along with documentation, vendor team must collect all forms and formats in printed, handwritten or whatever shape with proper mapping and understanding.
Once the requirement is gathered, documented and finalized must be signed by customer business process heads and thereafter by overall business head of the customer to own the responsibility that whatever has been told and documented is what they require to be built in the software.
I think anybody who is in software industry must be familiar with the complete lifecycle of software. Here is a treat of seven blogs in a row on the same very subject of SDLC – that is software development lifecycle.
Here is a segregated list of my blogs on testing mainly for the purpose of people enthusiast in testing, testers, QA, QC, bug management; and software Quality:
The post ‘Twenty ways to ensure complete coverage of software testing’ can be treated as a checklist for ensuring complete coverage of testing of any software. It talks about some basic fundamental but critical and important steps to take care of for the purpose.
Purpose of testing is not only to ensure reporting of bugs in a proper manner, complete coverage of product vertically and horizontally both, and ensuring that critical bugs are taken care of. Test team must also ensure timely reporting back of bugs fixed from the development team so that they can one more go over the complete product to verify that all bugs have been fixed – properly.
Test team while ensuring fixing of bugs through their verification cycle must also ensure that while re-writing or varying the code, development team has not developed any new bugs during the course of their action.
There could be various ways to ensure complete coverage of product, proper identification and reporting of bug; and validation of bugs fixed etc. depending on level, automation, and methodology adopted but checklist can become handy in any case.
Why Software Developers are not Doctors? was another interesting read to understand the satire behind the simple title line. Software developers are quite famous (and that is not in good sense) for writing a code that is never perfect and bug free. That is why any code written by a developer or programmer has to undergo scrutiny under tester’s microscopic eyes to find out the hidden bugs and thereafter fixing them by developer.
Definitely this whole gimmick of identification of bug, its reporting and then fixing by developer takes time. Not only this, when a developer fixes the bugs, the tester has to retest the code to verify the fixing of bug and identify if there is any new bug encountered due to change in code.
Story does not end here. A small change in code at one place of a software product may have its serious and many places impact if not handled properly. That is why the first wish of any developer from himself is to become a bug free coder which is very rare to find.
The satire very well remarks on this particular nature of developer of not writing a bug free software in first go which implies that if a developer had become a doctor, he would definitely be a failure as each of his patient would never have got cured in first go.
Do we mean to say that whatever a doctor prescribes to a patient need to be examined by another person (doctor-tester) before patient starts taking the medicine?
‘How Software Testing Took Birth’ would be an interesting read if you have not read it earlier. Give it a try to this small article that provides and insight to some very basic fundamental reasons about necessity of testing of software.
There would have been a time many years back when there was no concept of testing altogether. The software would have been produced and given on as is where is basis without any guarantee of its behavior or results produced by it.
Gradually a need would have arisen from both ends – customer and vendor to maintain a decorum, sanctity and reputation of software producer and software being produced.
Probablity in early days when software product cocept had started, software development would have been more of an experimental and adventure case rather than a serious business product building concept. And gradually when reliability on software increased, its necessity of providing a neat bug free product also would have arisen.
Each bug in the software costs. The first hidden cost is the developers time that could have gone in a neat code, except goes into embedding a bug in his code. This all happens unnoticingly. No developer intentionaly writes bugful codes. It happens inherently due to a set of fixed development creiteria or pattern in developers. A blog about ”A Linear Approach of Cost Estimation of Bug Fixing for Various Software Projects” focuses on need of estimating or rather evaluating overall cost of a bug right from its insertion to identificaiton to fixing to verification.
When a developer fixes a bug there are some chances of not fixing it completely, or generating another bug while fixing an existing bug. Similarly a tester while testing a software also has a chance of leaving a bug unnoticed, or identifying and reporting a bug wrongly. In either case it it the product and project that suffers most. A tester needs to be extra careful while testing whereas a developers needs to be equally careful while writing code. While verifying a bug fixed reported by development team, the tester need to ensure not only the reported bug fixed but also ensure that no other negative impact has arisen.
For that purpose a tester needs to adopt another approcah discussed in my earlier blog titled – ”Progressive Software Testing Approach by acquiring Soft Skills – Step by Step” in which an emphasis on certain essential soft skills has been highlighted that becomes catalyst to software development and testing process.
When I started blogging on ITKnowledgeExchange.com under the blog title ” Quality Assurance and Project Management” in the middle of the year 2008, I wanted to pour out all my experience on Project Management, Quality Assurance, Quality Control, Team Management and other related subjects.
My foremost pain was and still is the way developers develop a code or write a program. Though all developer are not alike, but one thing consistently I found was the way coding is done, it always leave a scope of bugs. And based on that pain my first blog was titled – “What stops a Good Programmer from being a Good Tester – 8 Reasons”. I wanted to highlight the top disciplines in absence of which a developer always leaves a scope of gaps in his coding.
Then came the next post regarding how a tester should work to get the best out of his scope of work. Some top reasons were discussed in my next post named as – “Knock! Knock! – it is tester here!”.
Tester in his own capacity is helpless as far as product neatness is concerned. To know about what exaclty is required to be tested, a tester requires a good knowledge of business requirements based on which development team has built the product. Testers basic purpose in my opinion is to ensure that there is no gap between the business requirements and the product being delivered, and use comfort in using the product.
There is no doubt that if tester has lesser or equal depth of knowledge as develper about business and product, he is also prone to leave gaps in two ways – either by testing the product wrongly based on wrong business assumptions, or by reporitng the actual business scenario insufficiently to the development team.
Usually it is not the developer’s fault if he build bug in addition to writing code for any application, The seriousness of application may vary from business point of view, the way that application is going to cater to the business management. Even a game code for a gaming company could be as serious as a banking application code for a financial institute.
In both the cases – game or finance – bug can’t be tolerated. First instance to check the bug is the way of acceptance or acknowledgement of bug by project manager, development manager, and management team. High level of acceptance give higher leverage to developer to chip in bugs during code writing. A developer by checking on his some of the qualities may become a good tester of his own code. And if that happens, the developer in turn will always become a better developer.
Second instance of check and control is the leverage given to project team to keep tester far away from product. A tester though needs to knock development team’s door repeatedly for certain set of requirements to perform his duty properly and also to justify his task of testing the product in terms of product release.
Project Team should have a way of measurement of time and money for each of the bug reported. If each bug fixing is measured from its evolution, reporting, fixing and validating cycle, an objective approach can certainly ascertain a value to these efforts.
Every Bug has a cost to fix and for that sake to report too. It takes someone’s time (tester’s) to find out the bug in a software product. It takes another piece of time to write and report it to development team who in turn is responsible to fix the bug.
Fixing of Bug again takes time as developer needs time to understand what wrong has been built or what scrap is to be removed and in its place what useful code is to be written and kept. There are various approaches to calculate the cost involved in this complete cycle.
The bug reporting and removal cycle does not stop with reporting by tester and fixing by developer. The rectified piece of code goes back to tester again to verify and confirm that it has been fixed. Tester has further to investigate and confirm that while fixing of this bug, developer has not created any other bug that impacts application functionality or usability.
An approach known as Linear Approach of Cost Estimation of Bug Fixing for Various Software Projects can help project team in ascertaining the preposition of accepting a leverage of developing bugs in software in place of a neat product.
There are seven instances when a tester need to knock to Project Manager for certain requirements or help from him without which his role as a tester cannot move further. Any lack in those assistance to tester will certainly mean lack in delivery of right product/ bug free product.
For isntance a tester certainly require business requirements document to understand what initally has been asked by business owner to build in the software viz a viz what actually the product has been built by development team.
Around three years back I wrote a post relevant to the same subject I have discucced above primarily talking about the crux of the requirements by a tester to justify his work related to a software project. The article was titled as ”Knock! Knock! – It IS Tester Here!”
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.