There is always a hide and seek game between Product Manager and QC Manager when a product is being built. Project Manager, Management and Customer on one hand stress on complete involvement of testing team during product building. On the other hand product manager keeps playing tricks to bypass testing by a separate team outside his control.
This could be due to a fear factor in him, or lack of confidence on his product. For the sake of not displaying his these weak points to other teams involved in Product Lifecycle, a Product Manager tries presenting his points in other fashion to convince management or other managers for not giving the product for testing or providing the least duration to testers. This satisfies him for the reason that least exhaustive testing by testers will lead to least number of bugs.
But by doing this he also is doing a inappropriate deed for his product and in turn for the organization. Usually Test team is taken as an opposing factor by the product manager. In a way while the development of the product; he gets emotionally attached to his product. Feeling of getting it scrutinized by an outsider (someone not from his team) makes him feel as if someone is intentionally going to find faults in him or his product. He also feels that the higher is the number of bugs,
1. Confidence: The confidence level at any stage of all team members, project manager, QC manager and all other stakeholders right from the beginning starts narrating the direction and overall health of the project. The clarity of requirements, goals, direction etc. all reflects through this handler.
2. Process: Ensure that right processes have been framed, adopted and adhered to in case you want to ensure success at each stage of the project. No process always carries a higher risk of failure that can be mitigated by a right process and methodology in place.
3. Quality: Quality has to be omnipresent throughout the project in all aspects not only in terms of the product or code but also in terms of people, process, methodology, communication, direction, documentation etc. Quality in any case is an asset for any project or organization. Organizations emphasizing more on quality aspect groom much faster compared to others.
4. Control: Control comes through measurement and analysis. Absence analysis and metrics never gives a right control and hence there is always a chance of deviation from the right direction. Control at all levels has to be there including a self-control factor in all team members up to the bottom level.
5. Morale: Keep your team’s morale at the peak all the time. Ensure nothing unproductive work hits any of the members during the project. Keep boosting their tempo and focussed on getting fruitful results at all stages.
Another approach is to build what customer can’t resist. This definitely is a stage higher than the approach mentioned in the above paragraph. The customer requirements are definitely given importance here but the business in-depth knowledge acquisition is much more important prior to building the product.
I am sure companies who deliver what their customer wants also would be striving for a stage where they build what customer can never resist. Definitely all of us know the difference between these two.
The extra edge that is carried by the second approach definitely helps in keeping both categories of companies far apart from each other.
Few months back I read this line somewhere in an article related to project management and product development. The line read as – “We don’t build what our customers want – we build what they can’t resist.”
There are two approaches I could clearly find out from this one line. This line infact summarizes the crux of whole software industry. The two clear segments of software industry with their clearly defined process approach focus either on customer requirement in front of software building or the customer business in front of the software building.
One approach is to build what customer wants. And there are companies who boast about delivering what their customer wants. This definitely would be requiring a number of iterations of changes in the product when the software is introduced to the customer for user acceptance or pilot run. The main focus in such approach remains on the crystal clear customer requirements and building them in the application.
Outsourcing is not an unfamiliar term. We keep doing that in our day to day life for our personal and home needs. The same is done in corporate world. All activities or work can’t be performed by a single person. Similarly all corporate functions may require outsourcing depending on size and need of the organization.
The first and foremost requirements for the outsourced vendor is give a feeling to the customer that they understand customer needs, are capable of performing it and can deliver it in time. So in short the three ingredients that are foremost required in a vendor are knowledge, skill and capability.
These three ingredients are required in right combination and must be transparently visible across. Otherwise retaining these features but not being able to pass across the right message will create bottlenecks for the vendor for acquiring new business.
Ultimately it is the mix of good ethics, standard processes, proven methodology (ies), excellent support and becoming an integral part of the project that makes customer and vendor a successful venture in any project.
5. Benchmark: To rate each of your selection criteria points for each vendor you will be required to benchmark each criteria with the best possible value available across the globe. Against this best possible value for each point your assessment for each vendor will give you a better understanding at the end of assessment exercise the level at which each vendor stands making it easier for you to shortlist or finalize the vendor.
6. SLAs: SLAs are nothing but an agreement to deliver or get a certain level of delivery of service or product and also taking care of addressing to any ambiguities arising at a later stage during the delivery.
7. Delivery: Delivery of software is different to delivery of a refrigerator. Software or part of software outsourced requires continuous involvement of inspection and verification by the customer to ensure that the efforts are being put in the right direction. A later stage engagement will involve higher risk compared to the involvement or engagement right from the beginning.
8. Payment: Payment terms usually are kept in agreement with the delivery of the product. If you are outsourcing a vendor for some part of the project, keep your terms of payment of the product in such a way that some part is paid after your customer signs off the project keeping in mind that if your customer is delaying the sign off but the reason is not associated with the part outsourced, then there is no point in lingering on the payment to your vendor.
9. Support: As you are bound to support your customer your vendor is also bound to support you not only on the part of the project he is outsourced for but also that part’s back and forth integration. This back and forth integration part is something which will be overlapping you and your vendor so you need to be extra careful about this integration part.
10. Contingency Plan: Any development is associated with risks. Identification of risks at the earlier stage gives you more time to plan for risks mitigation. A later discovery of risk creates a panic. A contingency plan gives you a little pain in the beginning of the project to cover up all your later stage pains.
1. Understand Complete Requirements: Customer requirements for the whole project play a very crucial role in building a new product. The whole requirements are shared by many teams for various purposes – viz. development, testing, implementation etc. A foolproof process of documentation of complete requirements is mandatory. The clearer the requirements, easier it is to build a customer favorable product. Unclear or incomplete requirements will cause delay and frustration in the project at both ends.
2. Map Existing Capabilities: All phases of project may not necessarily be possible to carry on with in-house teams. Some of the requirements may need specific skill-sets that might not be available with the existing profile of team members. This calls for either of two possibilities – either recruit relevant skill-set persons or outsource that part of the project to a relevant vendor having team of the required skill-set.
3. Sort Out Jobs for Outsourcing: Going for a fresh process of recruitment for filling the gap of required skill sets for the project might require extra time which may not be permissible by customer. Also the newly recruited persons take some time to settle down and get into the flow of main stream. So it is better to outsource a vendor to deliver such requirements.
4. Define Selection Criteria: Selecting a vendor will never be an easy task as the involvement of an external agency in a project adds another kind of risk to your project. There is n number of assessment criteria before arriving at a conclusion. The selection criteria must be chalked out very clearly before starting the vendor selection process. It could include size of the company, their projects history, customers, employee turnover, growth, management, knowledge base etc.
..to be continued…
5. Harvesting: Plants are ready for harvesting at different timescales. The crop decides the period of harvesting unless some negative impacts the growth. Same is with the people. Some grow fast, some take their own sweet time to grow and establish their achievements.
6. Plough: After harvesting a field needs to be ploughed and seeded. Same is with the people, if they are not given more challenges and extra tasks. Same repetitive tasks make them stagnant. They need continuous flow.
7. Sunlight: Essential for photosynthesis to convert light energy into chemical energy. In terms of people a sunshine, bright and cheerful environment definitely affects the progress and growth of an individual and a project.
8. Air: Air is important for all sections of a plant – the parts below the earth/ soil or the parts upward. A plant placed low natural air availability areas will go isolated and will develop at a lower speed.
9. Manure: All plants may not need it but they always welcome extra nourishment. Though excess of anything goes waste or produce bad results, it is the project manager who has to identify who needs how much motivation, growth and challenges.
10. Nurture: Small plants are not seeded in big pots so are the people. Newcomers or people with less experience in the organization can’t be expected to product big results unless they have a very strong background and outside experience. Otherwise each plan need to be nurtured in present to produce big results in the future.
A gardener is not a simple job, rather is a most tedious job of growing and nurturing nature. The similar job is that of a project manager who has to manage different teams in a project. The team members comprise of different ages, cultures, geographies (sometimes), experiences, backgrounds, qualifications etc. A project manager has to plant, nurture, care, water, grow, safeguard, and manure his team members depending on the stage of the plant (team member).
1. Nursery: All new incomers need to be placed here for providing them special attention, right direction and extra motivational strengths. A separate set of extra organizational cultural, functional and relevant technical training is required to be imbibed for synchronizing newcomers strengths with the organizational goals.
2. Trees: These are the existing team members for quite a few number of years spent in the organization. They have displayed their strengths, acquired new strengths; deliver at par with organizational expectations with least direction and efforts. One thing that goes unnoticed about trees is that trees strive to show their strength and knowledge by delivering fruits… I mean the people falling in this category strive to train people with less experience, share knowledge with juniors thereby helping in growth of others.
3. Plants: These are the most variant category requiring different stimuli depending on the category they fall in. Some may require extra sunlight, some extra water, some prefer to grow in shade, some need extra nutrients. This is the phase of the people where they neither decide for a long term engagement with the organization nor do they plan to leave it soon. It is the phase of bonding and attachment depending on the way they are treated.
4. Watering: Each plan has different water requirements but no plant can survive without water. Except the trees whose roots are well deep enough to get water directly from the earth. These people (trees) are having a deep attachment and bonding with the organization. As and when they feel low (which happens not to frequently), they themselves fetch energy from the management instead of waiting for someone to come and energize them. Rest for all plants a regular watering plan is must in terms of motivation, training, discussions, recursions, informal engagements.
5. Drive with a top down approach: If the project command is shared with one of the top management member of customer end, it gives a catalytic thrust to the project progress and becomes a winning note for the product.
6. Don’t pass a stupid message that successful business application implementation means decrease in Headcount. Rather pass on the message that the underutilized employees who are engaged in manual processes will be converting to more productive work.
7. Manage Change: Generally change is welcomed with a resistance. People want to stay cool with their regular routines with no considerable change. Any application implementation or process enhancement seeks change. It needs to be observed, controlled and managed wisely.
8. Motivate users: A person when felt as important pillar for a change, feels good and motivated. Engage users to their full strength for the change and implementation.
9. Remove junk: Sometimes an automated or fresh designed application process becomes lethargic and boring than the earlier used process (legacy or manual). Sort out, identify the major chunks of junks and convert them to more friendly and optimized user friendly.
10. Kick Process not People: It is the process or methodology that is responsible to make a success more than the people involved in it. Enhance the process of implementation rather than wasting energies on finding out the weak people links.
Sometimes business applications die an unnatural death even if the application is built with state-of-the-art technology fulfilling all relevant business requirements.
The reason of failure does not lie with the application but the people and processes involved in deploying it but unfortunately even in such cases the blame goes to the application and it is the application reputation that suffers.
The two main defaulters in this case who can be held responsible for Project death are Implementors and End Users/ Customer Management. To cope up with this risk and for mitigation let us work out on the following ten tips:
1. Understand business requirements and pain areas: This beautiful application may be lacking some customer specific areas which are not catered or are catered but not satisfactorily in the application. These pain areas need to be addressed as and when they evolve during the UAT or product implementation.
2. Address critical business processes in the application: Sometimes some core critical business process is misunderstood and built wrongly which is recognized at a later stage. It needs to be addressed either way.
3. Take feedback from users: It is very important to make user feel important in the project. One of the way is to ask for their feedback in a formal manner. It not only makes them feel an integral part of the project but also gives them a chance to speak their heart out. In any case the customer management would definitely be acting on their feedback only.
4. Engage employees and Management together: Many a times the project team forgets customer top management and focus entirely on end users without engaging and updating management.
———contd in my next blog.
Project performance encompasses performance of each individual member of each team working for a project. Each team members requires an environment around him that facilitates him to work towards his goals.
The components of an environment for a team member would be the working place, sitting place, workstation, and general administrative facilities.
Many of the components that may not draw immediate attention of focus but actually playing a role in project performance can be defined as below:
2. The communication process in the organization among other team members and management,
3. The comfort of sitting place, tea/coffee breaks, lunch provisioning etc.
4. The desktop/ laptop configuration
5. LAN and internet
6. Even the power supply, lighting in the office and on the seats, drinking water arrangements, rest rooms etc.
All these factors if are favorable towards employees in turn bring lot of favor to the project performance.
Six Sigma is more of common sense and facts based analysis of real data to arrive at an action plan. The basic steps to perform a six sigma project are as below:
2. Set goals to resolve this problem and define the result in terms of financials and timeframe
3. Collect data for a considerable period to analyze
4. Perform statistical analysis based on relevant tools to identify the core issues responsible for the problem
5. Hit on those core issues
6. Identify and measure the gains
Usually it is not easy to run above cycle once and achieve the desired final results. With the help of interim results in different iterations, the final results can be achieved.
To do that a basic six sigma approach can be applied as below:
2. set a goal of fixing top 5 or 10
3. collect relevant data – very important to understand that wrong or incomplete data will draw out wrong results
4. perform SIPOC
5. analyze the top most (say 5 or 10) factors responsible for your problem identified
6. set a goal to kill/mitigate those factors
7. see the results if you are moving near your result goals
8. analyze next top (5 or 10) factors
9. kill them
10. check the distance from your goals
11. and so on…
A lot about the product architecture and design depends on the inputs of business requirements. The team responsible for business study and documentation must understand the severity of risk built in development stages due to wrong or incomplete interpretation of business requirements to be built in the product.
Business requirements documents include both functional and non functional requirements emerging out during the discussions with customer management and key functional managers. All these requirements become integral part of the requirement document that moves to various teams during the different stages of project development.
What if some of the crucial requirements are not captured during the study phase? Or if some of the requirements are not documented in illustrating manner which in return present wrong interpretation to developers and the product development starts moving in wrong direction.
All such ambiguous/ wrong/ incomplete developments lead to a risk of customer/ user dissatisfaction at a later stage depending on how soon or late the product built is exposed to the customer front. Such risks must have a concrete mitigation plan beforehand in order to not to lose confidence, time and reputation.
Project Manager has to have leadership qualities to achieve success in projects. To carry on with these qualities for project management is good for project manager keeping in mind to regularly improvise and enhance these skills.
Another outlook is to inculcate these qualities in the team members down the line. Being a mentor for few of the team members is important to develop future project managers. Also if the team members touch down the inner feelings of project manager about the project, it becomes easier for all to synchronize their energies and move ahead in the same direction together.
Non Standard processes are prone to risk. So is the service. Service is more based on the people than the deliverables. Even the set standards will vary the level of sam service being delivered by different set of persons. Product is easy to judege in regard to quality. It is instantly demonstrable also in case of a product with the help of measurable parameters of testing.
In service it is difficult to set or establish process standards. Even if they are set, if is difficult to measure them to instantly declare if the service is of high quality, or low quality. With the same quality of service it is not possible to make each customer satisfied. The level of satisfaction will depend on lot of non-measurable parameters.
To outsource a vendor for a specific service, there has to be a checklist with parameters defined to ensure the right selection of vendor for that service. The selection cannot merely be based on gut feeling or the verbal commitments of the vendor. Some of the important parameters for selecting a vendor for a service could be:
2. Customer’s Turnover: Check out the vendor’s record (though he will not be easily disclosing it) how many customers have left him during last three years and try finding out the reasons for it.
3. Certifications: There are world class certifications available these days geographically everywhere. Checkout the relevant certifications your prospective vendor has obtained. Check out how old are these certifications, have all recertifications been done, when was the last audit done and see the audit report to find out the observations or non conformitites pointed out by the auditors. Also check out the reputation of the auditing agency.
4. Employee Turnover: Check out his employee turnover. Beware to outsource him for a service if his employee turnover is high.
5. Growth: Check out the financials to find out the rate of growth. If growth is turbulent or incosnsitent, it could be a point of worry. A consistent or atleast sustained growth is good.
Managing and running helpdesk is not an easy task. Once the project is completed after software application has been implemented and sign off has been taken from the customer. a new journey starts in terms of product support. The users who start working on the product entering real business data to product useful informative reports for themselves and their management face problems in the beginning while working on the new application in the organization.
These problems could be due to many reasons like:
2. hidden bugs in the product being exposed while working
Over a period of time helpdesk becomes a good repository of information gathered from application users in terms of complaints, suggestions, feedback etc. One way of working of helpdesk is to record the problem, provide the solution and treat the story as finished.
Another way to look at it is to analyze this data and find out if there are any complaints that are recurring in nature. Definitely there would be certain problems that would be occurring repeatedly. Providing a temporary solution is good as an ad-hoc provision but getting into its depth later and finding out a permanent solution is very important.
Tasks and Constraints go hand in hand. Life is full of tasks. So is a Project. Project Management consists of lot of planning and re-planning. If everything goes smooth as per plan, there is never a need of re-planning. In real-life scenario this doesn’t happen. Constraints are the generators of problems and problems need solutions. For addressing a problem and providing an alternative to suit as a best possible solution creates the need for re-planning.
A continuous analysis of what is happening around in a project is important to understand if everything is moving as per plan or if the deviation from the plan is going to cause a disastrous situation (or something in-between the two extremes).
The two constraints classifications are:
1. Capacity Constraint
2. Quality Constraint
Identification of factors causing any of the above constraint is of prime importance. Sometimes it is easy to perceive these constraints in early stages and make them part of your risk analysis. The mitigation plan is made accordingly. Sometimes these constraints if not perceived and made as part of risk plan cause trouble when arise at a later stage. If they are encountered at a later stage, it comes as a shock rather than a surprise.
Constraints may arise due to various reasons, some of them could be:
1. Lack of clarity of project goals
2. Lack in project management methodology
3. Non adherence of standard processes
4. ambiguous processes
5. Lack of drive
In a normal scenario testing of a product is done within the organization by the quality/ test team members. Lately as cloud computing came into the picture, a new concept of testing on cloud has emerged, though not many companies have jumped into it.
Testing on cloud carried quite a number of benefits in terms of cost and resources. It is something like “service on demand” or “testing on demand”. The cost of hardware, software, tools, tester etc. is charged on usage basis.
Some of the key benefits that can be drawn from this are:
1. Tool License Costs: You don’t need to invest in tool license. You have varied option of selection of choosing tool of your choice depending on product to be tested. The service provider is supposed to ensure that latest version of the tool is provided. So instead of paying a hefty amount for buying a tool, keeping track of updating it with latest patches and fixes, getting bothered about the new release and then depending on it for all your product range; you just need to pay-as-you-use basis.
2. Infrastructure Costs: To perform testing, to load tool and to provide a substantial hardware/ infrastructure platform in-house; you can go straightaway for the cloud service provider.
3. Flexibility and Wide Range: You have the flexibility of using only when you really require. And you have an option of choosing the right tool for right product.
4. No Setup and Procurement Time Wastage: You can bypass to invest your time in procurement and setup process. straightaway select the cloud vendor, and get the setup already up and running to start testing instantly.
5. Expertise: You don’t need to hire tool experts.
Project Management is involves strategy, plan and intuition. A project may be complex to manage if project targets are not indentified properly. It may be simple to manage if project targets are identified, risks perceived correctly and risk mitigation plan is made a important subset of project.
In a battling ‘software project targets’ situation two major villains that emerge out are lack of time and lack of visibility. It clearly indicates that a revisit and refinement is required in the project management system/ process. The Project management team comprising of all major stakeholders are required to investigate project management practices & procedures and acknowledge the loopholes.
Gaps in project management processes can result in loss of the business to competitors. That is why time investing in building a quality project management practice becomes prime important.
Some important points to take care in that case could be:
2. Manage the entire project cycle from project initiation to project sign-off with involvement of major stakeholders.
3. Monitor the progress with intrinsic insight.
4. Try to identify and nullify time and effort wasting activities.
5. Maintain regular status reports visible to everyone associated with the project.
6. Seek Feedback on project status and performance in every project meeting.
7. Control deadlines.
8. Track expenses and time budget.
Earlier IT organizations used to focus on technology and its synchronization with internal needs. But this focus has steeply shifted to an in depth selection of right technology out of all possible available in the market and its maximum utilization to cater to the end users who in turn use these tools to manage, control and enhance their service to internal and external clients.
This is where Standards come into the picture. Global standards help in meeting internal as well as external customer’s expectations. Standards chosen must be such that they meet today’s and tomorrow’s challenges to cater to the business needs. It should be based most comprehensive and widely accepted framework globally. It should be flexible yet filled with best practices to chalk out your own path to excel in both world’s expectations to help you in delivering the best practices based services.
Like any other large sized product, it has to be implemented in steps. It cannot be done in a single step. A mapping with the existing and future business needs with the best practices available is important for which the needs are to be indentified very clearly and correctly. For any organization, its business needs are unique and hence should be the strategy to adoption of best practices.
The benefit of such an approach is that it helps in ensuring expected level of service with a high level of consistency.
It will also help in achieving highest level of internal and external customer/ employee satisfaction as well as will in lowering in the cost of service thereby increasing business value and reputation.
Project comprises of many functions. Each function’s identification, staging and monitoring is prime during all stages of the project. Function’s progress indicates the progress of overall project. A broken function means an immediate attention. Attention will be possible only if the function is being closely watched or monitored. Else the breakage will go unnoticed and may attract attention at a later stage when something disastrous happens due to this earlier breakage gone unnoticed.
Sometimes a small breakage may evoke and evolve a sleeping volcano to create a major problem.
Function going smooth also indicates no bottlenecks in the project. A broken function means a risk identified that needs to be mitigated.
A smooth closure or finish of a function acts as a catalyst for the next function in the row. A broken function accumulates negative impact for the whole project.
Some broken functions may have chain reaction of generating more broken functions.
Data collected for any purpose is useless in three cases – one, if it is not collected in standardized form, two, if it is being collected just for the sake of collection thereby not doing any analysis and three, if no thought process is gone on analyzed data to improve the situation.
In all the three conditions, the purpose is not being catered to. But let us understand that different organizations in terms of data collection fall in different categories as mentioned above.
The organization falling in first category are just collecting data blindly without any serious thoughts gone into the process. The second category organizations are a little better than the first condition because the data being collected is in organized or structured form but no analysis is being conducted on that data. But in case the organization wakes up and plans to do some analysis – atleast they will have the base data in proper shape.
The third category organizations go upto analysis part but do not draw out sensible conclusions to improve the situation.
But sooner or later all organizations need to fall in the fourth category – that comprises of:
1. Collection of data in proper form
After the completion of a software project, the project closure report or project sign off starts a new experience. The users start practical usage of the product in live scenario. The management starts expecting the useful information in form of reports and screens to manage the business more efficiently. Above all everyone expects more comfort and more confidence.
Though in the initial few months both the users and management may not get completely what they expect. The users comfort will increase gradually as they become more and more conversant with the product in isolation.
This will be a learning stage for them too which will teach them some real lessons that were not covered in training sessions. The problems they encounter might not be technical issues, it might be related to wrong usage of the product. All this gradually evolves and results into a more knowledgeable user.
Management on the other will depend on two factors – the feedback from their key users, and their own experience with the product.
Over a period of time, after these initial struggles, the management, users, and product have to synchronize to get the useful results.
Post implementation support includes customer registering the problems related to the product and the product owner resolving it. There has to be an agreement or contract of service that defines the level of support.
Customer may report about a problem in various manners viz email, web portal, IVR, phone etc. giving too many windows to customer to register a problem, itself becomes a problem for the vendor. Vendor must ensure that any call coming via any media, must go to a central repository. If all calls from a customer are not registered in the database or central repository, the purpose of recording a call will not fetch out any useful results at a later stage.
Vendor will not be able to monitor the calls, keep track of open calls, or maintenance of a proper history of resolutions. At any later stage also if vendor decides to do some analysis, it won’t be possible if the repository contains partial number of calls.
Sometimes vendor wants or doesn’t want, pressure may come from customer end to produce analytical reports, failure of which may cause troubles in further renewal of contract or payments.
Product is understood, developed and implemented. Sign off has been taken, and post implementation report is submitted. All is well so far. What now?
Next leap of journey begins. The product usage, results expectations and problems encounter. Users get into the product on their own, start digging it deeper and deeper to understand it more and gradually get more confident. Problems encountered are being reported to the support contacts and issues are getting closed sooner or later.
But one point is skipped. There are many problems which are repeating every month. Customer reports and gets the solution but the level of confidence is lowering. Customer has started getting annoyed due to this repetition of problems.
Repetition of problems needs to be addressed. It is the most crucial factor and may become skeptical.
Someone needs to look into it and notice the deteriorating health of the product.
If the Project Manager doesn’t know the direction of the wind, he can’t be a good sailor. To drive a project a project manager need to set certain milestones. To make these milestones achievable on a regular basis (weekly, daily, hourly) he needs to break these milestones into tasks and sub tasks. These tasks are assigned to appropriate team members with the mutual consent on deadlines to finish the task.
The deadlines are closely self monitored by the task achievers (programmers, developers, testers,…) to maintain the rhythm and momentum.
At any moment if a task is getting delayed to finish, an alarm is required to be raised so that all members get alert and focused to find out the delaying factors. These factors are then analyzed and overcome with the team effort.
The direction of the wind keeps changing. So should be the priorities and planning of the project manager.
Project performance is the resultant of performance of each and every component of the project. Components of the project means – various team members. These team members are assigned various tasks and sub tasks of the project. The result of these assignments collectively draws out the overall project performance at any moment.
If any of the project tasks is not finished as per plan, the delay will effect the finishing of forthcoming tasks. Project manager has to be a good analyzer, critic and observer to identify the performers delaying the project from its plan. Once identified, the analysis can give the reasons of the delays.
If these reasons are timely identified and addressed to, the delay can be shortened and the performance of the project can be streamlined.
An eagle’s eye is required to identify the performance bottlenecks proactively to act upon to achieve the tasks as per plan.
Every project has a number of milestones. The achievement of each milestone establishes a landmark covered in the project thereby reducing the distance to the final destination. The milestone is divided into a number of tasks which are further divided into sub-tasks. A set of tasks is assigned to a team and the sub tasks associated are distributed among the team members.
Each sub task has two important coordinates. One – the owner who is supposed to perform this sub task and the time required to finish it. Completion of the sub task before the stipulated time is termed as ‘Successful’. Completion of any task/ sub task/ milestone beyond planned time marks it as ‘Delayed’. Non completion of any task marks it as ‘Failed’.
Result of a task or sub task delivers many important hints. It sets the further direction towards other tasks/ sub tasks or milestones. If result is ‘success’ the direction sets towards further tasks. If the result is ‘delayed’, it impacts on other tasks. If the result is ‘failed’ all focus is set on the current task to make it success.
This multidirectional focus on a single task has a propagating impact on further tasks.
1. At times development, requirement freezing gets done side by side and that too at customer location. In that case the product undergoes a lot of changes based on customer feedback on daily basis and finally product gets ready as per development team and customer.
After that it comes to QA for testing.
Is that right?
And how QA’s role differs here as compared to the scenario where customer requirements are freezed, product is developed, QA is done and then it goes for beta release, and final implementation
2. What if requirements are not documented properly and development team is dependant on what is told to them by the person who went to customer site for business study. But this guy has no document signed by customer; in that case if he has understood the business processes wrongly, it gets coded wrongly.
On what basis QA conducts the testing in this case?
No project can be started without estimations. The estimations are to be done about the resources, manpower, team compositions, budgets, releases, development and so on. Estimating software is not an easy task. Production estimations are simpler as compared to service delivery estimations.
More machinery involvement eases your estimations. On the other hand the more human involvement increases your estimation pains. There are more chances of your estimations going haywired when you are totally dependant on man than a machine for delivery to a customer. Machine breakdown can be handled in a more technical and professional manner. But to manage people you need extra skills to manage all kinds of turbulence.
Software project estimation can not be done just once in the beginning and then every thing moves accordingly. It has to be monitored, assessed and re-estimations need to be done from time to time.
Estimation is an art and skill which gets polished with experience and time.
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.
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.
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:
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 –
2- to move ahead in terms of requirements and building of product.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.