Release Management is a journey of software product starting from requirement gathering, product conceptualization, prototyping, coding, testing and finally landing to production server. This product inception and production journey starts with developer’s machine to development server to testing server to production server.
After developing and completing the code, development team hands over the product to specialized persons for performing unit test, integration test etc. to that the product can be formally handed over to testing team for regression, performance, functional and load testing.
A test server is built for this purpose creating a similar environment as that of the one going to be used in the real scenario (production stage). The code residing in development server is replicated or reproduced in test server for the purpose of testing.
It is always better to perform some good level of internal testing by development team before releasing the product to testing team.
Generally in a product support group the end user call is closed by a support executive. This sort of process misses out two important factors – the customer or end user and the quality group. A call closed by the support executive neither mostly gets it vetted by the end user nor is there an independent verifying agent involved in it. The system poses a dicey situation under such circumstances. The process calls for a modification to enhance it to such a level so that the above two setbacks are covered in that.
Risks involved in these circumstances are high and will never let the support centre reach to a satisfaction level. It will also keep raising a high level of dissatisfaction at end user level.
To mitigate such risks the process needs to be enhanced. The best way is to get following 3 points deeply engrossed in the process and without these 3 points activity no end user call should be allowed to be treated as closed. These 3 points are:
1. Get customer feedback: Have a small 2 or 3 questions mailer after every call closed to be filled by the end user to ascertain her satisfaction level for the last call closed.
2. Embed Quality for closure: Include quality executive in the call process loop having a responsibility to close the call. After the support executive closes the call, let the quality guy call the end user and confirm about the call closure and also quickly get his satisfaction level feedback on it.
3. Regular Analysis: A close monitoring of calls during a week, fortnight or month, their status, the open calls beyond permissible time limit, customer feedback etc.
A geographically scattered user base requires a well equipped support or call resolution centre to cater to their problems. A well launched product will never give troubles will be a misnomer. Any level of users at any stage keep encountering issues, problems, doubts, and usage related concerns. These need to be addressed by a team of persons having a good functional and technical knowledge of the product for which they are meant to provide the support.
In a wide country of different logistical user base using the application, there are different ways of handling their issues. One way is to group these various locations in small segments and provide them a group wise support team. This could work well in satisfying the users but could cause problem in looking at the scattered and localized data at a wider angle. Data accumulation, mining, digging and analysis could be a big headache for the product support manager to understand the product related issues. Since there is no common platform where are data is getting accumulated, the analysis of improperly gathered data lead to wrong conclusions regarding finding out the major pain areas of the end users. This would also lead to the wishes and whims of the local support function to decide whether they collect all complaints properly or keep missing lot of them. A wrong platter of data from various support centres may not be fruitful.
On the other hand a centralized support centre providing to support to the end users scattered across would be useful in maintaining uniformity, useful data collection, and proper analysis.
Support or handholding phase starts in a project after the project is handed over to the customer for real-life business usage. The end users start exploring the strengths in the software by performing their respective functions on the product. During this exploration period they do encounter the weaknesses also hidden in the product. The actual experience of end users on the product results into a different set of issues related to product which mostly is not pointed out in any phase of testing.
At this point of time, since the production server is live and the business users are realizing the product’s capabilities and shortfalls, besides running the application to draw out business expected results, the problems reported cannot be delayed for providing a solution.
The support executives have to understand the gravity of each call of the end users to make it a point that the issue reported need to be resolved within the agreed upon timeframe. Some issues reported might be irrelevant in the beginning due to the fresh interaction of user with application, but those can not be ignored.
The Support function schedule need to be fine tuned for optimization purposes keeping in mind the following points in mind:
1. Be objective
2. Define accountability for each member
3. Restrict deviation from schedule
4. Make unreasonable deviations penalized
1. Always strive to perform better manual testing (in the manual testing area).
2. Code and Testing are not two separate entities. A Coder can and should take as much care as possible of not embedding bugs (knowingly, unknowingly, carelessly or for whatsoever reasons) in his code.
3. Follow a proper methodology in testing. If it does not exist, stop all testing, get it framed first.
4. Manage tight schedules smartly by not compromising with the quality of testing.
5. Quantify risks to make everyone clear the shortcomings of testing with over-tight schedules.
6. Different phases and types of testing require different approach. One approach does not fit everywhere.
7. Test automation is not always beneficial; it has certain shortcomings too, varying case to case.
8. Quality is integral part of product or software supply chain.
9. Identify, plan, manage and mitigate testing risks.
10. Try to make Quality as an asset rather than overhead cost.
11. Focus on quality of project documents also to maintain the decorum of project.
12. Don’t expect too much credit for imbibing good quality in the product, which is what we are supposed to do.
13. Follow a metrics for your processes and methodology to understand the shortfalls.
14. Create quality rather than product.
15. Testing centre of excellence is not a hypothetical state, live with it.
Support function in a project after the completion of the project. Project sign off includes a successful ending of a journey beginning with business requirements study, development phases, testing, training and implementation. But the actual journey does not end here. After the project sign off, a stage by which the user and customer management have respectfully reflected their confidence in the product built for the purpose, but the actual hand-shaking (or fight) of end user with the product starts from here.
This is the time when in absence of implementation team, for the first time, the end user is starting using the product, all alone, on his own. All knowledge gained so far, by him, during the implementation phase, along with the supporting documents (user manuals) are the sole weapons left with him to win this battle. The initial phase of this familiarization with the product in isolation is really like a battle.
This is also the time when on a parallel spree back office support function starts for handholding the end user’s issues being encountered. In the beginning, since the maturity level of end user on product usage is not too high, some of the problems reported may appear to be absurd to the support function team. But they have to understand the reasons behind this and handle the situation accordingly by putting an effort of educating the end users to guide them for using the product in right manner.
The maturity of issues reported to support team will gradually improve as the usage of product and acquaintance with product increases.
A newly built Software application has to pass through one very interesting testing phase known as Usability Testing. This testing is more focused on finding non functional issues related to the application. The focus is more towards the end user who is going to use the application and not the management who is going to reap the benefits out of it. Ease and comfort, navigation, simple architecture, etc. are the relevant areas that are looked into while this testing.
The end user is the most suitable candidate for performing this testing. But if not available, then the developer or tester who perform this testing must put themselves first in the end user shoe before they start conducting the testing. The end user’s overall experience of using each relevant screen and report are the major concerns. Overall the application may be quite strong but if it does not make end user comfortable regarding its usability, it is prone to win over the management.
The design of the application has to be fit in the end user’s perspective for looking good as well as the professional touch in each of the screen and report. Five most crucial parameters in this aspect could be:
1. Intent of delivery: Try to fill in the gap between the end user’s expectations and the actual delivery.
2. Navigation: This is the area which could give most delightful moments of satisfaction to the user or can kick back in shape of user’s frustration.
3. Response Time: The application screen or report loading time should not go beyond user’s perceptions. A user understands very well about the heavy data centric screen or report versus the lighter ones, and prepares himself accordingly for the output. The users have their own experience with the other legacy applications in use or certain applications they use in person.
4. Cleanliness/ Alignment: The screen should soothe the user rather than presenting him with a non friendly positioned data labels. A symmetrical alignment, non cluttered placement of all components of the screen should be well planned for designing purposes.
5. Nomenclature: Keep in mind what terms end users and customer business are most familiar with regarding the similar labels being used in the application. For example if you post a label “employee’s card no.” and the customer denote their employees in all business records as, say, “associates” then your label should be “associate’s card no.”.
It depends exclusively on you whether you are driven by your circumstances or take command of your circumstances. We all encounter negative forces around us from various persons, situations, circumstances, and failures. Do we get bogged down by these negativities surrounding us or we tend to mould them in our favour, all depends on us. Negativities are unwelcome though but can not be avoided. Best way is to learn a lesson from each negative force to overcome it and change it into a positive factor for you.
A project manager has to face lot of hurdles during a project. A single person in the centre point has to face many fronts in terms of teams, management, peers, customer, project board, and stakeholders. Despite all hurdles he is supposed to keep his tempo up and maintain the momentum of the project progress.
It is not easy, though, to cheer up all around without first keeping yourself with high spirit. There are certain negative forces around the project manager which need to be mastered to play with and win over. Some of those could be:
1. Criticism: Criticism arises out of two situations – one could be due to a fall back in a task or achieving a milestone. Other could be the situational, intentional and irrelevant. Both can not be avoided. Some people have a tendency of raising unnecessary criticism just to stay on top of others by using their power. Learn about the situations, people, circumstances and failures that tend to invite criticism. A proper analysis of each such instance will definitely improve your learning curve towards handling such situations and give you knowledge and strength to handle such in future.
2. Self Assessment: Keep assessing your process, procedures, methodology and your crisis management techniques to understand if you are managing the show properly or it needs an improvement. Ignoring these will definitely cause more troubles at a later stage.
3. Arguments: Arguments with management, customer, peers, team members etc. do happen during the project. It could be on any matter related to the project. Avoid giving negative statements and mould arguments to some constructive direction where results can be drawn out. A long argument without any fruitful results is a waste of energy.
4. Conflicts: Although a project manager tries to keep everyone in line while driving a project but conflicts are unavoidable. Let conflicts happen but not for the sake of conflicts. Resolve conflicts while taking an in-depth dive into the situation to understand the purpose of the conflict and a way to handle it smartly.
5. Discussions: Discussions and meetings are for the purpose of monitoring of the project. An unexpected situation needs an immediate discussion for resolution. Know the best people to discuss with for your project issues. Unnecessarily discussion of an issue with irrelevant people will not fetch appropriate result.
6. Stress and Strain: Stress and strain need to be managed properly. If you don’t shelve out your stress if will pile up to an extent to reach to breakeven point.
7. Feedback: Seek feedback from appropriate persons concerned to understand your way of managing situations from their angle. It is a good way of building trust among peers, team members and management.
8. Mistakes: Mistakes do happen, risks do occur during projects. Don’t get bogged down. Rather learn from your mistakes and best way is never repeat a mistake. A repeated mistake will point towards your incapability of handling situations. Otherwise you will be quoted as a good risk mitigator.
Let us look at a practical scenario. A project manager of a mid-sized company (under its expansion plan) is given a responsibility to manage the hardware requirements of its new team at a new location. The new team is to be recruited and each team members is to be provided with a sufficiently working laptop. The project manager has to decide on various factors for the hardware requirements of his new team and many ideas bubble out in mind, like:
1. What to buy?: The technology is changing everyday. Today’s hardware purchase becomes obsolete at a very fast pace. Average hardware life in decreasing in today’s price versus technology war. If the procurement process takes long in terms of time in any organization, the final decision of buying a piece of hardware could result in procurement of an outdated product. Decide on the minimum requirements of the software to be run on the machine and based on that arrive at the configuration keeping a buffer of memory, hard disk, processor, graphics in mind. Software to be loaded on the machine too has its end of life predetermined by the software provider. So be sure about the hardware requirements of the software tools, OS etc. that are to be loaded on the machine.
2. How much warranty to be bundled with the purchase?: These days hardware comes with a tailor made warranty plans. Besides standard warranty of the product you can have extended warranty for different periods by paying its corresponding warranty cost. Bundle this cost with the initial cost of the product and you get the extended warranty for a period of 3 years, 5 years and so on right from the day one of your purchase.
3. Purchase Service contract on equipment and replace computers every three (or less or more) years: With the trend of technology enhancement every other day, your newly bought latest piece of hardware becomes short of certain new features shortly after the purchase. It is recommended that in such scenario have a company wide policy to replace your current hardware after every stipulated number of years. For example a policy of replacing all desktops and laptops every 3 years is not an unknown phenomenon these days.
4. The manufacturer provides a warranty on electronic equipment. Further protection is a rip-off: The warranty on your hardware does not suffice the purpose unless it is equipped with the equivalent warranty/ upgradation plan of other supporting agents. Anti virus, anti spam, firewall policies, network policies etc. all are non-isolated entities and need to be considered for each and every piece of hardware residing in a company. Some individual machines may require customized policies or features.
5. Rent electronics rather than purchasing them since technology changes so quickly: In fact the hardware can be leased on a service contract consisting of replacement terms and conditions as part of the contract. If the equipment is procured on rent, it becomes prime responsibility of the equipment provider to keep it defect free, 100% uptime availability and regular upgradation plan.
6. Create a common workspace where people sign-up to use machines. Limit use to two hours windows so that everyone has equal opportunity access: This is another practical scenario in heavy people centric organization where people can be called in shifts using the same set of machines in their shift being used by another set of persons in the previous shift. No machine belongs to an individual but an individual gets a feel of using his own personal machine by logging in with his/her own credentials.
The same solution may not work for all, as it will depend on nature of work of the company, its number of employees, its culture, policies and certain other parameters.
There are two options to focus upon during your project. Either Focus on results without bothering on the activities going on during the different phases of your project. Or focus on the activities of your teams without bothering about the results.
When you focus only on activities, apparently it would appear that all will go well since you are examining each and every activity under a microscope. Any loophole or defect in a particular activity will immediately pop up with an alert for the team to seek improvement or enhancement in that process thereby yielding an expected and desired result. With an eye on each activity process and fielding improvements where required will optimize each activity resulting in expected results in the overall project.
When you focus only on results, each team is supposed to produce results without much bothering about the activities they perform or the process they adhere to. The timely results will speak out loudly about the right processes in place and right activities being performed. A successful achievement of results at each stage of the project will finally produce a thoroughly successful project at the end.
Certain points to ponder upon could be:
1. When we talk of first case where prime focus is only on the activities – Is it possible to find out a slack or defect in a process without looking at results? A minute monitoring of activity or process if yields the desired result will automatically fall in a category where not much attention is required to enhance it. But even if a minutely observed activity or process if does not produce desired results will definitely mean that there is something wrong in the process or the activity being performed and requires immediate attention.
2. If you just keep focusing on results and you keep getting useful results, you might not bother yourself or your team to look deeply into the process adopted or the activities performed. A continuous yield of good results will take away attention from the process or activity monitoring which could result into a hot lava increasing under a volcano. The volcano can burst anytime at a lager stage resulting into a disaster.
That means a middle path is required to be taken where an examination of process, activity and result go hand in hand. This middle path will be most suitable for a sustained fruitful result and for any form of short term and long term benefits in the project.
Any product development requires extensive testing process before it is launched for production. A great effort is put by the software development company to launch the product for its customer in its perfect working condition. The goal is to provide the customer with an equivalent volume of benefit of the product in lieu of the price paid by the customer for it. Though all stages are crucial in product development lifecycle but utmost care is required during testing phase to ensure that there is utmost alignment between the product specifications, customer requirements, customer expectations, product developed and product delivered. Any gap will reap unwanted and harmful results.
There is always a gap between the perception of customer about the product and the actual product delivered. This is revealed only during the delivery phase when customer gets the first exposure of the real product. Product manager and development manager take definite steps to ensure that customer encounters least surprises at the time of delivery of the product. For that, it is always recommended to involve customer’s key users and management during all phases of the project. It is the duty of project manager to keep customer front updated on each and every step towards the progress of the project.
It is the customer finally who is going to vet whether the progress perceived by the project manager is PROGRESS in reality or if there is any gap. The customer’s observations need to be captured and recorded as clearly as possible to understand this gap, if any. Otherwise if the product is developed in closed doors without customer involvement, it could give a shock at the time of the product being brought out in the light for the first time.
The responsibility of project manager does not end by ensuring that all information related to product development reach customer front, he also need to ensure that the customer feedback at each step is taken seriously and followed upon. Any discrepancy of non possibility of adherence to any point or requirement highlighted by the customer should also be updated to the customer with a valid reason.
It is better always to demonstrate the partly produced software at frequent intervals to the customer in order to ensure that all people involved in the journey are sailing on the same boat.
A product manager during the product lifecycle has various options of selecting a pair of shoes to wear. It depends on his choice whether he wants to cover the journey in comfort and feel the pinch later or wears a not-so-comfortable pair of shoes felling for a pinch during the journey but feeling relaxed at the completion of the journey.
The various choices of selecting shoes are:
1. Shoes of his top management
2. Shoes of an analyst
3. Shoes of a technical architecture
4. Shoes of a developer
5. Shoes of a programmer
6. Shoes of a tester
7. Shoes of a development/product manager
8. Shoes of customer key user
9. Shoes of customer management
10. Shoes of Support executive
The choice is purely yours now as a development or product manager which pair of shoes would you like to wear. It also depends if you wear the same set of shoes throughout the journey or change it during the different stations of the journey depending on the current path of your journey. But keeping all shoes handy and an attitude to readily change the shoes will definitely keep your life less stressful.
Obviously you need to perceive the right moment to change your shoes, as wearing a wrong pair of shoes at a wrong time would give you more pains at that moment and moments coming at later stages.
Check out – which pair of shoes are you wearing at the moment!
And remember one more thing, if you don’t have the right pair of shoes with you to wear at right moment, lend it, but don’t run without it!!
When it comes to product building, a product manager is the person who is whole sole responsible person to own its success or failures, whatever the outcome results into. The product manager needs to carry some hot properties in his kitty to win over the situation.
His kitty bag should contain:
1. Good Business knowledge: Without an ample number of years of experience nobody can become a good product manager even with very high skills and qualification tags. A person who himself has spent certain substantial amount of time in understanding business, developing product and maintaining quality in his early career stages cannot become a good product manager.
2. Business analysis skills: Though this job is usually done by someone else in project management but a product manager is supposed to have an equally balanced business analysis skills to overcome any of the customer requirements skipped or semi-understood by the business analysts before the product development starts.
3. Technical know-how: Without having a good technical knowledge a product manager cannot decide about the right platform, development tools (front-end or backend) and thus his decisions about the technical set-up may create a big problem at a later stage.
4. Team management: A team comprises of all kind of people. No two programmers or testers think the same way. Two programmers will write the same code requirement in different fashion. The code written in two different ways may perform same but the two codes written may differ in terms of complexity, structured designing and size of the code. Similarly two different testers will test a code differently and will bring out different results. These issues at stretch can me managed with standard procedures. But there are more issues related to team – HR, behaviour, attitude, knowledge, experience etc.
5. Business solution architecture skills: A product manager has to be visionary in deciding about the product architecture. Database design, table structures, code architecture guidelines, server sizing, etc. has to be dealt with keeping in mind that these things create complex issues if require a change at a later stage.
6. Time management: Product deliver commitment is done in two ways. One way is estimate each micro level activity involved in the product development and then commits a deadline for delivery of the product. Another way is just give an estimated deadline and then start reverse engineering to fix timeline for each micro level activity. A buffer time basket will definitely help in both the cases to manage unpredicted problems arising in between during the development.
7. Leadership: There is a different in commanding the team and getting the things done by demonstrating yourself. The product manager has to lead in certain cases to demonstrate the team various possibilities in managing the situations.
8. Managerial skills: A regular flow of monitoring, follow-ups, sanctions, approvals, queries, questions, issues, confusions needs to be managed to keep the team members tied in a rope together to drive on the same road together in the same vehicle to the same destination.
9. Communication: A three way communication is very essential for the product manager during the product development. He needs to keep the communication bar intact and aligned between the customer, his own management, and his team members. He should be very clear to identify between the information that needs to be shared or to be communicated without sharing with others.
10. Change Management: Change requirements happen anywhere and everywhere even in day-to-day life. During product development, many such requirements arise that need to be managed tactfully and smartly so that the progress doesn’t get hampered on one hand, and the momentum of the team stays up-swing always.
11. Disaster Management: Risks are bound with any development be it a personal life relationship or a product development. A product manager must always be prepared for pre-conceived or sudden unknown surprise risks. He must be able to get the crux of the situation at any such moment and move ahead with a timely taken right decision.
If the product manager masters on the above skills and his delivery model accordingly, he has all chances to win over the situation by delivering the right product to his customer in stipulated time-frame.
Imagine yourself as a commercial builder. You are contracted for building a multi-storeyed building by the owner of that plot. The owner is too busy to concentrate on the job himself. He finds you as an expert in this line. The conceptualized model has been described to you by the owner. You are being paid to get this concept into reality. Owner does not want you to bother him again and again for understanding the requirement or building a right product.
Understanding the requirement and building a right product are two separate entities. You might have understood well about the requirements specified by the owner to you. But fact is that you are not going to build it on your own. You will hire a group of teams to perform this task. The dream concept, of the owner of the building, need to be translated well to the actual labour, who are going to build it. You have to be as equally good strong imagination power as able to explain it well to the people who are going to build it.
The owner perceives that his job is over by telling you the requirement and paying you a handsome amount to you to handover the responsibility to build it as per his dream. How much of the built product you are able to convince your owner depends totally on you. Nobody else is going to help you in that. It is purely your call that even if you build purely as per his requirement, he may not like it. It is your risk. You have to manage it and win over these hurdles. All labour and other people engaged in building process are directly under you and not under the owner of the building. You have to manage them, you have to pay them, you have to get the right product built by them to satisfy your owner.
The same thing applies in building a software product. You engage your customer during the build or not is your wish. You may be 100% confident that you have fully understood the requirement and are building a right product without involving the customer during the various stages. You could be confident in understanding the requirements and building of product but still may involve customer during all major stages of the project and keep taking his approval. You might fail in both the cases in final leap but chances are more if customer is not engaged during your journey.
A testing career like any other careers in Software Project has a long journey to cover to reach to a level of satisfaction. Tester needs to perform his career objectives consistently during all stages of his career. A consistency in performance will help him sustain his current level, but to acquire a continuous growth plan, he needs to think differently. A continuous improvement plan is required to attain an upward graph in his career growth. An extra edge over his peers can be attained by adopting following qualities that not only help in career growth but also provide a strong belief in his capabilities.
The qualities can be listed as below:
1. Capabilities Assessment: A Tester needs to assess his current capabilities at regular intervals. A regular monitoring helps him in analyzing the capabilities growth chart trend. If his capabilities increase continuously, the trust on him by his peers will keep increasing. His seniors also will rely more on him for any new challenges that come across during different phases of project related to quality areas. A regular trend also helps him in ascertaining his future capabilities.
2. Optimization: How do you optimize your skills? Do you have a successful mandate for that? Do you realize the importance of that? Do you understand the benefits of that? All these questions will definitely prompt you to understand the importance of optimization of your skills. It not only helps you in your professional growth but also enhances your knowledge stream thereby providing you an internal satisfaction. The catalytic effect is enormous in assessing your potential once you start driving on this path. The best way to get the feel of it is through your peers, mentors, seniors and friends.
3. Sustenance: Achieving a height is simple as compared to sustaining it. Next heights can be achieved only once you sustain your current potential. Then you can strive for your next leap. Higher level of capabilities can be tapped only by way of achieving it and more importantly sustaining it.
4. Strategize: There are two ways of growing. One is choosing a smooth road and driving on it without much efforts and pains. Another way is to choose a road with lot of potholes, doing extra efforts, taking pains and making your drive a smooth drive. If you want to catch sight of your peers and managers, choose the second path to demonstrate your hidden skills and talent. The managers will not hesitate in empowering you once you win their trust once for all.
5. Neutral: You need to take a neutral stride. Unbiased opinions and working style pays in long run. There is no short cut to success is a well known saying. Repeat it everyday so that it gets engrossed in your mind. Be open, neutral and transparent in your work.
Project Management is not everything related to the management of a project. It is absolutely not the end of the road. If you have a well defined project management methodology (or different methodologies for different project types actually), it never means that just the regular reviews of these methodologies will make your project’s life smooth. Project management and organization continuously need to think beyond the horizon of project management to look into the galaxy and keep exploring the new innovative ways to enhancement in the existing processes and methodologies.
The success of project depends on an absolute success of each of its phase which further is divided into that phase’s milestones. The adherence to timeline and budgetary targets need to be adhered to in order to achieve success in any project. Project management though comprises of different phases starting from project initiation till the project implementation, handover and final sign-off, requires different skill sets to mange each of the project phase.
If we look at the major areas that are required to be managed in a systematic and specialized manner, those would be:
1. Requirement Management: This is most critical phase of the project requiring specialized business analysts having a strong visionary knowledge about the business, product and documentation. Lack in any of these skills would impact on the total flow of the project lifecycle.
2. Development Management: It requires a good combination of skill management, team management, time management, task management and talent management. The development manager need to be a master of all these skills to get an edge over the timely delivery of the product.
3. Test Management: Test management requires an altogether different skill set. The test manager need to be proactive, innovative, intuitive with a good knowledge of the business and product.
4. Issue Management: No project progresses without any issues. A systematic approach to manage an issue helps in managing the project in a better manner.
5. Change Management: Changes to happen during a project, change in team, change in deadlines, change in product requirements, change in management perspective, change in strategies, change in plans and so on. A proper well defined change management process helps in managing the change smoothly.
Without a vision, project can never be managed. Without management a project has all chances to go out of control. To have full control over the project during all its phases certain visionary tools are required to overcome obstacles. Different teams are engaged during different phases of the project. Many teams have to be vertically and horizontally coordinate to make each phase a success to jump over to next phase. Certain phases overlap during the project lifecycle.
The teams harmony and coordination (inter and intra) are the two most useful keys. Team members are responsible for their individual roles. But they need to rely on their peers across other teams to progress. Project success, on top of all other motives, has to be supreme and universally acceptable to all teams. Stakeholders and top managers play a major role in achieving these goals.
Some important visionary tools in that regard, can be listed as below, which if adhered to in right manner, help in achieving the desired results at all stages and thereby providing a grand success to any project. Irrespective of project methodology or processes adopted in project management, these tools act as catalysts. The tools listed below need to be adopted and absorbed in all teams across the project board. The tools are:
1. Purpose Clarity: Project purpose must be very clearly defined right in the beginning of the project. Without a clear cut purpose, corresponding goals can’t be set. And without goals, no objectives can be achieved.
2. Vision Sharing: Top management and stakeholders have their own vision for any software project. The business goals and organization processes to be controlled through this project (software) must be clearly defined. The short term and long term vision must be shared with all the teams involved in the project.
3. Clear Responsibility: Purpose, goals, vision, targets etc. are important, and equally important is to clearly definition of responsibilities. Ambiguous or unclear responsibilities may lead to lot of confusions and ultimately a big disaster.
4. Mutual Harmony: A team comprises of different individuals having personal perspectives and ideas. A clear vision, purpose, set of goals, responsibilities keep all team members attuned and attached to each other like a bunch of flowers. Sharing of individual strengths by means of complimenting and supplementing will lead to a good harmony and thereby guaranteeing a project success.
5. Trust: Different teams need to trust each other. A vertical and horizontal scale of trust built among various team members within a team, and various teams brings better results. Positive conflicts do occur within or across the teams but as long as they are combined with mutual goals of targeting a powerful goal achieving plan, it benefits the project.
6. Feedback and Sharing: Isolation never pays good results. A continuous feedback is important by different managers to their team members. For feedback, managers need to be in line with the happenings around them. A regular review process, feedback and sharing of ideas gives a boost to the project progress.
A project never goes smooth. It brings unexpected problems during the execution of any phase that marks a difference between the planned activities and actual executions. The deviations enforce re-planning of further activities so that the extra budget and time spent on previous activities can be compensated by revised project plan.
A loser is a loser only when he realizes it and gives up. As long as one thinks he has the capability of changing lose situation to a winning situation, he is never a loser.
Project management philosophy emphasizes on sharing the problems with all stakeholders and team members so that different brains come out with different responses and any of the response(s) can become the best solution(s). Challenge sharing definitely brings out a solution from somebody else having a different set of experience and exposure who has already been into such a situation and has come out of it already. Sharing problems and challenges saves one from re-inventing the wheel. Documentation sharing and a knowledge sharing platform make a strong basis for keeping all on the same wheel.
Managers mostly focus on driving out results from the teams rather than enabling and empowering them to become self driven. Energy flows automatically and uncontrolled. Results start coming out without reaching the deadlines and prior to demand. It depends on managers that by empowerment they start preparing or building leaders within the teams. A combination of leaders, if synergized properly, propels a resultant progress of the project.
Managers become critical key in engaging people in the project. A high level of engagement is lodged in the team members via project manager. As long as the project manager is able to drive teams, it makes them engaged to the project. On the other hand if project manager inculcates and inspires team members to self-engage themselves, the team members do not depend to be driven by project manager.
Both accept challenges. Both have an ability to drive the situation. Both have knowledge and experience to handle a deadlock. What varies is their style of thinking and working. A project manager and a project leader both have a mixed blend of all qualities. What varies is the way they manage a problem.
A leader can be a manager and a manager can be a leader at times. Situations arise when a leader has to manage and a manager has to lead. When a leader is managing a situation, he might be acting more like a manager. Similarly when all of a sudden an unplanned issue arises, serious in nature, and needs an immediate solution, a manager might have to lead others in demonstrating how to manage such situations without looking for standards and procedures. The manager in such situations uses intuitive and innovative techniques more found in a leader.
Most of the successful managers and leaders are good thinkers and have strong expressive powers. Some basic differences between a leader and manager are:
1. Leaders have a power of changing the world. Managers have the power to manage the change.
2. Leaders find out the innovative ways, managers find out the best out of them to adopt.
3. Leaders are the frontrunners leading the way, paving the way, carving the fortune. Managers stay behind the team, taking care of each of the member, managing, monitoring, planning and executing.
4. Leader is more like a mentor; manager is more like an organizer and planner.
5. Leader looks for new challenges, manager becomes an expert in finding out best solutions when encounters a new challenge.
6. Leader enjoys panicky situations. Manager avoids panicky situations.
7. Leader is more like a revolutionary, manager is like a strategist.
8. Leader knows how to convince others with new ideas, manager adopts best procedures to convince.
9. Leader showers credit on team, manager takes the credit for each success.
10. Leader makes teams capable of handling adverse situations by empowering them, manager facilitates teams to achieve targets.
A tester must be visible to the test manager most of the time. The visibility comes through many ways. By means of communication – verbal, mail, status updation, discussions etc. Visibility helps a tester in many ways.
Some of the benefits to the tester by keeping himself visible could be:
2. A constant touch with his boss and other team members,
3. An informal feedback from his peers and superiors,
4. An update on the expectation level of his manager,
5. An positive image of a hard/ smart working person,
6. Challenge acceptor,
7. Trust and respect from his manager,
8. An improvised personality,
An invisible tester on the other hand will never be able to emerge as a winner in above aspects though he/she might be doing better in performance than others.
So the crux of the matter is:
2. If you don’t work, you can’t show it, as nothing is there to show.
3. If you are good in show business, you can grow better than others even if you are doing less.
4. If you are good at work, and good at showing it – you are an ultimate winner.
5. If you are doing nothing and trying to show a lot – you are going to be an ultimate loser.
Broadly a project manager and a project leader seem to carry a similar profile – that is of managing a project and leading it to success in stipulated time period. But if we seek a distinct clarification between the two roles – there comes a demand of a wide gap – as wide as 180 degrees. If one is a creator, another is a builder. If one is a sprinter, another is a marathon runner. If one is a swimmer, another is a flyer. if one is a dreamer, another is a doer. If one is a magician, another is a daredevil.
A manager is supposed to manage his project efficiently. Without taking much risk to avoid deviations from his project plans and milestone deadlines, a project manager would prefer to drive on a smooth road having least speed-breakers and potholes. The best team members, most comfortable deadlines, least cumbersome coding is what he would strive for. With a consistent manner of thinking, a project manager would prefer to strengthen himself and his teams with least changes during his project lifecycle management.
A project leader is supposed to be an innovator. He would be finding out new ways of performing a task rather than following the legacy or orthodox methodologies. He would be a person demonstrating ‘walk the talk’ rather than sitting on a chair and demanding the results. A project leader would not mind if things are not managed very efficiently as long as the desired results are coming upfront. Consistency is not a mandate for a leader. He would rather call for inconsistency and higher risk as he has an expertise to manage those situations.
1. No problem is small.
2. Never look for Shortcuts.
3. Never Jump to Solutions.
4. It is not true that a larger problem will have a higher risk.
5. Seek for value addition in any task you perform.
6. Build a culture around the teams.
7. First See and then Solve the Problem.
8. The gap between the Scope of Work and Scope of Control build up your Risk.
9. Learn Simple but Standardized Problem Solving Methods.
10. After you complete a task spend some time to analyze if it was worth that much time spending on it.
11. Time difference between resolving a problem and figuring out the solution should be minimal.
12. Attempt a solution only when you are clear about it. Hit and Trial method does not pay in most cases.
13. Learn from each problem.
14. Never Repeat a Problem.
15. Share Problems and Solutions.
16. Keep Project related Communication as Structured as possible.
17. Demonstrate others the ways to solve problems.
18. Collaborate People.
19. Don’t spread dirt if you intend to clean the mattress.
20. Still water is more prone to getting Stale.
Regression Testing takes lot hell of time out of overall time provided for testing of a product in any software project. Though it takes longest duration for complete product coverage but somehow or the other lot of things remain untouched or unnoticed during this testing. This could be due to lack of experience of tester, lack of knowledge of product, incomplete or unclear product/ business/ development documents or shortage of time and own management/ customer pressure. Each of these factors marks a big impact on the presumed smooth road of project journey.
Lack of knowledge of the tester could cover up in short form of testing but will definitely leak out in the larger version of testing i.e. regression testing. Many testers worldwide still feel regression testing as most boring and sometimes as non-productive too. Even the development teams feel prolonged time consumed for regression testing by testers as an un-necessary exercise. Due to its long duration many times the momentum and tempo of the testing team goes low. Test automation could be a solution in such situations to shorten the duration of testing and to cover up other shortcomings.
Product knowledge improperly transferred to tester could lead to an erroneous regression testing. Business knowledge transfer by respective business process owners at customer end to the business analysts could lead to another disaster of ambiguous documentation giving a totally wrong direction to product development. Right and appropriate business knowledge transformation is very important.
Larger chunk of total project time allocated to development thereby left with a shorter time-span for testing is responsible for dissatisfied customers.
To sum up the whole gamut, regression testing being the most difficult and crucial phase of project management should be justifiably have a strong backup of development team, customer management, own management, project manager in terms of providing the testers with accurate documents, product knowledge, sufficient time, and above all a good morale support.
Delivery Process: Delivery rate and delivery volume is directly proportional to productivity of various teams. Delivery of product depends on rate of development and testing, delivery of implementation depends on speed of implementation and so on. A process for delivery will focus on streamlining and enhancing productivity at all stages of the project. A collaborative and synchronized productivity will impact more on project delivery rather than focusing on a particular phase of a project. A delivery process also takes care of course of action in case of intermittent team size variance, multi location complexities, technological issues, defect management, test management, time management etc.
Empowerment: Never build an atmosphere of too many restrictions. Discipline and empowerment if imbibed in each team member, require no restrictions and process delaying approvals. Be more delivery oriented rather than restricting your team members to report in time. Flexibility in time can boost teams to deliver speedily.
Governance: Governance and Empowerment can go hand in hand. Governance of process, procedure, methodology, metrics etc. gives you better control over the project.
Optimization: Never compromise in terms of architecture, methods, tools, development platform, project organization, team structure, team sizing, infrastructure and relevant constraints to product a sub-standard product. It is better not to put half hearted efforts than producing a half cooked product.
Traceability: If process, methods, tools, teams and metrics are in place, traceability is important to understand the optimization level of each of them. No traceability means no tracking of output, result, progress etc.
Modernization: Building a product on old version of software or using non-current infrastructure could lead to a no-support scenario in a short run. Technology is changing very fast. Build your product using latest technology, get your teams skilled on them fast, and build product taking care of technology in news and about to come in near future.
Lack of communication, during any Project, forces team members to assume. This happens due to lack of clarification and shortage of time. The product built on assumptions stands nowhere for a useful purpose. Assumptions in turn create confusions and confusions lead to disaster.
A small assumption made at any step of the project may cause a severe negative impact on Project, Product and Managements involved. Data when validated becomes information which forms a basis for building a code. An assumption made in group or by an individual in isolation is bound to result in ambiguities. If for some purpose some assumptions have been made, then it needs to be validated with the help of a complete description and may be if possible, with an example. Example cited with a description give more clarity to the person who has to vet the case.
Assumptions result from not at all/ unclear/ vague communication. The sender and recipient of communication, both are at fault, if the communication loop is not closed properly. Any communication should be done with no pre-conceived notions in mind either by sender while sending it or by receiver at the time of receiving it.
Making assumptions is not bad. We do make assumptions many times a day. But those assumptions do not affect us badly. For example on a crowded station, I may make an assumption while coming back from office that first train might be missed due to heavy crowd. It does not affect me heavily even if I am able to catch first train amidst heavy rush. The stakeholders involved in this case are very limited – me and my family. But when it is a question of a business proposal involving many teams, stakeholders, project, product etc., we cannot work on assumptions. A realistic approach which is more objective and measurable is necessary in such scenario.
Assumptions made during project may cause misunderstandings, conflicts and confusions. Even sometimes an improper/ incomplete communication is the cause for this.
A structured communication process needs to be in place in any project management.
As discussed in previous post Identifying Hiccups During Project Lifecycle the identification of the showstoppers or hiccups in a project is very crucial. An appropriate action on a problem can be taken only if the problem is identified correctly. Otherwise the wrong identification may lead to a wrong analysis and solution thereby changing the direction of the project in an uncontrolled direction.
Some of the most crucial hiccups in a running project could be summed up as below:
1. Collaboration: The teams and stakeholders need to collaborate and be on a single platform to catch the same train. Else they would be travelling in different directions nullifying each other’s distances covered. The net effect in that case could lead to nil or negative.
2. Communication: Formal communication is an integral component of a successful project. Lot of communication going in an informal or unstructured manner could lead to ambiguities and confusions thereby resulting in chaos.
3. Team Building: Each team comprising of right mix of candidates is mandatory to achieve optimum results. Too many cooks may cause lot of conflicts.
4. Leadership: Right mix of empowerment and leadership is very important to run a project.
5. Service: Project development is a mix of service and product delivery. The service part is generally over-looked as the major focus is kept on product. The interruptions in service could lead to derailing of a smoothly running project.
6. Time-Plan: Adherence to time-plan during each stage of project is very crucial. A prolonged delay in project sometimes leads to complete rejection of the project if a need of technology change arises due to delay.
7. Language: Language barrier is a big risk in most of the overseas project. It has to be handled carefully otherwise there would be a big gap in understanding of the words being told and their perception in understanding.
8. Control: A control of down-time in hardware, code, people could lead to a big disaster. Cost also needs to be controlled.
9. Quality: Focus on quality of not only product but process, people, plan and code also plays a major role in project.
10. Integration: Integration of teams, management, stakeholders, code, modules, and product – everything is important.
A project of any nature or size, demands collaborative and systematic approach, from all teams, stakeholders. The teams engaged in various activities and tasks need to tackle hiccups and abruptions arising out of any internal or external turmoil.
The time-bound projects, if not finished in time, may cause issues raised out of business continuity, stakeholders or team member’s exits, technology in use going outdated, or change in management’s outlook causing decision changes.
The emphasis on cost reduction, restricted team size, productivity increase, control on expenses, process enhancement, collaboration optimization, quality improvements etc. are the factors that create pressure on the teams working on the project and in turn may affect the progress of the project. These factors need to be managed tactfully and smartly. If not, then a single pressure may cause aggravated impact on the speed of the project. A systematic approach becomes paramount in such cases to cross the fire safely.
If systems and processes are not in place to manage each and every phase of a project, it leads to panic across the teams. The smooth sailing gets disturbed thereby causing turbulence and unnecessary hindrance. It may call for a re-organization of the project organization in extreme eventuality even. To avoid such extremities, a better decision making approach, improved information structure and clear cut role definition becomes very crucial.
”We simply assume that the way we see things is the way they really are or the way they should be and our attitudes and behaviours grow out of these assumptions.”. This quote is from the author of the famous book “Seven Habits of Highly Effective People”, Stephen Covey.
In terms of software testing and software product, the quote seems to say a lot. The product requirement is understood by an analyst they way he perceives business. The requirements understood may be way different from the requirements told by the customer. The requirements documented by the analyst may have further a wide gap among the business is shown to him, the way he understands, and the way he documents.
Developers and development manager develop the product the way they understand from the document prepared by the analysts. The testers and test manager test the product the way they have understood the business requirements and their understanding of the product built. The test report or bugs report may have different meanings for testers and developers.
So the journey of a concept from business requirement told by customer to business requirement understood by analyst to business requirement documented to business requirement document understood by development team to product developed to business requirement understood by tester and the testers understanding of the product to bugs found out by testers to bugs reported to bugs understood by developers covers so many grey cells that the whole concept may get changed.
Lot of things are assumed during the process of understanding and building of product. The end result could be a shattering shock for a customer or it could be a state-of-the-art product for him. All depends on the way things are perceived, assumed and understood.
The wider is the gap between perception, assumption and understanding, the higher are the chances of the requirements turning into a nightmare as an end result for all.
A Process is the key parameter or metrics to establish the health and status of a project at any stage. Without established process, a method to measure it or its metrics and a continuous effort to re-establish it in terms of improvisation and enhancement, any drive in project management is useless. There are certain key entities to be kept in mind while reviewing any process.
Any process can be improved upon and brought near to ideally the best process. But as such no process is optimum or best; the best of best is only near to it and always has a scope of improvement.
Some key components that should be kept in mind while re-looking into a process for further improvement could be:
1. Identify Weak Areas in a process, be it comprising of parallel or sequential activities. Improvement on those weak areas would certainly help you in achieving better results than being driven out in its current state.
2. Techniques for performing a process or for that sake review purposes should always be scrutinized critically to get better and better results.
3. Focus upon each and every step of the process, and the forces driving those steps. Sometimes looking at a process step with a wider angle helps in finding out better improvement options.
4. Compare the way you define your processes with the similar processes being driven worldwide. It would help you out to find out proven and established methods adopted. Benchmarking helps in getting near to the optimization of a process.
5. Set your goals for better results from any process. And then start finding out the ways to achieve those results. Without a goal setting you are trying to achieve NOTHING.
6. Having a steering committee comprising of relevant key persons for reviewing the processes and getting it enhanced. Everybody’s baby is nobody’s pain.
7. Hire a consultant once you set out your goals to achieve better results and are not able to find out the ways to achieve it. An external expert’s experience in form of advice becomes quite handy to achieve your goals faster than waiting for something to happen on its own.
User Training, Product Demo, UAT all require visit to customer site and a face to face interaction with the end users and customer management. Worldwide scenario is changing now. Organizations in wake of going green and cutting costs prefer alternate ways to avoid travel expenses especially for overseas projects. The development and implementation teams use various approaches to interact with customer groups taking help of latest technologies that have emerged and stabilized now.
Technology these days is not limited to IT only, it has spread its wings even to the non-IT arena. Customers are also quite tech savvy and aware of various technologies available globally to connect different time-zones and geographies. High speed communication, internet, high bandwidth availability, mobile/ wireless technologies, dashboards, web conferences, commercial usage of skype and Web 2.0 etc. have emerged as winners in attaining these goals.
This has lead to innovative approaches to collaborate different teams working on same projects while sitting across different geographic locations, or creating a knowledge sharing platform for vendor-customer collaboration during various stages of a project.
In today’s world, vendor teams can connect to customer teams for the purpose of product demo, trainings and UAT in a very organized and structured manner to make such sessions a big success thereby lowering the project costs and time wasting or non-productive activities.
This has helped not only in meeting tight schedules but has given birth to smart planning and project management.
Let us, for example, take a scenario of changing existing functionality in software, by changing some part of the code, to enhance its performance and applicability. The enhanced or re-designed code is supposed to give better performance thereby giving higher level of user/customer satisfaction in terms of business and application usage.
The process if not defined will change the code, without any traceability, documentation and revision control. On the other hand if the process is well defined, a team will definitely first of all introspect in the business and code in place to work out WHY this change is required.
The change in code should not happen just for the sake of demand of a user, or customer management. It has to be well researched by the coder team in terms of its impact and workload.
The process for such a scenario would be:
1. Segregate the code that needs changes
2. Define the changes required
3. Segregate the other parts of the software where above changes will impact
4. Sort out the changes required in those areas defined in step 3
5. Change the identified code areas
6. Test the changed code in isolation
7. Re-examine the already existing test cases if they need to be extended, changed or altered
8. Perform re-definition of test cases, write new test cases
8. Perform integration testing
9. And so on…
A well defined process is a key performance tool for any project. Keeping in mind that any defined process required a life-long enhancement and improvisation helps project management team and management to strive for excellence in each stage of the project. If processes are undefined the project has highest level of risk of going for a toss at any stage. If processes are defined but are not adhered to, it is as worse case as the prior stage.
If processes are defined and are adhered to, is an ok state but can not be termed as a healthy state for the product, project or organization. The best scenario is that with each step of the project, the relevant process is re-looked into for an improvement.
Organizations having optimum processes defined do not sit idle on the established and polished processes. They still keep pondering and exploring on any possible improvement, variation or re-writing of process to get better results in next go.
Just like a mirror, if not cleaned regularly will not reflect appropriate image of yours, when you stand in front of you, thereby creating worrisome situations, though you may be looking as smart as yesterday.
Let us consider a simple scenario of writing code for a new application for a customer. The process starts with a clear understanding of customer business, key user’s expectations and customer management’s expectation regarding business benefits driven out of this application.
The most important journey begins with capturing all these details as minutely as possible. I always recommend not to map application with the business but map business with the application to get maximum benefits from the deal and make customer happy and satisfied.
Mostly during the requirements capturing, we start zeroing down the nearest application available with us and start moulding our requirement documents keeping in mind to sell that application to customer. That is the biggest mistake we make when we start looking at customer business framed in our existing application. Worse is when we change the direction of business discussion trying moulding it in our product way.
That itself starts leading to a big disaster. This strategy will definitely leave us with less efforts and more margins without customer knowing that we are delivering his business solution to him with an already product in place with us. But usually it will not be able to win the situation after implementation of product when the users and management starts reflecting their frustration. Even if you are paid for such project, it is not going to get you further business or reputation in the market.
On the other hand when you are capturing customer business requirements, never let any of your existing product come into your mind. Record all business requirements as if writing on a blank slate. Afterwards maybe you can find out the gap in an existing product and business requirements and thereby arriving at a conclusion of moulding this existing product with least twists or deliver him a new built product.
At the end of the day the customer should not only pay you but greet you with a smile on his face even after one year of delivery of the product.
1. Showstopper: Product manager always has the perception that the development team wants the progress of work whereas QC or testing team jams the progress. They even try to project in the way of showing development team sitting idle when the product is lying with testing team for finding out bugs in the product. It is reflected as if QC is not an enhancer but showstoppers.
2. Fault Finder: One of the reasons of not giving the product to QC for testing and emphasizing on an in-department testing is that QC or testing team is blamed for unnecessarily finding faults in the product just for the sake of highlighting the lacking in the product whereas it is claimed that the product is built perfectly and working fine.
3. Business Knowledge: One reason of bypassing QC team in Product development lifecycle is putting wrong perception in management’s mind that the testers lack business knowledge. For that sake even sometimes wrong, incomplete or ambiguous business process documents are produced to testing team so that they are not able to understand business properly and the test report lack the crucial business process bug reporting.
4. Process: Excellent process even in place are not adhered to sometimes in wake of fake reasons of lack of time, customer pressure, more time required for development and so on thereby giving short time to test teams for testing the product.
5. Management: Management if do not balance development and quality team equally then the product or the organizations do fall in trouble at a later stage.
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.