A project consists of various stakeholders – some internal and some external. Stakeholders of the project usually live on another planet. Being a stakeholder in a project give them a feel that they are like a king of the land called PROJECT ruling on the teams working in their project territory. They actually behave as a ruler and look at the project as if their contribution is just to make all people working on the project answerable about any delays or extrapolated commercial or projected targets.
Is it possible that I rule on a piece of land and do not contribute in the progress or growth of that piece of land and still expect positive results from whatever is happening on that land. How is that possible, when I am doing what is totally against the law of nature.
Monitoring, questioning and policing is the most simple thing on this earth and everyone likes to do it given a bit of a chance. Best part of being a stakeholder is that one must own the progress and completion of project as his/her personal target rather than looking at others and expecting other to drive your vehicle when you are yourself not adding any value in its speed, progress and contribution.
What is the fun of putting the badge of the owner of a building in making and contributing in none of its progressive components – like providing material, helping in building up process, working on some process to enhance the speed or otherwise look at making it reach to its milestones in lesser timeframe than it was stipulated initially. Finally it helps your teams to attain higher results if you find out some ways in reducing expenses on the project but without hampering on its progress.
Any project can be made successful if two of its components are left unnoticed, which are – expenses on the project and time limits. Though both of them are the most critical components and none of the projects on this earth can be run or finished on the basis of ignoring these two components. Even if a project is sponsored by internal stakeholders of the organization, it cannot have an uncontrolled flow of money to run it. Internally sponsored projects are also termed as self sponsored projects.
In an externally sponsored project pressure of both time and money is there in most of the cases. No client would let its money flow without getting desirable results from it, especially in today’s economical situations. Various efforts are done and measures are taken to apply controls and checks so that progress stays on track and nothing goes out of control.
In fact during your all running projects, one team can take a project of cost reduction. This project focuses on the processes of other projects in the organization with a target of doing some improvements in those projects’ processes so that there is a considerable reduction in time and expenses. This team’s intentions are not to pinpoint on any person or mistakes but to find out the gaps in the established or followed process so that it can be fixed or filled appropriately in order to increase the overall throughput of the project.
And we all know that throughput of any project can only be improved by means of improvement in cutting down its expenses or scheduled timeframe.
A big corporate starts new business and hence a new company takes birth. Though it is a new setup, there is a mix of old and new employees and similar is the case with business processes. Some old processes are adopted as it is, whereas some process are formed totally newly based on the learning from old processes existing in other business. Even with a lot of hiccups sometimes processes keep on lingering in an organization for two reasons – one, it has become too complex that thinking of an alternative becomes a big pain. And two, even if the process is staggering it has gone into the blood of employees and hence is not treated as a drop case.
So in the new organization when new setup is taking place, it is the function heads who try to spoil the show by means of taking shortcuts in established or newly defined processes in order to over-show their efficiency and over-knowledge. This works sometimes, but only for a short period and that too if the management is blindfolded. Otherwise if management is awake and is also aware about the processes in depth, any kind of shortcut can easily be caught. If a shortcut is caught and alerted or warned sternly, a clear cut message goes across the board that none of the unwanted shortcuts shall not be tolerated.
It is not only the management who is supposed to monitor any irregularities or shortcuts in the system. It is also the responsibility of older employees in the organization which are part of system and business process. If both are alert at their ends, nobody can make a misuse of any kind of situation in the organization.
No management ever wants any of the ongoing large scale projects in the organization getting failed or substantially delayed due to two main factors – one, their reputation is at stake, and two, they are bound to lose some of their personal financial kitty in that case. But still we see many of the big projects getting failed or unsuccessfully closed even when there are big products, established partners and solid base of functional knowledge available in the organization.
Who can help from outside the organization if organization itself loses its hope of success of a project? It happens even in biggest of the organizations but it usually is the different ways of handling the situation that matters most in such conditions.
If a project has gone in the unsuccessful category in an organization there are two ways of looking at it, first way would be:
– take it as a learning,
– find out the reasons of failure,
– take an oath not to repeat the same stupid mistakes leading to failure,
– dump the failed project,
– forget it,
– and start a new project for a bigger success.
Another way would be:
– Don’t find out the exact reasons of failures
– Fire one of two persons making them responsible for failure
– Keep going with the failing/ failed project with an effort to make it a success
– Bring in more people on board to tune failure into success
– Crib again after a couple of years for still it being a failure
– Fire one or two more persons
- Keep going with the efforts to make it a success
Now it is your turn to decide which organization would you choose to be a part of?
I recently visited a reputed international manufacturing company having 98% revenues from exports to various countries. The setup was somewhat like 3 manufacturing units in a major metro, creating a sort of zone. Another manufacturing unit was in a far off place taking 4 days to reach by road (though aerial connectivity is there from metro to that city, 4 days is just to give an idea of the distance between the two locations).
Four years back ERP was started (one of the frontrunner ERPs through one of the most successful implementation partners), in one out of the three metro units mentioned above. This unit that was chosen for implementation was the major revenue earner out of all the four units. Idea was that since is it most profit making unit, earning higher revenues than any other unit; based on these facts it was presumed that this unit will have best of the people among all units and hence there will be 100% successful implementation.
A big named ERP and the most successful implementation partner did not help to get a successful implementation among the top functional people present in the unit and hence even after four years, the story was that none of the top management reports were on ERP, most of the end reports of all functions were either on excel of on legacy software and overall it was a big chaos, frustration and disintegration. Group it was in a big dilemma on how to make this big investment a success.
ERP implementation in a Greenfield project that takes place for a new factory or office setup, as per my understanding, should be totally different from a conventional ERP implementation that takes place in an already running plant of office environment. None of the modules as such are required to a full extent except the core of the business process that needs to be catered to. Among most of the common ERP implementation methodologies this would be the quickest, more productive (in sense of functionalities subscribed or bought versus their usage and result drawing from them), and having higher rate of success.
Core business requirements identification and freezing will be very important as the whole implementation route will depend on it. A cloud subscription model in such cases is more relevant in such environments. As the needs of the business grow with the growth of the organization or business so can be the requirement related to ERP can be defined and implemented on a year to year target basis.
Since the inception of organization is new, it is open to adaptability of any world class system, methodology, environment or ERP. Hence any proven modular, subscription and cloud based product should be most suitable with a monthly (or a periodic) billing for usage on the cloud. This will have a least burden on the organization in terms of infrastructure, servers, security, backups, DR, BCP sort of issues as most of these can be part of the subscription model. Training requirements would be least and the usage along with learning can start quickly. This model will give a higher level of mobility to a user of working on ERP from anywhere, anytime.
Assumption is that the business processes are already there in the product with least scope of changes or additional requirements at this stage except some local legal requirement that need to be catered to like government rules on taxes etc.
My strategy in such a project would be:
1. Business Case and its approval
2. Core team building
3. Core requirements identification
4. Selection of a right partner for service (having a powerful modular product on cloud catering to our requirements)
5. Implementation Plan (30 days or so depending on core requirements)
6. Hands on/ Pilot to see results and gain confidence
7. Daily standing meeting in the morning to review any perceived threats to day’s targets
8. Daily standing meeting in the evening to review any deviation from today’s targets due to any unforeseen problem
9. Project completion and sign off
10. Support functions
A regular type of work all the time makes it boring and typed thereby taking away all the variety that one needs in life for progress. This leads to a stale state of mindset where you set yourself limited to only one kind of thinking that to a certain extent. Some ice breaking is required to get out of the shell and fill in or pump in some fresh air to change the gear or life and profession.
How does a project manager keep afresh so as not getting stale? Because if the project manager goes into this kind of mode, how can the teams that work under him ensure not getting into this mode. The team members are the real warriors in the battle called project. Warriors need a continuous dose of motivation and courage to keep moving in right direction so as to meet the targets in time and that to without any flaws or shortfalls. Getting into a shell by a project manager and not able to deliver the best in a project is not something that is clearly visible or measurable. It has to be felt, more by the project manager himself.
How does a project manager know that he is not able to deliver his best or his output is declining? One way to measure it is by means of monitoring of tasks in hand, whether those are getting completed in time of not. Further, there is a mechanism of feedback where the team members can point out some change in the project manager’s behaviour or way of functioning that might not be noticeable by the project manager himself.
Do you agree that a project manager needs a break during his long years of working on projects and doing nothing else?
Let us consider a project as a journey. For any journey you need to decide about lot of things in advance and during the journey. Time to time these decisions need to be looked into even if the journey has started to ensure that even if those have been taken, are they leading you to right direction and desired destination. And one more advantage of reviewing them on a regular basis is to take an appropriate measure in case some wrong decision is noticed or even if right decision has drawn out undesired results. An immediate course of corrective actions is something that can reassure your project leading to right direction and desired results.
1. Wrong foot in wrong place
2. Wrong foot in right place
3. Wrong direction
4. Wrong destination
5. Wrong driver
6. Wrong partners
7. Wrong milestones
8. Wrong speed
9. Wrong road
10. Wrong vehicle
11. Wrong mix of co-travellers
12. Frequent halts
13. Frequent change of co-travellers
14. Frequent change in directions
15. Frequent change of driver
16. Frequent change in speed
17. Frequent change of vehicle
18. Lower or Higher Pressure in Tyres
19. No Music System in the Vehicle
20. Malfunctioning Brakes, Accelerator and Clutch
For each of the point, when you read, and look at your projects, you will perceive various meanings related to it, depending on your experience in the field so far. But definitely each point makes sense.
First of all we would have never imagined of having multiple tabs in browsers, a decade back. To open multiple sites we had no choice but to open as many browser windows. And now it is just one window of any of the popular browsers like Google Chrome, IE or Firefox and you can enjoy as many tabs as you want. The same concept, though no one would have though of, is now available in terms of office add-ins, fully compatible with Microsoft Office. Look at the beauty of opening multiple documents for which you don’t require to open as many Microsoft Word windows. You can open as many tabs of any number of documents in a single window of Microsoft Word.
There are so many advantages that you get by using office tabbed interface in your work place or at home while using Office be it Word, Excel, PowerPoint, and beyond depending on the product you choose. Best part is that you can download it and use it for 30 days with all its features enabled so that you understand its power and beauty. Use it once and you will get hooked to retain it forever. Observe the clutter it is able to take away in terms of giving you a leverage of opening any number of files in word, excel, PowerPoint etc. in a single window of each. On top of that, you can save all these multiple tabs (multiple files) in one go.
This is a project of its own kind. A unique and innovative project focused on electronic recycling, computer recycling and any other type of eCycling services to its clients starting with a free consultation to understand the basic requirements of the client and some kind of assessment or scope of work thereby guiding the customer to move in right direction with all kinds of safety measurements, ensuring complete satisfaction.
Logically the concept is that of Value Recovery which means that all of the green initiatives taken by your organization in the past or being undertaken currently are not required to be counted or taken as a waste of resources. If the green initiative is completed and the resources utilized have reached their end of life stage, their value can be recovered in a way with the help of recycling initiative to convert your old used material into a useful and valuable revenue stream.
A large organization engaged in providing recycling services to big corporate businesses has to be capable of having sufficient resources and skilled manpower to manage almost any kind of waste or end of life material. Its processing of material capability also has to be enormously faster so as to cater to higher amount of businesses. That way the customer also recovers their end of life material’s cost faster.
The company providing such essential services must also ensure complete security of data while destroying their electronic media whether it is done on-site or on a remote location in any volume. This service also delivers a solution to an unnecessary space being occupied by wasteful stuff. ecycling basically comprises of two alternatives when it comes to recycling of electronics items that have reached to their end of life stage. Such electronic items can either be demanufactured or undergo a shredding operation. Demanufacturing is nothing but the dismantling of the electronics items in a manual way so as to segregate the reusable components from totally waste material. This has to be done in a very careful manner so as to keep the usability of the material intact that can be sent to the second hands components market. Shredding is done where the effort is higher in demanufacturing as compared to the value of the reusable components that can be recovered.
Corporate e waste involved lots of electronic recycling as the use of computers and electronic media has increased tremendously across the globe. it is better if the service provider takes care of any sort of components to the last level instead of taking further services from a third party.
E-learning is the trend these days. It has dissolved any geographic boundaries and made this world too small for the purpose of delivering and getting the Best. To make any learning most effective, the trainer must be much focussed and aware/ capable of delivering the crux of the matter. To find out such online companies is not a difficult task provided you spend some time and do some right kind of exploration over the internet.
Security awareness training is not a one time or a single person’s requirement for any organization. It is meant to be learned by each and every member of the team right from top to bottom. That is why in such training the strategy should be to design it a communication tool at enterprise level to inculcate an organizational culture in which each and every employee is well aware about security components in all aspects of any project.
Long term training in information security awareness has been found to be more effective than a one time training which loses its warmth and gravity over a period of time and serves only as a formality. The training needs to When be such powerful and effective that its intent starts flowing into the culture so strongly throughout. A relevant training to all team members must be decided and it could be as per the need of the project or the member. The purpose of training is not only to impart knowledge about world class standards like SOX, HIPAA, FISMA, PCI, GLBA, HITECH and Red Flag; but also to keep its awareness alive and updated with a repeated curriculum.
Such training if provided in a most structured and organized manner, are definitely purposeful and serve an organization in a great way, provided a right kind of partner is selected who understands the core requirements of the organization and its employees, who in turn can work towards enhanced security features in whatever they are doing.
Formulating your test strategies, test plan, QA vision, mission etc. on the same trend year on year without changing according the changes happening around the world could lead to a disaster. For instance being a QA Head, you would have clear cut instructions for your QC Head to perform certain set of norms for defining the criteria of testing or evaluating a project or a product.
How old are those norms, how drastically the product has changed over a period of time, how the technology and testing requirements are changing outside your organizations and how rapidly the customer’s perceptions are getting changes about a product or a service – Are you aware?
It is the simplest way to keep going the way you are going without bothering about technological and other advancements taking place around. Your product evaluation criteria could have got outdated by now and you might still be living in a dream world building your own fantasies about the strengths and popularity of your product.
Some thoughts for you:
How often do you look at other products available in the market which is in similar lines to your
product under evaluation or testing?
How do you benchmark your evaluation and testing process?
How often do you review your processes?
How do you empower yourself to have enough knowledge and understanding so that you can go and tell the project manager about enhancement in the functionalities built in the product?
Ultimately you also know very well that whatever scenario is prevailing today won’t succeed tomorrow. You have to be innovative and genuinely alert about updating yourself as per the world norms and not those set by yourself or your organization.
A project manager’s shell is his projects. Most of his life is spent in moving from one shell to another shell after spending a substantial amount of time, energy and efforts in each shell. Its quite funny if he introspects after a decade or so to analyze what exactly has he achieved by living in these shells. Probably there would have been a better way to run, execute, finish, start or close his projects, had he taken some of his crucial time to come out of this shell and see something around from where a new learning or idea could have been generated.
Some introspective questions from my side to a project manager:
Is it not important for a project manager to see other products similar to what he is delivering to his customers?
Is it not important to understand the gap between the ways you are coping you with the changes happening to the technology and the way it changing in the outside world?
Are you aware what I am asking you to do is already being done by your customer – exploring all possible products before placing an order to most appropriate for him?
Are you sure your successful product in the market will remain successful forever even if you don’t do any of the activities listed here and keep living inside your shell?
How do you measure your pace of advancement with technology vis-à-vis the actual rapid changed happening outside?
Are you sure you won’t get outdated soon with your traditional ways of managing a project without bothering about what advancements have taken place in that direction?
Choice is still yours. You love your shell, you feel management is quite satisfied with you, you are sure about your customer being happy with you and you are ok with your success rate.
But that is the scenario today. What for tomorrow?
A well known fact in business is that it always takes more efforts, time and money to attain a new customer than to sustain the existing ones. There are companies, online and offline, to assist you in sustaining your existing customer by way of maintaining a regular bonding with your customer on your behalf. This is something happening in a big way these days. This is called appreciation marketing. The same thing happens for employees too. This is something quite effective to sustain your good employees and customers for a win-win situation.
Something in the same lines is Financial Advisor Marketing in which all those engaged in financial planning and advisory business are offered a service that helps them to sustain their top customers which they would never like to loose. This service of financial planner marketing consists of appreciation and retention package.
If you are a Sports Marketing Company and are facing a problem in maintaining your existing good customers, there is some company specialist in that field, just to do the right amount of things in the right way, for you in a very customized manner.
If you are an automobile dealer, you very well understand the value of your customer and how it seriously affects your business. Automotive CRM is an art rather than a science. A personal human touch plays a major role in retention of your valuable customer and that is where some expert needs to be there.
Above all, if you see, when you loose an existing customer, you loose a lot more than merely losing one single customer. It takes away a brand ambassador of your business who could have given you enormous business by getting you more customers. That is why an existing customer’s retention is something very crucial.
I recently observed a website while randomly searching for something related to cooking, cookware etc on Google when I encountered Salamander Cookshop. The site is simple, plain, crisp and to the point; serving its purpose to the fullest. It is a site for online selling of most of the top branded kitchen related items covering almost 173 brands e.g. Fissler, Rosle, Couzon Cuisinox, Silverwood, WMF, Wusthof, Scanpan, Le Pentole and many more. The site is well reputed and has been featured in top media like The Guardian, Good Homes, Daily Mail, itv etc.
In the Kitchen Trolleys section you can find Trolleys and Butchers Blocks of a large variety depending on your choice of wood. I could locate there various product range like – Maple, Ash, Painted stuff, Limewood, Beechwood etc. All this stuff gives you a large flexibility for your modular kitchen.
The next section that I visited was of Cookware Sets where you could find a long range of cookware with huge savings indications tagged on each. The variety coverage is fantastic, product demonstration is absolutely lovely and overall design is superb.
With so much versatility, variety and smooth sailing on the site, who will not like to stop and gaze around as every kitchen needs something or the other to add up any moment of time.
I was wondering to ask my project manager and project management office (PMO) guys to visit the site and learn some techniques that simplify quality and delivery.
Project estimations is not management’s ballgame. It has to come from the person who is actually conversant with in and out of at least a good amount of different type of projects running within the same organization. Project estimation is not simple mathematics. It is not just A + B.
Various components need to be considered while working out project estimations. Few generic constituents would be simple to identify and work out. Few constituents would be quite specific to that particular type of project under consideration.
Ten major constituents of project estimations can be listed down as:
1. Project Physical Cost
2. Project Intellectual Cost
3. Project Cost of Quality (CoQ)
4. Project Buffer Cost
5. Project Overrun Cost
6. Project Commercial Cost
7. Project Sales Cost
8. Project Material Cost
9. Project Inventory Cost
10. Project Indirect Cost
All projects in which management is the sole player in deciding about project estimations have higher chances of failing as compared to projects in which all members engaged with project in any manner have been involved in determining project estimations. When it is management that does project estimations, it is not project estimations, it is rather something like setting targets without having a clarity of what is to be achieved, what is the scope, what are resources and so on.
Management is just like an overseeing agency that has no role in project development, project execution, and project implementation at micro level. Project estimations cannot be so haphazard that variation between project estimations and actual project cost comes out to be substantial huge. Nobody will accept that situation – not even the closest of stakeholders.
Project estimations need to come out from those persons who are actually well conversant with project know-how and behind the scene expenses. Management is works out on project estimations without inviting participation of actual project runners, it would be quite risky. There will be quite high chances of missing the actual rope to the mountain. There are certain costs which are apparently visible off the shelf for any kind of project.
I would like to classify overall project estimations or actual project cost in these parameters – project physical cost, project intellectual cost, project CoQ (cost of quality), project buffer cost, project overrunning cost, project commercial cost, project sales cost, project material cost, project inventory costs – to name few main of those.
Any project has some basic requirements like project committee, stakeholders, sponsors, requirements, initiation, team formation, plan and milestones identification, project development, execution, implementation, handover, and finally project closure. What it means is that each of these basic components of a project play major role in determining success or failure of that project. A lack or shortfall in any of the components impacts on tempo and momentum of project. It can be correlated with a relay race where each player of the team has to be in sync. The weakest player determines the final standing of team after completion of race.
One difference between relay race and project is that in former each player plays his role in sequence whereas in later some tasks go parallel and some are sequential.
Project Plan formation, milestones identification, plan execution, plan monitoring, plan change are all quite critical in any project. Project plan made for the sake of project without a commitment of strict adherence to it means a great level of shortcoming in project committee and teams responsible to execute the project.
There are ways to monitor and control project plan. Some ways lead to post-mortem after any failure or deviation occurs. Other ways lead to a proactive approach where the project committee anticipates a shortcoming well in advance and thereby takes appropriate actions to manage to control the risk at their best hence reducing the risk to near to zero.
A proactive approach always comes with an objective way of monitoring a project. A well matured metrics in place always help in accurate measurement of the situation and this everything in sync and proper rhythm.
A customer is supposed to be quite cooperative and involved throughout the project. A project is supposed to be completed well in time complying with all the requirements specified by customer. Customer requirements specified in the beginning of a project are supposed to be complete and accurate. Team formation is supposed to be so precise that all team members form a perfect team. Project manager is supposed to be well prepared and equipped to take care of project. Management is supposed to support and fulfil their commitment to customer for delivery of product.
All this is possible and happens in reality. More in reality that happens is reverse of this. Customer involvement is not there throughout with availability of right people having precise business knowledge and experience. Projects do not end in time and if they do, some of customer requirements are missed or skipped or are not catered to properly. Customer requirements specified lack completeness, accuracy, and clarity.
Team formation in the beginning of project does not necessarily stay same till end thereby varying perfection. Project managers miss either preparedness or don’t get well equipped. Management feels team and managers are enough to mange delivery of product thereby getting attentive to business functions having higher priority.
It is either win-win or lose-lose situation in a project. Nothing is there in between. If one party loses the game that doesn’t mean the other party wins. If product is not delivered in time, if product is not delivered in complete, if requirements do not match with delivery, if customer is not happy; all these lead to a lose-lose situation.
There is a big difference between mediocre companies and well structured companies working in same set of business. Let us see a set of software development companies. This set contains two types of companies having different project management methodologies. All other types of companies with different ratios of two extremes lie in between these two types of companies.
First type of companies are those which have no methodologies in place. All that works is person dependant as there is no system (or per se well defined system in place). Other type is those having well documented, adhered and audited systems in place to manage all projects they work on.
First type are very dangerous though they exist, survive and sustain. But everything is ad-hoc – the business, the projects, the existence, the survival and their sustenance. Such type have no written or documented procedures, methodologies or systems in place. Since last project they succeeded in had no reported leaks, the next project will follow the same route or process.
Risk level is high in such type of companies. Best thing is, since there is no risk assessment, or audit (internal or external), there is no realization of leaks, holes or lack of process in place.
Such companies may declare project initiation without even formation of proper team, defining of requirements, roadmap, milestones or a project plan in place. Things are done as they come, or as they fail. Actions are taken not on the basis of proactive approach but based on stakeholder’s reports, complaints, system failures, shouts etc.
Having a high level seat in an organization qualifies a person to sponsor a project. Sponsor could be one person, generally one top positions or a groups of persons comprising of top/ middle level of management of one or different organizations. Projects may be self sponsored too wherein there is no customer involvement in that case and the sponsoring organization starts project on their own keeping in mind a good amount of response from market after the development of product.
Teams are formed, priorities and milestones are set and journey begins towards successful completion of project. Conflicts, issues and change management are part of project’s any phase. Most of the issues and conflicts get resolved with the help of standards, procedures and team managers.
Some conflicts and issues go beyond the level of managers and hence seek attention of top or senior management. The best person in that case is the sponsor(s) to address to such requirements. Rather sponsors should be regular in all project review meetings to understand about the progress of project.
Attending project review meetings is one important requisite for sponsors. More important requirement is to be very clear about the path decided and path being taken for the project. Things should not change on their own especially requirements, team composition and milestones. And if change is the demand of time, sponsors should have a clear cut say on it about the necessity and importance of change.
A weak sponsor having no say in the project or taking no interest in project is equally bad as not getting involved in the project.
Project Sponsor(s) are the executives whose dream gets a hope of light of the day when the plan to give a reality shape to this dream is made by forming a team and assigning relevent task to each of the team members. Project sponsors ususally are too senior lot of people ususally CEOs, MDs, CFOs, COOs etc. They have a tendency to conduct a meeting to shout about their dream among other executives and team members, get a high round of applause and a nod to start the project.
The team gets formed, comprising of sub-teams, team head, sub-team heads, team members with each of them having a set of tasks in hand to be performed in stipulated period of time. The dream of sponsors gets traslated into a roadmap with well defined milestones. The product starts taking shape and progress being monitored regularly.
One important factor that can make all this beautiful garden haywired is absence of sponsors from product development or product progress scenario. If sponsor(s) feel or assume that one meeting is enough to pass on the whole crux of their dream to team, they are absolutely wrong. Nobody else can understand the value of dream other than the dreamer. To give it a shape in reality, one need to keep his/her team constantly awake about it.
A CEO of a software company dreamt about a very great product one fine day and decided to give it a shape in reality world with the help of his strongly skilled team. The team spent many days on brainstorming about this new product conceptualization, design and development part.
The team started working on it with a stipulated timeframe in mind. The team motivated by their CEO who was the sole sponsor of this project was able to finish the project well in time. After careful and thorough testing cycle of the product, it was ready for launch in the market.
Efficient sales team started approaching relevant prospective customers to get orders. At few customer places the deal started approaching towards final stages. One of a big customer wanted to meet the CEO of this software company.
CEO of software company met with higher officials of customer company to have a meeting and was able to convince them about conceptualisation, development and logical built of the product. After getting a good praise about all this CEO got stuck on one question raised by customer – What is the business value of this product?
Do we know the answer for our product?
Any human being is a born quality manager and keep demonstrating his quality skills in day to day life by managing everything that comes in way by means of best possible solutions. A child is taught about cleanliness and discipline right from begining to sreamline his daily work. Do we compromise in admitting our child in a substandard school or with the character and quality of teachers they are being taught by?
We do not compromise with the quality of items and commodities purchased. Do we take a chance of compromising with the quality of material used in building of our house? We very well know about the consequences and risks associated with compromising with quality in our routine life.
The same concept applies to software projects too. Quality can not be subdued or sidelined. Risks of failure of any project cannot be nullified or ignored in that case. Quality plays a major role in assuring the success of any project. A programmer or coder if writes a program the same way with same mindset the way he manages his domestic work with high level of quality, there are less chances of passing the code with high level of leakages in it to next level of team that is testers for testing the product.
The way a product is buit with high level of accuracy and least level of quality compromise can be treated as a part of Quality Assurance. A product when given to testing team for finding out bugs falls under quality control. The level of standards followed by testing team to perform testing process will come under quality assurance.
A child is born to get groomed to be responsible for various activities all across his life during his transformation from infant to toddler to teenager to adult to old. At various stages he has to undertake various responsibilites along with a continuous learning process. A stage at any moment in life of attaining a capable position does not hinder or restrain a person for further development.
In fact nobody is perfect hence aspiration to attain a ’near perfection’ state is a never ending process in life. An infant though unable to speak manages well about his signals of what he desires to have at any particular moment. The moment a child starts going to school, he starts managing his balance between home and school, coordination among his peers, learning from his parents and teachers, managing his tasks and disciplines assigned and taught by elders be it teachers in school or family members at home.
Demands in senior school and then in college are quite different as compared to junior school but by that age the child has learnt well to cope up well with them. A new journey starts with a fresh career and a consistent growth chart.
The logical and general skills required to manage any project in life and career already exist in any person inherently. It is only the specialized skills and technical knowledge that is required as an extra edge for a specific project.
Customer Requirements need to be wisely analyzed before committing its fulfilment to customer. Many a times a commitment which has not been properly analyzed and assessed impacts to a large extent on completion of project.
It may also happen that a requirement stated by customer at a later stage may appear to be quite genuine for business purposes and logically need to be covered in product development. Project Team need to properly analyze and though accept the requirement but need to clearly tell the customer management its impact and risk if any.
The requirement raised by customer may already be catered to in the product built for the purpose but not exactly in the manner defined or expected by customer. If the impact analysis draws out a bigger risk of changes to be done at that stage of product to cater to customer requirements as it is, customer management need to be convinced about the functionality and features already present in the product.
It is wise to build a functionality altogether different as a complete sub-product, if requirements need call for that; instead of fiddeling with the main product.
It is unwise to accept all requirements of customer and keep making changes in the product thereby changing its stable stage to unstable one.
It is better therefore to adhere to and adopt some best practices to manage Change Requirements.
Many a times it has been seen that a change in key users or one of the key management person tend to call for changes in the stable running product in the organization, which may turn out to be quite harmful.
Project Manager and Project Management Office need to convince top management of customer in case of some unnecessary requirements raised by one of the influentinal person in the organization who might have joined organization recently so as to impose his/her importance.
Changes once accepted, not only impact on product’s stability or the software environment but also many times has serious effect on performance of the product and its hardware requriements may change.
In fact requirements raised by customer must be mapped properly with their existing business model and its impact on software application running in the organization for that purpose.
An ecosystem to manage change requirements and a standard metrics system thus becomes prime important to manage the show.
A well defined system in place not only helps in streamlining the process but also helps in benchmarking with other systems being followed in other organizations.
Involvement or engagement of customer in formulation of systems is always beneficial for both parties.
These processes once defined must be adhered to and also need to be examined from time to time for the purpose of optimization.
Defining of processes is not difficult if compared to the later part which is adherence of those processes.
Release management is a systematic structured approach of releasing the product to customer. The product journey that starts from requirement gathering from customer, conceptualization, prototyping, coding, testing finally is declared or approved for release.
Testing phase can be termed as equally complex stage during Release Management. Product testing is done in various forms starting from smoke till regression testing.
Test Cases are performed on product and test report is submitted back to development team with an indication of severity of each bug reported. Development team fixes those bugs and product once again undergoes testing for validation and confirmation that no new bugs have evolved while fixing the reported ones. Product now has to undergo one more phase of testing which is termed as UAT or user acceptance testing.
Risk Management and Change Management are two very important components throughout the Release Management of product.
To summarize Release Management, a checklist is always important to maintain and update regularly in order to ensure the successful results throughout this journey.
Requirement Coverage: Requirement gathering and its documentation both need to be crisply and completely covered. Any lack in either of the activity is like a volcano in the making. In fact 88 percent of project failures worldwide are due to wrong or incomplete requirement study.
Team Selection: Development team need to be wisely selected keeping in mind – too many cooks spoil the broth. A mixed level of developers always keep better harmony in the team than having all of same level.
Development Plan: A proper plan with clear cut assigning of responsibilites along with target dates mutually agreed upon has to be in place without which no sailor will move the ship in right direction.
Quality Control: Each step testing is an important factor. Don’t wait for the product to complete first and then start testing. That will be a sheer wastage of time, efforts and resources. A side by side testing draws out better results.
Quality Assurance: Some benchmarking and standard processes need to be in place and to be followed to ensure a quantum control over the situation. Else nobody will be knowing what processes or methodology to be adhered to for ensuring success at every stage of the project.
Stakeholders/ Customer Engagement: Most of the time there is a wide gap between development team and other stakeholders/ managmeent/ customer representatives. This gives a big opportunity to development manager to misguide management about the progress of project or projecting the situation as per his comfort. This does not go healthy for project in a long run.
Software development comprises of various stages and components. As software development is a subset of Project Management; there are many similar components of Software Development Management. Some substantial components of Software Development would be –
• Customer Requirement
• Time Management
• Quality Control
• Quality Assurance
• Task Management
Covering these stages of Software Development Lifecycle following is the listing of some articles/ blogs for the purpose:
An extra mile of testing effort spent at initial level saves lot of efforts at a later stage. Minor hiccups passed over to customer too sometimes create big issues depending on their frequency and volume of occurrence.
Imagine a small fly in the sweet dish being taken by a customer after an n-course meal will create a big havoc for any good restaurant. It is different if customer acts as blind and ignores a small piece of hair found in the meal thinking that his own hair from head might have fallen in the dish while having his meal.
Similarly a user sometimes ignores a minor error encountered while using an application thinking it might have occurred due to lack of knowledge about the usage of product. User might think during initial phases of product usage that probably the problem might have occurred due to his non adherence to proper steps following.
A business comprises of different software. These software applications comprise of two business streams – business critical application and business supporting application. Usually business critical applications cover ERP like main stream application. Business support applications may comprise of legacy applications or side stream applications running standalone or interfaced with mainline business application.
The emphasis on level and type of testing solely depends on the nature of software under the scope of testing. All software cannot be put under the same frame of testing. It all depends on coding structure, interface, web based architecture or similar parameters that define the test strategy of a software product.
Testing during development, and at the end of product built too vary as per norms. The last testing phase prior to product release has to be extensive, elaborative and exhaustive in nature.
Tester is not the part of package of a team going for software product implementation. Probably that is wrong on part of project manager if he decided to send a technical team member along with implementation team with a sanction of development and requirement changes onsite.
Well actually there are two scenarios of catering to changes and development onsite. One way is all changes required are documented well and signed off, sent back to back office support technical team for development with a stipulated timeframe (which is definitely in hours or not more than 2-5 working days). This exercise of development includes testing in a proper manner.
Another scenario though would be less time consuming but more risky as developer(s) are there with implementation team but no tester(s). In this case the development (changes) part will be done instantly and onsite itself but the risk factor or vulnerability is higher as testing (if it has taken place) is done on site and that too by non professional testers. The product may behave ok in this case in first go and pass through UAT too by users. But in reality such extensions of development always have higher chances of carrying hidden bugs that may expose sooner or later thereby reducing trust factor in product.
I have not seen any implementation without a requirement of changes in the product to be implemented. But it all depends on so far well tested product management at this stage – if the changes take place offsite (back office) with same established way of testing (may be by consuming a little extra time); or catering to it onsite by developer (in a shorter time) with no proper testing.
Support comes after project completion. Project lifecycle but must treat support phase as a component of it. Prior to support the major project phases include – project initiation, requirement collection and freezing (though freezing is not actually freezing till the handover and sign off), product development, testing, implementation, pilot, live, sign offs and handover.
After the successful completion of above phases, implementation team leaves customer location in a typical situation.
That is the time when product is totally in hands of end users who start utilizing their product knowledge acquired so far. The practical phase is not that simple as lot of unexpected surprises start happening during this period. Some of the errors encountered by end users actually are not product errors but arise due to wrong or inappropriate usage of product. That is not unnatural. Since the end user start working on product on their own, it is something like a new player playing in his first match, or a person who has learnt driving afresh is driving on road for the first time all alone.
Support team has to be quite patient giving top priority to ‘voice of customer’. Technically and functionally, support team may know that a wrong complaint is being registered, but it becomes their prime role to guide end user about the right usage of product step by step without hurting his feelings or making him realized as wrong.
On the other hand if support team gets a change request in the already running product, at times, due to time crunch, it becomes important to handover the change developed without appropriate testing done by test team. But in the parallel line of action, the changes in product must be handed over to the test team with a stipulated time frame to ensure that the changes are done appropriately.
SDLC-I: Software requirements – This post talks about Software Requirements. Software requirements itself required a standard process or procedure to be followed and can’t be managed in a haphazard manner. The process must start with an initial discussion which may happen from a distance via any good communication media if client is far from vendor. Once the initial discussion gives comfort to both ends – that is – vendor feels comfortable on a broader scale to provide a solution to the customer and – customer feels comfortable that vendor is capable enough with a outline solution ready to cater to his solution.
A next level of meeting is scheduled only after first level of discussion shows some significant positive outcome. This next level of meeting is better result oriented if takes place at customer’s location. This meeting requires substantial time to be spent to gather customer’s business requirements that need to be catered to in the software application to be provided to customer later as an optimum business solution.
During this detailed meeting that is carried out by vendor’s business functional leaders along with customer’s respective business function leaders remains incomplete if the whole discussion regarding business discussion and business requirement is not documented properly.
Along with documentation, vendor team must collect all forms and formats in printed, handwritten or whatever shape with proper mapping and understanding.
Once the requirement is gathered, documented and finalized must be signed by customer business process heads and thereafter by overall business head of the customer to own the responsibility that whatever has been told and documented is what they require to be built in the software.
I think anybody who is in software industry must be familiar with the complete lifecycle of software. Here is a treat of seven blogs in a row on the same very subject of SDLC – that is software development lifecycle.
Here is a segregated list of my blogs on testing mainly for the purpose of people enthusiast in testing, testers, QA, QC, bug management; and software Quality:
The post ‘Twenty ways to ensure complete coverage of software testing’ can be treated as a checklist for ensuring complete coverage of testing of any software. It talks about some basic fundamental but critical and important steps to take care of for the purpose.
Purpose of testing is not only to ensure reporting of bugs in a proper manner, complete coverage of product vertically and horizontally both, and ensuring that critical bugs are taken care of. Test team must also ensure timely reporting back of bugs fixed from the development team so that they can one more go over the complete product to verify that all bugs have been fixed – properly.
Test team while ensuring fixing of bugs through their verification cycle must also ensure that while re-writing or varying the code, development team has not developed any new bugs during the course of their action.
There could be various ways to ensure complete coverage of product, proper identification and reporting of bug; and validation of bugs fixed etc. depending on level, automation, and methodology adopted but checklist can become handy in any case.
Why Software Developers are not Doctors? was another interesting read to understand the satire behind the simple title line. Software developers are quite famous (and that is not in good sense) for writing a code that is never perfect and bug free. That is why any code written by a developer or programmer has to undergo scrutiny under tester’s microscopic eyes to find out the hidden bugs and thereafter fixing them by developer.
Definitely this whole gimmick of identification of bug, its reporting and then fixing by developer takes time. Not only this, when a developer fixes the bugs, the tester has to retest the code to verify the fixing of bug and identify if there is any new bug encountered due to change in code.
Story does not end here. A small change in code at one place of a software product may have its serious and many places impact if not handled properly. That is why the first wish of any developer from himself is to become a bug free coder which is very rare to find.
The satire very well remarks on this particular nature of developer of not writing a bug free software in first go which implies that if a developer had become a doctor, he would definitely be a failure as each of his patient would never have got cured in first go.
Do we mean to say that whatever a doctor prescribes to a patient need to be examined by another person (doctor-tester) before patient starts taking the medicine?
‘How Software Testing Took Birth’ would be an interesting read if you have not read it earlier. Give it a try to this small article that provides and insight to some very basic fundamental reasons about necessity of testing of software.
There would have been a time many years back when there was no concept of testing altogether. The software would have been produced and given on as is where is basis without any guarantee of its behavior or results produced by it.
Gradually a need would have arisen from both ends – customer and vendor to maintain a decorum, sanctity and reputation of software producer and software being produced.
Probablity in early days when software product cocept had started, software development would have been more of an experimental and adventure case rather than a serious business product building concept. And gradually when reliability on software increased, its necessity of providing a neat bug free product also would have arisen.
Each bug in the software costs. The first hidden cost is the developers time that could have gone in a neat code, except goes into embedding a bug in his code. This all happens unnoticingly. No developer intentionaly writes bugful codes. It happens inherently due to a set of fixed development creiteria or pattern in developers. A blog about ”A Linear Approach of Cost Estimation of Bug Fixing for Various Software Projects” focuses on need of estimating or rather evaluating overall cost of a bug right from its insertion to identificaiton to fixing to verification.
When a developer fixes a bug there are some chances of not fixing it completely, or generating another bug while fixing an existing bug. Similarly a tester while testing a software also has a chance of leaving a bug unnoticed, or identifying and reporting a bug wrongly. In either case it it the product and project that suffers most. A tester needs to be extra careful while testing whereas a developers needs to be equally careful while writing code. While verifying a bug fixed reported by development team, the tester need to ensure not only the reported bug fixed but also ensure that no other negative impact has arisen.
For that purpose a tester needs to adopt another approcah discussed in my earlier blog titled – ”Progressive Software Testing Approach by acquiring Soft Skills – Step by Step” in which an emphasis on certain essential soft skills has been highlighted that becomes catalyst to software development and testing process.
When I started blogging on ITKnowledgeExchange.com under the blog title ” Quality Assurance and Project Management” in the middle of the year 2008, I wanted to pour out all my experience on Project Management, Quality Assurance, Quality Control, Team Management and other related subjects.
My foremost pain was and still is the way developers develop a code or write a program. Though all developer are not alike, but one thing consistently I found was the way coding is done, it always leave a scope of bugs. And based on that pain my first blog was titled – “What stops a Good Programmer from being a Good Tester – 8 Reasons”. I wanted to highlight the top disciplines in absence of which a developer always leaves a scope of gaps in his coding.
Then came the next post regarding how a tester should work to get the best out of his scope of work. Some top reasons were discussed in my next post named as – “Knock! Knock! – it is tester here!”.
Tester in his own capacity is helpless as far as product neatness is concerned. To know about what exaclty is required to be tested, a tester requires a good knowledge of business requirements based on which development team has built the product. Testers basic purpose in my opinion is to ensure that there is no gap between the business requirements and the product being delivered, and use comfort in using the product.
There is no doubt that if tester has lesser or equal depth of knowledge as develper about business and product, he is also prone to leave gaps in two ways – either by testing the product wrongly based on wrong business assumptions, or by reporitng the actual business scenario insufficiently to the development team.
Usually it is not the developer’s fault if he build bug in addition to writing code for any application, The seriousness of application may vary from business point of view, the way that application is going to cater to the business management. Even a game code for a gaming company could be as serious as a banking application code for a financial institute.
In both the cases – game or finance – bug can’t be tolerated. First instance to check the bug is the way of acceptance or acknowledgement of bug by project manager, development manager, and management team. High level of acceptance give higher leverage to developer to chip in bugs during code writing. A developer by checking on his some of the qualities may become a good tester of his own code. And if that happens, the developer in turn will always become a better developer.
Second instance of check and control is the leverage given to project team to keep tester far away from product. A tester though needs to knock development team’s door repeatedly for certain set of requirements to perform his duty properly and also to justify his task of testing the product in terms of product release.
Project Team should have a way of measurement of time and money for each of the bug reported. If each bug fixing is measured from its evolution, reporting, fixing and validating cycle, an objective approach can certainly ascertain a value to these efforts.
Every Bug has a cost to fix and for that sake to report too. It takes someone’s time (tester’s) to find out the bug in a software product. It takes another piece of time to write and report it to development team who in turn is responsible to fix the bug.
Fixing of Bug again takes time as developer needs time to understand what wrong has been built or what scrap is to be removed and in its place what useful code is to be written and kept. There are various approaches to calculate the cost involved in this complete cycle.
The bug reporting and removal cycle does not stop with reporting by tester and fixing by developer. The rectified piece of code goes back to tester again to verify and confirm that it has been fixed. Tester has further to investigate and confirm that while fixing of this bug, developer has not created any other bug that impacts application functionality or usability.
An approach known as Linear Approach of Cost Estimation of Bug Fixing for Various Software Projects can help project team in ascertaining the preposition of accepting a leverage of developing bugs in software in place of a neat product.
There are seven instances when a tester need to knock to Project Manager for certain requirements or help from him without which his role as a tester cannot move further. Any lack in those assistance to tester will certainly mean lack in delivery of right product/ bug free product.
For isntance a tester certainly require business requirements document to understand what initally has been asked by business owner to build in the software viz a viz what actually the product has been built by development team.
Around three years back I wrote a post relevant to the same subject I have discucced above primarily talking about the crux of the requirements by a tester to justify his work related to a software project. The article was titled as ”Knock! Knock! – It IS Tester Here!”
There are good programmers and there are good testers. But in 99% of cases good programmers are not good testers and in 100% of cases good testers are not good programmers. Whats exactly would stop a good programmer to be a good tester. Three years back I wrote a post on this titled ”What stops a Good Programmer from being a Good Tester – 8 Reasons.
That was my first post on ITKnowledgeExchange.com. The topic and contents of the article came right from my heart as this pain I was facing for many years during my exprience as a developer in my early years and then later after becoming the head of QA/QC.
The post talks about eight activities if done by a developer can turn him into an as good tester as a developer he or she is.
Success of a project depends on many factors. To name a few would be Team composition, team size, project management methodology, benchmarking, optimization, time management, resource management, monitoring and so on. The list may go endless. Besides all mentioned above, some simple techniques that are easy to adopt and adhere to can change the life of a project manager or for that sake any of the team members who adopt these techniques.
1. Take Lead: Move forward to adopt a tougher task rather than waiting for someone else to grab it and hoping for a simpler task to come into your pocket. Sometimes reverse may happen. And moreover without moving forward you will never be able to bring yourself into limelight.
2. Grow Taller: With each problem and solution, grow your inner strength to handle such situations in a better way in future. Fighting with same situation again and again in same manner is not at all a wise decision. Find out a better solution every time you face a problem.
3. Learn From Mistakes: Who says I work and never make a mistake. Only one person can never make a mistake – who never works. Anyone who works has always a chance to make a mistake. Best thing is to keep learning from your mistakes. Failures and mistakes are the best teachers. Keep one thing intact in mind – never repeat a mistake.
4. Share Onus: You might be smart to handle any situation but in a team never try to take credit alone for any win. Do it only if you want to grow alone and keep all others in team as still as they are. A small piece of appreciation and motivation can do wonders. Try it and see miracles happening.