Quality Assurance and Project Management


August 31, 2010  10:43 AM

Think Beyond Project Management



Posted by: Jaideep Khanduja
change management, development management, issue management, Project Lifecycle, project management, requirement management, Software Project

Project Management is not everything related to the management of a project. It is absolutely not the end of the road. If you have a well defined project management methodology (or different methodologies for different project types actually), it never means that just the regular reviews of these methodologies will make your project’s life smooth. Project management and organization continuously need to think beyond the horizon of project management to look into the galaxy and keep exploring the new innovative ways to enhancement in the existing processes and methodologies.

The success of project depends on an absolute success of each of its phase which further is divided into that phase’s milestones. The adherence to timeline and budgetary targets need to be adhered to in order to achieve success in any project. Project management though comprises of different phases starting from project initiation till the project implementation, handover and final sign-off, requires different skill sets to mange each of the project phase.

If we look at the major areas that are required to be managed in a systematic and specialized manner, those would be:
1. Requirement Management: This is most critical phase of the project requiring specialized business analysts having a strong visionary knowledge about the business, product and documentation. Lack in any of these skills would impact on the total flow of the project lifecycle.
2. Development Management: It requires a good combination of skill management, team management, time management, task management and talent management. The development manager need to be a master of all these skills to get an edge over the timely delivery of the product.
3. Test Management: Test management requires an altogether different skill set. The test manager need to be proactive, innovative, intuitive with a good knowledge of the business and product.
4. Issue Management: No project progresses without any issues. A systematic approach to manage an issue helps in managing the project in a better manner.
5. Change Management: Changes to happen during a project, change in team, change in deadlines, change in product requirements, change in management perspective, change in strategies, change in plans and so on. A proper well defined change management process helps in managing the change smoothly.

August 31, 2010  10:01 AM

Six Visionary Tools For Project Management



Posted by: Jaideep Khanduja
project management, project manager, project team, Software Project

Without a vision, project can never be managed. Without management a project has all chances to go out of control. To have full control over the project during all its phases certain visionary tools are required to overcome obstacles. Different teams are engaged during different phases of the project. Many teams have to be vertically and horizontally coordinate to make each phase a success to jump over to next phase. Certain phases overlap during the project lifecycle.

The teams harmony and coordination (inter and intra) are the two most useful keys. Team members are responsible for their individual roles. But they need to rely on their peers across other teams to progress. Project success, on top of all other motives, has to be supreme and universally acceptable to all teams. Stakeholders and top managers play a major role in achieving these goals.

Some important visionary tools in that regard, can be listed as below, which if adhered to in right manner, help in achieving the desired results at all stages and thereby providing a grand success to any project. Irrespective of project methodology or processes adopted in project management, these tools act as catalysts. The tools listed below need to be adopted and absorbed in all teams across the project board. The tools are:

1. Purpose Clarity: Project purpose must be very clearly defined right in the beginning of the project. Without a clear cut purpose, corresponding goals can’t be set. And without goals, no objectives can be achieved.

2. Vision Sharing: Top management and stakeholders have their own vision for any software project. The business goals and organization processes to be controlled through this project (software) must be clearly defined. The short term and long term vision must be shared with all the teams involved in the project.

3. Clear Responsibility: Purpose, goals, vision, targets etc. are important, and equally important is to clearly definition of responsibilities. Ambiguous or unclear responsibilities may lead to lot of confusions and ultimately a big disaster.

4. Mutual Harmony: A team comprises of different individuals having personal perspectives and ideas. A clear vision, purpose, set of goals, responsibilities keep all team members attuned and attached to each other like a bunch of flowers. Sharing of individual strengths by means of complimenting and supplementing will lead to a good harmony and thereby guaranteeing a project success.

5. Trust: Different teams need to trust each other. A vertical and horizontal scale of trust built among various team members within a team, and various teams brings better results. Positive conflicts do occur within or across the teams but as long as they are combined with mutual goals of targeting a powerful goal achieving plan, it benefits the project.

6. Feedback and Sharing: Isolation never pays good results. A continuous feedback is important by different managers to their team members. For feedback, managers need to be in line with the happenings around them. A regular review process, feedback and sharing of ideas gives a boost to the project progress.


August 30, 2010  10:12 AM

Project Management Philosophy



Posted by: Jaideep Khanduja
project management, project philosophy, Software Project

A project never goes smooth. It brings unexpected problems during the execution of any phase that marks a difference between the planned activities and actual executions. The deviations enforce re-planning of further activities so that the extra budget and time spent on previous activities can be compensated by revised project plan.

A loser is a loser only when he realizes it and gives up. As long as one thinks he has the capability of changing lose situation to a winning situation, he is never a loser.

Project management philosophy emphasizes on sharing the problems with all stakeholders and team members so that different brains come out with different responses and any of the response(s) can become the best solution(s). Challenge sharing definitely brings out a solution from somebody else having a different set of experience and exposure who has already been into such a situation and has come out of it already. Sharing problems and challenges saves one from re-inventing the wheel. Documentation sharing and a knowledge sharing platform make a strong basis for keeping all on the same wheel.

Managers mostly focus on driving out results from the teams rather than enabling and empowering them to become self driven. Energy flows automatically and uncontrolled. Results start coming out without reaching the deadlines and prior to demand. It depends on managers that by empowerment they start preparing or building leaders within the teams. A combination of leaders, if synergized properly, propels a resultant progress of the project.

Managers become critical key in engaging people in the project. A high level of engagement is lodged in the team members via project manager. As long as the project manager is able to drive teams, it makes them engaged to the project. On the other hand if project manager inculcates and inspires team members to self-engage themselves, the team members do not depend to be driven by project manager.


August 30, 2010  9:12 AM

Ten Differences Between Project Manager and Project Leader



Posted by: Jaideep Khanduja
Leadership, project leader, project management, project manager, Software Project

Both accept challenges. Both have an ability to drive the situation. Both have knowledge and experience to handle a deadlock. What varies is their style of thinking and working. A project manager and a project leader both have a mixed blend of all qualities. What varies is the way they manage a problem.

A leader can be a manager and a manager can be a leader at times. Situations arise when a leader has to manage and a manager has to lead. When a leader is managing a situation, he might be acting more like a manager. Similarly when all of a sudden an unplanned issue arises, serious in nature, and needs an immediate solution, a manager might have to lead others in demonstrating how to manage such situations without looking for standards and procedures. The manager in such situations uses intuitive and innovative techniques more found in a leader.

Most of the successful managers and leaders are good thinkers and have strong expressive powers. Some basic differences between a leader and manager are:

1. Leaders have a power of changing the world. Managers have the power to manage the change.

2. Leaders find out the innovative ways, managers find out the best out of them to adopt.

3. Leaders are the frontrunners leading the way, paving the way, carving the fortune. Managers stay behind the team, taking care of each of the member, managing, monitoring, planning and executing.

4. Leader is more like a mentor; manager is more like an organizer and planner.

5. Leader looks for new challenges, manager becomes an expert in finding out best solutions when encounters a new challenge.

6. Leader enjoys panicky situations. Manager avoids panicky situations.

7. Leader is more like a revolutionary, manager is like a strategist.

8. Leader knows how to convince others with new ideas, manager adopts best procedures to convince.

9. Leader showers credit on team, manager takes the credit for each success.

10. Leader makes teams capable of handling adverse situations by empowering them, manager facilitates teams to achieve targets.


August 20, 2010  11:41 AM

Ten Boosters For A Visible Tester



Posted by: Jaideep Khanduja
project management, Software Project, test manager, tester, testing

A tester must be visible to the test manager most of the time. The visibility comes through many ways. By means of communication – verbal, mail, status updation, discussions etc. Visibility helps a tester in many ways.

Some of the benefits to the tester by keeping himself visible could be:

  • 1. It keeps him attuned to his work,
    2. A constant touch with his boss and other team members,
    3. An informal feedback from his peers and superiors,
    4. An update on the expectation level of his manager,
    5. An positive image of a hard/ smart working person,
    6. Challenge acceptor,
    7. Trust and respect from his manager,
    8. An improvised personality,
    9. Appreciation,
    10. Growth
  • An invisible tester on the other hand will never be able to emerge as a winner in above aspects though he/she might be doing better in performance than others.

    So the crux of the matter is:

  • 1. If you work and you are not capable of showing it, it does not get you good results.
    2. If you don’t work, you can’t show it, as nothing is there to show.
    3. If you are good in show business, you can grow better than others even if you are doing less.
    4. If you are good at work, and good at showing it – you are an ultimate winner.
    5. If you are doing nothing and trying to show a lot – you are going to be an ultimate loser.

  • August 17, 2010  11:10 AM

    180 Degrees Gap Is A Must Between Your Managerial And Leadership Skills



    Posted by: Jaideep Khanduja
    Leadership, project leader, project management, project manager, Software Project

    Broadly a project manager and a project leader seem to carry a similar profile – that is of managing a project and leading it to success in stipulated time period. But if we seek a distinct clarification between the two roles – there comes a demand of a wide gap – as wide as 180 degrees. If one is a creator, another is a builder. If one is a sprinter, another is a marathon runner. If one is a swimmer, another is a flyer. if one is a dreamer, another is a doer. If one is a magician, another is a daredevil.

    Project Manager

    A manager is supposed to manage his project efficiently. Without taking much risk to avoid deviations from his project plans and milestone deadlines, a project manager would prefer to drive on a smooth road having least speed-breakers and potholes. The best team members, most comfortable deadlines, least cumbersome coding is what he would strive for. With a consistent manner of thinking, a project manager would prefer to strengthen himself and his teams with least changes during his project lifecycle management.

    Project Leader

    A project leader is supposed to be an innovator. He would be finding out new ways of performing a task rather than following the legacy or orthodox methodologies. He would be a person demonstrating ‘walk the talk’ rather than sitting on a chair and demanding the results. A project leader would not mind if things are not managed very efficiently as long as the desired results are coming upfront. Consistency is not a mandate for a leader. He would rather call for inconsistency and higher risk as he has an expertise to manage those situations.


    August 13, 2010  10:33 AM

    Twenty Pebbles In The Still Waters Of Project Management



    Posted by: Jaideep Khanduja
    project management, project manager, Software Project

    1. No problem is small.

    2. Never look for Shortcuts.

    3. Never Jump to Solutions.

    4. It is not true that a larger problem will have a higher risk.

    5. Seek for value addition in any task you perform.

    6. Build a culture around the teams.

    7. First See and then Solve the Problem.

    8. The gap between the Scope of Work and Scope of Control build up your Risk.

    9. Learn Simple but Standardized Problem Solving Methods.

    10. After you complete a task spend some time to analyze if it was worth that much time spending on it.

    11. Time difference between resolving a problem and figuring out the solution should be minimal.

    12. Attempt a solution only when you are clear about it. Hit and Trial method does not pay in most cases.

    13. Learn from each problem.

    14. Never Repeat a Problem.

    15. Share Problems and Solutions.

    16. Keep Project related Communication as Structured as possible.

    17. Demonstrate others the ways to solve problems.

    18. Collaborate People.

    19. Don’t spread dirt if you intend to clean the mattress.

    20. Still water is more prone to getting Stale.


    August 12, 2010  10:56 AM

    Toughest And Most Crucial Form Of Testing



    Posted by: Jaideep Khanduja
    project management, Regression Testing, Software Project, tester

    Regression Testing takes lot hell of time out of overall time provided for testing of a product in any software project. Though it takes longest duration for complete product coverage but somehow or the other lot of things remain untouched or unnoticed during this testing. This could be due to lack of experience of tester, lack of knowledge of product, incomplete or unclear product/ business/ development documents or shortage of time and own management/ customer pressure. Each of these factors marks a big impact on the presumed smooth road of project journey.

    Lack of knowledge of the tester could cover up in short form of testing but will definitely leak out in the larger version of testing i.e. regression testing. Many testers worldwide still feel regression testing as most boring and sometimes as non-productive too. Even the development teams feel prolonged time consumed for regression testing by testers as an un-necessary exercise. Due to its long duration many times the momentum and tempo of the testing team goes low. Test automation could be a solution in such situations to shorten the duration of testing and to cover up other shortcomings.

    Product knowledge improperly transferred to tester could lead to an erroneous regression testing. Business knowledge transfer by respective business process owners at customer end to the business analysts could lead to another disaster of ambiguous documentation giving a totally wrong direction to product development. Right and appropriate business knowledge transformation is very important.

    Larger chunk of total project time allocated to development thereby left with a shorter time-span for testing is responsible for dissatisfied customers.

    To sum up the whole gamut, regression testing being the most difficult and crucial phase of project management should be justifiably have a strong backup of development team, customer management, own management, project manager in terms of providing the testers with accurate documents, product knowledge, sufficient time, and above all a good morale support.


    August 5, 2010  11:50 AM

    Six Project Catalysts For Project Management



    Posted by: Jaideep Khanduja
    delivery process, development process, process management, project governance, project management, project metrics, project optimization, project team, project traceability, software development, Software Project, team management

    Delivery Process: Delivery rate and delivery volume is directly proportional to productivity of various teams. Delivery of product depends on rate of development and testing, delivery of implementation depends on speed of implementation and so on. A process for delivery will focus on streamlining and enhancing productivity at all stages of the project. A collaborative and synchronized productivity will impact more on project delivery rather than focusing on a particular phase of a project. A delivery process also takes care of course of action in case of intermittent team size variance, multi location complexities, technological issues, defect management, test management, time management etc.

    Empowerment: Never build an atmosphere of too many restrictions. Discipline and empowerment if imbibed in each team member, require no restrictions and process delaying approvals. Be more delivery oriented rather than restricting your team members to report in time. Flexibility in time can boost teams to deliver speedily.

    Governance:
    Governance and Empowerment can go hand in hand. Governance of process, procedure, methodology, metrics etc. gives you better control over the project.

    Optimization:
    Never compromise in terms of architecture, methods, tools, development platform, project organization, team structure, team sizing, infrastructure and relevant constraints to product a sub-standard product. It is better not to put half hearted efforts than producing a half cooked product.

    Traceability: If process, methods, tools, teams and metrics are in place, traceability is important to understand the optimization level of each of them. No traceability means no tracking of output, result, progress etc.

    Modernization:
    Building a product on old version of software or using non-current infrastructure could lead to a no-support scenario in a short run. Technology is changing very fast. Build your product using latest technology, get your teams skilled on them fast, and build product taking care of technology in news and about to come in near future.


    August 3, 2010  11:14 AM

    Lack Of Communication Generates Assumptions



    Posted by: Jaideep Khanduja
    communication management, communication process, project communication, project management, Software Project

    Lack of communication, during any Project, forces team members to assume. This happens due to lack of clarification and shortage of time. The product built on assumptions stands nowhere for a useful purpose. Assumptions in turn create confusions and confusions lead to disaster.

    A small assumption made at any step of the project may cause a severe negative impact on Project, Product and Managements involved. Data when validated becomes information which forms a basis for building a code. An assumption made in group or by an individual in isolation is bound to result in ambiguities. If for some purpose some assumptions have been made, then it needs to be validated with the help of a complete description and may be if possible, with an example. Example cited with a description give more clarity to the person who has to vet the case.

    Assumptions result from not at all/ unclear/ vague communication. The sender and recipient of communication, both are at fault, if the communication loop is not closed properly. Any communication should be done with no pre-conceived notions in mind either by sender while sending it or by receiver at the time of receiving it.

    Making assumptions is not bad. We do make assumptions many times a day. But those assumptions do not affect us badly. For example on a crowded station, I may make an assumption while coming back from office that first train might be missed due to heavy crowd. It does not affect me heavily even if I am able to catch first train amidst heavy rush. The stakeholders involved in this case are very limited – me and my family. But when it is a question of a business proposal involving many teams, stakeholders, project, product etc., we cannot work on assumptions. A realistic approach which is more objective and measurable is necessary in such scenario.

    Assumptions made during project may cause misunderstandings, conflicts and confusions. Even sometimes an improper/ incomplete communication is the cause for this.

    A structured communication process needs to be in place in any project management.


    August 2, 2010  10:15 AM

    Ten Crucial Hiccups In Project Management



    Posted by: Jaideep Khanduja
    collaboration, communication, Leadership, project control, project management, project quality, Software Project, Team building, time-plan

    As discussed in previous post Identifying Hiccups During Project Lifecycle the identification of the showstoppers or hiccups in a project is very crucial. An appropriate action on a problem can be taken only if the problem is identified correctly. Otherwise the wrong identification may lead to a wrong analysis and solution thereby changing the direction of the project in an uncontrolled direction.

    Some of the most crucial hiccups in a running project could be summed up as below:

    1. Collaboration: The teams and stakeholders need to collaborate and be on a single platform to catch the same train. Else they would be travelling in different directions nullifying each other’s distances covered. The net effect in that case could lead to nil or negative.

    2. Communication: Formal communication is an integral component of a successful project. Lot of communication going in an informal or unstructured manner could lead to ambiguities and confusions thereby resulting in chaos.

    3. Team Building: Each team comprising of right mix of candidates is mandatory to achieve optimum results. Too many cooks may cause lot of conflicts.

    4. Leadership: Right mix of empowerment and leadership is very important to run a project.

    5. Service: Project development is a mix of service and product delivery. The service part is generally over-looked as the major focus is kept on product. The interruptions in service could lead to derailing of a smoothly running project.

    6. Time-Plan: Adherence to time-plan during each stage of project is very crucial. A prolonged delay in project sometimes leads to complete rejection of the project if a need of technology change arises due to delay.

    7. Language: Language barrier is a big risk in most of the overseas project. It has to be handled carefully otherwise there would be a big gap in understanding of the words being told and their perception in understanding.

    8. Control: A control of down-time in hardware, code, people could lead to a big disaster. Cost also needs to be controlled.

    9. Quality: Focus on quality of not only product but process, people, plan and code also plays a major role in project.

    10. Integration: Integration of teams, management, stakeholders, code, modules, and product – everything is important.


    August 2, 2010  8:20 AM

    Identifying Hiccups During Project Lifecycle



    Posted by: Jaideep Khanduja
    business continuity, collaboration, project approach, project management, project organization, project quality, project size, project stakeholders, Software Project

    A project of any nature or size, demands collaborative and systematic approach, from all teams, stakeholders. The teams engaged in various activities and tasks need to tackle hiccups and abruptions arising out of any internal or external turmoil.

    The time-bound projects, if not finished in time, may cause issues raised out of business continuity, stakeholders or team member’s exits, technology in use going outdated, or change in management’s outlook causing decision changes.

    The emphasis on cost reduction, restricted team size, productivity increase, control on expenses, process enhancement, collaboration optimization, quality improvements etc. are the factors that create pressure on the teams working on the project and in turn may affect the progress of the project. These factors need to be managed tactfully and smartly. If not, then a single pressure may cause aggravated impact on the speed of the project. A systematic approach becomes paramount in such cases to cross the fire safely.

    If systems and processes are not in place to manage each and every phase of a project, it leads to panic across the teams. The smooth sailing gets disturbed thereby causing turbulence and unnecessary hindrance. It may call for a re-organization of the project organization in extreme eventuality even. To avoid such extremities, a better decision making approach, improved information structure and clear cut role definition becomes very crucial.


    July 29, 2010  11:47 AM

    Software Testing And Stephen Covey



    Posted by: Jaideep Khanduja
    business analyst, business requirement, developer, Development, project management, Software Project, software requirement, Stephen Covey, tester, testing

    ”We simply assume that the way we see things is the way they really are or the way they should be and our attitudes and behaviours grow out of these assumptions.”. This quote is from the author of the famous book “Seven Habits of Highly Effective People”, Stephen Covey.

    In terms of software testing and software product, the quote seems to say a lot. The product requirement is understood by an analyst they way he perceives business. The requirements understood may be way different from the requirements told by the customer. The requirements documented by the analyst may have further a wide gap among the business is shown to him, the way he understands, and the way he documents.

    Developers and development manager develop the product the way they understand from the document prepared by the analysts. The testers and test manager test the product the way they have understood the business requirements and their understanding of the product built. The test report or bugs report may have different meanings for testers and developers.

    So the journey of a concept from business requirement told by customer to business requirement understood by analyst to business requirement documented to business requirement document understood by development team to product developed to business requirement understood by tester and the testers understanding of the product to bugs found out by testers to bugs reported to bugs understood by developers covers so many grey cells that the whole concept may get changed.

    Lot of things are assumed during the process of understanding and building of product. The end result could be a shattering shock for a customer or it could be a state-of-the-art product for him. All depends on the way things are perceived, assumed and understood.

    The wider is the gap between perception, assumption and understanding, the higher are the chances of the requirements turning into a nightmare as an end result for all.


    July 29, 2010  10:14 AM

    Seven Tips To Optimize Process Management



    Posted by: Jaideep Khanduja
    process management, project management, Software Project

    A Process is the key parameter or metrics to establish the health and status of a project at any stage. Without established process, a method to measure it or its metrics and a continuous effort to re-establish it in terms of improvisation and enhancement, any drive in project management is useless. There are certain key entities to be kept in mind while reviewing any process.

    Any process can be improved upon and brought near to ideally the best process. But as such no process is optimum or best; the best of best is only near to it and always has a scope of improvement.

    Some key components that should be kept in mind while re-looking into a process for further improvement could be:

    1. Identify Weak Areas in a process, be it comprising of parallel or sequential activities. Improvement on those weak areas would certainly help you in achieving better results than being driven out in its current state.

    2. Techniques for performing a process or for that sake review purposes should always be scrutinized critically to get better and better results.

    3. Focus upon each and every step of the process, and the forces driving those steps. Sometimes looking at a process step with a wider angle helps in finding out better improvement options.

    4. Compare the way you define your processes with the similar processes being driven worldwide. It would help you out to find out proven and established methods adopted. Benchmarking helps in getting near to the optimization of a process.

    5. Set your goals for better results from any process. And then start finding out the ways to achieve those results. Without a goal setting you are trying to achieve NOTHING.

    6. Having a steering committee comprising of relevant key persons for reviewing the processes and getting it enhanced. Everybody’s baby is nobody’s pain.

    7. Hire a consultant once you set out your goals to achieve better results and are not able to find out the ways to achieve it. An external expert’s experience in form of advice becomes quite handy to achieve your goals faster than waiting for something to happen on its own.


    July 27, 2010  7:30 AM

    Change User Training Model



    Posted by: Jaideep Khanduja
    collaboration, project management, Software Project

    User Training, Product Demo, UAT all require visit to customer site and a face to face interaction with the end users and customer management. Worldwide scenario is changing now. Organizations in wake of going green and cutting costs prefer alternate ways to avoid travel expenses especially for overseas projects. The development and implementation teams use various approaches to interact with customer groups taking help of latest technologies that have emerged and stabilized now.

    Technology these days is not limited to IT only, it has spread its wings even to the non-IT arena. Customers are also quite tech savvy and aware of various technologies available globally to connect different time-zones and geographies. High speed communication, internet, high bandwidth availability, mobile/ wireless technologies, dashboards, web conferences, commercial usage of skype and Web 2.0 etc. have emerged as winners in attaining these goals.

    This has lead to innovative approaches to collaborate different teams working on same projects while sitting across different geographic locations, or creating a knowledge sharing platform for vendor-customer collaboration during various stages of a project.

    In today’s world, vendor teams can connect to customer teams for the purpose of product demo, trainings and UAT in a very organized and structured manner to make such sessions a big success thereby lowering the project costs and time wasting or non-productive activities.

    This has helped not only in meeting tight schedules but has given birth to smart planning and project management.


    July 26, 2010  9:58 AM

    Process Chart At Every Stage Help Part II



    Posted by: Jaideep Khanduja
    process chart, project management, Software Project

    Let us, for example, take a scenario of changing existing functionality in software, by changing some part of the code, to enhance its performance and applicability. The enhanced or re-designed code is supposed to give better performance thereby giving higher level of user/customer satisfaction in terms of business and application usage.

    The process if not defined will change the code, without any traceability, documentation and revision control. On the other hand if the process is well defined, a team will definitely first of all introspect in the business and code in place to work out WHY this change is required.

    The change in code should not happen just for the sake of demand of a user, or customer management. It has to be well researched by the coder team in terms of its impact and workload.

    The process for such a scenario would be:

    1. Segregate the code that needs changes
    2. Define the changes required
    3. Segregate the other parts of the software where above changes will impact
    4. Sort out the changes required in those areas defined in step 3
    5. Change the identified code areas
    6. Test the changed code in isolation
    7. Re-examine the already existing test cases if they need to be extended, changed or altered
    8. Perform re-definition of test cases, write new test cases
    8. Perform integration testing
    9. And so on…


    July 26, 2010  9:51 AM

    Process Chart At Every Stage Helps Part I



    Posted by: Jaideep Khanduja
    process chart, project management, Software Project

    A well defined process is a key performance tool for any project. Keeping in mind that any defined process required a life-long enhancement and improvisation helps project management team and management to strive for excellence in each stage of the project. If processes are undefined the project has highest level of risk of going for a toss at any stage. If processes are defined but are not adhered to, it is as worse case as the prior stage.

    If processes are defined and are adhered to, is an ok state but can not be termed as a healthy state for the product, project or organization. The best scenario is that with each step of the project, the relevant process is re-looked into for an improvement.

    Organizations having optimum processes defined do not sit idle on the established and polished processes. They still keep pondering and exploring on any possible improvement, variation or re-writing of process to get better results in next go.

    Just like a mirror, if not cleaned regularly will not reflect appropriate image of yours, when you stand in front of you, thereby creating worrisome situations, though you may be looking as smart as yesterday.


    July 23, 2010  12:25 PM

    Two Approaches Of Capturing Customer Requirements



    Posted by: Jaideep Khanduja
    business requirement, customer requirement, project management, software product, Software Project

    Let us consider a simple scenario of writing code for a new application for a customer. The process starts with a clear understanding of customer business, key user’s expectations and customer management’s expectation regarding business benefits driven out of this application.

    The most important journey begins with capturing all these details as minutely as possible. I always recommend not to map application with the business but map business with the application to get maximum benefits from the deal and make customer happy and satisfied.

    Mostly during the requirements capturing, we start zeroing down the nearest application available with us and start moulding our requirement documents keeping in mind to sell that application to customer. That is the biggest mistake we make when we start looking at customer business framed in our existing application. Worse is when we change the direction of business discussion trying moulding it in our product way.

    That itself starts leading to a big disaster. This strategy will definitely leave us with less efforts and more margins without customer knowing that we are delivering his business solution to him with an already product in place with us. But usually it will not be able to win the situation after implementation of product when the users and management starts reflecting their frustration. Even if you are paid for such project, it is not going to get you further business or reputation in the market.

    On the other hand when you are capturing customer business requirements, never let any of your existing product come into your mind. Record all business requirements as if writing on a blank slate. Afterwards maybe you can find out the gap in an existing product and business requirements and thereby arriving at a conclusion of moulding this existing product with least twists or deliver him a new built product.

    At the end of the day the customer should not only pay you but greet you with a smile on his face even after one year of delivery of the product.


    July 22, 2010  11:05 AM

    Five Tips For Bypassing Testing Of Product



    Posted by: Jaideep Khanduja
    developer, project management, QC, quality control, software development, Software Project, software testing, tester

    1. Showstopper: Product manager always has the perception that the development team wants the progress of work whereas QC or testing team jams the progress. They even try to project in the way of showing development team sitting idle when the product is lying with testing team for finding out bugs in the product. It is reflected as if QC is not an enhancer but showstoppers.

    2. Fault Finder: One of the reasons of not giving the product to QC for testing and emphasizing on an in-department testing is that QC or testing team is blamed for unnecessarily finding faults in the product just for the sake of highlighting the lacking in the product whereas it is claimed that the product is built perfectly and working fine.

    3. Business Knowledge: One reason of bypassing QC team in Product development lifecycle is putting wrong perception in management’s mind that the testers lack business knowledge. For that sake even sometimes wrong, incomplete or ambiguous business process documents are produced to testing team so that they are not able to understand business properly and the test report lack the crucial business process bug reporting.

    4. Process: Excellent process even in place are not adhered to sometimes in wake of fake reasons of lack of time, customer pressure, more time required for development and so on thereby giving short time to test teams for testing the product.

    5. Management: Management if do not balance development and quality team equally then the product or the organizations do fall in trouble at a later stage.


    July 22, 2010  10:31 AM

    Hide And Seek Between Development And Quality Teams



    Posted by: Jaideep Khanduja
    project management, quality control, software development, Software Project, software quality, software testing, tester

    There is always a hide and seek game between Product Manager and QC Manager when a product is being built. Project Manager, Management and Customer on one hand stress on complete involvement of testing team during product building. On the other hand product manager keeps playing tricks to bypass testing by a separate team outside his control.

    This could be due to a fear factor in him, or lack of confidence on his product. For the sake of not displaying his these weak points to other teams involved in Product Lifecycle, a Product Manager tries presenting his points in other fashion to convince management or other managers for not giving the product for testing or providing the least duration to testers. This satisfies him for the reason that least exhaustive testing by testers will lead to least number of bugs.

    But by doing this he also is doing a inappropriate deed for his product and in turn for the organization. Usually Test team is taken as an opposing factor by the product manager. In a way while the development of the product; he gets emotionally attached to his product. Feeling of getting it scrutinized by an outsider (someone not from his team) makes him feel as if someone is intentionally going to find faults in him or his product. He also feels that the higher is the number of bugs,


    July 21, 2010  12:10 PM

    Five Quick Handlers For Project Management



    Posted by: Jaideep Khanduja
    project management, Software Project

    1. Confidence: The confidence level at any stage of all team members, project manager, QC manager and all other stakeholders right from the beginning starts narrating the direction and overall health of the project. The clarity of requirements, goals, direction etc. all reflects through this handler.

    2. Process: Ensure that right processes have been framed, adopted and adhered to in case you want to ensure success at each stage of the project. No process always carries a higher risk of failure that can be mitigated by a right process and methodology in place.

    3. Quality: Quality has to be omnipresent throughout the project in all aspects not only in terms of the product or code but also in terms of people, process, methodology, communication, direction, documentation etc. Quality in any case is an asset for any project or organization. Organizations emphasizing more on quality aspect groom much faster compared to others.

    4. Control: Control comes through measurement and analysis. Absence analysis and metrics never gives a right control and hence there is always a chance of deviation from the right direction. Control at all levels has to be there including a self-control factor in all team members up to the bottom level.

    5. Morale: Keep your team’s morale at the peak all the time. Ensure nothing unproductive work hits any of the members during the project. Keep boosting their tempo and focussed on getting fruitful results at all stages.


    July 20, 2010  12:05 PM

    What Type Of Product Do You Build Part II



    Posted by: Jaideep Khanduja
    product development, project management, software product

    Another approach is to build what customer can’t resist. This definitely is a stage higher than the approach mentioned in the above paragraph. The customer requirements are definitely given importance here but the business in-depth knowledge acquisition is much more important prior to building the product.

    I am sure companies who deliver what their customer wants also would be striving for a stage where they build what customer can never resist. Definitely all of us know the difference between these two.

    The extra edge that is carried by the second approach definitely helps in keeping both categories of companies far apart from each other.


    July 20, 2010  11:33 AM

    What Type Of Product Do You Build Part I



    Posted by: Jaideep Khanduja
    product development, project management, software product

    Few months back I read this line somewhere in an article related to project management and product development. The line read as – “We don’t build what our customers want – we build what they can’t resist.”

    There are two approaches I could clearly find out from this one line. This line infact summarizes the crux of whole software industry. The two clear segments of software industry with their clearly defined process approach focus either on customer requirement in front of software building or the customer business in front of the software building.

    One approach is to build what customer wants. And there are companies who boast about delivering what their customer wants. This definitely would be requiring a number of iterations of changes in the product when the software is introduced to the customer for user acceptance or pilot run. The main focus in such approach remains on the crystal clear customer requirements and building them in the application.


    July 9, 2010  9:54 AM

    Three Basic Ingredients For Becoming A Good Vendor



    Posted by: Jaideep Khanduja
    outsourcing, project management, project success, Software Project, Software vendor

    Outsourcing is not an unfamiliar term. We keep doing that in our day to day life for our personal and home needs. The same is done in corporate world. All activities or work can’t be performed by a single person. Similarly all corporate functions may require outsourcing depending on size and need of the organization.

    The first and foremost requirements for the outsourced vendor is give a feeling to the customer that they understand customer needs, are capable of performing it and can deliver it in time. So in short the three ingredients that are foremost required in a vendor are knowledge, skill and capability.

    These three ingredients are required in right combination and must be transparently visible across. Otherwise retaining these features but not being able to pass across the right message will create bottlenecks for the vendor for acquiring new business.

    Ultimately it is the mix of good ethics, standard processes, proven methodology (ies), excellent support and becoming an integral part of the project that makes customer and vendor a successful venture in any project.


    June 30, 2010  9:45 AM

    Ten Tips For Outsourcing Project Partner Part 2



    Posted by: Jaideep Khanduja
    project management, Project Plan, Project Risk, Software Project

    5. Benchmark: To rate each of your selection criteria points for each vendor you will be required to benchmark each criteria with the best possible value available across the globe. Against this best possible value for each point your assessment for each vendor will give you a better understanding at the end of assessment exercise the level at which each vendor stands making it easier for you to shortlist or finalize the vendor.

    6. SLAs: SLAs are nothing but an agreement to deliver or get a certain level of delivery of service or product and also taking care of addressing to any ambiguities arising at a later stage during the delivery.

    7. Delivery: Delivery of software is different to delivery of a refrigerator. Software or part of software outsourced requires continuous involvement of inspection and verification by the customer to ensure that the efforts are being put in the right direction. A later stage engagement will involve higher risk compared to the involvement or engagement right from the beginning.

    8. Payment: Payment terms usually are kept in agreement with the delivery of the product. If you are outsourcing a vendor for some part of the project, keep your terms of payment of the product in such a way that some part is paid after your customer signs off the project keeping in mind that if your customer is delaying the sign off but the reason is not associated with the part outsourced, then there is no point in lingering on the payment to your vendor.

    9. Support: As you are bound to support your customer your vendor is also bound to support you not only on the part of the project he is outsourced for but also that part’s back and forth integration. This back and forth integration part is something which will be overlapping you and your vendor so you need to be extra careful about this integration part.

    10. Contingency Plan: Any development is associated with risks. Identification of risks at the earlier stage gives you more time to plan for risks mitigation. A later discovery of risk creates a panic. A contingency plan gives you a little pain in the beginning of the project to cover up all your later stage pains.


    June 30, 2010  9:28 AM

    Ten Tips For Outsourcing Project Partner Part 1



    Posted by: Jaideep Khanduja
    project management, Project Plan, Project Risk, Software Project

    1. Understand Complete Requirements: Customer requirements for the whole project play a very crucial role in building a new product. The whole requirements are shared by many teams for various purposes – viz. development, testing, implementation etc. A foolproof process of documentation of complete requirements is mandatory. The clearer the requirements, easier it is to build a customer favorable product. Unclear or incomplete requirements will cause delay and frustration in the project at both ends.

    2. Map Existing Capabilities: All phases of project may not necessarily be possible to carry on with in-house teams. Some of the requirements may need specific skill-sets that might not be available with the existing profile of team members. This calls for either of two possibilities – either recruit relevant skill-set persons or outsource that part of the project to a relevant vendor having team of the required skill-set.

    3. Sort Out Jobs for Outsourcing: Going for a fresh process of recruitment for filling the gap of required skill sets for the project might require extra time which may not be permissible by customer. Also the newly recruited persons take some time to settle down and get into the flow of main stream. So it is better to outsource a vendor to deliver such requirements.

    4. Define Selection Criteria: Selecting a vendor will never be an easy task as the involvement of an external agency in a project adds another kind of risk to your project. There is n number of assessment criteria before arriving at a conclusion. The selection criteria must be chalked out very clearly before starting the vendor selection process. It could include size of the company, their projects history, customers, employee turnover, growth, management, knowledge base etc.

    ..to be continued…


    June 22, 2010  11:45 AM

    Ten Reasons for a Project Manager To Act As A Gardener Part II



    Posted by: Jaideep Khanduja
    project management, project manager, Software Project

    5. Harvesting: Plants are ready for harvesting at different timescales. The crop decides the period of harvesting unless some negative impacts the growth. Same is with the people. Some grow fast, some take their own sweet time to grow and establish their achievements.

    6. Plough: After harvesting a field needs to be ploughed and seeded. Same is with the people, if they are not given more challenges and extra tasks. Same repetitive tasks make them stagnant. They need continuous flow.

    7. Sunlight: Essential for photosynthesis to convert light energy into chemical energy. In terms of people a sunshine, bright and cheerful environment definitely affects the progress and growth of an individual and a project.

    8. Air: Air is important for all sections of a plant – the parts below the earth/ soil or the parts upward. A plant placed low natural air availability areas will go isolated and will develop at a lower speed.

    9. Manure: All plants may not need it but they always welcome extra nourishment. Though excess of anything goes waste or produce bad results, it is the project manager who has to identify who needs how much motivation, growth and challenges.

    10. Nurture: Small plants are not seeded in big pots so are the people. Newcomers or people with less experience in the organization can’t be expected to product big results unless they have a very strong background and outside experience. Otherwise each plan need to be nurtured in present to produce big results in the future.


    June 22, 2010  11:29 AM

    Ten Reasons for a Project Manager To Act As A Gardener Part I



    Posted by: Jaideep Khanduja
    project management, project manager, Software Project

    A gardener is not a simple job, rather is a most tedious job of growing and nurturing nature. The similar job is that of a project manager who has to manage different teams in a project. The team members comprise of different ages, cultures, geographies (sometimes), experiences, backgrounds, qualifications etc. A project manager has to plant, nurture, care, water, grow, safeguard, and manure his team members depending on the stage of the plant (team member).

    1. Nursery: All new incomers need to be placed here for providing them special attention, right direction and extra motivational strengths. A separate set of extra organizational cultural, functional and relevant technical training is required to be imbibed for synchronizing newcomers strengths with the organizational goals.

    2. Trees: These are the existing team members for quite a few number of years spent in the organization. They have displayed their strengths, acquired new strengths; deliver at par with organizational expectations with least direction and efforts. One thing that goes unnoticed about trees is that trees strive to show their strength and knowledge by delivering fruits… I mean the people falling in this category strive to train people with less experience, share knowledge with juniors thereby helping in growth of others.

    3. Plants: These are the most variant category requiring different stimuli depending on the category they fall in. Some may require extra sunlight, some extra water, some prefer to grow in shade, some need extra nutrients. This is the phase of the people where they neither decide for a long term engagement with the organization nor do they plan to leave it soon. It is the phase of bonding and attachment depending on the way they are treated.

    4. Watering: Each plan has different water requirements but no plant can survive without water. Except the trees whose roots are well deep enough to get water directly from the earth. These people (trees) are having a deep attachment and bonding with the organization. As and when they feel low (which happens not to frequently), they themselves fetch energy from the management instead of waiting for someone to come and energize them. Rest for all plants a regular watering plan is must in terms of motivation, training, discussions, recursions, informal engagements.


    June 18, 2010  11:57 AM

    Ten Tips To Increase Business Application Usage Part II



    Posted by: Jaideep Khanduja
    change management, process optimization, project management, Software Project

    5. Drive with a top down approach: If the project command is shared with one of the top management member of customer end, it gives a catalytic thrust to the project progress and becomes a winning note for the product.

    6. Don’t pass a stupid message that successful business application implementation means decrease in Headcount. Rather pass on the message that the underutilized employees who are engaged in manual processes will be converting to more productive work.

    7. Manage Change: Generally change is welcomed with a resistance. People want to stay cool with their regular routines with no considerable change. Any application implementation or process enhancement seeks change. It needs to be observed, controlled and managed wisely.

    8. Motivate users: A person when felt as important pillar for a change, feels good and motivated. Engage users to their full strength for the change and implementation.

    9. Remove junk: Sometimes an automated or fresh designed application process becomes lethargic and boring than the earlier used process (legacy or manual). Sort out, identify the major chunks of junks and convert them to more friendly and optimized user friendly.

    10. Kick Process not People: It is the process or methodology that is responsible to make a success more than the people involved in it. Enhance the process of implementation rather than wasting energies on finding out the weak people links.


    June 18, 2010  11:35 AM

    Ten Tips To Increase Business Application Usage Part I



    Posted by: Jaideep Khanduja
    change management, process optimization, project management, Software Project

    Sometimes business applications die an unnatural death even if the application is built with state-of-the-art technology fulfilling all relevant business requirements.

    The reason of failure does not lie with the application but the people and processes involved in deploying it but unfortunately even in such cases the blame goes to the application and it is the application reputation that suffers.

    The two main defaulters in this case who can be held responsible for Project death are Implementors and End Users/ Customer Management. To cope up with this risk and for mitigation let us work out on the following ten tips:

    1. Understand business requirements and pain areas: This beautiful application may be lacking some customer specific areas which are not catered or are catered but not satisfactorily in the application. These pain areas need to be addressed as and when they evolve during the UAT or product implementation.

    2. Address critical business processes in the application: Sometimes some core critical business process is misunderstood and built wrongly which is recognized at a later stage. It needs to be addressed either way.

    3. Take feedback from users: It is very important to make user feel important in the project. One of the way is to ask for their feedback in a formal manner. It not only makes them feel an integral part of the project but also gives them a chance to speak their heart out. In any case the customer management would definitely be acting on their feedback only.

    4. Engage employees and Management together: Many a times the project team forgets customer top management and focus entirely on end users without engaging and updating management.

    ———contd in my next blog.


    June 14, 2010  10:00 AM

    Optimized Environment Gives Optimized Project Performance



    Posted by: Jaideep Khanduja
    project management, project team, Software Project

    Project performance encompasses performance of each individual member of each team working for a project. Each team members requires an environment around him that facilitates him to work towards his goals.

    The components of an environment for a team member would be the working place, sitting place, workstation, and general administrative facilities.

    Many of the components
    that may not draw immediate attention of focus but actually playing a role in project performance can be defined as below:

  • 1. The ease of difficulty with which a team member commutes,
    2. The communication process in the organization among other team members and management,
    3. The comfort of sitting place, tea/coffee breaks, lunch provisioning etc.
    4. The desktop/ laptop configuration
    5. LAN and internet
    6. Even the power supply, lighting in the office and on the seats, drinking water arrangements, rest rooms etc.
  • All these factors if are favorable towards employees in turn bring lot of favor to the project performance.


    June 11, 2010  1:03 PM

    Apply Six Sigma Approach In Project Management



    Posted by: Jaideep Khanduja
    project management, six sigma, Software Project

    Six Sigma is more of common sense and facts based analysis of real data to arrive at an action plan. The basic steps to perform a six sigma project are as below:

  • 1. Identify a problem
    2. Set goals to resolve this problem and define the result in terms of financials and timeframe
    3. Collect data for a considerable period to analyze
    4. Perform statistical analysis based on relevant tools to identify the core issues responsible for the problem
    5. Hit on those core issues
    6. Identify and measure the gains
  • Usually it is not easy to run above cycle once and achieve the desired final results. With the help of interim results in different iterations, the final results can be achieved.

    To do that a basic six sigma approach can be applied as below:

  • 1. identify the set of problems
    2. set a goal of fixing top 5 or 10
    3. collect relevant data – very important to understand that wrong or incomplete data will draw out wrong results
    4. perform SIPOC
    5. analyze the top most (say 5 or 10) factors responsible for your problem identified
    6. set a goal to kill/mitigate those factors
    7. see the results if you are moving near your result goals
    8. analyze next top (5 or 10) factors
    9. kill them
    10. check the distance from your goals
    11. and so on…

  • June 9, 2010  11:44 AM

    Business Study And Product Architecture Mitigation



    Posted by: Jaideep Khanduja
    project management, Software Project

    A lot about the product architecture and design depends on the inputs of business requirements. The team responsible for business study and documentation must understand the severity of risk built in development stages due to wrong or incomplete interpretation of business requirements to be built in the product.

    Business requirements documents include both functional and non functional requirements emerging out during the discussions with customer management and key functional managers. All these requirements become integral part of the requirement document that moves to various teams during the different stages of project development.

    What if some of the crucial requirements are not captured during the study phase? Or if some of the requirements are not documented in illustrating manner which in return present wrong interpretation to developers and the product development starts moving in wrong direction.

    All such ambiguous/ wrong/ incomplete developments lead to a risk of customer/ user dissatisfaction at a later stage depending on how soon or late the product built is exposed to the customer front. Such risks must have a concrete mitigation plan beforehand in order to not to lose confidence, time and reputation.


    June 7, 2010  11:53 AM

    Project Team And Leadership Skills



    Posted by: Jaideep Khanduja
    leadership skills, project management, project manager, Software Project

    Project Manager has to have leadership qualities to achieve success in projects. To carry on with these qualities for project management is good for project manager keeping in mind to regularly improvise and enhance these skills.

    Another outlook is to inculcate these qualities in the team members down the line. Being a mentor for few of the team members is important to develop future project managers. Also if the team members touch down the inner feelings of project manager about the project, it becomes easier for all to synchronize their energies and move ahead in the same direction together.


    June 3, 2010  11:22 AM

    Five Key Points In Vendor Selection For Outsourcing A Service



    Posted by: Jaideep Khanduja
    outsourcing, project management, Software Project

    Non Standard processes are prone to risk. So is the service. Service is more based on the people than the deliverables. Even the set standards will vary the level of sam service being delivered by different set of persons. Product is easy to judege in regard to quality. It is instantly demonstrable also in case of a product with the help of measurable parameters of testing.

    In service it is difficult to set or establish process standards. Even if they are set, if is difficult to measure them to instantly declare if the service is of high quality, or low quality. With the same quality of service it is not possible to make each customer satisfied. The level of satisfaction will depend on lot of non-measurable parameters.

    To outsource a vendor for a specific service, there has to be a checklist with parameters defined to ensure the right selection of vendor for that service. The selection cannot merely be based on gut feeling or the verbal commitments of the vendor. Some of the important parameters for selecting a vendor for a service could be:

  • 1. Market Reputation: Check with the existing customers of your prospective vendor about their experience and satisfaction level. Select these customers with a right mix of old and new ones. Both types will have a different set of pros and cons stories to tell you. Also be careful in selecting those customers who are availing similar sort of service from the vendor what you are planning to outsource for.

    2. Customer’s Turnover: Check out the vendor’s record (though he will not be easily disclosing it) how many customers have left him during last three years and try finding out the reasons for it.

    3. Certifications: There are world class certifications available these days geographically everywhere. Checkout the relevant certifications your prospective vendor has obtained. Check out how old are these certifications, have all recertifications been done, when was the last audit done and see the audit report to find out the observations or non conformitites pointed out by the auditors. Also check out the reputation of the auditing agency.

    4. Employee Turnover: Check out his employee turnover. Beware to outsource him for a service if his employee turnover is high.

    5. Growth: Check out the financials to find out the rate of growth. If growth is turbulent or incosnsitent, it could be a point of worry. A consistent or atleast sustained growth is good.


  • June 2, 2010  11:00 AM

    Optimizing Helpdesk Performance And Customer Satisfaction



    Posted by: Jaideep Khanduja
    helpdesk, project management, Software Project, software support

    Managing and running helpdesk is not an easy task. Once the project is completed after software application has been implemented and sign off has been taken from the customer. a new journey starts in terms of product support. The users who start working on the product entering real business data to product useful informative reports for themselves and their management face problems in the beginning while working on the new application in the organization.

    These problems could be due to many reasons like:

  • 1. unawareness of users with the real functionality and flow of the product
    2. hidden bugs in the product being exposed while working
  • etc.

    Over a period of time helpdesk becomes a good repository of information gathered from application users in terms of complaints, suggestions, feedback etc. One way of working of helpdesk is to record the problem, provide the solution and treat the story as finished.

    Another way to look at it is to analyze this data and find out if there are any complaints that are recurring in nature. Definitely there would be certain problems that would be occurring repeatedly. Providing a temporary solution is good as an ad-hoc provision but getting into its depth later and finding out a permanent solution is very important.


    May 31, 2010  10:01 AM

    Two Types of Constraints in Project Management



    Posted by: Jaideep Khanduja
    capacity constraint, project constraint, project drive, project goals, project management, Project Plan, project task, quality constraint, Risk Management, Software Project

    Tasks and Constraints go hand in hand. Life is full of tasks. So is a Project. Project Management consists of lot of planning and re-planning. If everything goes smooth as per plan, there is never a need of re-planning. In real-life scenario this doesn’t happen. Constraints are the generators of problems and problems need solutions. For addressing a problem and providing an alternative to suit as a best possible solution creates the need for re-planning.

    A continuous analysis of what is happening around in a project is important to understand if everything is moving as per plan or if the deviation from the plan is going to cause a disastrous situation (or something in-between the two extremes).

    The two constraints classifications are:

    1. Capacity Constraint
    2. Quality Constraint

    Identification of factors causing any of the above constraint is of prime importance. Sometimes it is easy to perceive these constraints in early stages and make them part of your risk analysis. The mitigation plan is made accordingly. Sometimes these constraints if not perceived and made as part of risk plan cause trouble when arise at a later stage. If they are encountered at a later stage, it comes as a shock rather than a surprise.

    Constraints may arise due to various reasons, some of them could be:
    1. Lack of clarity of project goals
    2. Lack in project management methodology
    3. Non adherence of standard processes
    4. ambiguous processes
    5. Lack of drive


    May 28, 2010  8:20 AM

    Five Benefits of Software Testing On Cloud



    Posted by: Jaideep Khanduja
    cloud computing, project management, Software Project, software testing, tester

    In a normal scenario testing of a product is done within the organization by the quality/ test team members. Lately as cloud computing came into the picture, a new concept of testing on cloud has emerged, though not many companies have jumped into it.

    Testing on cloud carried quite a number of benefits in terms of cost and resources. It is something like “service on demand” or “testing on demand”. The cost of hardware, software, tools, tester etc. is charged on usage basis.

    Some of the key benefits that can be drawn from this are:

    1. Tool License Costs: You don’t need to invest in tool license. You have varied option of selection of choosing tool of your choice depending on product to be tested. The service provider is supposed to ensure that latest version of the tool is provided. So instead of paying a hefty amount for buying a tool, keeping track of updating it with latest patches and fixes, getting bothered about the new release and then depending on it for all your product range; you just need to pay-as-you-use basis.

    2. Infrastructure Costs: To perform testing, to load tool and to provide a substantial hardware/ infrastructure platform in-house; you can go straightaway for the cloud service provider.

    3. Flexibility and Wide Range: You have the flexibility of using only when you really require. And you have an option of choosing the right tool for right product.

    4. No Setup and Procurement Time Wastage: You can bypass to invest your time in procurement and setup process. straightaway select the cloud vendor, and get the setup already up and running to start testing instantly.

    5. Expertise: You don’t need to hire tool experts.


    May 26, 2010  12:14 PM

    Eight Mantras To Win Over Battling Project Targets



    Posted by: Jaideep Khanduja
    project management, project monitoring, Project Plan, project progress, project quality, Project Status, project strategy, project target, project team, Software Project

    Project Management is involves strategy, plan and intuition. A project may be complex to manage if project targets are not indentified properly. It may be simple to manage if project targets are identified, risks perceived correctly and risk mitigation plan is made a important subset of project.

    In a battling ‘software project targets’ situation two major villains that emerge out are lack of time and lack of visibility. It clearly indicates that a revisit and refinement is required in the project management system/ process. The Project management team comprising of all major stakeholders are required to investigate project management practices & procedures and acknowledge the loopholes.

    Gaps in project management processes can result in loss of the business to competitors. That is why time investing in building a quality project management practice becomes prime important.

    Some important points to take care in that case could be:

  • 1. Streamline and stabilize your complete project management process.
    2. Manage the entire project cycle from project initiation to project sign-off with involvement of major stakeholders.
    3. Monitor the progress with intrinsic insight.
    4. Try to identify and nullify time and effort wasting activities.
    5. Maintain regular status reports visible to everyone associated with the project.
    6. Seek Feedback on project status and performance in every project meeting.
    7. Control deadlines.
    8. Track expenses and time budget.

  • May 24, 2010  11:18 AM

    IT Organization and Best Practices



    Posted by: Jaideep Khanduja
    best practices, business reputation, business value, global standards, IT organization

    Earlier IT organizations used to focus on technology and its synchronization with internal needs. But this focus has steeply shifted to an in depth selection of right technology out of all possible available in the market and its maximum utilization to cater to the end users who in turn use these tools to manage, control and enhance their service to internal and external clients.

    This is where Standards come into the picture. Global standards help in meeting internal as well as external customer’s expectations. Standards chosen must be such that they meet today’s and tomorrow’s challenges to cater to the business needs. It should be based most comprehensive and widely accepted framework globally. It should be flexible yet filled with best practices to chalk out your own path to excel in both world’s expectations to help you in delivering the best practices based services.

    Like any other large sized product, it has to be implemented in steps. It cannot be done in a single step. A mapping with the existing and future business needs with the best practices available is important for which the needs are to be indentified very clearly and correctly. For any organization, its business needs are unique and hence should be the strategy to adoption of best practices.

    The benefit of such an approach is that it helps in ensuring expected level of service with a high level of consistency.

    It will also help in achieving highest level of internal and external customer/ employee satisfaction as well as will in lowering in the cost of service thereby increasing business value and reputation.


    May 21, 2010  10:45 AM

    Project Management and Project Functions



    Posted by: Jaideep Khanduja
    project function, project management, Software Project

    Project comprises of many functions. Each function’s identification, staging and monitoring is prime during all stages of the project. Function’s progress indicates the progress of overall project. A broken function means an immediate attention. Attention will be possible only if the function is being closely watched or monitored. Else the breakage will go unnoticed and may attract attention at a later stage when something disastrous happens due to this earlier breakage gone unnoticed.

    Sometimes a small breakage may evoke and evolve a sleeping volcano to create a major problem.

    Function going smooth also indicates no bottlenecks in the project. A broken function means a risk identified that needs to be mitigated.

    A smooth closure or finish of a function acts as a catalyst for the next function in the row. A broken function accumulates negative impact for the whole project.

    Some broken functions may have chain reaction of generating more broken functions.


    May 20, 2010  10:45 AM

    Project Management and Project Data



    Posted by: Jaideep Khanduja
    Project data, project management, Software Project

    Data collected for any purpose is useless in three cases – one, if it is not collected in standardized form, two, if it is being collected just for the sake of collection thereby not doing any analysis and three, if no thought process is gone on analyzed data to improve the situation.

    In all the three conditions, the purpose is not being catered to. But let us understand that different organizations in terms of data collection fall in different categories as mentioned above.

    The organization falling in first category are just collecting data blindly without any serious thoughts gone into the process. The second category organizations are a little better than the first condition because the data being collected is in organized or structured form but no analysis is being conducted on that data. But in case the organization wakes up and plans to do some analysis – atleast they will have the base data in proper shape.

    The third category organizations go upto analysis part but do not draw out sensible conclusions to improve the situation.

    But sooner or later all organizations need to fall in the fourth category – that comprises of:
    1. Collection of data in proper form
    2. Analysis
    3. Improvements


    May 19, 2010  10:48 AM

    Project Management and Post Project Closure Scenario



    Posted by: Jaideep Khanduja
    project closure, project management, project sign-off, Software Project

    After the completion of a software project, the project closure report or project sign off starts a new experience. The users start practical usage of the product in live scenario. The management starts expecting the useful information in form of reports and screens to manage the business more efficiently. Above all everyone expects more comfort and more confidence.

    Though in the initial few months both the users and management may not get completely what they expect. The users comfort will increase gradually as they become more and more conversant with the product in isolation.

    This will be a learning stage for them too which will teach them some real lessons that were not covered in training sessions. The problems they encounter might not be technical issues, it might be related to wrong usage of the product. All this gradually evolves and results into a more knowledgeable user.

    Management on the other will depend on two factors – the feedback from their key users, and their own experience with the product.

    Over a period of time, after these initial struggles, the management, users, and product have to synchronize to get the useful results.


    May 18, 2010  12:13 PM

    How Important is Support Data



    Posted by: Jaideep Khanduja
    project management, project support, Software Project, support data

    Post implementation support includes customer registering the problems related to the product and the product owner resolving it. There has to be an agreement or contract of service that defines the level of support.

    Customer may report about a problem in various manners viz email, web portal, IVR, phone etc. giving too many windows to customer to register a problem, itself becomes a problem for the vendor. Vendor must ensure that any call coming via any media, must go to a central repository. If all calls from a customer are not registered in the database or central repository, the purpose of recording a call will not fetch out any useful results at a later stage.

    Vendor will not be able to monitor the calls, keep track of open calls, or maintenance of a proper history of resolutions. At any later stage also if vendor decides to do some analysis, it won’t be possible if the repository contains partial number of calls.

    Sometimes vendor wants or doesn’t want
    , pressure may come from customer end to produce analytical reports, failure of which may cause troubles in further renewal of contract or payments.


    May 17, 2010  12:12 PM

    Post Implementation Support Data Delivers Product Health Report



    Posted by: Jaideep Khanduja
    Post implementation support, project health, project management, Software Project

    Product is understood, developed and implemented. Sign off has been taken, and post implementation report is submitted. All is well so far. What now?

    Next leap of journey begins. The product usage, results expectations and problems encounter. Users get into the product on their own, start digging it deeper and deeper to understand it more and gradually get more confident. Problems encountered are being reported to the support contacts and issues are getting closed sooner or later.

    But one point is skipped. There are many problems which are repeating every month. Customer reports and gets the solution but the level of confidence is lowering. Customer has started getting annoyed due to this repetition of problems.

    Repetition of problems needs to be addressed. It is the most crucial factor and may become skeptical.

    Someone needs to look into it and notice the deteriorating health of the product.


    May 13, 2010  12:29 PM

    Project Management and Project Direction



    Posted by: Jaideep Khanduja
    project management, project manager, Software Project

    If the Project Manager doesn’t know the direction of the wind, he can’t be a good sailor. To drive a project a project manager need to set certain milestones. To make these milestones achievable on a regular basis (weekly, daily, hourly) he needs to break these milestones into tasks and sub tasks. These tasks are assigned to appropriate team members with the mutual consent on deadlines to finish the task.

    The deadlines are closely self monitored by the task achievers (programmers, developers, testers,…) to maintain the rhythm and momentum.

    At any moment if a task is getting delayed to finish, an alarm is required to be raised so that all members get alert and focused to find out the delaying factors. These factors are then analyzed and overcome with the team effort.

    The direction of the wind keeps changing. So should be the priorities and planning of the project manager.


    May 12, 2010  10:50 AM

    Project Management and Project Performance



    Posted by: Jaideep Khanduja
    project management, project performance, Software Project

    Project performance is the resultant of performance of each and every component of the project. Components of the project means – various team members. These team members are assigned various tasks and sub tasks of the project. The result of these assignments collectively draws out the overall project performance at any moment.

    If any of the project tasks is not finished as per plan, the delay will effect the finishing of forthcoming tasks. Project manager has to be a good analyzer, critic and observer to identify the performers delaying the project from its plan. Once identified, the analysis can give the reasons of the delays.

    If these reasons are timely identified and addressed to, the delay can be shortened and the performance of the project can be streamlined.

    An eagle’s eye is required to identify the performance bottlenecks proactively to act upon to achieve the tasks as per plan.


    May 11, 2010  11:19 AM

    Project Management and Project Results



    Posted by: Jaideep Khanduja
    project management, project result, Software Project

    Every project has a number of milestones. The achievement of each milestone establishes a landmark covered in the project thereby reducing the distance to the final destination. The milestone is divided into a number of tasks which are further divided into sub-tasks. A set of tasks is assigned to a team and the sub tasks associated are distributed among the team members.

    Each sub task has two important coordinates. One – the owner who is supposed to perform this sub task and the time required to finish it. Completion of the sub task before the stipulated time is termed as ‘Successful’. Completion of any task/ sub task/ milestone beyond planned time marks it as ‘Delayed’. Non completion of any task marks it as ‘Failed’.

    Result of a task or sub task delivers many important hints. It sets the further direction towards other tasks/ sub tasks or milestones. If result is ‘success’ the direction sets towards further tasks. If the result is ‘delayed’, it impacts on other tasks. If the result is ‘failed’ all focus is set on the current task to make it success.

    This multidirectional focus on a single task has a propagating impact on further tasks.


    April 30, 2010  7:09 AM

    Two Questions for Quality Manager and Project Manager



    Posted by: Jaideep Khanduja
    customer requirement, Project Head, project management, project manager, project quality, QA, requirement analysis, software development, Software Project

    1. At times development, requirement freezing gets done side by side and that too at customer location. In that case the product undergoes a lot of changes based on customer feedback on daily basis and finally product gets ready as per development team and customer.

    After that it comes to QA for testing.

    Is that right?

    And how QA’s role differs here as compared to the scenario where customer requirements are freezed, product is developed, QA is done and then it goes for beta release, and final implementation

    2. What if requirements are not documented properly and development team is dependant on what is told to them by the person who went to customer site for business study. But this guy has no document signed by customer; in that case if he has understood the business processes wrongly, it gets coded wrongly.

    On what basis QA conducts the testing in this case?


    April 29, 2010  11:46 AM

    Project Management and Project Estimation



    Posted by: Jaideep Khanduja
    project budget, project composition, project estimation, project management, project resource, project team, software development, Software Project, software release, team composition

    No project can be started without estimations. The estimations are to be done about the resources, manpower, team compositions, budgets, releases, development and so on. Estimating software is not an easy task. Production estimations are simpler as compared to service delivery estimations.

    More machinery involvement eases your estimations. On the other hand the more human involvement increases your estimation pains. There are more chances of your estimations going haywired when you are totally dependant on man than a machine for delivery to a customer. Machine breakdown can be handled in a more technical and professional manner. But to manage people you need extra skills to manage all kinds of turbulence.

    Software project estimation can not be done just once in the beginning and then every thing moves accordingly. It has to be monitored, assessed and re-estimations need to be done from time to time.

    Estimation is an art and skill which gets polished with experience and time.


    Forgot Password

    No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

    Your password has been sent to: