There are different kinds of project managers – those who take testers as a threat and thus treat them as foes and those who take testers are friends and hence always welcome them to put hands on the product in pipeline. Neither of the two is a strange factor. Both scenarios are natural and realistic.
If the situation is former, it becomes quite tough for testers to break the ice. It is not the question of just putting your hands on the product but also a good amount of cooperation and alignment is required from the development team. Without understanding business requirements on the basis of which the product in question has been developed, it is impossible to test the product. It is something like deciding to ride on a bicycle without knowing about the destination, road condition and distance to travel. Without knowing about the exact functionality requirements, it is next to impossible to test a product.
But logically, if you see, those project managers who treat testers as a threat lack confidence in themselves, their team and the product developed. Though this might not be true if some amount of probing is done in such cases, but it is the project manager that needs to introspect on such kind of behaviour. It could merely be lack of confidence and knowledge of project manager only that forces them to develop such atmosphere of hide and seek. The development team and product might be well in place! And the project manager would have placed them in a poor situation.
Shall we treat tester as a code destroyer? If on one hand a developer develops a code, a tester always tries to find out the holes in the pot. That is where a conflict on personal level originates when a programmer or coder takes it too personal by getting faults being found out in the code written by him. But internally a coder knows very well that the whole exercise of bug finding by tester is for a good cause that is going to benefit all involved in the chain.
Howsoever a programmer is treated as a constructive builder; he is prone to inherently bring in some bugs in the code. Even if a code is sure about some leakage in the code, he would not regret in falling love with his style of coding. That is where a jealousy begins when the code undergoes post-mortem by testing team. As any human being, we prefer to listen to the praise for our creation rather than somebody criticizing it.
Usually why a coder doesn’t have flair of a tester. Does it mean that tester is a saviour for coder? Tester is able to look at a code through a critic’s angle, and only then is he able to find out the shortcomings in the code. But on the other hand, a tester is supposed to possess a good knowledge of product and business requirements behind the building of that product so as to examine the product in right manner.
Probably coder and tester are made for each other to compliment each others’ efforts.
Still water leads to getting things rotten or stale. Flowing water keeps it fresh and healthy. Nobody
likes a project in a standstill position. It needs to be in a ‘move-on’ condition all the time till it reaches
its final position of successful deployment and sign off. Who does not want their project to finish in
time, successfully and without hiccups? But everyone knows it happens very rarely. What could be the
Why is it that among all kind of plans and monitoring activities a project faces delays, hiccups and
troubles? At a broader level a project team can be divided into following categories – planners,
executioners, monitors and decision makers. All four are very important components of a project. A
right mix and timely action from each of the component makes a larger sized positive impact on the
project and vice versa. Higher mix of planers and lesser count of executioners will lead to good amount
of thinkers but lesser amount of doers. Similarly lack of visibility or presence of decision makers in
a project will lead a project to a standstill. And that is where the stagnation and rottenness begins.
Monitoring gains momentum in the project and lack of it acts as a decelerator.
Actual need of presence of eagle’s eye is very important in a project. Someone has to take that role and lead in the project by smelling, sensing and foreseeing ‘Still Water’. This person must have the power to raise an alarm in time and activate the trigger for taking right action by right members of the team. A
universal sync among prominent team members is a must.
I had some spare time that I planned to invest in watching some useful program on TV. Starting with
channel one, moving on to next channel and trying to figure out how useful the coming program would
be; I reached to the higher limit of double figure digit of channels but ending up to nothing of my taste
so far. By this time I had spent almost 20 minutes while switching over from one channel to another and staying there for a while in trying out to figure out if something good or bad was there.
That is what happens in a project. Project starts, initiation activities are performed, teams are formed,
plans are made, methodology is adopted, project moves, milestones are monitored and delays are
justified. Actually does it move as it should move or things keep slowing down whilst during assumptions of them moving at right pace? Sometimes project owners are not able to catch hold of the things in right time. And by the time they become aware of the situation, probably it already has resulted into cracking of the egg. In this case the egg has not cracked in a natural manner but by mistake, done by someone in the team.
Point is not to zero down on the mistake doer, but to catch hold of the mistake and get it rectified at the earliest. It is never possible to rectify a mistake until it has been identified as a mistake and someone takes charge of it.
After half an hour I realized if I had browsed newspaper page that gives channel wise programs
beforehand, I would have headed to the right channel in right time without wastage of much energy and time.
No project is executed and completed without encountering troubles and hiccups. If that could happen
plans were not required. There were no monitoring, follow ups, alerts, alarms; if the projects were there to run smoothly and end up in time with success all over. Is it people or process that makes a project successful?
The same set of people without a good execution plan in hand and well defined processes to drive the
project, will never be able to make a project successful. Similarly the same set of execution plan and well defined processes in place will never end up in completion of a successful project in all places under all kind of circumstances.
So what is it that makes a project more problematic? Or what makes a project sail smoothly on troubled waters. Is it the people who are real driver of project or is it the well defined charter or project that makes it more successful. Even in presence of both, there are good amount of examples of failed projects even in large establishments. Does it mean that there are some more driving forces than the process and people that can win or lose a project success?
Actually it is very difficult to pin down the exact percentage of various factors that are responsible
for the success of a project. But is it a right mix of management, approach, system, people, process,
methodology, plan and control mechanism that makes it successful.
Did I mention that passion and fire in the belly are other two hidden ingredients that play a major role in the whole journey?
Depending on situation and demand of a project, teams are formed in accordance with the project requirements. Earlier when there was no concept of team it was found that based on tasks assigned to individuals in an organization, small teams used to get evolved automatically since in any kind of task, an individual is bound to seek assistance from internal or external member of the organization depending of the kind of task assigned.
Somehow some knowledgeable person in an organization would have studied the behaviour of different functional verticals when put under higher amount of work stress. A major activity that takes place under such circumstances is delegation of authorities, job allocation and team formation. When time is less and more tasks need to be performed, a best way to cut the long rope short is by removing unnecessary steps of the process which otherwise in normal situations would make a lot of sense and equally justify their existence.
Delegation of authorities and power is a strong tool when there is or are certain amounts of projects that need to be finished in very short duration. Though it does not mean that planning or monitoring is not required or such projects can survive without the two. What it means is that a more accurate and concrete form of planning or monitoring is required in such situations.
Post project is not the closure of a project. It is generally the beginning of the second innings of the project in which end users start using the product in actual and face the real fight. During project implementation phase, the challenge is not much as most of the cycle is done in presence of the functional and technical experts of the implementation team. But what happens when all the team is gone and support is not at a hand’s distance.
It is the stretch which is most painful in fact. No support on seat. Actual data to be done in the product and management expects some real bunch of useful reports. The acid test is for all who work on the product.
But it is during this stage that the ruggedness of product gets introduced or the weakness of the product gets exposed. It is usually this stage that the product is either absorbed in business for a long run or gets discarded even after a big amount spent on it.
You need to build a team for any of your project. None of the sizeable projects can be done by a single person. Building a team is not an easy task, as it involves all kind of right skills in the Project Manager to perform a right kind of permutation and combination to choose perfect match of team members. All team members with same or similar kind of members. Exact sizing need to be done with versatile and variable set of talents so as to build a mix of compliments and supplements kind of people in the team.
Why same kind of team members would not work well. Reason for this could be many but I would like to have opinions from readers.
An unconnected, isolated and purely professional project manager cannot and should not expect a connection between him and his team members on personal grounds. If this doesn’t affect the project manager it could be ok for his sake but as far as business and work is concerned, it is a well proven fact that a personal connect between a manager and subordinates delivers a potentially substantial amount of throughput in work. A project manager with rude attitude among or towards his team members does not do a good job for his project and management.
A personal connect with the organization grows with the help of its employees. After all organization is nothing but a collective and organized group of people. A proper tuning and harmony engages employees more with their organization and with each other in the organization. If this level is attained in the organization, its employee turnover is less than average as per industry standards. It has been seen that it is not the workload that makes people leave an organization but the personal connect with the organization that binds them with the organization in absence of which nobody stays in the organization for long.
Even at the time of appointment these things do matter for a newly introduced employee to make up his or her mind for a long term stay. Many a times interviewing managers do not convey the right message about the culture of their organization and hence increase the probability of losing high potential prospective employees.
You need not have a magic wand in your hand to accelerate your project in terms of financial savings or time saving. Logically if you see, any component of a project, I mean any member of a project, working on project at any level, can contribute in accelerating or pushing his/her project in right direction without coming into highlight or trying to get noticed about it.
Actually if you see, it does not matter to come into limelight to do anything good and considerable that able to enhance your project’s progress. Any breather is always welcome while climbing on a hill. A team working on a project is almost like doing an uphill task and a small dose of oxygen works wonders at that time.
It is not difficult to take a lead in this aspect and provide a breather first to your team members rather than waiting for others to take a lead.
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: