Broadly a project manager and a project leader seem to carry a similar profile – that is of managing a project and leading it to success in stipulated time period. But if we seek a distinct clarification between the two roles – there comes a demand of a wide gap – as wide as 180 degrees. If one is a creator, another is a builder. If one is a sprinter, another is a marathon runner. If one is a swimmer, another is a flyer. if one is a dreamer, another is a doer. If one is a magician, another is a daredevil.
A manager is supposed to manage his project efficiently. Without taking much risk to avoid deviations from his project plans and milestone deadlines, a project manager would prefer to drive on a smooth road having least speed-breakers and potholes. The best team members, most comfortable deadlines, least cumbersome coding is what he would strive for. With a consistent manner of thinking, a project manager would prefer to strengthen himself and his teams with least changes during his project lifecycle management.
A project leader is supposed to be an innovator. He would be finding out new ways of performing a task rather than following the legacy or orthodox methodologies. He would be a person demonstrating ‘walk the talk’ rather than sitting on a chair and demanding the results. A project leader would not mind if things are not managed very efficiently as long as the desired results are coming upfront. Consistency is not a mandate for a leader. He would rather call for inconsistency and higher risk as he has an expertise to manage those situations.
1. No problem is small.
2. Never look for Shortcuts.
3. Never Jump to Solutions.
4. It is not true that a larger problem will have a higher risk.
5. Seek for value addition in any task you perform.
6. Build a culture around the teams.
7. First See and then Solve the Problem.
8. The gap between the Scope of Work and Scope of Control build up your Risk.
9. Learn Simple but Standardized Problem Solving Methods.
10. After you complete a task spend some time to analyze if it was worth that much time spending on it.
11. Time difference between resolving a problem and figuring out the solution should be minimal.
12. Attempt a solution only when you are clear about it. Hit and Trial method does not pay in most cases.
13. Learn from each problem.
14. Never Repeat a Problem.
15. Share Problems and Solutions.
16. Keep Project related Communication as Structured as possible.
17. Demonstrate others the ways to solve problems.
18. Collaborate People.
19. Don’t spread dirt if you intend to clean the mattress.
20. Still water is more prone to getting Stale.
Regression Testing takes lot hell of time out of overall time provided for testing of a product in any software project. Though it takes longest duration for complete product coverage but somehow or the other lot of things remain untouched or unnoticed during this testing. This could be due to lack of experience of tester, lack of knowledge of product, incomplete or unclear product/ business/ development documents or shortage of time and own management/ customer pressure. Each of these factors marks a big impact on the presumed smooth road of project journey.
Lack of knowledge of the tester could cover up in short form of testing but will definitely leak out in the larger version of testing i.e. regression testing. Many testers worldwide still feel regression testing as most boring and sometimes as non-productive too. Even the development teams feel prolonged time consumed for regression testing by testers as an un-necessary exercise. Due to its long duration many times the momentum and tempo of the testing team goes low. Test automation could be a solution in such situations to shorten the duration of testing and to cover up other shortcomings.
Product knowledge improperly transferred to tester could lead to an erroneous regression testing. Business knowledge transfer by respective business process owners at customer end to the business analysts could lead to another disaster of ambiguous documentation giving a totally wrong direction to product development. Right and appropriate business knowledge transformation is very important.
Larger chunk of total project time allocated to development thereby left with a shorter time-span for testing is responsible for dissatisfied customers.
To sum up the whole gamut, regression testing being the most difficult and crucial phase of project management should be justifiably have a strong backup of development team, customer management, own management, project manager in terms of providing the testers with accurate documents, product knowledge, sufficient time, and above all a good morale support.
Delivery Process: Delivery rate and delivery volume is directly proportional to productivity of various teams. Delivery of product depends on rate of development and testing, delivery of implementation depends on speed of implementation and so on. A process for delivery will focus on streamlining and enhancing productivity at all stages of the project. A collaborative and synchronized productivity will impact more on project delivery rather than focusing on a particular phase of a project. A delivery process also takes care of course of action in case of intermittent team size variance, multi location complexities, technological issues, defect management, test management, time management etc.
Empowerment: Never build an atmosphere of too many restrictions. Discipline and empowerment if imbibed in each team member, require no restrictions and process delaying approvals. Be more delivery oriented rather than restricting your team members to report in time. Flexibility in time can boost teams to deliver speedily.
Governance: Governance and Empowerment can go hand in hand. Governance of process, procedure, methodology, metrics etc. gives you better control over the project.
Optimization: Never compromise in terms of architecture, methods, tools, development platform, project organization, team structure, team sizing, infrastructure and relevant constraints to product a sub-standard product. It is better not to put half hearted efforts than producing a half cooked product.
Traceability: If process, methods, tools, teams and metrics are in place, traceability is important to understand the optimization level of each of them. No traceability means no tracking of output, result, progress etc.
Modernization: Building a product on old version of software or using non-current infrastructure could lead to a no-support scenario in a short run. Technology is changing very fast. Build your product using latest technology, get your teams skilled on them fast, and build product taking care of technology in news and about to come in near future.
Lack of communication, during any Project, forces team members to assume. This happens due to lack of clarification and shortage of time. The product built on assumptions stands nowhere for a useful purpose. Assumptions in turn create confusions and confusions lead to disaster.
A small assumption made at any step of the project may cause a severe negative impact on Project, Product and Managements involved. Data when validated becomes information which forms a basis for building a code. An assumption made in group or by an individual in isolation is bound to result in ambiguities. If for some purpose some assumptions have been made, then it needs to be validated with the help of a complete description and may be if possible, with an example. Example cited with a description give more clarity to the person who has to vet the case.
Assumptions result from not at all/ unclear/ vague communication. The sender and recipient of communication, both are at fault, if the communication loop is not closed properly. Any communication should be done with no pre-conceived notions in mind either by sender while sending it or by receiver at the time of receiving it.
Making assumptions is not bad. We do make assumptions many times a day. But those assumptions do not affect us badly. For example on a crowded station, I may make an assumption while coming back from office that first train might be missed due to heavy crowd. It does not affect me heavily even if I am able to catch first train amidst heavy rush. The stakeholders involved in this case are very limited – me and my family. But when it is a question of a business proposal involving many teams, stakeholders, project, product etc., we cannot work on assumptions. A realistic approach which is more objective and measurable is necessary in such scenario.
Assumptions made during project may cause misunderstandings, conflicts and confusions. Even sometimes an improper/ incomplete communication is the cause for this.
A structured communication process needs to be in place in any project management.
As discussed in previous post Identifying Hiccups During Project Lifecycle the identification of the showstoppers or hiccups in a project is very crucial. An appropriate action on a problem can be taken only if the problem is identified correctly. Otherwise the wrong identification may lead to a wrong analysis and solution thereby changing the direction of the project in an uncontrolled direction.
Some of the most crucial hiccups in a running project could be summed up as below:
1. Collaboration: The teams and stakeholders need to collaborate and be on a single platform to catch the same train. Else they would be travelling in different directions nullifying each other’s distances covered. The net effect in that case could lead to nil or negative.
2. Communication: Formal communication is an integral component of a successful project. Lot of communication going in an informal or unstructured manner could lead to ambiguities and confusions thereby resulting in chaos.
3. Team Building: Each team comprising of right mix of candidates is mandatory to achieve optimum results. Too many cooks may cause lot of conflicts.
4. Leadership: Right mix of empowerment and leadership is very important to run a project.
5. Service: Project development is a mix of service and product delivery. The service part is generally over-looked as the major focus is kept on product. The interruptions in service could lead to derailing of a smoothly running project.
6. Time-Plan: Adherence to time-plan during each stage of project is very crucial. A prolonged delay in project sometimes leads to complete rejection of the project if a need of technology change arises due to delay.
7. Language: Language barrier is a big risk in most of the overseas project. It has to be handled carefully otherwise there would be a big gap in understanding of the words being told and their perception in understanding.
8. Control: A control of down-time in hardware, code, people could lead to a big disaster. Cost also needs to be controlled.
9. Quality: Focus on quality of not only product but process, people, plan and code also plays a major role in project.
10. Integration: Integration of teams, management, stakeholders, code, modules, and product – everything is important.
A project of any nature or size, demands collaborative and systematic approach, from all teams, stakeholders. The teams engaged in various activities and tasks need to tackle hiccups and abruptions arising out of any internal or external turmoil.
The time-bound projects, if not finished in time, may cause issues raised out of business continuity, stakeholders or team member’s exits, technology in use going outdated, or change in management’s outlook causing decision changes.
The emphasis on cost reduction, restricted team size, productivity increase, control on expenses, process enhancement, collaboration optimization, quality improvements etc. are the factors that create pressure on the teams working on the project and in turn may affect the progress of the project. These factors need to be managed tactfully and smartly. If not, then a single pressure may cause aggravated impact on the speed of the project. A systematic approach becomes paramount in such cases to cross the fire safely.
If systems and processes are not in place to manage each and every phase of a project, it leads to panic across the teams. The smooth sailing gets disturbed thereby causing turbulence and unnecessary hindrance. It may call for a re-organization of the project organization in extreme eventuality even. To avoid such extremities, a better decision making approach, improved information structure and clear cut role definition becomes very crucial.
”We simply assume that the way we see things is the way they really are or the way they should be and our attitudes and behaviours grow out of these assumptions.”. This quote is from the author of the famous book “Seven Habits of Highly Effective People”, Stephen Covey.
In terms of software testing and software product, the quote seems to say a lot. The product requirement is understood by an analyst they way he perceives business. The requirements understood may be way different from the requirements told by the customer. The requirements documented by the analyst may have further a wide gap among the business is shown to him, the way he understands, and the way he documents.
Developers and development manager develop the product the way they understand from the document prepared by the analysts. The testers and test manager test the product the way they have understood the business requirements and their understanding of the product built. The test report or bugs report may have different meanings for testers and developers.
So the journey of a concept from business requirement told by customer to business requirement understood by analyst to business requirement documented to business requirement document understood by development team to product developed to business requirement understood by tester and the testers understanding of the product to bugs found out by testers to bugs reported to bugs understood by developers covers so many grey cells that the whole concept may get changed.
Lot of things are assumed during the process of understanding and building of product. The end result could be a shattering shock for a customer or it could be a state-of-the-art product for him. All depends on the way things are perceived, assumed and understood.
The wider is the gap between perception, assumption and understanding, the higher are the chances of the requirements turning into a nightmare as an end result for all.
A Process is the key parameter or metrics to establish the health and status of a project at any stage. Without established process, a method to measure it or its metrics and a continuous effort to re-establish it in terms of improvisation and enhancement, any drive in project management is useless. There are certain key entities to be kept in mind while reviewing any process.
Any process can be improved upon and brought near to ideally the best process. But as such no process is optimum or best; the best of best is only near to it and always has a scope of improvement.
Some key components that should be kept in mind while re-looking into a process for further improvement could be:
1. Identify Weak Areas in a process, be it comprising of parallel or sequential activities. Improvement on those weak areas would certainly help you in achieving better results than being driven out in its current state.
2. Techniques for performing a process or for that sake review purposes should always be scrutinized critically to get better and better results.
3. Focus upon each and every step of the process, and the forces driving those steps. Sometimes looking at a process step with a wider angle helps in finding out better improvement options.
4. Compare the way you define your processes with the similar processes being driven worldwide. It would help you out to find out proven and established methods adopted. Benchmarking helps in getting near to the optimization of a process.
5. Set your goals for better results from any process. And then start finding out the ways to achieve those results. Without a goal setting you are trying to achieve NOTHING.
6. Having a steering committee comprising of relevant key persons for reviewing the processes and getting it enhanced. Everybody’s baby is nobody’s pain.
7. Hire a consultant once you set out your goals to achieve better results and are not able to find out the ways to achieve it. An external expert’s experience in form of advice becomes quite handy to achieve your goals faster than waiting for something to happen on its own.
User Training, Product Demo, UAT all require visit to customer site and a face to face interaction with the end users and customer management. Worldwide scenario is changing now. Organizations in wake of going green and cutting costs prefer alternate ways to avoid travel expenses especially for overseas projects. The development and implementation teams use various approaches to interact with customer groups taking help of latest technologies that have emerged and stabilized now.
Technology these days is not limited to IT only, it has spread its wings even to the non-IT arena. Customers are also quite tech savvy and aware of various technologies available globally to connect different time-zones and geographies. High speed communication, internet, high bandwidth availability, mobile/ wireless technologies, dashboards, web conferences, commercial usage of skype and Web 2.0 etc. have emerged as winners in attaining these goals.
This has lead to innovative approaches to collaborate different teams working on same projects while sitting across different geographic locations, or creating a knowledge sharing platform for vendor-customer collaboration during various stages of a project.
In today’s world, vendor teams can connect to customer teams for the purpose of product demo, trainings and UAT in a very organized and structured manner to make such sessions a big success thereby lowering the project costs and time wasting or non-productive activities.
This has helped not only in meeting tight schedules but has given birth to smart planning and project management.
Let us, for example, take a scenario of changing existing functionality in software, by changing some part of the code, to enhance its performance and applicability. The enhanced or re-designed code is supposed to give better performance thereby giving higher level of user/customer satisfaction in terms of business and application usage.
The process if not defined will change the code, without any traceability, documentation and revision control. On the other hand if the process is well defined, a team will definitely first of all introspect in the business and code in place to work out WHY this change is required.
The change in code should not happen just for the sake of demand of a user, or customer management. It has to be well researched by the coder team in terms of its impact and workload.
The process for such a scenario would be:
1. Segregate the code that needs changes
2. Define the changes required
3. Segregate the other parts of the software where above changes will impact
4. Sort out the changes required in those areas defined in step 3
5. Change the identified code areas
6. Test the changed code in isolation
7. Re-examine the already existing test cases if they need to be extended, changed or altered
8. Perform re-definition of test cases, write new test cases
8. Perform integration testing
9. And so on…
A well defined process is a key performance tool for any project. Keeping in mind that any defined process required a life-long enhancement and improvisation helps project management team and management to strive for excellence in each stage of the project. If processes are undefined the project has highest level of risk of going for a toss at any stage. If processes are defined but are not adhered to, it is as worse case as the prior stage.
If processes are defined and are adhered to, is an ok state but can not be termed as a healthy state for the product, project or organization. The best scenario is that with each step of the project, the relevant process is re-looked into for an improvement.
Organizations having optimum processes defined do not sit idle on the established and polished processes. They still keep pondering and exploring on any possible improvement, variation or re-writing of process to get better results in next go.
Just like a mirror, if not cleaned regularly will not reflect appropriate image of yours, when you stand in front of you, thereby creating worrisome situations, though you may be looking as smart as yesterday.
Let us consider a simple scenario of writing code for a new application for a customer. The process starts with a clear understanding of customer business, key user’s expectations and customer management’s expectation regarding business benefits driven out of this application.
The most important journey begins with capturing all these details as minutely as possible. I always recommend not to map application with the business but map business with the application to get maximum benefits from the deal and make customer happy and satisfied.
Mostly during the requirements capturing, we start zeroing down the nearest application available with us and start moulding our requirement documents keeping in mind to sell that application to customer. That is the biggest mistake we make when we start looking at customer business framed in our existing application. Worse is when we change the direction of business discussion trying moulding it in our product way.
That itself starts leading to a big disaster. This strategy will definitely leave us with less efforts and more margins without customer knowing that we are delivering his business solution to him with an already product in place with us. But usually it will not be able to win the situation after implementation of product when the users and management starts reflecting their frustration. Even if you are paid for such project, it is not going to get you further business or reputation in the market.
On the other hand when you are capturing customer business requirements, never let any of your existing product come into your mind. Record all business requirements as if writing on a blank slate. Afterwards maybe you can find out the gap in an existing product and business requirements and thereby arriving at a conclusion of moulding this existing product with least twists or deliver him a new built product.
At the end of the day the customer should not only pay you but greet you with a smile on his face even after one year of delivery of the product.
1. Showstopper: Product manager always has the perception that the development team wants the progress of work whereas QC or testing team jams the progress. They even try to project in the way of showing development team sitting idle when the product is lying with testing team for finding out bugs in the product. It is reflected as if QC is not an enhancer but showstoppers.
2. Fault Finder: One of the reasons of not giving the product to QC for testing and emphasizing on an in-department testing is that QC or testing team is blamed for unnecessarily finding faults in the product just for the sake of highlighting the lacking in the product whereas it is claimed that the product is built perfectly and working fine.
3. Business Knowledge: One reason of bypassing QC team in Product development lifecycle is putting wrong perception in management’s mind that the testers lack business knowledge. For that sake even sometimes wrong, incomplete or ambiguous business process documents are produced to testing team so that they are not able to understand business properly and the test report lack the crucial business process bug reporting.
4. Process: Excellent process even in place are not adhered to sometimes in wake of fake reasons of lack of time, customer pressure, more time required for development and so on thereby giving short time to test teams for testing the product.
5. Management: Management if do not balance development and quality team equally then the product or the organizations do fall in trouble at a later stage.
There is always a hide and seek game between Product Manager and QC Manager when a product is being built. Project Manager, Management and Customer on one hand stress on complete involvement of testing team during product building. On the other hand product manager keeps playing tricks to bypass testing by a separate team outside his control.
This could be due to a fear factor in him, or lack of confidence on his product. For the sake of not displaying his these weak points to other teams involved in Product Lifecycle, a Product Manager tries presenting his points in other fashion to convince management or other managers for not giving the product for testing or providing the least duration to testers. This satisfies him for the reason that least exhaustive testing by testers will lead to least number of bugs.
But by doing this he also is doing a inappropriate deed for his product and in turn for the organization. Usually Test team is taken as an opposing factor by the product manager. In a way while the development of the product; he gets emotionally attached to his product. Feeling of getting it scrutinized by an outsider (someone not from his team) makes him feel as if someone is intentionally going to find faults in him or his product. He also feels that the higher is the number of bugs,
1. Confidence: The confidence level at any stage of all team members, project manager, QC manager and all other stakeholders right from the beginning starts narrating the direction and overall health of the project. The clarity of requirements, goals, direction etc. all reflects through this handler.
2. Process: Ensure that right processes have been framed, adopted and adhered to in case you want to ensure success at each stage of the project. No process always carries a higher risk of failure that can be mitigated by a right process and methodology in place.
3. Quality: Quality has to be omnipresent throughout the project in all aspects not only in terms of the product or code but also in terms of people, process, methodology, communication, direction, documentation etc. Quality in any case is an asset for any project or organization. Organizations emphasizing more on quality aspect groom much faster compared to others.
4. Control: Control comes through measurement and analysis. Absence analysis and metrics never gives a right control and hence there is always a chance of deviation from the right direction. Control at all levels has to be there including a self-control factor in all team members up to the bottom level.
5. Morale: Keep your team’s morale at the peak all the time. Ensure nothing unproductive work hits any of the members during the project. Keep boosting their tempo and focussed on getting fruitful results at all stages.
Another approach is to build what customer can’t resist. This definitely is a stage higher than the approach mentioned in the above paragraph. The customer requirements are definitely given importance here but the business in-depth knowledge acquisition is much more important prior to building the product.
I am sure companies who deliver what their customer wants also would be striving for a stage where they build what customer can never resist. Definitely all of us know the difference between these two.
The extra edge that is carried by the second approach definitely helps in keeping both categories of companies far apart from each other.
Few months back I read this line somewhere in an article related to project management and product development. The line read as – “We don’t build what our customers want – we build what they can’t resist.”
There are two approaches I could clearly find out from this one line. This line infact summarizes the crux of whole software industry. The two clear segments of software industry with their clearly defined process approach focus either on customer requirement in front of software building or the customer business in front of the software building.
One approach is to build what customer wants. And there are companies who boast about delivering what their customer wants. This definitely would be requiring a number of iterations of changes in the product when the software is introduced to the customer for user acceptance or pilot run. The main focus in such approach remains on the crystal clear customer requirements and building them in the application.
Outsourcing is not an unfamiliar term. We keep doing that in our day to day life for our personal and home needs. The same is done in corporate world. All activities or work can’t be performed by a single person. Similarly all corporate functions may require outsourcing depending on size and need of the organization.
The first and foremost requirements for the outsourced vendor is give a feeling to the customer that they understand customer needs, are capable of performing it and can deliver it in time. So in short the three ingredients that are foremost required in a vendor are knowledge, skill and capability.
These three ingredients are required in right combination and must be transparently visible across. Otherwise retaining these features but not being able to pass across the right message will create bottlenecks for the vendor for acquiring new business.
Ultimately it is the mix of good ethics, standard processes, proven methodology (ies), excellent support and becoming an integral part of the project that makes customer and vendor a successful venture in any project.
5. Benchmark: To rate each of your selection criteria points for each vendor you will be required to benchmark each criteria with the best possible value available across the globe. Against this best possible value for each point your assessment for each vendor will give you a better understanding at the end of assessment exercise the level at which each vendor stands making it easier for you to shortlist or finalize the vendor.
6. SLAs: SLAs are nothing but an agreement to deliver or get a certain level of delivery of service or product and also taking care of addressing to any ambiguities arising at a later stage during the delivery.
7. Delivery: Delivery of software is different to delivery of a refrigerator. Software or part of software outsourced requires continuous involvement of inspection and verification by the customer to ensure that the efforts are being put in the right direction. A later stage engagement will involve higher risk compared to the involvement or engagement right from the beginning.
8. Payment: Payment terms usually are kept in agreement with the delivery of the product. If you are outsourcing a vendor for some part of the project, keep your terms of payment of the product in such a way that some part is paid after your customer signs off the project keeping in mind that if your customer is delaying the sign off but the reason is not associated with the part outsourced, then there is no point in lingering on the payment to your vendor.
9. Support: As you are bound to support your customer your vendor is also bound to support you not only on the part of the project he is outsourced for but also that part’s back and forth integration. This back and forth integration part is something which will be overlapping you and your vendor so you need to be extra careful about this integration part.
10. Contingency Plan: Any development is associated with risks. Identification of risks at the earlier stage gives you more time to plan for risks mitigation. A later discovery of risk creates a panic. A contingency plan gives you a little pain in the beginning of the project to cover up all your later stage pains.
1. Understand Complete Requirements: Customer requirements for the whole project play a very crucial role in building a new product. The whole requirements are shared by many teams for various purposes – viz. development, testing, implementation etc. A foolproof process of documentation of complete requirements is mandatory. The clearer the requirements, easier it is to build a customer favorable product. Unclear or incomplete requirements will cause delay and frustration in the project at both ends.
2. Map Existing Capabilities: All phases of project may not necessarily be possible to carry on with in-house teams. Some of the requirements may need specific skill-sets that might not be available with the existing profile of team members. This calls for either of two possibilities – either recruit relevant skill-set persons or outsource that part of the project to a relevant vendor having team of the required skill-set.
3. Sort Out Jobs for Outsourcing: Going for a fresh process of recruitment for filling the gap of required skill sets for the project might require extra time which may not be permissible by customer. Also the newly recruited persons take some time to settle down and get into the flow of main stream. So it is better to outsource a vendor to deliver such requirements.
4. Define Selection Criteria: Selecting a vendor will never be an easy task as the involvement of an external agency in a project adds another kind of risk to your project. There is n number of assessment criteria before arriving at a conclusion. The selection criteria must be chalked out very clearly before starting the vendor selection process. It could include size of the company, their projects history, customers, employee turnover, growth, management, knowledge base etc.
..to be continued…
5. Harvesting: Plants are ready for harvesting at different timescales. The crop decides the period of harvesting unless some negative impacts the growth. Same is with the people. Some grow fast, some take their own sweet time to grow and establish their achievements.
6. Plough: After harvesting a field needs to be ploughed and seeded. Same is with the people, if they are not given more challenges and extra tasks. Same repetitive tasks make them stagnant. They need continuous flow.
7. Sunlight: Essential for photosynthesis to convert light energy into chemical energy. In terms of people a sunshine, bright and cheerful environment definitely affects the progress and growth of an individual and a project.
8. Air: Air is important for all sections of a plant – the parts below the earth/ soil or the parts upward. A plant placed low natural air availability areas will go isolated and will develop at a lower speed.
9. Manure: All plants may not need it but they always welcome extra nourishment. Though excess of anything goes waste or produce bad results, it is the project manager who has to identify who needs how much motivation, growth and challenges.
10. Nurture: Small plants are not seeded in big pots so are the people. Newcomers or people with less experience in the organization can’t be expected to product big results unless they have a very strong background and outside experience. Otherwise each plan need to be nurtured in present to produce big results in the future.
A gardener is not a simple job, rather is a most tedious job of growing and nurturing nature. The similar job is that of a project manager who has to manage different teams in a project. The team members comprise of different ages, cultures, geographies (sometimes), experiences, backgrounds, qualifications etc. A project manager has to plant, nurture, care, water, grow, safeguard, and manure his team members depending on the stage of the plant (team member).
1. Nursery: All new incomers need to be placed here for providing them special attention, right direction and extra motivational strengths. A separate set of extra organizational cultural, functional and relevant technical training is required to be imbibed for synchronizing newcomers strengths with the organizational goals.
2. Trees: These are the existing team members for quite a few number of years spent in the organization. They have displayed their strengths, acquired new strengths; deliver at par with organizational expectations with least direction and efforts. One thing that goes unnoticed about trees is that trees strive to show their strength and knowledge by delivering fruits… I mean the people falling in this category strive to train people with less experience, share knowledge with juniors thereby helping in growth of others.
3. Plants: These are the most variant category requiring different stimuli depending on the category they fall in. Some may require extra sunlight, some extra water, some prefer to grow in shade, some need extra nutrients. This is the phase of the people where they neither decide for a long term engagement with the organization nor do they plan to leave it soon. It is the phase of bonding and attachment depending on the way they are treated.
4. Watering: Each plan has different water requirements but no plant can survive without water. Except the trees whose roots are well deep enough to get water directly from the earth. These people (trees) are having a deep attachment and bonding with the organization. As and when they feel low (which happens not to frequently), they themselves fetch energy from the management instead of waiting for someone to come and energize them. Rest for all plants a regular watering plan is must in terms of motivation, training, discussions, recursions, informal engagements.
5. Drive with a top down approach: If the project command is shared with one of the top management member of customer end, it gives a catalytic thrust to the project progress and becomes a winning note for the product.
6. Don’t pass a stupid message that successful business application implementation means decrease in Headcount. Rather pass on the message that the underutilized employees who are engaged in manual processes will be converting to more productive work.
7. Manage Change: Generally change is welcomed with a resistance. People want to stay cool with their regular routines with no considerable change. Any application implementation or process enhancement seeks change. It needs to be observed, controlled and managed wisely.
8. Motivate users: A person when felt as important pillar for a change, feels good and motivated. Engage users to their full strength for the change and implementation.
9. Remove junk: Sometimes an automated or fresh designed application process becomes lethargic and boring than the earlier used process (legacy or manual). Sort out, identify the major chunks of junks and convert them to more friendly and optimized user friendly.
10. Kick Process not People: It is the process or methodology that is responsible to make a success more than the people involved in it. Enhance the process of implementation rather than wasting energies on finding out the weak people links.
Sometimes business applications die an unnatural death even if the application is built with state-of-the-art technology fulfilling all relevant business requirements.
The reason of failure does not lie with the application but the people and processes involved in deploying it but unfortunately even in such cases the blame goes to the application and it is the application reputation that suffers.
The two main defaulters in this case who can be held responsible for Project death are Implementors and End Users/ Customer Management. To cope up with this risk and for mitigation let us work out on the following ten tips:
1. Understand business requirements and pain areas: This beautiful application may be lacking some customer specific areas which are not catered or are catered but not satisfactorily in the application. These pain areas need to be addressed as and when they evolve during the UAT or product implementation.
2. Address critical business processes in the application: Sometimes some core critical business process is misunderstood and built wrongly which is recognized at a later stage. It needs to be addressed either way.
3. Take feedback from users: It is very important to make user feel important in the project. One of the way is to ask for their feedback in a formal manner. It not only makes them feel an integral part of the project but also gives them a chance to speak their heart out. In any case the customer management would definitely be acting on their feedback only.
4. Engage employees and Management together: Many a times the project team forgets customer top management and focus entirely on end users without engaging and updating management.
———contd in my next blog.
Project performance encompasses performance of each individual member of each team working for a project. Each team members requires an environment around him that facilitates him to work towards his goals.
The components of an environment for a team member would be the working place, sitting place, workstation, and general administrative facilities.
Many of the components that may not draw immediate attention of focus but actually playing a role in project performance can be defined as below:
2. The communication process in the organization among other team members and management,
3. The comfort of sitting place, tea/coffee breaks, lunch provisioning etc.
4. The desktop/ laptop configuration
5. LAN and internet
6. Even the power supply, lighting in the office and on the seats, drinking water arrangements, rest rooms etc.
All these factors if are favorable towards employees in turn bring lot of favor to the project performance.
Six Sigma is more of common sense and facts based analysis of real data to arrive at an action plan. The basic steps to perform a six sigma project are as below:
2. Set goals to resolve this problem and define the result in terms of financials and timeframe
3. Collect data for a considerable period to analyze
4. Perform statistical analysis based on relevant tools to identify the core issues responsible for the problem
5. Hit on those core issues
6. Identify and measure the gains
Usually it is not easy to run above cycle once and achieve the desired final results. With the help of interim results in different iterations, the final results can be achieved.
To do that a basic six sigma approach can be applied as below:
2. set a goal of fixing top 5 or 10
3. collect relevant data – very important to understand that wrong or incomplete data will draw out wrong results
4. perform SIPOC
5. analyze the top most (say 5 or 10) factors responsible for your problem identified
6. set a goal to kill/mitigate those factors
7. see the results if you are moving near your result goals
8. analyze next top (5 or 10) factors
9. kill them
10. check the distance from your goals
11. and so on…
A lot about the product architecture and design depends on the inputs of business requirements. The team responsible for business study and documentation must understand the severity of risk built in development stages due to wrong or incomplete interpretation of business requirements to be built in the product.
Business requirements documents include both functional and non functional requirements emerging out during the discussions with customer management and key functional managers. All these requirements become integral part of the requirement document that moves to various teams during the different stages of project development.
What if some of the crucial requirements are not captured during the study phase? Or if some of the requirements are not documented in illustrating manner which in return present wrong interpretation to developers and the product development starts moving in wrong direction.
All such ambiguous/ wrong/ incomplete developments lead to a risk of customer/ user dissatisfaction at a later stage depending on how soon or late the product built is exposed to the customer front. Such risks must have a concrete mitigation plan beforehand in order to not to lose confidence, time and reputation.
Project Manager has to have leadership qualities to achieve success in projects. To carry on with these qualities for project management is good for project manager keeping in mind to regularly improvise and enhance these skills.
Another outlook is to inculcate these qualities in the team members down the line. Being a mentor for few of the team members is important to develop future project managers. Also if the team members touch down the inner feelings of project manager about the project, it becomes easier for all to synchronize their energies and move ahead in the same direction together.
Non Standard processes are prone to risk. So is the service. Service is more based on the people than the deliverables. Even the set standards will vary the level of sam service being delivered by different set of persons. Product is easy to judege in regard to quality. It is instantly demonstrable also in case of a product with the help of measurable parameters of testing.
In service it is difficult to set or establish process standards. Even if they are set, if is difficult to measure them to instantly declare if the service is of high quality, or low quality. With the same quality of service it is not possible to make each customer satisfied. The level of satisfaction will depend on lot of non-measurable parameters.
To outsource a vendor for a specific service, there has to be a checklist with parameters defined to ensure the right selection of vendor for that service. The selection cannot merely be based on gut feeling or the verbal commitments of the vendor. Some of the important parameters for selecting a vendor for a service could be:
2. Customer’s Turnover: Check out the vendor’s record (though he will not be easily disclosing it) how many customers have left him during last three years and try finding out the reasons for it.
3. Certifications: There are world class certifications available these days geographically everywhere. Checkout the relevant certifications your prospective vendor has obtained. Check out how old are these certifications, have all recertifications been done, when was the last audit done and see the audit report to find out the observations or non conformitites pointed out by the auditors. Also check out the reputation of the auditing agency.
4. Employee Turnover: Check out his employee turnover. Beware to outsource him for a service if his employee turnover is high.
5. Growth: Check out the financials to find out the rate of growth. If growth is turbulent or incosnsitent, it could be a point of worry. A consistent or atleast sustained growth is good.
Managing and running helpdesk is not an easy task. Once the project is completed after software application has been implemented and sign off has been taken from the customer. a new journey starts in terms of product support. The users who start working on the product entering real business data to product useful informative reports for themselves and their management face problems in the beginning while working on the new application in the organization.
These problems could be due to many reasons like:
2. hidden bugs in the product being exposed while working
Over a period of time helpdesk becomes a good repository of information gathered from application users in terms of complaints, suggestions, feedback etc. One way of working of helpdesk is to record the problem, provide the solution and treat the story as finished.
Another way to look at it is to analyze this data and find out if there are any complaints that are recurring in nature. Definitely there would be certain problems that would be occurring repeatedly. Providing a temporary solution is good as an ad-hoc provision but getting into its depth later and finding out a permanent solution is very important.
Tasks and Constraints go hand in hand. Life is full of tasks. So is a Project. Project Management consists of lot of planning and re-planning. If everything goes smooth as per plan, there is never a need of re-planning. In real-life scenario this doesn’t happen. Constraints are the generators of problems and problems need solutions. For addressing a problem and providing an alternative to suit as a best possible solution creates the need for re-planning.
A continuous analysis of what is happening around in a project is important to understand if everything is moving as per plan or if the deviation from the plan is going to cause a disastrous situation (or something in-between the two extremes).
The two constraints classifications are:
1. Capacity Constraint
2. Quality Constraint
Identification of factors causing any of the above constraint is of prime importance. Sometimes it is easy to perceive these constraints in early stages and make them part of your risk analysis. The mitigation plan is made accordingly. Sometimes these constraints if not perceived and made as part of risk plan cause trouble when arise at a later stage. If they are encountered at a later stage, it comes as a shock rather than a surprise.
Constraints may arise due to various reasons, some of them could be:
1. Lack of clarity of project goals
2. Lack in project management methodology
3. Non adherence of standard processes
4. ambiguous processes
5. Lack of drive
In a normal scenario testing of a product is done within the organization by the quality/ test team members. Lately as cloud computing came into the picture, a new concept of testing on cloud has emerged, though not many companies have jumped into it.
Testing on cloud carried quite a number of benefits in terms of cost and resources. It is something like “service on demand” or “testing on demand”. The cost of hardware, software, tools, tester etc. is charged on usage basis.
Some of the key benefits that can be drawn from this are:
1. Tool License Costs: You don’t need to invest in tool license. You have varied option of selection of choosing tool of your choice depending on product to be tested. The service provider is supposed to ensure that latest version of the tool is provided. So instead of paying a hefty amount for buying a tool, keeping track of updating it with latest patches and fixes, getting bothered about the new release and then depending on it for all your product range; you just need to pay-as-you-use basis.
2. Infrastructure Costs: To perform testing, to load tool and to provide a substantial hardware/ infrastructure platform in-house; you can go straightaway for the cloud service provider.
3. Flexibility and Wide Range: You have the flexibility of using only when you really require. And you have an option of choosing the right tool for right product.
4. No Setup and Procurement Time Wastage: You can bypass to invest your time in procurement and setup process. straightaway select the cloud vendor, and get the setup already up and running to start testing instantly.
5. Expertise: You don’t need to hire tool experts.
Project Management is involves strategy, plan and intuition. A project may be complex to manage if project targets are not indentified properly. It may be simple to manage if project targets are identified, risks perceived correctly and risk mitigation plan is made a important subset of project.
In a battling ‘software project targets’ situation two major villains that emerge out are lack of time and lack of visibility. It clearly indicates that a revisit and refinement is required in the project management system/ process. The Project management team comprising of all major stakeholders are required to investigate project management practices & procedures and acknowledge the loopholes.
Gaps in project management processes can result in loss of the business to competitors. That is why time investing in building a quality project management practice becomes prime important.
Some important points to take care in that case could be:
2. Manage the entire project cycle from project initiation to project sign-off with involvement of major stakeholders.
3. Monitor the progress with intrinsic insight.
4. Try to identify and nullify time and effort wasting activities.
5. Maintain regular status reports visible to everyone associated with the project.
6. Seek Feedback on project status and performance in every project meeting.
7. Control deadlines.
8. Track expenses and time budget.
Earlier IT organizations used to focus on technology and its synchronization with internal needs. But this focus has steeply shifted to an in depth selection of right technology out of all possible available in the market and its maximum utilization to cater to the end users who in turn use these tools to manage, control and enhance their service to internal and external clients.
This is where Standards come into the picture. Global standards help in meeting internal as well as external customer’s expectations. Standards chosen must be such that they meet today’s and tomorrow’s challenges to cater to the business needs. It should be based most comprehensive and widely accepted framework globally. It should be flexible yet filled with best practices to chalk out your own path to excel in both world’s expectations to help you in delivering the best practices based services.
Like any other large sized product, it has to be implemented in steps. It cannot be done in a single step. A mapping with the existing and future business needs with the best practices available is important for which the needs are to be indentified very clearly and correctly. For any organization, its business needs are unique and hence should be the strategy to adoption of best practices.
The benefit of such an approach is that it helps in ensuring expected level of service with a high level of consistency.
It will also help in achieving highest level of internal and external customer/ employee satisfaction as well as will in lowering in the cost of service thereby increasing business value and reputation.
Project comprises of many functions. Each function’s identification, staging and monitoring is prime during all stages of the project. Function’s progress indicates the progress of overall project. A broken function means an immediate attention. Attention will be possible only if the function is being closely watched or monitored. Else the breakage will go unnoticed and may attract attention at a later stage when something disastrous happens due to this earlier breakage gone unnoticed.
Sometimes a small breakage may evoke and evolve a sleeping volcano to create a major problem.
Function going smooth also indicates no bottlenecks in the project. A broken function means a risk identified that needs to be mitigated.
A smooth closure or finish of a function acts as a catalyst for the next function in the row. A broken function accumulates negative impact for the whole project.
Some broken functions may have chain reaction of generating more broken functions.
Data collected for any purpose is useless in three cases – one, if it is not collected in standardized form, two, if it is being collected just for the sake of collection thereby not doing any analysis and three, if no thought process is gone on analyzed data to improve the situation.
In all the three conditions, the purpose is not being catered to. But let us understand that different organizations in terms of data collection fall in different categories as mentioned above.
The organization falling in first category are just collecting data blindly without any serious thoughts gone into the process. The second category organizations are a little better than the first condition because the data being collected is in organized or structured form but no analysis is being conducted on that data. But in case the organization wakes up and plans to do some analysis – atleast they will have the base data in proper shape.
The third category organizations go upto analysis part but do not draw out sensible conclusions to improve the situation.
But sooner or later all organizations need to fall in the fourth category – that comprises of:
1. Collection of data in proper form
After the completion of a software project, the project closure report or project sign off starts a new experience. The users start practical usage of the product in live scenario. The management starts expecting the useful information in form of reports and screens to manage the business more efficiently. Above all everyone expects more comfort and more confidence.
Though in the initial few months both the users and management may not get completely what they expect. The users comfort will increase gradually as they become more and more conversant with the product in isolation.
This will be a learning stage for them too which will teach them some real lessons that were not covered in training sessions. The problems they encounter might not be technical issues, it might be related to wrong usage of the product. All this gradually evolves and results into a more knowledgeable user.
Management on the other will depend on two factors – the feedback from their key users, and their own experience with the product.
Over a period of time, after these initial struggles, the management, users, and product have to synchronize to get the useful results.
Post implementation support includes customer registering the problems related to the product and the product owner resolving it. There has to be an agreement or contract of service that defines the level of support.
Customer may report about a problem in various manners viz email, web portal, IVR, phone etc. giving too many windows to customer to register a problem, itself becomes a problem for the vendor. Vendor must ensure that any call coming via any media, must go to a central repository. If all calls from a customer are not registered in the database or central repository, the purpose of recording a call will not fetch out any useful results at a later stage.
Vendor will not be able to monitor the calls, keep track of open calls, or maintenance of a proper history of resolutions. At any later stage also if vendor decides to do some analysis, it won’t be possible if the repository contains partial number of calls.
Sometimes vendor wants or doesn’t want, pressure may come from customer end to produce analytical reports, failure of which may cause troubles in further renewal of contract or payments.
Product is understood, developed and implemented. Sign off has been taken, and post implementation report is submitted. All is well so far. What now?
Next leap of journey begins. The product usage, results expectations and problems encounter. Users get into the product on their own, start digging it deeper and deeper to understand it more and gradually get more confident. Problems encountered are being reported to the support contacts and issues are getting closed sooner or later.
But one point is skipped. There are many problems which are repeating every month. Customer reports and gets the solution but the level of confidence is lowering. Customer has started getting annoyed due to this repetition of problems.
Repetition of problems needs to be addressed. It is the most crucial factor and may become skeptical.
Someone needs to look into it and notice the deteriorating health of the product.
If the Project Manager doesn’t know the direction of the wind, he can’t be a good sailor. To drive a project a project manager need to set certain milestones. To make these milestones achievable on a regular basis (weekly, daily, hourly) he needs to break these milestones into tasks and sub tasks. These tasks are assigned to appropriate team members with the mutual consent on deadlines to finish the task.
The deadlines are closely self monitored by the task achievers (programmers, developers, testers,…) to maintain the rhythm and momentum.
At any moment if a task is getting delayed to finish, an alarm is required to be raised so that all members get alert and focused to find out the delaying factors. These factors are then analyzed and overcome with the team effort.
The direction of the wind keeps changing. So should be the priorities and planning of the project manager.
Project performance is the resultant of performance of each and every component of the project. Components of the project means – various team members. These team members are assigned various tasks and sub tasks of the project. The result of these assignments collectively draws out the overall project performance at any moment.
If any of the project tasks is not finished as per plan, the delay will effect the finishing of forthcoming tasks. Project manager has to be a good analyzer, critic and observer to identify the performers delaying the project from its plan. Once identified, the analysis can give the reasons of the delays.
If these reasons are timely identified and addressed to, the delay can be shortened and the performance of the project can be streamlined.
An eagle’s eye is required to identify the performance bottlenecks proactively to act upon to achieve the tasks as per plan.
Every project has a number of milestones. The achievement of each milestone establishes a landmark covered in the project thereby reducing the distance to the final destination. The milestone is divided into a number of tasks which are further divided into sub-tasks. A set of tasks is assigned to a team and the sub tasks associated are distributed among the team members.
Each sub task has two important coordinates. One – the owner who is supposed to perform this sub task and the time required to finish it. Completion of the sub task before the stipulated time is termed as ‘Successful’. Completion of any task/ sub task/ milestone beyond planned time marks it as ‘Delayed’. Non completion of any task marks it as ‘Failed’.
Result of a task or sub task delivers many important hints. It sets the further direction towards other tasks/ sub tasks or milestones. If result is ‘success’ the direction sets towards further tasks. If the result is ‘delayed’, it impacts on other tasks. If the result is ‘failed’ all focus is set on the current task to make it success.
This multidirectional focus on a single task has a propagating impact on further tasks.
1. At times development, requirement freezing gets done side by side and that too at customer location. In that case the product undergoes a lot of changes based on customer feedback on daily basis and finally product gets ready as per development team and customer.
After that it comes to QA for testing.
Is that right?
And how QA’s role differs here as compared to the scenario where customer requirements are freezed, product is developed, QA is done and then it goes for beta release, and final implementation
2. What if requirements are not documented properly and development team is dependant on what is told to them by the person who went to customer site for business study. But this guy has no document signed by customer; in that case if he has understood the business processes wrongly, it gets coded wrongly.
On what basis QA conducts the testing in this case?
No project can be started without estimations. The estimations are to be done about the resources, manpower, team compositions, budgets, releases, development and so on. Estimating software is not an easy task. Production estimations are simpler as compared to service delivery estimations.
More machinery involvement eases your estimations. On the other hand the more human involvement increases your estimation pains. There are more chances of your estimations going haywired when you are totally dependant on man than a machine for delivery to a customer. Machine breakdown can be handled in a more technical and professional manner. But to manage people you need extra skills to manage all kinds of turbulence.
Software project estimation can not be done just once in the beginning and then every thing moves accordingly. It has to be monitored, assessed and re-estimations need to be done from time to time.
Estimation is an art and skill which gets polished with experience and time.
Measurement is important to manage. We manage money in our bank by keeping a track of the credits and debits. The performance and versatility of project management goes in the same manner. There are plans, estimations, targets, budgets, resource crunch and so on in any project.
The ability to achieve the best results crossing all these hurdles is what makes a project manager and project teams successful. One of the most important purposes of measurement is to improve. Improvement is important in all aspects and in all directions. If customer requirements, software development, management goals and customer expectations all gel well and take care of each other, it will result into a win-win situation for all.
Measurement is also termed as Metrics. Project Measurement that way is known as Project Metrics. IT Metrics is the term used to measuring various processes and activities of IT.
Metrics methodology is quite important. Metrics helps in tracking project. It also helps in keeping all informed about the project current state along with increasing the productivity of the different teams working on the project.
Project management is an active stream worldwide. New methodologies and technologies are being produced and introduced from various corners of the world. Some organizations are quite active in optimization of software project management. By optimization we understand the productivity and quality increase. Some of the technologies and methodologies are not as effective as others.
There are certain standard analytical approaches used to evaluate and measure the effectiveness of such technologies or methodologies. Software maintenance is a long phase post project completion that manages the customer and product delivered. The shortfalls in the product delivered may cause a painful experience for the maintenance or the support team.
Every project needs to be managed. Different businesses acquire different methodologies and tools to do it. The level of maturity of the organization decides on the level of methodology or tools in use. It may happen vice versa too. Highly matured tools and world class methodologies may help gain high maturity to the organization.
Business requirements and customer specifications when are met perfectly above 90% in the software built; such software has least chances of failing due to quality or customer acceptance. Definitely the time schedules are always important but such products where business requirements and customer specifications are understood well and built perfectly in the software will require least changes at later stages.
The objectivity of project management is fruitful and worthy in such cases. Success is mostly ensured if such factors are well kept in mind right from the first stage of the project.
It is not easy to capture the complete, accurate and clear customer requirements due to many factors. Some of the prominent factors could be:
Wrong users chosen for prescribing business requirements
Wrong scope defined for Business Analyst
Incapable Business Analyst
No Top management involvement from either/ both sides
Language barrier especially in case of overseas project
These are few of the major reasons but not all. In real scenario sometimes all requirements do not emerge in one go at the initial stage. They evolve along with the discussions, meetings and brainstorming.
In such cases the project goes in iterations with the building of prototype of the ‘so-far’ understood product and its demonstration to the customer for two reasons –
2- to move ahead in terms of requirements and building of product.
If customer requirements and business process are not the top priority during the software development; then the software built will have a very short future and less commercial value. This is because, if the software can not cater to manage or enhance any business, its demand will be very low in the market.
The low demand impacts on the commercial value of the product mostly. Even if a very low priced product is in high demand in the market due to its high business value; an increase in its commercial value will not affect its growing sales. As long the software acts as a strong business tool, its demand keeps increasing.
Rather if we see some quite low value products do well in business profits due to very high volume sales. One way of deriving at the product value is to calculate the number of man months spent on the development of the product. This costing model works where the product is focused on a single customer. Development of the product means the complete development cycle including testing, rework etc.
But sometimes this cost is so high that product can not be tagged with this price. Then the costing model is worked on division of total cost of the product incurred to the estimated number of customers per year. The total cost is planned to be recovered in a three years or five years model.
The purpose of a business seeking software application to cater to a business process or a group of business processes is to optimize the business. The requirements emerge through the key process owners of the business. The requirements analysis and gathering phase is the most crucial of all stages of a software project.
Any software organization which does not understand the gravity of capturing of right set of business requirements in the first go, can never deliver the right product to its customer. If software is built for the sake of building some features and functionalities without understanding the real business requirements; the software can be a good showcase for demonstration purposes but can not be a useful tool for any business.
The business requirements broadly are spelled out by the top management along with the identification of core business process owners in the organization to further explain the requirements upto the micro level. These core business process owners need not necessarily be the top management.
Infact mostly they are not. These are the people who are there with the organization for some considerable amount of time. This is not the only reason for them to qualify to become core business process owner. They must be in the main driver seat. Every department or business process comprises of some people who drive the business process.
If requirements for any business application are not taken seriously, it not only hampers the targets and budgets but also create a deformed product.