Quality Assurance and Project Management


April 28, 2010  12:19 PM

Project Management and Project Measurement



Posted by: Jaideep Khanduja
project budget, project estimation, project management, project measurement, project metrics, Project Plan, project resource, Software Project, targets

Measurement is important to manage. We manage money in our bank by keeping a track of the credits and debits. The performance and versatility of project management goes in the same manner. There are plans, estimations, targets, budgets, resource crunch and so on in any project.

The ability to achieve the best results crossing all these hurdles is what makes a project manager and project teams successful. One of the most important purposes of measurement is to improve. Improvement is important in all aspects and in all directions. If customer requirements, software development, management goals and customer expectations all gel well and take care of each other, it will result into a win-win situation for all.

Measurement is also termed as Metrics. Project Measurement that way is known as Project Metrics. IT Metrics is the term used to measuring various processes and activities of IT.

Metrics methodology is quite important. Metrics helps in tracking project. It also helps in keeping all informed about the project current state along with increasing the productivity of the different teams working on the project.

April 27, 2010  10:44 AM

Project Management Methodology and Tools



Posted by: Jaideep Khanduja
project management, project management tool, project methodology, Software Project

Project management is an active stream worldwide. New methodologies and technologies are being produced and introduced from various corners of the world. Some organizations are quite active in optimization of software project management. By optimization we understand the productivity and quality increase. Some of the technologies and methodologies are not as effective as others.

There are certain standard analytical approaches used to evaluate and measure the effectiveness of such technologies or methodologies. Software maintenance is a long phase post project completion that manages the customer and product delivered. The shortfalls in the product delivered may cause a painful experience for the maintenance or the support team.

Every project needs to be managed. Different businesses acquire different methodologies and tools to do it. The level of maturity of the organization decides on the level of methodology or tools in use. It may happen vice versa too. Highly matured tools and world class methodologies may help gain high maturity to the organization.


April 26, 2010  7:21 AM

Why Business Requirements Matter Most in Project Success



Posted by: Jaideep Khanduja
business analysis iteration, business analyst, business requirement, project failure, project management, project success, prototype, software development, Software Project, top management

Business requirements and customer specifications when are met perfectly above 90% in the software built; such software has least chances of failing due to quality or customer acceptance. Definitely the time schedules are always important but such products where business requirements and customer specifications are understood well and built perfectly in the software will require least changes at later stages.

The objectivity of project management is fruitful and worthy in such cases. Success is mostly ensured if such factors are well kept in mind right from the first stage of the project.

