I was just browsing through some quality related videos on Youtube and found this lovely piece of video having a length of approximately over 10 minutes but is quite interesting to watch patiently and think about how we keep working in our day to day life tasks wasting so much of time. It demonstrates a simple task being done by 6 persons as a team in two different ways and that is what makes a difference in the way we think and perform a task assigned to us.
TQM means Total Quality Management and is having no limitations for optimization of performing any tasks in work area (or personal life) in an optimized and best possible manner. This video was made for TQM training to be imparted to final year students of Edinburgh University. Its purpose was to ensure that the goal of training to students about teamwork, optimized manner of performing tasks, exploring different ways of working on the same problem, redefining process, reducing defects and striving for never ending improvement. This video was directed by Eric and produced by Stuart.
It forces you to introspect on optimizing any process by reviewing the current cycle time and process. Synchronization of Production, Cycle Time, Team Size, Process and Desired Results is very important for optimization of any process to increase results.
The same concept can also be applied in Software development lifecycle where different teams of varying size work on a product that is under development.
Logically it is not Quick Test Professional (QTP) versus Open Source Testing Tools but I would rather say it is a comparison between paid/ costly tools vis a vis open source tools which are supposed to be presumably free of cost tools. There can be a number of differences between the two categories that can be listed down based on technical capabilities of these tools, commercial aspects and overall procurement and support function.
Following differences can be listed:
1. Paid tools are Paid but Free tools are Not Free: Paid tools have a value tag attached to them like QTP has a value imbibed with it and depending on your needs of test automation, the final cost is evaluated by the vendor.
2. You have a visible person in picture working with a particular company authorized to sell that specific paid tool.
3. If you plan to go for a free tool, think twice before you ascertain that if you are quite capable of managing the show on your own – go ahead. But if you need an assistance, you will be wasting a big amount of time in searching for a suitable capable party who can download the tool on your behalf, customize it for you and make it run for you with all kind of support required.
4. Support in real time for paid tools: You have a vendor to whom you have paid for tool, got it deployed at your location and may be bundled training on that tool also in the deal. You will have a well defined support level bundled in the deal to make it a safe deal.
Test Automation has become predominantly and unquestionably a ‘must’do’ entity in project management, especially of larger size and involving higher stakes. Scenarios are changing at a faster pace from legacy, orthodox, out of date waterfall model of testing to ‘quick to attain perfection’ in smaller pieces based agile methodology. Everyone around the globe, engaged in software development, must be aware of some kind or the other testing automation tool.
Even the organizations those are still not using test automation tools, do not indicate that their testing teams do not require any tool, or the test guys are not aware about the existence of automation tools. It merely might be happening in two cases – one, where the test team understands the need but has not been able to make management understand the need and importance of the same; two, management also understands the need and importance but is not able to justify the investment if currently the customer base is low; or product volume turnaround is lesser.
Note that test automation tools will never be able to replace manual testing completely. There is nothing called 100% testing automation. There needs to be manual testing component in all kind of testing, which has its own importance and need for existence. Only thing is that now the test automation and manual testing has to exist in right proportion so as to do full justification with the product testing and thereby producing an ultimate bug free product at the end of the day.
A manual tester might not be the perfect guy to perform automated testing and vice versa.
There is a lot of information that floats and flows between top management and customer management. Even though some of this information might not be directly linked to the project but might impact seriously on the growth and progress of the project thereby marring the tempo and momentum despite all good efforts being put by various project teams engaged in the project. These scenarios generally arise all of a sudden, out of blue, unexpectedly; but there is no point in hiding or overshadowing them.
One classical example of this that has happened in real life is decision of deploying an ERP in the organization, change in top management key members in a short duration, decision of deploying the same ERP put on hold for a couple of months and ultimately reversed. And during all this period when management at both ends were aware about this situation and rising clouds over the fate of ERP, Project teams were not at all informed about the same and hence finally all these efforts went into a dustbin.
Some fool in the top management who knew all these changes happening in the management of customer side, still was hopeful that this project will not get shaken at all inspite of getting such indications from customer end. The project teams especially the development team sensed decline in relevant information flow from customer’s key users who were aware of the final fate of project by that time.
Had top management took a wise decision of putting the same project on hold till things getting clearer from customer end, and deploying teams elsewhere on other project; it would have been better in terms of financial results and performance.
Project manager has to be a versatile and universal kind of entity in an organization rather than limiting him/herself to a particular department or specific focus area. Project Manager has to be visibly an overall scale predicting the progress and health of the project. He has to be informative about all round progress of project even from the corners where relevant activity has ended or is yet to start. It is not that start happens only when it visibly or apparently appears to start, it starts much before that.
Taking all this into consideration, a Project Manager has to act as a radar or high frequency antenna so as to keep capturing relevant information related to project automatically or to a large extent without much of an effort. This can happen only if Project Manager takes care of his/ her important and regularly to be monitored/ reviewed touch points from where all important pieces of information will come through. By joining thread of these various pieces of information, project manager can attain very useful analysis about the progress and health of project.
Thee Critical Touch Points for Project Manager are:
1. Customer: This will be the source of first level of information that will be raw, useful and foundation of product in asking.
2. Management: It is important to understand management goals and vision prior to setting your own goals for any project.
3. Quality: This is the area which needs to be focused upon carefully. The guys should be set free to raise any kind of query related to customer and product that may turn out to be a bigger introspective point for management to look into.
If, for any kind of project, focus on three important areas when put right since the beginning of project; might help in attaining desired results and outcomes in appropriate, timely and within budget targets. The logistics are not mentioned here in terms of their importance as I feel all of them are equally important in order to drive a project successfully. Irrespective of the hierarchy they have been mentioned below, understanding and adherence is more relevant.
Three logistic points of any project management can be listed as:
1. Information flow from Customer: It is very important to keep a continuous information flow from customer end regarding their business requirements, changes required, enhancement perceived, and expectations from the new project in terms of deliverable, value addition in business and processes etc.
2. Customer Requirement flow to all concerned in Project: It is not only development team that is demanding customer requirements to be built in within the product. It is quality, implementation and any other stakeholders for whom this information is a good source of introspection and product logic discussions.
3. Internal flow of documents and information: Code is not a secret entity within any organization engaged in development of a product for a customer. It needs to be shared among various other teams (other than development team) so as to get them the flavor of product in the building process and hence prepare their relevant tasks accordingly. It might become a handy and useful tool for teams like QC, QA, Implementation, Deployment etc. so as to prepare accordingly.
Measure what is measurable and make measurable what is not. ~ Galileo Galilei
A code is always testable. large of small, but each piece of code that is catering to a specific need of the business must be tested thoroughly. A small piece unattended may spoil the whole product.
If we always do what we’ve always done, we will get what we’ve always got. ~ Adam Urbanski
If we keep doing the same thing the same way, we keep getting what we have already got, nothing more nothing less. That is why Change is must, in process, in product, in testing, in development – in everything. Change can get you ‘better than previous’.
“The starting point for improvement is to recognize the need.” – Masaaki Imai
Unless and until you know what is to be changed, you will never be able to get the optimized product. It is something like if you are not able to find a bug in a product, you will never be able to find out the actual defect and hence the improvement that is required in the product.
Like tools, mind also gets rusted if not used regularly.
Failure is only the opportunity to begin again more intelligently. ~Henry Ford
Everything can be improved. ~C. W. Barron
Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for. ~Peter F. Drucker
Professionalism means consistency of quality. ~Frank Tyger
It is quality rather than quantity that matters. ~Lucius Annaeus Seneca
Heineken is one of the prime brands in liquor industry and one of the top beers sold across all continents on the globe. The whole credit of success of this Dutch beer brand becoming most popular across the globe goes to its founder Freddy Heineken. Freddy used to be too conscious about the quality of the product rather than focusing on producing in large volumes. He never let his success spoil his quality conscious mind and was always used to get disturbed even for a single quality issue arising anywhere in the globe related to his product. He used to take any bad bottle of Heineken as a personal insult to him. And that is what makes him a great successful businessman.
Philip Crosby gave a different perspective on Quality. He wrote – “Quality is free, but only to those who are willing to pay heavily for it”. Quality is not given and deemed by everyone. Quality has more relationship with conscious rather than anything else.
Mahatma Gandhi always emphasized on the quality of work rather than quantity of work. He wrote once that it is the quality of work that will be easily able to please God rather than the quantity of work. A Programmer if takes a learning from here can go a long way in building bug-free code during his career. Usually programmers are more focused on quantity of work, to demonstrate their capabilities to their seniors. They have a mental blockage in doing work faster and finishing it in of before time and in turn might compromise with the quality of work they produce.
John Ruskin in one of his writings indicated that there is always a scope of compromising with the quality of a product. A product can be picked, compromised with its quality and then can be sold in the market at a cheaper rate. What it really meant was that a compromise in quality, or by making a product little worse, its value can be degraded or lowered and then it can be sold at a lower price in the market. But in software industry, all those companies those tried to follow it, failed and vanished over a period of time.
“Quality is not an act. It is a habit. – Aristotle 384BC-322BC, Greek philosopher and scientist, student of Plato and teacher of Alexander the Great”. This great philosopher, scientist, learner, student, and teacher from Greece knew decades back the secret of quality what even the current era quality gurus are not aware of. Ignorance is a bliss – it is said, but is applicable for fools only.
Quality requires additional sense. Quality comes from heart. Quality has to be in blood, has to be habit rather than acquiring it off and on. A person who becomes a quality analyst, quality control, or quality assurance department has to quality conscious not only in particular projects or products but in all aspects of his/her life.
How many of you guys belong to quality related job and wear quality specialist jacket only at work place?
: It it not good to fail in all your projects and in achieving your goals. But it is inevitable to avoid failures or delays at times. This can happen in any kind of project and at any stage of the project. One bad habit that is counted as good is the ‘Passion of Winning”. Everyone has an urge to win in life. But few are there who are passionate about winning always. There is a good quote I found somewhere whose author is not known. It goes like this: “Good decisions come from wisdom. Wisdom comes from experience. Experience comes from bad decisions. ~ Anonymous”.
This is an excellent quote that fits into all times and eras. We do take decisions in our day to day life, whether in projects or in personal life. All decisions do not go in favor. Sometimes some decisions do large amount of harms that result into project disruption, delays. Wiser men do not let go this opportunity waste. They do learn from the bad decisions taken and their impact on project. This experience if carried forward in further projects and decisions come too handy in going right next time. Such experiences make you wiser one step further every time.
Sounding good or bad, but in my opinion, a software project resembles making love or having sex. There are many similarities that can prove this verbatim. Let us look at the resemblances:
1. Mental preparation: You have to be mentally prepared to achieve your goals and set your milestones. Clear vision and urge to achieve mission is the ultimate goal in your mind in both the cases.
2. Physical Vigor: Without having strength to achieve what you want to achieve, target setting has no meaning. If you assign a bigger task for yourself, you need to be physically prepared for it.
3. Passion: Having both above, and not being passionate about your goals, it is going to hit you badly from both perspectives – yours and the other party.
4. Achievement: Achieving stipulated goals in estimated time is very important. You can’t relax in between even if you want you. Delayed response may end up in no enjoyment during the journey.
5. Respect: Give respect to feeling and requirements of both the parties involved. You just can’t keep on singing a song that is boring to the ears of other party.
Hey guys, this is not a technical video attached here in this post. This is a waterfall in a place called Panchkula near Jammu in India. This waterfall video I have watched n number of times and every nth time I watch it, it strikes me of the situation of quality of software that is still in a sorry state in many of the software organizations. Many software development companies are still scaling quality at a lower mark and find their entry in the picture only at the time of completion of development of product.
Waterfall sometimes reminds me of a well organized development team engaged in a project in which they are supposed to develop a business suited product that is meant to cater to the complete business cycle. The business analyst prepared a well structured thick document signed by all stakeholders to vet that yes, this is what is required to be built in the product. Development team is handed over the document with expert comments of project manager and a timeline stating when the product is supposed to get ready and when it is to be handed over to the testing team. Well so far so good, the document has not gone to testing department. They are not aware about the business requirements of the customer and neither are they aware about the beginning of the development of the product.
One fine morning, Project manager reviewed the product and found it okay to be handed over to testing team for finding out the shortfalls.
Is this the biggest shortfall in itself?
This new book on QTP for Web Testing is a simple, crisp and a must read for all beginners, novice and experts in the field of software testing. I thought of producing and making all testing guys aware about what all experts are saying about this book – “Technology Specific Guide for QTP” written by Aditya Kalra and co-authored by Timothy Rajan Alex.
This is Joe Colantonio – an expert in test automation tools and is helping all testing guys across the globe through his website by providing latest tools, tips and expert advice in this field. And if an expert is praising about this book, it means a lot. According to Joe, the book is a bouquet full of roses for all QTP learners at any level of their expertise or career. As per him the book, if read thoroughly, is bound to make an individual expert in the field of QTP for test automation. Joe, though using QTP since its launch, has had lot to praise for the book, in terms of learning something new from every chapter of the book.
Sivasankar Jayagopal is one of the Senior QA Managers in Adobe Systems and is happy to see the content written in a very organized manner to cover almost everything that QTP potentially is capable of.
Shalaka Dani, Program Director of MindTree shares his idea about this book by confirming that the content has been chosen quite seriously, full of examples and in a very easy to understand manner.
Technical review of this book has been done by Sandeep Laik – published in the beginning of this book. Sandeep is an end to end test engineer for Unilever Project working with MindTree.
Hey Guys, another attempt to present my one of the earliest blogs in a video. If is not very much different in terms of context of the article but listening to a song and reading its lyrics, makes a big difference. I am not sure whether this attempt is good or not, probably you guys would be the right judge to pass on your opinion openly without any hesitation.
Here is the video:
Hi Guys, This is basically the video version of my long back posted article here on IT Knowledge Exchange website. Probably that is one of my earliest blogs and it got quite popular among readers belonging to Project Management, Software Projects, Quality Assurance, Quality Control fields.
Here goes the video that is published on YouTube:
The book is precisely of 200 pages, if you include the last 2 pages meant to jot down notes. It is a well written, well titled, and crisply sequenced book written by Aditya Kalra and Timothy Rajan Alex. Aditya or more popularly known as Ady among his friends, is carrying a little less than 4 years of rich experience in software testing in companies like MindTree, Fidelity and JP Morgan. Currently he is Test Automation Architect in J P Morgan, Bengaluru.
Ady started his career as Test Automation Engineer and very soon climbed the ladder to reach to a height with a new title – Test Automation Architect.
Timothy, co-author of this book, is has a great journey so far in test automation in companies like – Keane, Sapient and Adobe. Currently, he is Automation Tech Lead in Adobe Systems, Bengaluru. Having an excellent experience of over 6.5 years, Timothy is a thorough professional naturally equipped with software testing skills. Starting his career with manual testing, he has excelled in both flavors of testing – manual and automation. By now he has got an expertise in developing any number of variants of automation frameworks – be it open source, or commercial one.
Timothy is as passionate about testing as he is strong in technical skills in software testing. He has mastered and specialized in Web and Windows based applications – JAVA, .NET, SAP, VB – using different tools at different times – HP’s Quick Test Pro Automation tool, Selenium 2.0 (Webdriver), TestNG framework and so on.
1. Change in priorities are always a big hurdle in a project
2. Change is not always good
3. Change does not always brings in good
4. Change is good to avoid at times
5. Change in priorities will boost one project but at the cost of many other ongoing ones
Any project if goes well and ends well keeps drawing stakeholder’s attention during its lifecycle. This attention drawing goes all in positive manner, cheering teams, glorifying moments of milestones’ achievements, project completion etc. It might go other way round also in a way that it does draw everyone’s attention but this time, in a negative manner. Milestones not achieved in time, repeated number of times, teams getting demotivated and demoralized, management losing hopes over completion of project, most of talented people looking out extensively for another job.
If it is later, the situation is not too good for any of the stakeholders. If some of the stakeholders are not getting affected due to these adverse conditions, probably they are holding fake keys in their hands. It is well evident that it is team that makes any project success or failure. A single person may put extra energy or efforts in a project to drive it faster, but a project cannot fail on the whole merely with the wrong intentions of a single person of the team.
There is a big difference between mistaken happened due to ignorance and intentional mistake. A sensible person if makes a mistake ignorantly will learn a big lesson from it and shall never dare to repeat it. Repeated ignorance can be treated as bad or harmful as a big mistake done intentionally to harm project progress in a big manner.
Change in requirements does happen frequently or infrequently depending on the acceptability level of development team. It also depends on how tightly activities are planned and milestones are being monitored. At times there are certain changes that come right in the middle of a project but shake the progress in a big way. It might happen that the changes are inevitable and may nullify all efforts done so far at both ends.
In such a case there will be a fresh start with a valid reason and justification. Such changes are driven by big and usually external forces. Some of such factors are listed below:
1. Economic downturn: A big deal got undone due to certain reasons thereby shaking the anticipated inflow of funds over a period of time in a negative manner will definitely force management to think twice why they should not stop investing big amount in an ongoing project. Why not shrink requirements to save the larger chunk of investments in the project at a later stage when inflow gets stabilized.
2. Political imbalance: It is not about national or international politics. It is about politics that rests within an organization. An imbalance occurring due to any reason may impact the requirements defined for a project to a large extent.
3. Change in top management: This change at the bottom layer of sea and top layer of management usually brings a hidden storm within itself. The changed brain starts impacting existing brain by infusing ideas to mold them in a different direction. An ongoing project could be a classical example of this.
Change in requirements is not an unknown phenomenon in any kind of project. In software development it is rather happens more frequently. The adaptability of asking for such changes from customer end and accepting such changes at vendor end is quite higher and syncs well to such an extent that when a project has overshot budget or planned timeframe – neither of the two get to realize until it becomes too late for both of them.
There could be many positive and negative factors that control demand for changes during an under development project. Some of the top negative factors can be listed below and if these are controlled well during any project; probably success rate of projects will go higher by 50% from current level of failures:
1. Lack of involvement: Requirements have been given at the beginning of project and a sign off of requirements has happened; hence nobody from customer end is required to vet those requirements getting translated into code.
2. Lack of seriousness: At times project gets imposed on customer end users without them taken into confidence and therefore they might not get involved in the project with all kind of seriousness.
3. Lack of Interest: A key user sitting at a high level might have been ignored in past by management and hence just to take revenge; the key user may keep low interest in the project but keeping full care that it does not smell out in the air.
4. Shortage of time: Key users are given this important task of defining and managing business requirements in the project but along with are engaged in many other equally critical activities thereby leaving them with no time to be sincere with the project.
5. Change in strategies: Management at customer end may have change in strategies at their end thereby pushing the ongoing top priority project to a lower one and hence change the prepositions for all involved in the project.
Developers are probably most creative group of people who keep themselves engaged in creating code all the time. Since perfection and human beings are some steps apart in whatsoever is done by human beings, there always is an urge found to strive for perfection. This is what makes them good developers. There are certain pre-requisites to attain that stage, lack of which may behold them to reach to that stage.
Top most reasons that hold good developers to build a bug free code can be listed as below:
1. Tight schedules: Tight schedules as such are not an issue for any good developer. But when it gets clubbed with certain more pulling impacts; the developer gets drifted away from developing extremely good quality of code.
2. Disturbing/ Tense atmosphere: This is what impacts a developer, or for that sake, any creative guy most. The developers need a non disturbing and cool kind of atmosphere around them so that they keep juggling new ideas in their mind and putting them in the code they are building.
3. Frequent interruptions/ Change in priorities: This is something that will disable any person for reaching to his goals. You start for something, change your mind for something else, or are forced to change your current work in hand with some other work; you are never going to attain your goals in life.
4. Lack of Documentation: This is something quite basic in nature but is not being followed for ages. Nobody understands the gravity of documentation and hence least attention is paid to this most important exercise.
5. Change in Requirements: Change in requirements is as disturbing in nature as change in priorities. It is usually done from stakeholder’s end and usually happens due to many reasons like – lack of involvement, lack of seriousness, shortage of time, change in strategies etc.
Whenever any application is used for the first time by a user, there is always a perceived notion in the mind of user on the behavior and functionality of the application. If the application being used for the first time behaves better than the expectations set in user’s mind, the battle is won; otherwise it is lost. Although it is very difficult to satisfy every end user by a single application, there are certain apps which have higher tendency of likelihood by its end user and hence such apps do well across the globe.
It happens in any kind of application whether it is based on client-server architecture or is a web based application. For web based applications some basic information, if is launched, along with the application; will help changing the preconceived notion of user from a wider spectrum to a specific pattern. Such information can be listed as below:
1. Browser Support: The web application, in whichever browser is opened, must clearly state the specific browser(s) on which it has been specifically built and tested.
2. Resolution: an application may play weird if not opened in proper resolution of the system. Hence it is important that the use knows well in advance about the best resolution for the application.
3. Limitations: Every application has certain limitations that are well known to its creators at the time of its launch. It is better to make user aware about such limitations so that he does not remain in dark.
4. Future Plans: If you let your users know about what enhancements you are planning, it will keep your users hooked to the app.
5. Feedback: A must have feature on every app to gather user’s feedback.
It was an astonishing outcome of project manager’s approach when I recently met with a group of project managers managing building of multiple products for multiple customers through multiple development and deployment teams. I started with a survey and as per my feeling most of them failed in that. The survey was focused on deriving findings on their approach, concern, belongingness, bonding; with end users.
It all started with a call from one remote end user who was facing difficulty in using an already launched web application. The screen was to add a new record and had 13 columns to be filled on screen-1 and 7 columns on screen-2. When it was opened by the end user, she could find only 11 columns and despite scrolling down, she was not able to see the rest of columns.
She approached the product manager and this guy remotely did something that she was now able to see the rest of columns. Wonderful though, but next day the same problem occurred to the same user. She approached the project manager this time. The project manager also did some jugglery and set the things right for her.
She could not understand what was wrong and what is being fixed by these two gentlemen that it all becomes ok. It was not at all a comfortable situation for her to work on that application to add any records further facing so many hiccups.
Can you just find out the missing pieces of this puzzle? Try and get back to me to see how many pieces you could find out.
Business applications are moving from client server architecture to web based. The design and usability have become predominantly necessity as strongly as earlier it used to be for navigation. Screen designs need to be dependent on browsers, resolution and focused audience. Microsoft, howsoever popular or widely used has been, still produces unexpected results for which there are no technical reasons. IE8 differs from IE9 and applications working fine on one, do not work well on other, if are not built with depth and knowledge.
Apps built on one browser do not work on others apparently producing lot of misbehaving results. At times there is an incompatible issue that needs to be addressed has to be brought into compatibility mode. Howsoever advancements technology brings in, the issues keep arising in one shape or the other.
Some important factors that need to be taken care of while building a web based product must have following basic factors:
1. Understand web audience well before starting designing of product.
2. Your users are much smarter now as they are not limited to the office boundaries and using only the product hosted on in-house servers.
3. They have understood the strength of web and must have tasted lot number of web based applications before they will start using it.
4. Current day end users are quite tech savvy and well versed with web apps and their strengths.
5. You can’t give illogical or absurd reasons of certain things not happening in the app which are well done in other products on the web. Tools and platform can’t be held responsible for such actions.
Team composition is one of the most critical tasks in any project. It if not the count of people that matters but it is the experience, level and maturity of team members that is to be focused upon while selection of members. Members with more open mind and fewer egos can do well as team members even if they are slightly short in knowledge than other members who have personality otherwise.
The strategy of team composition is highly dependent on the size and nature of project. A large sized complex project would require a higher level of strategy formation as compared to a small sized and simple natured project. Though it would be a misnomer that complex issues do not arise in simple projects, there also it depends on the right formation of team and deployment of strategies. A very small product development project may encounter bigger hiccups if the team composition is not done wisely.
It is better to delay a project for the sake of finding right kind of people rather than just completing the stipulated head count in the team irrespective of the skills and experience matching criteria assigned for the selection of candidates. Inappropriate composition of team members will always delay a project and on the other hand in a delayed project if right kind of people are included in the team, they would be able to cover up the time and milestones achievement backlog.
4. Milestones identification and achievement: Any project definitely needs perfect identification of milestones. Milestones have to be achievable, remarkable and not too distant from each other. Unless you identify quick milestones to project to management that things are moving in right direction, quite visibly; management will lose interest in project and that may start impacting the project and teams involved.
5. Reporting: If you are doing good in a project, you should be smart enough to project it well, timely and accurately, to all stakeholders. The achievements are to be acquired and shared well in time if you want to enjoy them the most, else they may lose their gravity and impact.
So in a nutshell if we see, it is a right nix of all above points that is required to win over all hurdles in a project. Correct requirement gathering not only depends on right process owners to define the business requirements but also require wise guys who understand business criticalities and can read the mind of requirement spellers.
Team that goes for requirement gathering needs to perform some homework in advance before landing into the customer’s location. There are lot of information that can be collected and understood before meeting the customer.
Though it is difficult the assume in advance what kind of problems will percolate during a particular project but more or less all kind of problems faced during a project execution/ deployment/ management can be segregated in five top most reasons or categories. These generic segments/ reasons/ categories will be able to address all issues that are encountered during a project and if these categories are taken care of well in advance in a proactive manner, the chances of failure/ delays in any project get minimized and hence increasing the chances of success.
5 Top reasons can be summarized as below:
1. Customer Requirements: Capturing right requirement first time is an art and a science too. Business Analysts and organizations need to master in this so as to move ahead with crisp directions for development team.
2. Team Sizing: Estimation of right kind of people in team, with right kind of experience and appropriate count of them helps in creating an optimum team size. It could be difficult to do the right sizing well in advance but if customer requirements are documented well, identification of right roles and experience becomes much easier.
3. Team Management: Team management is an uphill task during any project. It is not only the technical aspects than need to be overseen but also the soft side of the personality of each of he individual in the team that need to be addressed to.
Wrong requirement gathering can happen in two ways – 1. The team assigned to collect that information from direct process owners at customer end are incapable to differentiate between picking up right thread and dropping wrong threads so that no confusions arise later. But this is the most critical job and done by least business analysts. And 2. The process owners at customer end are incapable to spell out the right kind of business requirements that need to be built in the new application in question.
This does not mean that the designated process owners are dumb in their roles or knowledge. It is the question of spelling out the right requirement where they might not be expert. Management’s and BA’s role (and experience) comes quite handy in such instances.
Customer needs a tree that needs to have green leaves and bears fruits every season and you documented to build a lemon tree that becomes a cause of failure at the end. Did you ask customer what season should the tree bear the fruit, what should the maximum height and width of tree, what size of fruit will be most suitable for customer, hard or soft fruit required, what are the maximum benefits to be drawn out from the fruit – juice, fibre, extract, sweetness etc.; is very important to capture right in the beginning so as to give maximum clarity to your development team that is well aligned with the customer real requirements.
After all it is the right information that has to flow in building of the application. If it happens RIGHT IN FIRST GO, nothing like it. It becomes win-win for both.
Many of you would not be aware about the abbreviation PBL. Well, it is Project Based Learning. Simple. What do you do with it? Can I see a single document that you made during or after a project that comprised only and only of learning acquired from the project? What? There is no document. Well! Then where is the learning gone? How long will it remain in memory? What will be the final resultant of this learning? Has there been a long term beneficial learning from this project?
Project ending successfully in time or called off after spending some extra months over the stipulated ones; give lot of learning. It all depends on the project team, how much matured it is, so as to get the best pieces of learning getting recorded in their knowledge management and keep referring to it as and when required during the ongoing projects in future.
Project based learning can be termed as learning only if each and every success and failure during the project is minutely observed, documented and analyzed deeply to find out the top 5 reasons that made that success of failure happen.
Delays and achievements of milestones, team member’s strengths and weaknesses, identification of real heroes, achievers, motivators and strategists of the project; all that matters a lot to record.
Someone in the management has to intelligent enough to understand what all is happening during a project that is getting ignored and can become a big knowledge base for future projects.
Any activity that is not done right becomes wrong. Probably it is not the management of project that matters more but it is the learning from previous projects that can help you in running a project well and completing it in time. There are lot of factors that can help in running a project in a well-structured manner and ensuring achievements and success of milestones during each phase of the project.
It is the struggle that project team has to face and win over.
Various wrongs that can ensure project failure are:
Project Estimation: Project estimation, if not done appropriately, can lead to wrong team sizing, wrong direction and wrong milestones selection. A small hole appearing as no warning in the beginning may become cause of the sinking of large ship in deep waters at a later stage.
Project Team: Project team is the real bunch of warriors that make your success happen in the war known as project. A team needs to be rightly selected, so that all members respect each other, stay in sync, keep motivating each other along with being self-motivators and above all need to be success hungry. Any shortcoming in understanding the core requirements of a team can lead to wrong selection of team and hence giving a wrong shape to the project at every step.
Most of the projects get delayed worldwide. There could be various reasons for that. Anything can hamper the progress of a project – be it logistics, demographic, person based or decision based reason. A material getting stuck for delivery could hamper the progress of a project. Any local issue also may arise as a showstopper for a project. Persons involved in a project may become a bottleneck. A major decision could even mar the progress.
Why it happens becomes historical and a reason of analysis to work on at a later stage. As a project manager one needs to be proactive to anticipate a problem in advance and find out the reason to mitigate the risk arising out of it. First goal of a project manager should be to ensure that no risks evolve during a project. Though it is impossible to run a project and complete it without encountering any unanticipated risk but then the second goal of a project manager should be to be prepared for any unalarmed risk and promptly finding out a solution for it so that the risks get minimized and progress gets saved from getting derailed.
Third goal of the project manager should be to mentally prepare himself for any kind and any level of problem arising during the project. He should have means and measures to encounter such unwanted weeds growing vigorously in between the useful crop. For each vertical of a project, project manager should work out alternative routes well in advance so as to take a planned diversion in case of a crisis.
ETL stands for Extract Transform and Load. ETL can be treated as wider and broader horizon of normal testing that is done for business applications. Technically the process remains same as is there in any other kind of testing. First and foremost step is to understanding of requirements and business.
Once the requirements are well understood and business concepts are clear, it needs to be mapped various aspects like what is there at presents, what is required, in what timeframe and with what kind of resources. In fact once the requirements are clear as well the business goals are understood, one needs to validate and get them vetted by the respective process/business owners. After this estimation needs to be worked out on the basis of timelines being proposed to be consumed.
Once this gets approved, test planning is prepared. Basis of test planning is always the test estimates, business requirements and scope of work. Test cases are built along with the test scenarios based on the requirements and understanding. After the test cases are ready and get approved by test lead, test bed is prepared, pre testing assessments are done, approvals are taken and tests are executed to find out the results.
CPA (Critical Path Analysis) and PERT are well proven age old tools to use for scheduling and management of large and complex kind of projects. They came into existence in mid of 1950 when in US huge projects were looking for ways to control them in a systematic and objective manner rather than their get going in subjective manner without any monitoring or control over them. There are many other planning and analysis tools that can help you in driving your project in right direction with right pace.
Tools are nothing but means to equip you to measure your project at any instance; and take corrective measures in case if required so. Tools help you to assess project in an objective manner proactively rather than taking it for granted going in right direction without any real measurement of it.
It is not necessary to invest big amounts for such tools. Simple but effective templates built in-house can be used for the same purpose of analyzing the progress of a project.
Failures do happen in projects. There are definitely sizing and severity of failure in a project. The size and severity of a failure is measured by the impact a failure poses on business in various terms – reputation, financial and future loss in growth impacted by such factors. Some organizations are wise enough to understand the gravity of failure and start working in direction of mitigation of risks that arise out of it.
In fact chances of failures go higher in a project if there is a major component missing during the management of project and that component must be taken care of well in the beginning of a project as a whole; and at the beginning of each phase of the project. This component is nothing but is termed as Risk Management. Risk management in simple terms is how you manager risks. To manager risks it must be clear to you what can pose as a risk in a project and how much impact can it have on the project if it occurs. Measurement of impact needs to be objective.
More realistic assessment of risk, planning preparation to mitigate the risk and actions taken for the mitigation – all deliver to higher chances of progress of a project and its success.
Project comprises of many components. There are people to manage project, there are others who drive the project. Managing and driving a project is not similar though there might be some overlapping forming a common area between the two. Managing could be more of controlling and monitoring whereas driving could be more of actions so as to make management easier.
It is quite possible that ultimate goal could be same – to complete the project in time; but there will be two differential activities happening in the project. One would be more based on strategy forming and planning; second would be acting/ working on those strategies and giving them a real shape.
Planning and implementation go hand in hand – head to head – in a dynamic mode. The moment one becomes static and other remains dynamic; there will be a deadlock. By nature – both are supposed to be dynamic – as there is nothing like planning and then implementing. If it could be that simple, management part could have been required only in the beginning of a project. But in reality it does not happen. Planning keeps changing based on the project taking shape during its implementation. The pace of dynamism in both is actually required to be progressing in sync.
Irrespective of whether it is offshore project or the whole team is sitting within the same building; communication does play a major role in project management. No project covers its trajectory painlessly. It is the communication that keeps all teams attuned and intact in terms of staying together in a project. It is only communication that can revive back a derailed project; if done timely and appropriately. Else a project going in going in high speed in right direction may lose its track and start moving in a wrong direction.
It is not only important to receive proper information. The story does not end here. It is more important to understand the right kind of gravity of information in right time and on top of that – taking action on the same. Closing of loop happens only once you have received an information and understood its impact on ongoing project; and act accordingly in right direction.
How do you treat and build up communication as – as Thread or as Threat?
Do you take Problem as Opportunity?
Project Management Started around 6 decades back when it was felt by top engineers, builders, designers and architects; the need of a systematic and structured approach to manager complex projects so as to stay focused and informed throughout the project about its progress and achievement of landmarks or milestones. The management tools designed during that period spread all across various streams like civil projects, defense projects, engineering and of similar kind.
It was Henry Gantt during 1950s who is known to create some systematic approach to project management by means of concrete planning, monitoring, controlling and measuring techniques. And hence he is also known as the Father of Project Planning. Gantt charts are as famous, popular and effective today as they were in the beginning. Even today Gantt Chart is established as one of the most effective project controlling tool. Henry Gantt was highly influenced by his mentor and teacher Fredrick Winslow Taylor. Taylor is known to be the original creator of theories for the management of projects in a scientific manner.
It was firstly in Taylor’s papers that something known as WBS or work breakdown structure emerged as a good source of cutting down your huge and complex project into simple and small tasks and hence achieving success in each task one after the other. Gradually a group of tasks’ completion earmarks an achievement of a milestone. Completion of certain set of milestones completes a project phase. And ultimately completion of certain phases overall finishes the project.
Once you have created WBS for your project, then comes another effective tool produced by Taylor, known as Resource Allocation.
What is takes in a project is to plan, organize, and manage – time and resources so as to optimize commercial part of the project. And managing it in some way or the other is known as Project Management. The way could be any legacy, orthodox, manual process to a modern, fully automated, state of the art, well proven and well established project management tool.
Basically Project Management is nothing but to run the show in most disciplined manner. Resources, Planning, organization and management is all inclined to gain achievement and success in any project being part of. What you know in a project is scope of work, start time, target time, and usually based on this you have to work out the size of your various teams, financial goals, project plan and its smooth implementation. It is not difficult to achieve results, provided you are well aware of the goals and objectives. There is no project where constraints do not arise during its lifecycle – related to finance, time, objectives, team or customer.
Management of project is a mix of two ingredients – managerial skills and technical capabilities. A right amount of balance is a must in project management. Although these are two entirely different streams of management but somehow at times have a singular goal of achievement in target.
There are many tools available in the global, local and glocal markets that boast about helping you in management of your projects. Some of them might be really good. But the point of fact is that not all good things in life fit in well to everyone. Depending on the culture in your organization, kind of people you have employed who are directly responsible for projects, and above all your intentions of staying wherever you are in competition and revenues aspects or climb up the ladder fast to reach to one of the top few positions and then sustain to stay there for long.
PRINCE2 is one of the legendary tool to manage projects in a well structured manner so as to optimize the project progress throughout it various phases and increase the chances of its success. It was launched in market in the year 1996. It was in line with and an advanced version of an older tool that was known as PROMPT. Gradually it emerged as a strong tool in terms of a strong and well defined project management framework and helps organizations in adopting world class methodologies to manage the project.
Basically PRINCE2 teaches you to synchronize the two major aspects of any project – people and tasks. It provides you with a wire frame to structure your project in a well defined manner thereby aligning all micro level tasks that are part of the project with the various members of the team who are managing the project. PRINCE2 provides you with a wider spectrum to help you in deciding on the design of the project and the manner it must be supervised to ensure its success. There are timely alerts in real time of running of project to get raised in case there is any deviation in the project progress as per its plan. It not only raises an alarm but also finds out best possible ways for you to get back on the track.
As a developer you might be very good in coding having an expertise in writing bug-free code extensively long having thousands of lines and quite rigorous in nature. But what about the non-coding component that is required to be built in and around your coding. Have you ever wondered that not all excellent coders are very successful in life in long run.
Top three tips to become a good coder that can make you an all rounder in all aspects and probably can act as a ladder to climb higher than you normally perceive during your career growth; are:
1. Act as a Catalyst to Business: Your value will increase when you stop talking in coding terms and start talking in business terms.
2. Value your code on the basis of your actual delivery to business: The day you know value of business that your coding can deliver or is delivering or vice versa, you will either start refurbish your coding style (as well as your understanding pattern) or you will start enhancing your coding to deliver more than what you are delivering.
3. Demand business knowledge: When your project manager tries to make you understand the coding he is expecting from you without showing you the wider angle, demand it. Ask what is going to be delivered by writing this code. What value will it add to the business. Your project manager might be travelling on a wrong boat with wrong perception. Brainstorming could help in alignment of technology and business thereby bringing more value to both.
For a tester it is important to be having a different frame of mind in terms of looking at the product from a different angle something uniquely apart from how others look at it. Usually testers have a third eye probably either developed on their own or is god gifted. With this third eye they are able to see the product the way it is to be looked at by the customer or the end user.
A Tester must forget certain things while testing a product if he is determined to produce or find out all of the ‘critical bugs’ hidden in the product so that it goes in a good shape to the customers. Five most important things to remember to forget while testing are:
1. Never underestimate your capabilities and different style of looking at a product
2. Never hide a bug from development team if it appears as a half bug to you. Half bug is something where you are not sure whether it is a bug or not. In any case of ambiguity or doubt in mind, just discuss the scenario with your peers, or superiors to conclude the things.
3. Cover the whole product but passing through each of the chunk. Your test cases have to work both at a broader level and micro level. The product sanity as a whole is as important as the functioning of each of its unit.
4. Deliver in time but without compromising with any of the situation.
5. Re-use test cases from your library where the repository keeps building up as a generic collection.
A project never goes smooth throughout its lifecycle. One or the other hiccups keep raising their heads belonging to various verticals connected to the project. It could be customer raised issue, product related concern or finance related query raised on project, for instance. Things, still, keep moving. Nothing stops. Efforts to overcome these obstacles keep going on. Once or twice in the beginning there is a tendency to give up things all together. Otherwise, based on experience and maturity, this give up tendency is overpowered by never dying attitude.
Attitude of the team matters most in any project. Higher is the amount of risks perceived, higher will be preparation required by the team to mitigate those risks. Mostly similar kind of risks that are part of current project become handy to tackle based on their happening in previous projects and the mitigation process adopted. Though it is not necessary that a mitigation process also remains as it is throughout various projects. A mitigation process also may require increase in maturity level so as to manage the things in a much better way than they were manager previously.
Tester is running n number of test cases to build a confidence over test lead that testing on product is being taken care of in most professional way, with complete coverage of all scenarios. Test lead gets satisfied and after few test runs, the product becomes ready to launch.
Product is working fine and ultimately it is put on production server after all UAT activities are formally closed. Usability is one of the factor that goes with feeling of the user rather than the appearance on screen. It might, though cover appearance, navigation, layout, design, and overall comfort it gives to the user.
Not all users will have same feelings about a product. Depending on how much one is required as an end user to delve in the usage of product, one will start looking at it or rather will start feeling it when it is being used on a regular basis.
Although you are performing your task quite handsomely and have earned a good amount of respect among your peers, team members, management and customers. But one important thing to keep in mind always is that all days are not equal, everyday is not Sunday and above all, you just can’t sit on your laurels. Each day is a new challenge in life. Everyday you have to do something new, a new achievement to establish yourself and maintain your sustainability.
Sustenance is tougher than gaining fame for a particular deed. Memories are short lived as far as achievements are concerned. History is not very important in corporate life. You might have done or achieved far more than others but if that is history, and chances are that if you are running at a slower pace now, many others will overtake you and you might not even get to know about it.
Your team is your most valuable asset in the whole project management cycle. Products come and go, showstoppers chip in and are resolved out, issues are raised and closed, deadlines are given and passed or met, milestones are made to show some tangible achievements during any project.
But how all this keep happening is because of your team. Your achievements, project success, milestones achievements, meeting the deadlines, closure of issues, resolution of showstoppers is all managed by none other than your team members. Imagine a scenario where you are told to manage the show single handed and it is dead sure that everything will become a standstill at that moment only.
When you build your team, it is like building with the best possible people and in best possible manner so that it becomes a win-win preposition for all – including organization, team members, and top management. how about sustenance of the same win-win preposition throughout, forever. Initially when team members are new in the team, they are shown and told about all best things but gradually the thorns start erupting out and the bed of roses starts converting into bed of thorns.
How as a Project Manager do you ensure that this bed of roses remains as it is forever. Think of building the bed with roses after removing their thorns. 🙂
Hi Project Manager,
Last time when we were sitting together and discussing about your projects, you were anxious to work out a service level agreement to be discussed with your Internet Service Provider with whom you had a meeting after some time. You wanted to know what are the key factors that should be placed in a standard agreement with the ISP so as to make it more powerful in terms of ensuring consistent unfailing service from your vendor.
Well that you got materialized and your ISP is providing you excellent services for the last one quarter. I was just wondering how about working out a service level agreement between you and your team. How about understanding what your team would be expecting from your besides whatever facilities and perks they are getting in the organization. There is something more than salary and perks that matters in professional life in terms of giving it to your team. Some approach that keeps your team charged, committed, connected and in sync all the time.
Have you ever thought on such matter ever or is it a plain vanilla routine project management running in the organization?
Hey Project Manager, you could be a very successful professional doing perfectly good in your projects. How about your teammates. Have you ever bothered to notice their qualities and have publicly praised and appreciated about those? You might have, I am sure, and many times. After all you know that it is your team that is delivering at their best thereby making you the most successful project manager among your peers.
Well, that is right. But that does not mean everything you have achieved in your professional life is only because of your teammates and with none of your personal qualities or extra efforts that you keep pouring in your project lifeline. That also sounds good. Now let us go a step further. Are you recognized among your team members as a good project manager or a mentor. As a good project manager you will be able to get the best out of your team members but as a mentor your will enhance their capabilities beyond their expectations.
As a good project manager you will be remembered by your team members as long as they are with you. But if you have been able to mentor them well, they will never be able to forget you wherever they are in their career ladder.
Issues getting raised, understood, tackled, handled and resolved is not anything new during an ongoing project. It keeps happening from time to time during the complete project lifecycle. More so often, if there are no problems in executing a project, it becomes doubtful as if there is definitely something wrong in the game.
Priorities do change during the execution not for the purpose of delay in the final timeline committed to the customer but to cover up the delays happening during the project due to various reasons. Prioritization is not simple. It may spoil the whole gamut if it is not done properly and wisely. Re-prioritization is rather more difficult. There are certain things already in stream in which so many team members are engaged. Changing their track and moving them from any running task to a new task is really challenging for all involved in the process. It might be easy to suggest a change in track but looking at its intricacies and requirements of speedily changeover, it becomes an uphill task for project manager to manage the show.
That is why the most important thing before re-prioritization of tasks is to understand the intricacies each task wise and the probably it is always better to do a risk assessment and analysis for such cases demanding higher priority at the cost of already prioritized and running activities.