This was the first time Chris Cooper from Richmond was attending a hackathon. He was not at all aware that he was going to be the grand prize winner among all participants. After reading an invitation on meetup.com (the online site that is quite prominently active in US for meetings and discussions), he decided to participate in the event to ascertain his programming skills. Initially he had no better motive than attending this interesting event to get some fun out of it and meeting some local people at the venue.
This was 24-hour non-stop event that started on 19th Oct 2012 to end on 20th Oct. that was simultaneously organized at three different locations in Virginia. Cooper finally got the grand prize of USD 1,500 for his excellent piece of coding that he wrote for formulating a tool that helps in developing alerts for profiles of students in schools that have chances of getting in the dropout bucket. This tool in turn will then help the local associated educational administration agencies to find out ways to mitigate this risk for those students and get them out of that bracket of students having higher chances of dropouts.
The event termed as HAC4EDU was sponsored by Apps4VA
The purpose of this event is to provide an opportunity to aspirant developers to develop some innovative kind of programming to use student’s data and help in using that data to produce solutions for some challenging issues that are being faced in education circle.
This is related to Quality which all human beings always strive for. This is not related directly to software. But Quality in any area is inspirational and motivating for achieving higher and higher level of success without any compromise in life. That is what Quality conscious people do in life. They don’t compromise in achieving success. Getting better should always be measured in terms of quality that shall cover all other aspects of delivery – time, money, people, resources and process.
Rourkela Steel Plant (RSP) has one of their mill named as Silicon Steel Mill. A team from this unit of RSP participated in the recently held International Convention on Quality Control Circles (ICQCC) – 2012 that was organized in KL (Kuala Lumpur, Malaysia). Quality circles are formed to find out a scope of betterment in process in production units and then implement it successfully after analyzing it. This quality circle was named as “Aakash” meaning Sky, by the team members.
Prior to achieving this international three star award which is highest in that category, Aakash team had to undergo a very strict scrutiny process at the National Level Quality Circle Conference that was held in Hyderabad and among all teams present from various cities and states, they were adjudged as best for their going ahead for participating in this International Event in Malaysia.
Aakash team has achieved a phenomenal breakthrough in formulating an innovative enhancement in the process in their production line that was facing a long term problem of failure of Looper rope in one of their AP process of SSM. The team has achieved it by means of development of an indigenous logical circuit that would brake Looper drum at appropriate moment so as to avoid such failures. With appropriate enhancements in the process, the Aakash team has been able to reduce their stoppage in production line by more than 28 hours every month gradually saving an amount of Rs 56 lac annually (USD 0.11 million).
This has been achieved not only in terms of an annual saving, but also with an increase in safety and simplification of process.
Project Plan without a regular review is as good as a rail on the track without an engine. Hence though the rail is on the track but is not moving since there is no driving or moving force to it. Similarly howsoever structured or strong project plan is built, if there is no review to monitor the plan and assess if going in right direction and with right pace; it will be of no use. Review enables you to take proactive actions in response to some risks perceived during discussion about project plan tasks and their current status.
Risks don’t come in a planned manner. All of a sudden a risk may arise during a smooth going project. Teams and even the team members belonging to the same team do not sit together in today’s high speed life and professional requirements. Focus of any business is more on outcome and results rather than forcing old time discipline to be adhered to. Team members may work from anywhere working on the same module of a project during its development. A very structured task allocation, planning and its review would be required to manage this kind or for that sake any kind of development environment.
It is important to take help of technology to keep assessment and review abreast of any kind of lacunae. Review of particular tasks in a project plan allocated to a particular team member may not require whole team to assemble together. It may be a one to one kind. The whole purpose is to keep things get going… in right direction… with right pace…
The amount of data lying in the servers resting in data center of any organization might not be equivalently accessed, analysed and used in terms of Business Intelligence. The volume of terabytes of data viz a viz its churning to get some fruitful and crisp information might not be existing in right proportion. Any project where delivery of software is prime concern, it should also take care of the resultant reports for top management for the purpose of analysis of business in real scenario.
A software Project where business requirements and development is prime requirement of the project, must also take care of the concerns of top level management and their expectation from this software application right in the beginning at the time of requirements analysis phase. Content lying in server but of no use to management for analysis purposes is like having a large amount of currency in your pocket but not applicable in the country where you are. If a real justification of a software application and the infrastructure/ hardware cost is to be justified, it can be done only in this manner. Else the huge data lying in the servers lying in low temperature maintained data center will be a shear wastage.
Application development is not an easy task. It takes lot of planning and efforts to convert requirements into a code that is capable of delivering what is being asked for. It is not an easy job. The milestones and target dates committed keep everyone in the development and testing team on their toes till their targets are met. The value of data is meaningless as long as it resides in server and does not fetch any useful information.
iPhone 5 has been in news right since its launch was announced. Lot of news, articles, reviews and comments were there all across the world – some talking about its excellent features, some about the removal of Google Maps from iPhone 5 and insertion of Apple’s own map application pre-installed in the instrument. There were long queues and advance bookings so as to grab the piece during first 2 days of its launch. People from remote locations had camped and spend nights outside the stores to grab the piece on its launch date.
Well this news is not too good for Apple’s iPhone 5. The supply is getting affected due to some consistently serious issues arising during its quality inspection before the lots are sent outside the factory for sales to its various stores.
There is a reported crackdown happened at Foxconn Technology Group. Reportedly there are evidences of scratches and nicks on the pieces and that is what has caused the rejection of these pieces at quality station. With its launch not gone too far, happening last month only; and the demand getting higher and higher everyday, this issues is affecting the supplies of iPhone 5.
Stephen Covey is the man who brought Eisenhower matrix into limelight in front of the whole world. But the actual credit goes to this man – , the ex President of United Stated Dwight D. Eisenhower. Stephen Covey used it extensively in his first book ‘First Thing First’ and that is from where the matrix got quite popular all across the globe.
This matrix reminds me a great book that I read years back – “I am OK, You are OK”. The book said there are four stages of any kind of situation – I am Ok You are Ok, I am Ok You are not Ok, I am not Ok You are Ok and I am not Ok You are not Ok.
The similar kind of concept lies here in Eisenhower Matrix. The four categories are – Urgent and Important, Not Urgent and Important, Urgent and Not Important; and finally Not Urgent and Not Important.
If project tasks are identified based on these four categories and accordingly dealt with, probably the life can become simpler in terms of managing complex projects.
Eisenhower himself is quoted it somewhere that :
“What is important is seldom urgent and what is urgent is seldom important.”
Project Management started like this and kept on running like this for years. It reflects the silos that exist within and across the teams working on a project. The silos at most of the times are not created intentionally, but it becomes prime responsibility of the key members of each team working on the same project to fill in the gap and bring them all together on a single platform. Bringing them all together on a single platform not only nullifies silos and gaps but also gets them all in sync and hence the energies get unidirectional and more presumptive.
Actual requirements of a customer and the way customer explains it, might carry a gap in it. And it is the Business Analyst’s job to bring that gap to the minutest if health of project is required to be intact throughout. Business Analyst has a dual responsibility. One, he has to fill in the gap between what is the business requirement of customer viz a viz how he puts it forward. Secondly, the BA has to ensure that whatever customer is explaining his requirements as, must be understood word by word without leaving a hole in it.
Theoretically it might sound quite simple, but it has taken ages, and a number of process experts across the globe have put all their expertise on it; but still the fight goes on and on and the gap has yet to be closed. Who has the medicine for this chronic disease being faced by all kind of projects all across the globe.
A project manager is always surrounded by project priorities falling in financial, logistic, people related, technical, machine related and many more categories. Each category is important and critical for project performance and enhancement. In each category, priorities will be set in different segments. There would be top most priorities, most critical priorities, less critical priorities, and may be sometimes non critical priorities.
So far so good but so many critical, semi critical, non critical and many more kind of priorities revolving around you will not let you work smoothly and perform consistently. The best way is to find out a method with which you are able to tackle all these problems without any hiccups and in an painless manner. How to do that? The best way is to arrange them in a sequential manner. You know very well – an elephant can never be eaten in one go. So is with priorities. Although those all are priorities but can’t be focused upon or taken into hand at the same time. There has to be some way out.
Once you have prioritized your priorities – take top 3, and forget rest of them for a while. Once you have only 3 priorities in front of you instead of a large pool, you will psychologically feel relieved and will be able to focus on all the three. Take first priority, find out the best possible solution, allocate it to the person whom you know will be able to perform it in your prescribed manner, give him a target date and set him free.
Do the same with rest two. And then go to your larger pool, pick top three…
This is a review of C++ Primer, Fifth Edition, by Stanley B. Lippman, Josee Lajoie and Barbara E. Moo, available from Addison-Wesley Professional. A complimentary e-copy was provided for this review.
It is important to understand what additions have been made to this book (and the language itself) as compared to the earlier variants. Since the inception of C++, a huge number of programmers have learned this language and benefited in one way or another. While earlier variants of C++ focused more on extracting machine efficiency, the latest version is all about making enhancements to programmer efficiency.
Some very important changes were incorporated by the C++ Standards Committee in 2011 and there was a major revision in ISO C++ Standards and Guidelines. Primarily, with these changes, the focus is on making C++ more universal so as to enhance its adaptability, reliability and stability. There is also emphasis on making C++ standard libraries more versatile, powerful and safer so as to increase their usability. An important point of these revisions is to ensure that programmers become more capable in writing abstractions and libraries. The C++ Primer covers all the important factors emphasized in the latest ISO C++ standard.
The new features making C++ 11 what it is are very well explained here, and the book serves as a good guide for any programmer. In particular, it covers features like ‘auto’ for type inference, smart pointers, and move-enabled containers, all of which enable a programmer to write their own customized classes without any hassles in an easier and more organized manner.
Any Project has high or low level of encountering gaps during its entire lifecycle. High or low will depend on how strong shield is built around the project to anticipate those gaps in advance and ensure getting them filled as soon as they occur during any phase of the project. There can be different forms of Project Managers for managing these projects. One kind will just burst out the moment a sudden gap is encountered during a project which was not anticipated in advance and will try creating hue and cry out of it.
This first type of Project Manager will just keep cribbing about the gap encountered thus making it more disastrous and deadly than it could actually be. If the focus is not gone on filling the gap that has just emerged out, probably the risk increases and it could cause more disaster if given more time to survive. On the other hand we have a small breed of some intelligent kind of Project Managers. This breed is not too worried about encountering any uninvited gap as they are well aware that these kind of scenarios do occur in project lifecycle. They, would rather, immediately assess different ways of filling the gap that has occurred suddenly and decide about the best of the solution out of those worked out.
And once the best solution is identified, its implementation/ action gets started immediately so as to fill the gap at the earliest and reduce the risk life. The higher is the
In any project prior to its development, during the initiation phase, risk assessment, analysis and mitigation planning is done. PM office, Project team, external stakeholders including the end customer management team members all become the part of this committee to work out and cover all possible areas from where any kind of risks can arise. Once all risks are listed down, their priority or severity is set based on their chances of occurance, gravity of impact on the project and time it would require for its mitigation.
Mitigation of each risk is a cost. Similarly each risk has an impact on project cost also. Hence there is a cost that is getting impacted by means of project delay etc. and there is a cost to overcome or mitigate this kind of delays. If cost of mitigation of a risk is higher than the cost of impact, nobody would like to invest in its mitigation. It is always true that higher is the impact cost, higher is the severity of the risk. And hence higher are the chances of its importance for mitigation.
After all kind of exercises of risk assessment, mitigation planning and management; there is always a hole from where unwanted rats always slide in, unstintingly. And you have no choice other than fighting against it, finding out quick ways to mitigate it and resolve it so that it has least impact on the progress of the running project.
Following parameters may be kept in mind while going for selection of an automating testing tool:
1. Cost: Cost of the tool should be clearly justifiable with the number of projects in hand, foreseen to come in future, cost of projects in hand and those coming in future. There is nothing wrong in looking for open source tools provided you have courage to go in depth of learning and adaptability.
2. Team Size: Large team size of developers vis-à-vis negligible testers is a death trap. You certainly need an automation tool else you will certainly require to increase number of testers.
3. Right Tool Selection: You just can’t go and adopt any tool just for the sake of having an automation tool. There must be criteria of choosing right tool for right kind of product to be tested. All tools do not fit for all platforms.
4. Usability: Team who is going to use that tool must be comfortable in using it. It must be easy to operate, clear in understanding and least cumbersome to operate
5. Recording: An automated tool without recording and playing back provision is useless.
6. Manual Skills: Any kind of automated tool will require manual skills in terms of team member having capability of writing manual scripts to be embedded in the automation tool.
7. GUI: Prefer to have a GUI based tool where things are easier to handle and understand
8. Reusability: The tool should be able to build a library in an intelligent manner where it is easier to pick a script to be reused for similar kind of testing at a later stage on the same of different product.
9. Maintainability: Tool should be up and running for long. It should not die at a shorter length.
10. Community: You never can master a tool, whatsoever you choose. You need a community to share your achievements, pains, feedback, suggestions, and so on.
We all have certain amount of myths within us and sometimes we start loving to live with them. A developer’s job is quite critical in any software development project as this is the guy who is doing all ground level work. Whatever he produces goes to the customer though after passing through testing phase.
Understanding the customer requirement is most critical for a developer even if he is master in coding. All excellent developers do not turn into successful ones dues to this factor. It is not bad living in myths if those are positive ones and have a narrow gap with the reality. The higher is the gap of a myth with reality, more difficult it becomes for others in the team to digest and ultimately if might produce a negative impact for overall project.
If we try finding out 5 myths of a developer that could turn dangerous for his own career could be listed as below:
1. I am supreme and am not bound to produce any bugs in my coding. Once this feeling chips in, developer starts negating any improvement points required for his coding and all bugs though get fixed by him but keeps him working carelessly.
2. Tester is just there to find out faults in my coding. If intentions of a tester are doubted by the developer, then probably he will not be able to take his feedback positively.
3. I must write a code that keeps my team dependent on me. Coding in an unstructured manner is a crime but some developer love doing it.
4. I can steal this code as I am writing it. This is unethical. Whatever a coder is writing, he is being paid for it.
5. Keep provisions of code going haywire with a future timestamp? This is a crime.
This is a video by ProjectManager.com and presented by their Program Direction – Jennifer Whitt, PMP. The topic is – Learn 7 steps to avoid project closing pitfalls and be left holding the project bag. Basically whatever is done in a project is for the successful closure, closure sign off and commercial closures. The whole journey of any project is based on certain pillars to make it stand, run and reach to its destination. First you have a look at the video and then we discuss few points further down the line.
Inputs, Acceptance approvals, documentation may all appear to be quite simple procedures and small activities but in real life these are basically the activities that if not done smoothly choke the progress of any project.
India has achieved its 100th Space mission and it makes India as a strong contender one among the top technically strong nations across the globe. India in fact is a unique example of absorbing so many cultures, so many castes, communities and so many contrasts complementing and supplementing; and making the whole nation as successful in various streams.
The same zeal and fire is required in a project manager who must understand the wider and long term goals without bothering about short term hiccups and criticism. Let us celebrate the day and move in the direction of managing projects with a higher level of responsibility and authority.
Your qualities are unacceptable as long as you don’t vet them yourself. Your value is ignored as long as you do not accept it yourself. The moment you realize your real value, you will wonder, that everyone else also becomes aware about it. Doing ordinary things in ordinary fora but even in ordinary projects you can manage or handle things in extraordinary manner so as to bring it to new achievements or heights. Doing same things in same manner endlessly will make you mechanized, inhuman and brainless entity.
IF you carry your brains with you, you are supposed to do small innovations in all aspects of life. A project will always have a scope of improvement in its various stages. Watch this video completely to understand what I have said above:
People who fear in life does not mean that they fail in all aspects of life. But keeping a fear in mind out of certain failures can hamper your progress, growth and success in a bigger way. It may become a mere showstopper and block all paths of your life intended to take you towards success and growth. People who do not fear in life for failing or making mistakes have higher tendency of doing extraordinary, amazing and out of box.
Every project will be a hit, success and finish in time is a misleading concept. There are issues – bigger or smaller – in any project. Running away from problems or failures will not let you each to your destination. Watch this lovely video of less than 2.5 minutes that will give you some energy to stay away from fear of failures.
A Project manager is supposed to lead some teams namely – development team, implementation team, Business/ Requirement Analysis team, Quality/testing team, Process team, support team and so on… Though these teams will be having their own respective leaders (or managers?) but a real LEADER at the top edge of this triangle is a must. There is a big difference between a leader and a manager. Manager is the one who manages, leader LEADS.
Enjoy this video which is quite inspirational, motivating and will definitely fill some real knowledge on leadership.
Why a project fails? It is quite an interesting subject to ponder upon and introspect if you are a project manager. In real life everyone is a project manager irrespective of what role he plays in professional life. We all have to manage multiple things most of the time and success of what we are trying to manage is very important to progress in personal and professional life for all of us. Now let us look at various roles a project manager has to perform during a project life cycle. Have a look at this lovely video:
The life of a project (project initiation) starts with something known as Feasibility Study. And then life begins to look at resources for everything that is about to happen in the project. Resources for feasibility study, resources for development, resources for deployment, resources for hand-holding, resources for training, resources for post implementation support and so on.
At each step of project you move ahead, or rather make any move, based on certain set of assumptions. Assumption that the team built for the project is perfect. Assumption that projected timelines will have no variance. Assumption that design will perfectly match with what customer is dreaming of, Assumption that this project’s success will pour in many more projects…
This video, which is of less than 5 minutes duration takes you through a complete project, stage by stage, making you part of it.
This is a good piece of video on Youtube titled History of Project Management. It is quite interesting and though provoking kind of video that seriously tries to provide good amount of information on how project management could have begun years back. What made it happen? What could have generated the requirement of project management? What could have been the starting point of project management? How Project Management got evolved?
Was it PERT, IPMA, PMI, PMBoK or was it something else that created the need of its existence? Was it GANTT in 20th century or it had taken birth way back in the days of Giza Pyramids. Probably Giza Pyramids is the best example where one can see well structured and matured project management in place. Have a look at following video and put your ideas right about the subject, in right place.
Just enjoy this funny video and check if this is what mostly happens while managing projects
You will really enjoy this video published on Youtube that very crisply conveys its message on the gap between the communication arising due to different nations having different ascents for speaking even the same language – say English. This is what actually happens on overseas projects. Having a good vocabulary, speaking power or ascent does not do as good as being versatile and smart to grasp your client’s style of communication though talking in the same language.
Have a look at the video below, that is lovely and crisp enough to convey its message about how to convert all your communication during various project phases into effective and result driven communication. This is a small video, not more than 1.20 minutes but is strong enough to convey its message clearly. Have a look:
This is a video I found on Youtube and though it is a promotional video about some company assisting in Project Management, but video has an example showcasing a project management team headed by project manager Zack. He experiences different ups and downs and different kind of people during management of his projects. The video tries to highlight certain magical project management skills required in a project manager so that he is able to manage his project well.
Here it is, enjoy the video:
Hey Guys! While exploring in the ocean of videos called Youtube, I managed to find another good video that was educative, informative, guiding and humorous all at the same time. It is focused on some of the very important aspects of product development or production. Customer requirement is most important aspect of any project – be it production or service oriented. Both ends while understanding customer requirements should be very clear about finalizing business critical issues that are required to be issued in the product or service in question.
Once customer requirement is clear, any outsourcing or in-house development requires some material and resources. It is very clear to get these material and resources in place in time so that the planned development goes as per schedule and resources are well utilized in order to achieve success in developing right product first time. Higher the rework or bugs in the product, higher is the wastage in time and resources and eventually high risk grows in terms of not being able to deliver to customer as per committed datelines.
It becomes very important to streamline and follow processes so that optimization is attained in cycle time, production and defect free delivery. Logically it is not only the project manager of the product manager who drive the project or product but involvement and commitment of each and every member of all teams becomes equally important.
This is a lovely video on TOTAL QUALITY MANAGEMENT (TQM) produced by by Rafael Cravioto Torres. It makes you understand well in a very simple manner on all aspects of TQM, the factors responsible to promote it in any organization and some factors on the other hand that demote it or do not let it happen within the organization.
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.