It is not easy to capture the complete, accurate and clear customer requirements due to many factors. Some of the prominent factors could be:

  • Non-clarity of business goals to be achieved
    Wrong users chosen for prescribing business requirements
    Wrong scope defined for Business Analyst
    Incapable Business Analyst
    No Top management involvement from either/ both sides
    Language barrier especially in case of overseas project

  • These are few of the major reasons
    but not all. In real scenario sometimes all requirements do not emerge in one go at the initial stage. They evolve along with the discussions, meetings and brainstorming.

    In such cases the project goes in iterations with the building of prototype of the ‘so-far’ understood product and its demonstration to the customer for two reasons –

  • 1 – to get their consent that the product is moving in right direction;
    2- to move ahead in terms of requirements and building of product.

  • April 25, 2010  7:31 AM

    Software Project and Product Cost Models



    Posted by: Jaideep Khanduja
    project cost, project management, software development, Software Project

    If customer requirements and business process are not the top priority during the software development; then the software built will have a very short future and less commercial value. This is because, if the software can not cater to manage or enhance any business, its demand will be very low in the market.

    The low demand impacts on the commercial value of the product mostly. Even if a very low priced product is in high demand in the market due to its high business value; an increase in its commercial value will not affect its growing sales. As long the software acts as a strong business tool, its demand keeps increasing.

    Rather if we see some quite low value products do well in business profits due to very high volume sales. One way of deriving at the product value is to calculate the number of man months spent on the development of the product. This costing model works where the product is focused on a single customer. Development of the product means the complete development cycle including testing, rework etc.

    But sometimes this cost is so high that product can not be tagged with this price. Then the costing model is worked on division of total cost of the product incurred to the estimated number of customers per year. The total cost is planned to be recovered in a three years or five years model.


    April 24, 2010  5:02 PM

    Software Project and Business Purpose



    Posted by: Jaideep Khanduja
    business application, business process, business requirement, process owner, project management, requirement analysis, Software application, Software Project

    The purpose of a business seeking software application to cater to a business process or a group of business processes is to optimize the business. The requirements emerge through the key process owners of the business. The requirements analysis and gathering phase is the most crucial of all stages of a software project.

    Any software organization which does not understand the gravity of capturing of right set of business requirements in the first go, can never deliver the right product to its customer. If software is built for the sake of building some features and functionalities without understanding the real business requirements; the software can be a good showcase for demonstration purposes but can not be a useful tool for any business.

    The business requirements broadly are spelled out by the top management along with the identification of core business process owners in the organization to further explain the requirements upto the micro level. These core business process owners need not necessarily be the top management.

    Infact mostly they are not. These are the people who are there with the organization for some considerable amount of time. This is not the only reason for them to qualify to become core business process owner. They must be in the main driver seat. Every department or business process comprises of some people who drive the business process.

    If requirements for any business application are not taken seriously, it not only hampers the targets and budgets but also create a deformed product.


    April 23, 2010  9:30 AM

    Project Management and Project Defects



    Posted by: Jaideep Khanduja
    Bug, business process, project defect, project management, software development, Software Project, software requirement, software testing

    A study shows that incomplete, improper or imperfect requirements collection during business and requirement study leads to 70% defects in the final product. The shortfalls in the software product delivered to customer affect its business process not only initially but for long. As long as, till the shortfalls are identified and fixed.

    Each shortfall accounts for a risk. Each risk calls for mitigation.

    Usually customers either are not able to identify the shortfalls completely during the implementation phase; or the incomplete identification does not lead to the proper fixing plan. Some fixes may require a major overhaul of the product. Gradually, customer compromises with the shortcomings of the software and starts using it as it is. Sometimes such a compromise may even lead to a change in the business scenario/ process in practice, which no customer would like to.

    Incomplete requirements have a long lasting impact on the product to be developed and leads to a big scope of loopholes in the product segment as and when it gets developed. The entire teams get into wrong loop without even realizing the wrong direction being taken by them. The quality team, for instance, may have done a wonderful job in testing the product by reporting complete range of bugs. But tragedy is that the testing is based on wrong base of requirements thereby putting a big question mark on the report submitted.

    At a later stage when awakening happens regarding the requirements, it might be too late to revert back or a big chunk of the product may require complete overhauling. Sometimes it may require even scrapping of what has been developed and the entire team may have to build entirely a new product to cater to the later understood business needs. This will lead to complete product lifecycle stages of development, testing etc.


    April 22, 2010  8:12 AM

    Software Project and Project Budget



    Posted by: Jaideep Khanduja
    management control, project budget, project delay, project management, project manager, project monitoring, Project Plan, project strategy, project team, Software Project

    Around 50% of software projects either overshoot the timeline/ targets, cross the stipulated budget, or do not satisfy customer regarding the features and functionalities. The plan overshoot is definitely deciding factor for the budget overshoot. These delays not only affect budgets, schedules, organizational reputation etc. but also decrease the customer base and business.

    Overshooting of timelines or planned targets is bound to happen to cause budgetary turmoil. The causes of delay in timeplan could be many. It may effect due to:

  • 1. lack in strategy,
    2. shortage of manpower,
    3. lack of management control,
    4. unclear customer requirements,
    5. ambiguous or unreal plan,
    6. change in team members,
    7. project manager’s knowledge,
    8. lack of technical expertise,
    9. lack of functional expertise,
    10. and so on…
  • Delays do happen even in most properly handled situations but the worst is the quick response to manage them and turn the soar situation into sweet.


    April 21, 2010  7:18 AM

    Software Development Project and Rework



    Posted by: Jaideep Khanduja
    business analyst, Project Development, project implementation, project management, project requirement, project rework, project team, requirement analysis, requirement study, software development, software implementation, Software Project, software requirement, software rework

    As per study software development team on an average spends almost 40% of their time on rework. The rework requirements may arise by way of – development team revisiting their code and finding out some lacunae; Quality control test/ bug report; or requirements fine tuning at customer end during the implementation or UAT phase.

    Requirement fine tuning and new requirements arising during the various stages of a project are two separate entities. It is very important to identify and keep track of both. Fine tuning may arise due to lack of understanding business requirements during requirements study phase. It may also arise due to the lack in giving a proper understanding by customer to the requirement analysts. The reason for this may be lack of involvement at customer end, wrong selection of key user or else.

    New requirement arising during the development or implementation phase is again due to both the reasons mentioned above. The new requirements arising at the implementation phase are very dangerous and deadlier for both ends.

    The earlier identification of new requirements or tuning requirements ask for less efforts as compared to these getting identified at a later stage.


    April 20, 2010  10:01 AM

    Software Project Success in Human Context



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

    Using best methodologies, procedures, tools and practices do matter. But what matter more is the human factor. It is the people who have to drive the project. As best people under perform in subdued conditions, similarly the best of the tools and methodologies will not be able to get you the optimum benefits out of them unless you have good team members, administration staff, team leaders, project manager, tester etc.; if not the best.

    These are the people who are going to work according to the pre-set methodologies using the available tools to give you the best results. It is not either-or condition. It is ‘and’ condition that works here. All above have to be good. The people, the methodologies, and the tools. Definitely one thing more that will work as a booster, will be the management policies and strategies.

    Methodologies once adopted are sustainable, tools once built or procured are also sustainable. It is the people who are volatile. Their sustenance is the most difficult part during the ongoing projects. Someone leaves the job, someone goes for a long unplanned leave, someone gets de-motivated, someone doesn’t like the way things are being handled. There are n no. of reasons for not doing a job and not delivering the best.

    People who love their organization deliver their best. It is the passion that drives the people, passion with the organization, passion with the work. This drive derives the desired deliverables.


    April 19, 2010  9:54 AM

    Software Project Turning into Success OR Failure by use of Tools and Methodologies



    Posted by: Jaideep Khanduja
    project failure, project health, Project Lifecycle, project management, project management tool, project methodology, project monitoring, project progress, project success, project tool, software methodology, Software Project, software tool

    Software project may finally result into success or failure depending on certain factors. It doesn’t exactly depend only on the methodologies and tools adopted during the project lifecycle. It also depends on the human factor comprising of administration, team members, team leaders, project manager, management strategies and above all the culture of the organization.

    The methodologies and tools on one hand do help us in tracking of project progress and assessment of project health at any moment during the project lifecycle. It depends on the quality of tools adopted and the standard of methodologies in use. The whole process of tracking and assessment via methodologies and tools may range from the simplest manual process using word documents as standards and excel as assessment tool.

    The next level could be by using some simple project management tool like MS Project. If cost is a constraint initially to spend on tools and methologies – there are certain open source, free of cost project management tools available. Some of these tools are quite competitive with the cost based tools. The detail of such tools can be searched over the net or may be requested from the author.


    March 29, 2010  10:21 AM

    Ability to Change Vs Organizational Rules



    Posted by: Jaideep Khanduja
    enhancement, guideline, management, optimization, organization, organizational rule, process

    An organization is driven by some set of rules. Few of these rules are so hidden in the process that they are not visible or known clearly. But those rules keep being followed inherently. Other rules are quite transparent, visible and known clearly.

    The organization behavior, management style of working
    etc reflect these rules or are guided by these rules. The governance is so automatic and self driven in most of the cases that which rule is governing or deriving what decision is sometimes difficult to find out. The management and employees are thus so accustomed to this scenario that they forget to think about any change in the working style or find a solution to some problem in an innovative way.

    There is no defined guideline or process in most of the organizations
    to identify or review these rules from time to time. This calls for the same rules, hidden or visible, be followed year over year without being challenged for a change. Though the requirements may have changed which may need these rules to be reviewed and changed, it keeps going on and on without any notice.

    The management’s involvement in this scenario is quite important
    as the people down the line either are unaware or not authorized to ‘change’. It is the prime role of the management to review, assess, and identify the rotten eggs from the basket and put them in ‘to change for better’ bucket. Then a separate team can work upon the change required in those rules for the purpose of optimization or enhancement.


    March 25, 2010  10:24 AM

    Five Points to Prove Test Team as Major Stakeholder in Software Project



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

    1. One big mistake that a project manager makes is that testers are not treated as major stakeholders in the project.

    2. Development team has a misconception of treating tester as someone policing and pinpointing loopholes in developer’s area of expertise.

    3. The test team is intentionally kept out of loop upto a certain stage of the project.

    4. The knowledge transfer from development team to test team starts at a later stage and immediately they are told to start testing without providing them ample time either to absorb what they have understood about the customer business or to prepare test cases for complete coverage.

    5. The bugs reported are not taken as seriously as they are reported – usually the bug closure priorities are set more on the basis of time required to fix a bug or the time left to release rather than the severity of the bug. Most of the project meetings are conducted without test team involved in it – and worst thing is that a lot about quality is discussed in such meetings.


    March 22, 2010  11:20 AM

    Dilemma of a Tester



    Posted by: Jaideep Khanduja
    Bug, bug report, developer, project management, software development, software testing, tester

    A tester’s prime task after testing a product is to describe the bug. The development team while receiving a test report of a product from tester expects a detailed bug report. The report should be presented in such a way that is easily understood by developers. The point of confusion most of the time is a tester while reporting a bug, if know the best possible solution to be incorporated in the product. Should he report it as a part of his bug report or keep silent about it and let the developer explore the solution on his own.

    There are two aspects to it. There is already a feeling in development team that whatever they produce goes to test team for finding bugs or any other inconsistency. This does not give a comfortable feeling to development team. On top of it if a tester tries suggesting a suitable solution for fixing a bug, the developer might get hurt.

    This might give him a feeling that on one hand the tester is exploiting the code written by him to find out bugs. On the other the tester confidently suggesting a suitable technical solution to fix a bug to a developer, might give him a feeling that his knowledge is being challenged. This might be taken by the developer as a two way attack.

    The tester has to be quite cautious in suggesting a solution for fixing a bug reported by him.


    March 19, 2010  12:07 PM

    Five Operational Tactics Project Manager Needs to Understand



    Posted by: Jaideep Khanduja
    milestone, project management, project manager, project phase, project stage

    1. During all the project management phases, each process should be clearly having operational key indicator metrics to measure the health of the project at any stage.

    2. Approvals, decisions, milestones, tasks, micro tasks should not become a hurdle for the project.

    3. People driven project has less chances of growth as compared to a process driven project.

    4. Pace, growth, acclamation, business and revenue can be achieved with the help of benchmarks, standards, methodology, procedures, reporting etc. on one hand and engagement, personal growth, commitment, employee delight etc. on other hand.

    5. People are not bad – neither those who are part of management nor those working below. It is the process and procedure of management that makes the difference.


    March 18, 2010  12:30 PM

    Eight critical Ps in the Life of a Project Manager



    Posted by: Jaideep Khanduja
    project management, project manager, project reputation, project stake

    Peers: There is always a peer pressure, right from our school age. There are people who always try to make you feel inferior, or insignificant so as to increase their importance of for any other purpose. The same happens in corporate world too. There will be people at your level who will try to highlight your shortcomings or failures in front of the management just to hide theirs. A minute issue will be reflected as a bottleneck by them. They also do with the intention that you be always in defensive mode and they be always be in attacking mode. Management’s role is very important in such scenarios. How to cut such person’s intentions is your area to understand and act.

    Project: Project is bread and butter for a project manager. He can not afford to delay or failure of a project. The project reputation directly reflects on the organization reputation and further business. It is also important for the sake of your own progress.

    People: You will find all sorts of people in peers, subordinates, juniors, seniors. Some may like you, others may dislike you. Winning second lot is an important factor. Once you manage to win such people, it will always help you in managing any team.

    Plan: Promises are made to break. Plans and commitments are made and presented not to be adhered to. This is not possible in Projects. A single failure in adherence to a plan’s task or commitment needs introspection. Remember the famous saying – “Never repeat a mistake”.

    Priorities: Learn to prioritize your tasks. Out of hundred tasks in your hand you cannot focus on all at the same time. You need to prioritize your tasks and finish them as per priority set. Remember – “You cannot eat an elephant in one go”.

    Prestige: Your Project prestige affects your own prestige in the organization. Honor your words and commitments given to anyone – be it team members, management, customer or peers.

    Presence: You need to make others feel your presence in your project. You should not be ignored in any decisions related to your project. After all if it is you who owns the success or failure of the project, how can a single decision related to it can be taken by any one else without your consent.

    Patience: Patience is very important. People around will try to exaggerate situations, excite you to react abruptly or make you give wrong commitments. Don’t react too hurriedly in any case. Understand the situation and act accordingly.


    March 15, 2010  11:55 AM

    Ten Ideas to consider Customer Key Users as Major Stakeholders In Software Project



    Posted by: Jaideep Khanduja
    key user, project management, software development, Software Project, stakeholder

    1. Key users are selected based on their organization engagement, knowledge about the business; and their own area expertise.

    2. The selection criteria also depend on their openness and acceptance to adaptability, manageability, and their goodwill.

    3. Key users play a major role in representing their organization in terms of defining business requirements to the business analyst thereby defining the scope of the software requirements.

    4. Key users group play a vital role between their management and the product.

    5. During the development phase key users can help development team to a large extent in checking and confirming if the requirements are getting built in the right manner.

    6. The product specifications derived from business requirements when built are demonstrated to the respective key users for confirmation.

    7. Key users have also to ensure the proper cross integration of the business requirements embedded into the product.

    8. The Key users are responsible for a long term tie up with the product when handed over to their organization.

    9. Key users are not only responsible to manage the product but also to keep educating the new recruitment connected to the product function.

    10. For any change in the business requirements, it is the key users who are expected to get it built in the product.


    March 11, 2010  6:29 AM

    Project Manager and Project Pressures



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

    You have many projects running in your organization. You have to compete with peers, competitors, time, money and yourself to manage these projects to finish in time. There are clashes in priorities among various project timelines. You have instances when you have to change your priorities depending on situation of various projects. These changes might be due to people involved in the project, customer, management, technicalities or functionalities. As your project is at stake and need to be finished in time, others also have the same needs. With the limitations of scope, people, knowledge and involvement; you have to cope up with all situations to strive and thrive.

    At times a project manager has to reprioritize and reschedule. Reasons could be many or any. It may be the demand of the situation that a project manager is forced to change his strategy, plan or methodology. Only word of caution is that the more frequently it happens during a project; more hassles are created for him and the team. More so painful it becomes if no standard process is being followed in the organization to mange projects. Whatever may the situation be; the changes should be visible clearly to everyone across the teams involved in the project. Though it will be painful and challenging for the project manager to manage but it has to happen as it is very important to be on the same carpet.

    Such intense situation help project manager and team members mature faster
    . The project manager gradually has to expertise in key tactics and deep insight to manage current project and forthcoming ones.


    March 10, 2010  9:00 AM

    Ten Ideas About Customer Management As Project Stakeholder



    Posted by: Jaideep Khanduja
    customer management, project management, project stakeholder, Software Project

    1. Customer Management: Usually the top management’s involvement is very important during any stage of a project.
    2. But tragedy is that they contribute too less in the project.
    3. They consider themselves as the busiest person on this earth and for this reason they direct others to invite them only when crucial decisions are to be taken during a project.
    4. They keep themselves limited to only crucial decisions and are unaware during the project what is happening under the water.
    5. Since they don’t carry the actual knowledge of the progress of the project, they go by the feedback from their down the line people engaged in the project.
    6. In such a situation their decision may change the direction of a project in wrong direction as it is highly under the influence of someone else in the team.
    7. The person influencing such a decision may himself be having less knowledge of the project or be having some strong biased outlook towards the implementation party.
    8. Top management will keep themselves engaged in other critical issues being faced by the organization to escape from the ownership of the project.
    9. Though it is the customer who is sponsoring a project and paying money for that, but their internal unity becomes a big issue at times thereby giving birth to politics.
    10. Sometimes ego among the top management too create silos and conflicts thus effecting a good project and team with wrong results.


    March 9, 2010  9:15 AM

    Project Stakeholders



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

    There are many stakeholders having different proportions of stake in a software project. Some stakeholders engage themselves during the complete lifecycle of project; others feel their presence is not crucial for every stage of the project. If any stakeholders feel themselves in the second category, they are not only doing injustice to the project but also to their role and responsibility. A stakeholder may not be required to produce results or give decisions at times during the project lifecycle but their engagement is unimportant is a misnomer.

    The major stakeholders whose contribution is most important in a project affect the progress of a project to a very large extent. Some stakeholders merely assume their role to sign the reports and project stage sign off without knowing the real state of project. Others assume just to be meeting icons. Some keep finding excuses to skip project meetings. Some stakeholders will have ample time for anything else except project. Some stakeholders will be very judgmental in giving their opinion about the future of a project right at the time of its inception. If they are so correct about their predictions, probably they should consume their talent in being a little proactive and finding out ways of mitigating their predictions about something going wrong with the project.


    March 6, 2010  9:00 AM

    Seven Steps for Risk Management People Management and Project Management



    Posted by: Jaideep Khanduja
    high risk, people management, process, project management, Risk analysis, Risk Management, risk mitigation, Software Project

    Any project, small or big, is bound to have risks. Risks perceived can be managed well as an advanced risk management plan can be prepared with the ways to mitigate the risk. Risks that are not perceived during the risk management plan are bound to create chaos and unplanned handholding at the time of its occurrence which may not necessarily be the ultimate way of managing the risk.

    Following steps
    can help you in identifying, managing and planning the risk mitigation:

    1. Analyze

    2. Allocate right resources and efforts to manage the risk depending on the level of the risk.

    3. Form right strategies

    4. Higher the risk (severity) does not always mean spend large amount for mitigation. A combination of severity of risk and its chances of occurrence will formulate its mitigation procedure and plan.

    5. All risks may not occur that are perceived. All mitigation plans will come to use. Some risks that were never thought of will definitely occur sometime or the other. An ad-hoc mitigation plan will be required in those situations.

    6. Planning, Testing and performing is very important. Planning alone will not suffice the purpose. Performing without a proper planning or testing may end up in unwanted results.

    7. Attack the system or process not the people. It is lack of system or poor process that causes risk management ending up in unpredictable results. People love to live in discipline provided it is for all and not person based.


    March 5, 2010  9:27 AM

    Three Types of Project Managers to Manage Problems



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

    Problems are the reasons for opportunities. If there were no problems there would have been no opportunities, not much challenges, not much jobs, not much talent hunts. Tell me a project which gets completed without any problems. Tell me a person who has had no problem in his life. Tell me a day when there was no sunset at the end of it, all dark; and a bright sunshine after some hours back bringing the life and spontaneity.

    Well, philosophy apart, there are three type of project managers to deal with problems in their projects. Each one of them has a different approach to handle, manage and tackle the problem. Each one of them is able to bring back the normal situation to make it appear that there is no problem. But, by the way each one of them handle the problem, you can clearly tell whether the problem is suppressed, hidden or vanished. The three approaches are:

    1. Suppressors: This type of project managers will have a unique approach of managing the problem by finding out the team members who have created the problem. They feel that by punishing the people behind the problem will resolve the issue. It does, indeed, but not for a long time. It reoccurs, because people are people. They are not process.

    2. Hiders: This type of project managers will not focus on the problem or the team members who are problem creators. Rather they will make their target the people who highlight the problem. The purpose is to keep the wall neat and clean. What is happening behind the wall does not matter at all. So intention of such project managers is to keep the rosy picture in front of the management without giving them a hint of lava boiling underneath.
    3. Vanishers: This category of project managers will neither target the person who creates the problem or the person who brings it to the table. They will find out the loophole in the process that allowed the team member(s) to create a problem and fill it forever; so that such problem never emerges again.

    Vanishers are better than both suppressors and hiders.

    If processes are intact, in place and perfect (rather near to perfect, as perfect is an imaginary, unrealistic state); any sort of people will have to follow the process. The Vanishers believe that process driven projects are bound to be more successful than people driven projects.


    March 3, 2010  3:03 PM

    Five Reasons to have A Product Development Consultant and A Product Development Manager



    Posted by: Jaideep Khanduja
    development consultant, Development Manager, product consultant, product manager, project management, Software Project

    For any software product development, the product can be managed in two manners by either giving the development and deployment charge to an internal product development manager or by hiring a product development consultant to manage an in-house team of developers. The same applies to the development of any product.

    A parallel approach is adopted lately by many organizations by having the both. That means there will be a product development consultant and a development and delivery manager both working on the same product.

    Why would that happen?

    5. A consultant will never own the product or be responsible for the timely delivery. A product manager will have to do the both.

    4. A consultant can be a front end for the customer featuring the highlights of the product or understanding their requirements for mapping and finding out the gap. The development manager can keep concentrating on product features and committed deliverables.

    3. A consultant will be acting somewhat as a bigger umbrella over the smaller umbrella called product manager thereby giving double protection to the product and a shield to the product manager.

    2. A product manager will focus on both – making the product feature rich/ stable and delivering on committed date whereas consultant will focus more on customer requirements enablement in the product and getting it done from the product manager.

    1. The overall control of the development team will lie on the product manager. The responsibility of providing an extra edge of technology or feature will also lie on the consultant.


    February 26, 2010  1:00 PM

    Five Stages of DONE in Project Management



    Posted by: Jaideep Khanduja
    milestone, process, project management, project stages, project task, Timeline, timeplan

    A Project is nothing but a collection of tasks, milestones and activities. These are managed with the help of some standard methodology, process and procedure. In every stage of project we are supposed to perform some tasks, achieve certain milestones by the way of performing activities. The tasks for distribution purposes are broken down in sub tasks and sub-sub tasks (and further on…) to manage and monitor them in right manner. A set of tasks will make you achieve something considerable that can be termed as milestone.

    The five stages of Done can be:

    5. Done: This is the best stage for any task during any project phase. Satisfaction level and tempo of the teams concerned would be at the highest level.

    4. Reasonably done: This is quite satisfactory though lesser than the above stage. This stage still carries a high level of the probability of it reaching the above stage unless it is stuck at some point where a solution is not feasible.

    3. Partially done: This is No-win, No-lose stage. Team would not be happy at this stage but still would be having an urge to speed up the process to bring it to Done stage.

    2. Minimally done: This will be an indicative of something serious happening in the team. The cause could be either lack of right people, right technology or right direction. The chances of death will be higher than life unless some miracle happens.

    1. Not done: This is a dead situation already. An immediate introspection will be required to do a deep analysis to arrive at a conclusion that whether to try it once more or call it off.

    Mind it that any task, milestone has no meaning unless it is bound with a timeline. The above situations have a meaning only when a task is associated with a timeplan.


    February 24, 2010  12:13 PM

    Five Points to do Justice with Your Project Information



    Posted by: Jaideep Khanduja
    Development Manager, project information, project management, project manager, quality manager, Software Project, stakeholder

    You might be a project manager, senior management, customer management, customer project manager, quality manager, development manager, business manager. That makes you an active and responsible stakeholder in the project. Your role is not just to release or collect that piece of information at regular intervals; and dump it. If you do that, you will be the happiest person on this earth only till you are not caught doing it and are not dethroned. Your job and responsible position in the organization also will not allow you to just sit over it and focus on some other activities.

    A running project is the prime objective of the organization and nothing can take priority over it. The main focal points about Project Information can be prescribed as:

    5. Project information is very critical and important. Look from your perspective if it is completely satisfying your needs according to your job function. If it is claimed to be complete but insufficient for your respective role in the project – claim it, shout out, demand it.

    4. Look at the project information as a critic. It might be ok for you for the time being but may be lacking some information that you will require at a later stage. Look at it at the point of valuable repository point of view.

    3. Put yourself in every other stakeholder’s shoe and examine the information that is being generated and delivered. Someone in your peer’s section performing some other role might not able to examine it whereas based on your experience, learning, and knowledge – you might be able to help him to point out the missing piece.

    2. Ensure that the information and its flow are following some standard methodology/ process. This is in respect to the frequency, timeliness and accuracy of the information.

    1. Be an agent of your top management. Sometimes top management at both the ends might be involved in some other priority/ activity. Inform them appropriately about the green and red areas of the information to them and seek their guidance or give suggestion for some immediate actions if required in certain areas.


    February 23, 2010  12:35 PM

    Ten Insights About Project Information



    Posted by: Jaideep Khanduja
    information flow, information flow charter, project charter, project information, project level, project management, project manager, project milestone, project projection, task breakdown

    1. A project is associated with lot of information flow.
    2. Be it any stage of the project, information is very important to understand if a particular project is progressing, accelerating, decelerating, not moving, illumined or merely under the influence of illusion.
    3. If information flow is not appropriate or not feasible to access to relevant associate partners of the project (stakeholders), it may appear to be progressing in right direction but it might be assimilating lot of heat under the earth to burst a volcano at a later stage.
    4. Sometimes that later stage could be very dangerous. It could be a stage where nothing is possible to recover from. It could be a stage where it is too late to go back and start the journey again. The starting point could be too far at that moment and invisible.
    5. Project information is the right amount of information without any complexity to make everyone connected to project clear about the status of the project.
    6. The information flow should be clearly defined (process of information flow).
    7. It should also be available to right people in right amount at right time.
    8. The information should tell about the milestones achieved, milestones missed (with age analysis).
    9. Information should also tell about the micro level tasks (sub tasks and sub-sub tasks breakdown) targets and actual timelines.
    10. Project Manager is straightaway responsible for not presenting the right information to right people in the project. Any wrongdoing in terms of information (wrong projections, inappropriate projections, false projections, incomplete projections etc.) should be the overall responsibility of Project Manager.


    February 19, 2010  8:00 AM

    Two 360 Degrees Aspects of Reputation Management



    Posted by: Jaideep Khanduja
    project management, Reputation risk, Software Project

    A reputation risk associated with a product is prone to cause a ‘bad’ reputation to the product. But reputation management does not limit itself only to mitigate reputation risks. Its other purpose is to increase the ‘good’ reputation factors. One way is to decrease the reputation risks which itself will increase the ‘good’ reputation. It is because if product keeps running smoothly without giving any trouble to the user or customer, the product is bound to have a ‘good’ reputation. A good reputation will definitely boost the morale of the organization that sells the product. And will also increase its reputation in the market, with a chance to increase its sales.

    Both good and bad reputation can’t survive together for a product. It is the net resultant of the both, but not always. Sometimes a bad reputation factor overpowers many good reputation factors. A decrease in bad reputation or increase in the good reputation may or may not impact on organization’s increasing profits to a large extent, but a bad reputation spread in the market will definitely cause damage to the product further growth in terms of sales.

    Both the aspects are equally important to focus upon.


    February 17, 2010  7:00 AM

    Five Different Levels of Reputation Damage



    Posted by: Jaideep Khanduja
    Project, project management, Reputation risk, risk mitigation, Software Project

    As we know a risk to a product is connected to the risk to the management or organization using that product. The higher the damage involved with the risk the higher is the mitigation procedure required as a countermeasure. The reputation damage of the product not only affects the company using it but it affects highly to the company who has designed the product. There is one case when the high reputation risk occurrence will affect only the customer using that product and not the company who has produced that product – and that is the case when product is perfectly designed ok but has been used wrongly (or misused) by the end users of the customer organization.

    The reputation risks causing damage to the reputation of the customer can be classified in following categories:

    1. Non-significant Damage – Non signification or very minute risks will not cause any impact to the usage of product neither to the reputation of the product of customer. But when these non-significant risks start occurring in a higher volume the irritation to the user turns to a significant size.

    2. Minor Damage – These types of risks cause minor reputation damage to the product. These could be divided in two categories. Either some non significant risks start occurring in a high volume or some significant risks start happening.

    3. Moderate Damage – These risks are better to be identified in advance and must be handled accordingly. The moderate risk in the product will be prone to cause moderate amount of damage to the company using the product.

    4. Severe Damage – These category of risks if identified already in advance and have not been mitigated, are like mini bombs existing in the product. The product owner releasing the product with such risks or the organization using the product knowing it has such risks are not doing the right thing. Only case where such risks existing in the product but not causing any damage is if they do not occur at all. Or if their chances of occurrence are too small, then the chances of damage also become negligible. But that is rare since the risk lying in this category has significant amount of occurrence.

    5. Deadly Damage – Something occurring and causing such a high impact to the organization that its survival or existence becomes an issue.

    Any risk that has been perceived already becomes the part of risk management document where its mitigation plan is already must be existing.


    February 15, 2010  8:00 AM

    Four Commandants for Project Manager to be a Good Proxy Customer during Product Development



    Posted by: Jaideep Khanduja
    business analyst, business requirement, product development, project management, project manager

    There is no harm in owning the product (on behalf of the customer) by the project manager during the development phase, but keep some key points in mind while doing it:

    1. Ensure the business requirement documents are well in place and are quite exhaustive in nature to pin down the minutest of the business process that is to be built in the product

    2. The availability of business analyst to answer a query related to the customer business as there are chances to skip documenting (unknowingly) something related to business which is clear in the business analyst’s mind but has not been documented clearly.

    3. Be a ‘proxy customer’ in terms of clarity of business and processes so that you are able to guide your teams in the right directions.

    4. Keep customer involved in the queries resolved and solutions proposed for the product as there should not be a gap between what you think as the right solution to a query and the actual solution what customer would have proposed. This is applicable for all business process and requirements issues.


    February 14, 2010  8:30 AM

    Who Exactly is the Product Owner – Customer or Project Team



    Posted by: Jaideep Khanduja
    product development, product owner, project management, project team

    Product development requires day to day interactions and query solving of the development team related to the product. The customer presence is not extensive and hence most of the product related queries have to be resolved by the project manager.

    The business analyst becomes the handiest useful key to help project manager in resolving these product related queries. The business analyst is the only person who so far has interacted with the customer management and the end users to understand their expectations and requirements. That is why input of business analyst in such queries will be much more accurate than anyone else in the team. Infact sometimes even the customer will tell you to decide on your own if a nitty-gritty query is shot upon them to build a particular functionality or process in the product.

    As long as the product is not ready to launch it is not a problem if the customer decided not a “own” it in real sense. This happens exactly. The customer has a mindset that he is “helping you” in building the product rather than taking the ownership right from the beginning of the project and deciding upon the direction of the project.


    February 14, 2010  8:18 AM

    Product Ownership – A Weirdly Sensible Philosophy



    Posted by: Jaideep Khanduja
    Product ownership, Project Development, project management, project manager, project team, software product

    It is not difficult to answer who is the product owner. Obviously the answer is – “customer” who is paying for the product. Ownership always consists of two aspects, in all circumstances, everywhere in the world. The two aspects are “joys” and the “pains”. I buy something from the market – say plasma TV or a new mobile handset. I keep enjoying the comfort it brings with it and don’t mind even if I don’t share the “joys” with anyone else. But the moment it gives me a trouble or “pain”, I would like to involve the dealer, the product company representative and so on to share my pain or get me relieved of it at the earliest. I even won’t mind it sharing with my friends or family members to discuss the trouble it is giving to me and asking for a suggestion from them. Though these could be the persons not related to the product directly (or indirectly) or were not a least involved in the decision of buying this product.

    So that is the basic philosophy of life. The more reluctant we become in sharing “joys” of life, the more it gets turned into “pain” to force us to share. As the mindset is – the moment we start experiencing “pain”, we seek its solution, thus involving the people most suitable for giving us a solution.

    Human tendency of giving the “credit” of “joy” is mostly to himself; and assigning the “blame” of “pain” to someone else.

    The same if we summarize in terms of a project, customer, and product – the customer will prefer to say least amount of words if the product is trouble-free but will speak more than his “heart” out in case of a small trouble the product starts giving.


    February 8, 2010  10:06 AM

    Six Assured Steps to Become Worst Project Manager



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

    1. Vision and Leadership: As a project manager never provide any technology vision and leadership in the development and implementation to your teams engaged in your project.

    2. Planning: No planning must be done to build your customer’s operations in the application you are building. Thus this way you will not be required to provide any support at a later stage (since the project will never get over!). In worst case if you are forced to plan, plan for a most ineffective and costliest solution.

    3. Strategy: Build a strategy to enhance all sorts of problems in the development, evaluation and coordination during your project.

    4. Communication: Communication is your worst enemy. Build and maintain least communication between your teams, management, customer and other stakeholders involved in the project within and outside the organization.

    5. Productive System: If you build a productive system, it will definitely stop the growth of end users. Let you be humane enough to not to stop them lose their productivity in any manner by giving them an effective system. Guide your development team to build simplest of the business requirements in most complex manner in the application.

    6. Training: As a project manager do not plan any training for the product to the customer management or the end users. Even if you plan some training, you will not be able to conduct because you are not aware of the system you have built for your customer.


    February 5, 2010  1:21 PM

    Five Ways to Increase Project Risk



    Posted by: Jaideep Khanduja
    project charter, project definition, project deliverables, project management, project objective, Project Plan, Project Risk, project scope, project team, project vision, Risk Management

    1. Project Definition: Either don’t define your project or define it in most ambiguous manner so that even if you read it again, you are not able to make anything out of it. Don’t define Project Charter comprising of project vision, project objective, project scope and project deliverables. This way you will never come to know what is to be achieved. So How to achieve and when to achieve will never bother you except that your project risk will shoot up manifold. And that is what we intend to do here.

    2. Project Plan: Once your project definition is prepared in most ambiguous manner, start preparing your project plan in such a manner that it never sees the light of the day.

    3. Project Team: Comprise your project team with lousiest people in the organization and give them liberty to do whatever they want to do. Don’t bother if they don’t understand what this project is about since you even don’t know this. Moreover if they come to know what this project is about, your task will increase. You will have to assign tasks to them and in turn your accountability will increase thereby decreasing the risk.

    4. Project Risk Management: Do no risk identification, assessment, or risk mitigation plan even if you are able not to follow above steps.

    5. Reward Scheme: Announce a reward scheme in your organization that whosoever will create risk for the project will be rewarded accordingly depending on the level of risk created. Motivate your employees, team members to contribute bigger and bigger risks to the project.

    Though by following these steps you deserve the Highest Risk Creator Award but don’t be so selfish. Let it go to someone else. Trying is no harm, maybe someone else in the team is more talented than you.


    February 5, 2010  10:33 AM

    22 Ways to Increase your Project Success Rate



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

    1. Overcome constraints
    2. Increase quality of service
    3. Drive your team to perform better and become more productive
    4. Keep yourself and your teams Happy
    5. Have a stable and consistently improving process mechanism in place
    6. Transform your teams to High Performing Teams
    7. Keep your benefits higher than cost
    8. Set your goals clearly
    9. Drive yourself and make it mandatory for everyone in the team, your business will be driven automatically
    10. Have useful self assessment tools in the organization to be used by everyone
    11. Maintain bold leadership
    12. optimize for Excellence, not success
    13. Convert your process bottlenecks to process accelerators
    14. Stand up to Threats
    15. Have employee performance management system
    16. Have a clear visibility on the work of the team
    17. Maintain a delivery Cadence
    18. Optimize software quality procedures
    19. Maintain service and support driven by SLAs
    20. Have a good communication system in place
    21. Base your development on project objectives driven through customer requirements
    22. Address all business situations


    February 1, 2010  11:40 AM

    Six Contributors to the Reputation Risk of Your Software Project



    Posted by: Jaideep Khanduja
    project management, Reputation, Reputation risk, Software Project

    Reputation and reputation risk both are estimated during the project and the way it progresses while crossing its milestones. The customer is the last milestone in any project and it is the external agency like customer or the market from where the reputation or reputation risk is established about a product. Reputation and reputation risk are inversely proportional to each other. The Reputation on one hand brings in more business and orders. The higher reputation risk brings in a threat of lowering in business or product sale.

    No organization or product owner wishes for a higher reputation risk. Though every product is associated with some percentage of reputation risk it will be foolish for a product owner or project manager if the risk assessment is not done well in advance and the appropriate steps are not taken in advance to mitigate the risk.

    Six major contributors to the software project are:

    1. Customer – end users, customer management
    2. Product requirements – not well told, not well understood, not well documented, not well translated into the product
    3. Project Team – documentation, development, testing, implementation, training
    4. Development Process – how well the product has been understood and developed
    5. Product Testing – it is not the tester but the testing procedure that matters more
    6. Implementation Team – sign offs, training, meetings


    January 29, 2010  8:05 AM

    Ten Reasons to Adopt Hoshin Kanri for Project Management



    Posted by: Jaideep Khanduja
    Hoshin, hoshin kanri, kanri, process, project failure, project management, project methodology, project result, project strategy, project success, Software Project

    Project Management is an Art and Science both. An artistic touch makes it beautiful. A scientific approach makes it successful. Both are essential in case of a software project. Hoshin Kanri is a Japanese term. In Japanese, hoshin means compass or moving in the right direction and kanri means management or control. The combination would mean either “moving in right direction to have a better control” or “controlling it in a masterly way to move in the right direction. This is a great tool for any management to enhance their project management or urge for excellence so as to move towards better optimization and least defects in their processes.

    A well defined process and its adherence make it possible to achieve higher standards in process optimization. Many organizations have no defined processes in place. Others have well defined processes but no adherence or a wide gap in what is defined and what is being followed. The organizations are capable to sustain and enhance their growth and success via doing the both – defining best practices in their project processes and adhering to those practices so that there is least gap between the two.

    An organization would definitely require adopting “Hoshin Kanri” if they are facing following issues in their project management:
    1. If there is no planning process in place or if there is a process defined but there is no monitoring on a regular basis of what is defined and what is being followed.
    2. If the processes are age old with no reviews and improvements analysis.
    3. If the processes are well defined and lying in a closet and people who are the project owners are not aware of those processes.
    4. If actions performed in projects differ to what is defined in the relevant process.
    5. If processes are discouraging and demotivating in nature.
    6. If lot of improvement projects are running in the organization with no or little improvement apparently visible.
    7. If people are held responsible for failures rather than focusing on improvement of process.
    8. If results of strategic objectives differ from actual work in place.
    9. If opinions play major role in decision making than the facts trying to lead to different cause to be taken care of.
    10. If Customer is not HAPPY.


    January 28, 2010  11:38 AM

    Seven Commandants for the Success of any Project



    Posted by: Jaideep Khanduja
    project management, project manager, Software Project
  • 1) Any project is undertaken for success. No organization, no management or no project manager would start a project with an intention of making it a failure.
    2) Success is a combination of two main ingredients: Decision and Choice. Choice mainly comes from the top management, Decision from all levels during the different phases of a project. Any action on the project is a resultant of a decision taken by anyone in the team. The low level decisions are to be controlled by senior levels. The hidden or uncontrolled decisions may fluctuate your project’s SUCCESS between the two intrinsic limits – DISASTERS and HIGH ACCOMPLISHMENTS.
    3) Opportunities do not knock twice at your door. You have to be intuitive and bold enough to recognize and grab the right opportunities.
    4) Don’t underestimate you or your teams, neither the capabilities. Reach to your highest potential to fulfill your goals. Keep reminding yourself and your teams – ‘you can do it’
    5) Define your goals clearly. Clarity in you will show right path to others too.
    6) Every act is associated with a risk. You must be able to proactively identify the risk, perform risk assessment, risk analysis and find out ways to mitigate the risks.
    7) Dream when you are asleep, achieve them when awake.

  • January 26, 2010  9:00 AM

    What Generates Reputation Risk to my New Software Product?



    Posted by: Jaideep Khanduja
    project management, Reputation risk, Software Project

    As discussed in the previous articleWhat is Reputation Risk in regard to a Software Product?” the situation can arise in case of any product or any company. There is no point in getting bogged down if after all sincere efforts the product has failed to be successful at customer place. Better option is to find out the reasons behind its failure or rather put all your efforts to find out what is missing in the product that has not been able to convince the end user and their management. Instead of losing heart and withdrawing the product, focus on those points, act upon them and reproduce the product to the management and the users.

    The best way to do this is to quantify the reputation risk. The amazing reasons will emerge out once you start quantifying it. Worst scenario could be that there is nothing wrong with the product but still user’s acceptance level is quite low. Probably the product has been launched or introduced in a wrong way. Probably it has not been introduced to the users well. Probably its key features have not been highlighted the way they should have been.


    January 25, 2010  8:14 AM

    What is Reputation Risk in regard to a Software Product?



    Posted by: Jaideep Khanduja
    Reputation risk, software development, software product, testing

    Reputation risk of the product is a very critical factor related to a product that a company delivers to its customer(s). The reputation risk of a product is directly related to the rate of acceptance of a product by its end users and is indirectly related to the volume of benefit it delivers to the management of that organization.

    Let use start with the customer requirements based on which a company decided to develop a software product. The software is produced after following all internal procedures of development, testing etc. and is declared as ‘ready to launch’. It reaches to the customer along with the implementation team. The implementation team educates the end users about the product and its usage. The end user starts using it but somehow feel uncomfortable in what they perceived and what it delivers.

    If end user is not comfortable about the product functioning and its usage they will definitely not be able to deliver the desired results to the management of their organization.

    The lack of interest by end user due to whatsoever reasons will cause a bad name to the product as it is not going to deliver the desired results in the organization. Assuming that the product has been developed with utmost care but still if it could not convince the users, it is a bad luck for the product and the company that has developed it.

    This is how the reputation of a product is built which in turn largely affects the company who has developed that product.


    January 22, 2010  11:12 AM

    Ten Benefits of Continuous Learning Programs for Project Teams



    Posted by: Jaideep Khanduja
    culture, developer, performance, project management, project team, recognition, Software tester, training

    There is no end to learning. Still water becomes contaminated and harmful for use. Continuous flowing water keeps it fresh and pure. Similarly if your developers and testers or for that sake anybody in the organization keeps performing the same functions without any improvement or value addition, it is like no update and no upgrade.

    Any organization must have a continuous learning program for their technical teams. Rather irrespective of the stream a candidate belongs to, all must have a continuous learning program. Organizations that do not focus on this area, invite more employee turnover and less dedicated employees. There are many benefits beyond stated here but main benefits of having continuous learning program for project teams would be:

    1. Performance: The performance of your project team members will increase manifold. Their efficiency will be better.

    2. Recognition: Team members will be willingly staying for a longer period in the organization. So if their performance keeps improving and they stay in the organization for a longer number of years, definitely it is a boost for the organization.

    3. Empowerment: Teams are self motivated, empowered and more organized.

    4. Turnover: There will be tremendous decrease in employee turnover.

    5. Flawless Speed of Delivery: The delivery in their respective areas will be flawless and spontaneous.

    6. Role Models: Such employees with high performance, complete dedication, longer years of service and quick delivery will definitely set an example for others in the organization and hence will attract better employees to join the organization from outside. Internally also it will keep a healthy competition among the teams and team members.

    7. Culture: This will lead to a strong learning culture within the organization. Continuous improvement will be a subset of this culture.

    8. Brand Ambassador: Not only the employees working in the organization but even those who leave the organization and join somewhere else would be the brand ambassadors of the organization.

    9. Consistency: The organization as a whole will be on a trend of consistently improving organization thereby optimizing its potential and achieving new heights. This way organization can aim for bigger goals to achieve.

    10. Social Impact: With such a culture, the employees will not only be leaders within their own professional spheres but will excel in their personal arenas too thereby setting an example in the society.

    Learning is a life long process with no bars.


    January 19, 2010  10:50 AM

    Have You Installed Latest Patch For YOUR OWN Upgrade



    Posted by: Jaideep Khanduja
    patch, programmer, software, tester, training, update, upgrade

    Like a piece of software or hardware requires regular upgrades and updates to perform smoothly with the changes scenarios, a programmer or tester also needs the same. Or for that sake every human being on personal and professional front requires it. How it is done is important. In case of software or hardware the update or upgrade patch is released at regular intervals by their respective manufacturer or owner to keep it updated. How is it needs to be done in case of us – the human beings. Here comes the role of reading, exploring, training, brainstorming, discussion, interaction with peers and superiors etc. There is a big difference between the flowing water and still water. Movement is life. Improvement and enhancement are essential for growth at both fronts – personal as well as professional.

    As we all know books are the best friends. Any read will give you some or the other learning. So it is important to keep reading latest books, articles, views relevant to your job. Join in some important newsletters, forums, sites that keep you abreast in your technology area. Reading blogs, subscribing to RSS is another thing that can be done easily to keep getting information flow. Training is important for all ages. There is no end to learning. There is always a scope of new learning, improvement and knowledge acquiring. Don’t wait for someone to sponsor for your training. Go ahead, find out the requirement for yourself and jump into a training session. Investment in training always gets you returns in manifold.


    January 15, 2010  9:45 AM

    Ten Linking Factors between Project Management, Quality Assurance and Quality Control



    Posted by: Jaideep Khanduja
    Bug, bugs report, project management, Project Management Methodology, project manager, Project Plan, QA, QA compliance, QA head, QC, quality assurance, quality control, Software Project, Software tester, software testing, Version Control

    Project Management is vague if not adhered to a proper project management methodology. Project management methodology is useless if not in sync with a project. Quality Assurance is an integral part of project management methodology. The methodology need to be designed, managed, controlled, monitored, reviewed and fine tuned by Quality Assurance. Project teams need to follow project management methodology religiously.

    Quality control goes haywired if not supported well by project teams. Project teams lose control over project at times. All these and many more factors need to bind project team, quality assurance team, quality control team tightly so that they all aim to a common goal of successful project completion.

    Following are the major linking factors between project management, project team, project methodology, quality assurance and quality control:

    1. Visibility of Open Projects: There need to be a bulletin board related to all open projects visible to all stakeholders that is updated regularly stating the progress status of each project.

    2. Team Members: There might be n number of projects running and in pipeline. The team hierarchy, member names, responsibilities, jobs assigned and work status for each project should be visible to all concerned to keep them all in sync.

    3. QA Compliance: Project Management Methodology compliance is part of Quality Assurance. It is quality assurance (QA) head’s responsibility to design the right methodology and ensure its adherence. Though the project teams may not decide to comply with the methodology in one go. Let it be in parts. Let the most essential documents be adopted and adhered to in first go. Get conversant with the benefits and then decide to adopt the next leap of methodology. But whatever they accept to adhere to in first go, they must. All such documents from various project teams should be marked to QA also for audit purposes. A complete adherence but partial flow of information to QA will project wrong picture. QA also has to ensure whether only sample sheets have been sent to them or it is the complete set of documents related to project coming to them.

    4. Repository building: QA has to play a major role in building proper repository of project related documents. If there is no visibility and clarity of compiled repository of all documents related to a project, QA needs to be alerted. In turn QA may alert relative project heads for compliance and information flow.

    5. Proper Templates Compliance: Confirmation of receiving of documents by QA initially does not imply the adherence to proper formats released by QA. Project teams especially in case of multi projects and overseas projects may not change the formats immediately in between the project and may like to continue with the old templates (or non uniform templates) till the running projects get completed. QA must ensure that all new projects are strictly disciplined to adopt the standard formats in place of any non uniform templates for compliance.

    6. Project ON and OFF Trigger: At times there is no apparent visibility of project ON and OFF dates. Respective Project managers need to release formally the project plans and tentative ON and OFF dates. The monitoring agency must be aware of it. QA must be considered as one the stakeholders of the project.

    7. Version control: If project managers are not able to control and maintain the versions for their software applications, QA needs to intervene, and they can only intervene if they are involved in the process of monitoring the controlling process.

    8. Version Control Methodology: QA needs to evolve exact Methodology or Policy for version control. Project managers are bound to adhere to it after evaluating, fine tuning and accepting it.

    9. Product to be released for QC: One of the roles of QA is to enforce QC plan to be an integral part of project plan. This can happen only if the respective project manager is clear about its teams plan to release the product for QC. QC may be an ongoing process (continuous) or in batch mode depending on the nature of project and methodology it falls into.

    10. QC bugs: QA must ensure that the bugs reported by QC to product owners must come back to QC in the form of acceptance and feedback. Some project managers don’t feel it is important.

    The organizations where QA sits on top of project teams and quality control teams drive projects better in comparison to organizations following any other pattern.


    January 13, 2010  10:10 AM

    Five Benefits of Linking a Bug to its Respective Identifier, Creator and Killer



    Posted by: Jaideep Khanduja
    Bug, bug fixing, defect, developer, programmer, Project, project cost, project delay, project management, software development, Software Project, tester, time sheet

    Bug is a common factor between a tester and a developer. A developer creates a bug, tester identifies it, and then the same or different developer in turn kills the bug. A developer has two faces – creator of bug and destroyer of bug.

    The intermediate phase is identification of bug which is performed by the tester.

    It may happen and it mostly happens that new bugs are generated while fixing the old ones. And that makes this cycle repeatable till all the bugs are reported closed by the testing team or if in between development team decides to withdraw further testing. The second option is quite dangerous as the bugs suppressed will definitely play their crashing role at later stages.

    It is always better to connect a bug to its creator, killer and identifier for the following reasons:

    Billing: If the billing structure is such that the actual hours spent on the project are directly billed to the customer on weekly/ monthly basis, the time spent on bug identification, creation and closing are important for that purpose.

    Time Sheet: The daily time sheet is required to be maintained by software organizations so that they come to know where the employees are spending their productive time.

    Project Cost: These costs definitely add up in the ongoing cost of the project. to estimate the cost incurred at any stage of the project, these costs need to be accumulated in the total cost of the project.

    Project Delay: Definitely if the bugs closing and testing cycle is repeated many times to bring the product to the expected level of performance, the delay in timelines will count in such exercises.

    Performance factor: To evaluate an individual developer or tester at the end of a project, during a project or at the time of appraisal, this data will help in assessment. The developer generating more bugs, the tester coming out with less bugs, the developers taking more time for bug fixing etc. will help in the proper evaluation.


    January 11, 2010  6:25 AM

    Sixteen checkpoints for Software Project, Project Methodology, Project Management and Project Managers



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

    1. It is important to create and follow a methodology for your software project management.

    2. Let your project management not turn into a sad story.

    3. Out of a project methodology and adhering to it, adherence is more critical, whatever methodology you design for your projects management.

    4. Different software projects may not necessarily fall into the same methodology. So depending on your project type you need to define a separate project management methodology. For instance there might be a difference between your in-house, domestic and offshore projects.

    5. An unfit methodology or wrong way of managing your project may cause a retardation in the progress of your project thereby causing a frustration in project stakeholders.

    6. The maturity in the way a project is managed decides the success or failure of project.

    7. Project management methodology may also depend on the project size also.

    8. Don’t let your methodology become stale by not observing, evaluating and redesigning it.

    9. Various soft spots or loopholes in your project methodology may cause a number of wrong results in your project thereby deviating you and your teams from the desired progress or flow of the project.

    10. A real transformation is required from time to time to keep your project and methodology you are adhereing to – to keep the progress on track.

    11. You must be very clear all the time to understand and adopt the real ingredients to keep your project end in time successfully.

    12. The project manager has to become maverick sometimes to pinpoint the flaws in project and overcoming them.

    13. The project manager has to have certain set of skills to keep his project alive so as to accelerate the progress.

    14. The project manager has to have handy checkpoints at the start of a project.

    15. The project manager has to interact, interject or do both during the project.

    16. The large sized projects have more chances of failures if not managed properly.


    January 8, 2010  6:45 AM

    Avoid Bug Fixing Nuance



    Posted by: Jaideep Khanduja
    Bug, developer, project management, software development, Software Project, software testing, tester

    Usually when the bugs report is submitted back to developers by the testers after testing the product, the developers fix the bugs and return back the product for re-testing. Definitely in any software development project there are multiple developers involved in the development process. Separate modules are distributed to different developers for development, and post completion of the development the modules are integrated to produce the final product.

    The bugs reported may not be assigned to the same developer to fix who has written the code due to many reasons. It is more problematic if it happens as the different person working on someone else’s code to fix the reported bug may just focus on the bug without getting into the depth of the code that may create a new set of bugs in the code reworked. This issue may be handled, if not perfectly well, upto maximum extent if there is a proper development technical documentation in place, which mostly is not. Moreover if now developer B is working on the code written by developer A, there are chances of deviation from the core customer requirements as developer B has not worked on them right from the beginning. Probably in this case there is a chance of writing a bug in lieu of existing bug. The new bug created might be more severe than the original one.

    A wise step to avoid this nuance is to assign each bug to the respective developer who wrote the relevant code for it.


    January 6, 2010  10:00 AM

    Development-QC-Development-QC-Dev-Product Launch



    Posted by: Jaideep Khanduja
    blackbox testing, boundary value testing, Bug, business specification, BVA, customer requirement, customer specification, development team, implementation team, performance testing, project management, QC, QC feedback, quality control, Regression Testing, software development, Software Project, tester, testing

    In software development life cycle when the product is completed by development team, it is handed over to testing team for thorough or regression testing. The QC team (testers), besides performing other testing like boundary value testing/ approach (BVT or BVA) or black box testing, performs functional testing based on customer requirements and business specifications built in the product. Main goal is to scan the product thoroughly to check mainly following two things besides others –
    - the product built covers to all requirements and specifications
    - the product built caters to these requirements and specifications correctly

    The bugs or defects list is submitted back to the development team for minor to exhaustive overhaul of the product depending on the number and severity of bugs. After fixing of bugs and verifying at their end the development team invites QC team again for verification so that the product can be launched for the customer. This testing-fixing-verification may happen in one go or may require re-runs depending on the QC feedback. Once QC gives a final nod to development head, the product is handed over to implementation team for its launch.

    Though we still keep wondering what stops the best of the breed of programmers being good testers, probably for testing purposes it is better to learn linear approach of cost estimation of bug fixing for various software projects and testers acquiring soft skills for progressive software testing approach.


    January 5, 2010  12:08 PM

    An orthodox software project scenario



    Posted by: Jaideep Khanduja
    Bug, coder, coding, developer, Development, project management, software, Software Project, tester, testing

    In most of the orthodox software project scenarios software testing is a late entry. Mostly testing starts when the coding is finished. The concept of complete code testing prevails where the testers are assumed to conduct testing on the product once it is declared as complete. A whole lot of time has already been consumed in development, and another timeslot is reserved for testing. In both slabs one team sits idle most of the time. When the development is getting completed, developers are busy in coding, and testers sit idle. When the testing is being done, testers are busy and developers sit idle and keep waiting for testing to get complete so that bugs report or test report is submitted to them by the testers.

    The two teams – developers and testers – remain isolated most of the time and testers don’t get enough time to understand the product well.

      The separating wall between the two teams is quite visible in this sort of scenario

    . Fallbacks in this are felt on both the sides. On one hand where the testers do not get the full taste of the product as they are kept away while the product is in making, on the other hand the developers suffer the similar heat when the testers are testing, finding out the bugs and recording the bugs without actually involving developers with them so that the developers actually see how the bugs are getting simulated by the testers.

    Though testers do take snapshots of the screens trying to decipher the occurrence of the bugs but usually that is not enough for the developers and another lap of time is spent by development team in understanding the bugs and trying simulating them to understand the real flaw in the code.

    If everyone understands the loopholes in this system, why aren’t the efforts done to overcome it…


    December 30, 2009  10:00 AM

    My Last Post for the Year 2009



    Posted by: Jaideep Khanduja

    We all want to be successful in our profession; few of us try hard, few very hard.
    In case of a failure we have two paths to follow – bounce back with a higher thrust, or get bogged down.
    Silence is gold but not always.
    Higher we go, difficult it becomes to progress.

    Yearning for excellence and knowledge success will automatically follow you.
    Out of all possibilities try the most difficult one first.
    Unwinding and winding of your knowledge and experience keeps it fresh.

    All things that happen have a logic, only that some we are not able to understand.
    Listening is a great asset.
    Listening is an art too.

    An ending that is not with happiness is not an ending.

    Very often we lose trust in ourselves.
    Every mind is a goldmine, it depends how much gold we are able to dig out of it.
    Regression means forgetting what you think you know and knowing what you have forgotten.
    Yesterday is gone, tomorrow is yet to come, but both are linked with what I do today.

    Handling a needle is as tough as handling a sword, both need talent.
    Anyone who feels himself superior to others seeks negative vibes.
    People management is prime requirement in any project.
    People make projects successful, not personalities.
    You are the best judge of your situations. Don’t let others overrule you.

    Never compromise.
    End a project in time – rather before time – successfully.
    We is better than I in a project

    Your all prayers get answered instantly; check your unread prayers box.
    End of year means beginning of a new year.
    All is well – keep repeating.
    Roar in such a manner that even a lion get a new meaning of roaring from you.

    2
    0
    1
    0


    December 24, 2009  10:00 AM

    Eight Soft Intuitive Checkpoints for Project Manager during an Ongoing Project



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

    The following applies to complete Project proceedings at any stage with internal teams, management, customer users, customer management and so on. Be it project meetings, briefings, development, documentation, implementation, testing or whatever – you have to be alert, awake and open to capture all kind of responses.

    Take care of the following checkpoints if your project is moving and in right direction:

    Beating the Drums:
    If you keep on beating drums without noticing whether the music is being enjoyed by your audience, you are not doing any justification with the audience and the music both. Next point arises is that you have to be smart enough while playing your music to understand whether your audience are yawning or yearning.

    Eyes speak louder than words:
    Keep looking into the eyes of your team members. The confusion, frustration, downward mood, interest, disinterest and so many other things that are not expressed through words by any of the team members will be clearly visible through their eyes.

    Keep your fears and beliefs alive:
    Live with your fears and beliefs everyday. This will give you more strength to move forward in right direction.

    Do something weird once in a blue moon:
    Try doing or expressing something weird to check who out of your team members, peers and superiors. This will clearly earmark people who really care for you as they will come forward and alarm you about it.

    Listen to be listened:

    Listen to each of your team member when in group or in individual. Clear their doubts. Understand them and make them understand you.

    Sense the wave:
    Monitor how much everybody is contributing and how involved one is in getting the project done. A less competent team member would prefer less complicated work. Check the people who would be skipping meetings with any worthy or unworthy reasons.

    Mixing and Grinding:
    Don’t mix too much of tasks or ideas at a same time with your team. Share with relevant members appropriately, may be separately or in different sessions.

    Movers and Shakers:
    All people may not move along at the same pace. Judge them. Read them. Understand them. Don’t take hasty decisions in changing team members too frequently.

    Beating Retreat:

    Celebrate small achievements in a small manner. Celebrate milestones in a big manner. Don’t hesitate in recognizing, acclaiming and celebrating.


    December 23, 2009  10:00 AM

    Productivity Metrics vs. Quality Metrics



    Posted by: Jaideep Khanduja
    quality, quality control, software development, software quality

    Imagine a Pen manufacturing company having lot of orders from their customers to manufacture various types of pens. There can be two scenarios – either the delivery is production centric, or quality centric. Let us see what the difference in both is.

    In Production centric delivery system the focus will be more on the numbers produced. The performance will purely be measured based on the volumes produced. The company will be using productivity metrics focusing on increasing production all the time.

    In Quality centric delivery system the focus will be more on the number of good pieces produced. This may enforce quality check at each station. The performance will purely be measured based on good pieces produced irrespective of howsoever high is the number of overall pieces produced. The company will be using quality metrics focusing on increasing quality all the time.

    We see no competition in first case where the company is production centric. The risk of failure in the market is high since the company is not quality focused and hence rejections and failures at customer site will definitely be higher.

    We see a high competition or rather a war between quality and production in second case. Any rejection at customer site is counted as failure of quality. But the overall risk is very low of getting rejections or failures at customer site since all the bad pieces have already been detected and discarded by the quality at their own premises.

    The same goes true for software industry also…


    December 22, 2009  10:00 AM

    Eight Facts About Developers



    Posted by: Jaideep Khanduja
    developer, software development

    A developer when joins a company carries some expectations to deliver and expectations to get.

    He has lot of things in mind what extra edge he is going to deliver to make him different from other along with being a warm contributor to the team.

    Also he expects certain commodities like good salary, ample space, good working atmosphere, timely actions etc.

    All developers will not be working at the same salary. Not even those with the same number of years of experience. It all depends on their historical growth, skills and smartness.

    Similar is with the performance, each developers performance will be different from the other.

    A developer may not gel well in one team or with one set of team members or with a manager. But that does not qualify him unfit for the company.

    Overall performance over a course of period will vary based on the type of job given and the team in which he is placed.

    Overall assessment of a developer cannot be biased based only on his poor performance during that period.


    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: