What is Postmortem Meeting?

According to the dictionary, postmortem means an examination of a body after death to determine the cause of death or the character and extent of changes produced by disease. It can also be defined as a critical examination, evaluation, or assessment of someone or something past. Based on this definition, we can define postmortem as an examination of the project after it is complete to determine the cause of problems and delays, and ways of avoiding them in the future.

  • Postmortem of the project is the last step performed to evaluate the effectiveness of the documentation process. This basically means that the project has to be looked at in detail for the following information to do away with any possible mistakes in the future:

                        – Evaluate what worked and what did not.
                        – Identify the problem areas and processes.
                        –  Identify areas and/or processes that worked well.
                        – Look for a working solution that can be applied to the future projects.

  • It is a case study that provides practical help in understanding why problems or mistakes occur and how they can be avoided. Documenting your problems and solutions is the best way to develop best practices.
  • It is the comparison of actual performance with your plan. You can’t afford to repeat the mistakes and encounter the same problems project after project.
  • It is a process of looking at the current process, identifying what went wrong, and situations that weren’t working right. You can then analyze the situation, check how such problems and situations can be prevented in the future projects and come up with appropriate alternate solutions.
  • It is a practical method that helps you capture experience and collect suggestions for improvement from completed projects. It is also about identifying the positive and strong aspects of the projects and applying it to the future projects.

There is a famous quote by George Santayana, “Those who do not remember the past are condemned to repeat it.”

The same applies here as well. In short, the postmortem of a project actually allows you to learn from your mistakes. After any documentation project (big or small), you should step back and look at all the aspects of the documen the good, the bad, and the ugly. This will give you a proper direction to move ahead. So postmortem is not just about looking back, but is about looking back so that you can move ahead with ease and double confidence.

It is important to look back at what went right and what went wrong during a project and to share this information with others in the group/team. Continue following the procedures which worked well and try to nd solution and/or work arounds for problematic areas. Postmortem is the comparison of actual performance with your plan. It provides the opportunity for us to learn how to proceed with future documentation in a better way.

Why Have a Postmortem

When a project goes sour, it is natural to have bruised egos, and low levels of self confidence. In such a situation, the writer is blamed for deviating from the required quality or the schedule. There might be a person or persons at the point where something went wrong, but anyone in the position would have made the same decision, or failed in the analysis. It is the ill fate of the person(s) who happened to be there at that point of time. Most of these problems can be eliminated easily by improving the process.

In such a situation, you may desperately want to put the bad experience behind you and move on. Having such a meetings will help you and the project members discuss the experiences openly you can review what went wrong and what went right. You can find solutions to the problems and apply the lessons learned to the future projects.

If the projects should start with a kicko meeting, it is but natural that it should wrap up with a postmortem meeting. Having a postmortem meeting after every single project will help you gain more value out of the experiences. It improves the functioning for the next project. Hence postmortem has to be an integral part of the documentation process. It will help you collect valuable information about the problems you faced and the project in general.

Goals of a Postmortem Meeting

The project is over and is probably alive as a huge success and the writers involved are either excited about  the success and the positive outcome of their efforts or dazed at the negative results inspite of the hard work and effort they put in. The latter might be nursing a bruised ego. Is it necessary to talk of postmortem? Sure it is, because this is an extremely productive method of improving your documentation practices. The goals of the postmortem meeting is to:

  • Provide an environment that supports constructive criticism.
  •  Identify the loopholes in the project.
  • Encourage improvement in procedures and processes.
  • Encourage the project members (writers, developers, engineers, SMEs, managers, QA personnel, etc.) to share lessons learned the hard way.
  • Help to draw meaningful conclusions from the results of the previous projects.
  • Help you learn from your successes and failures.
  • Provide a process that allows you to identify some activities as best policies and adapt them in the future projects.
  • Support easy collection and archival of information.

Postmortem is intended to be an exercise which will help you realize more about how you work and help you make decisions about how to work more e ectively. You can identify some of the activities or processes that worked well and you can continue with, and problematic areas that you can avoid in the future.

Advertisements

Postmortem Meeting: Guidelines (Part II)

11. Did You Manage the Change

Documentation by default is prone to changes. Here, we discuss the unexpected changes:

  • Did unanticipated changes occur in the project?
  • Did you encounter any problem that you had not forseen or taken into account?
  • How did you respond to such problems?
  • Did you have a risk management system in place?
  • Did you have an alternative method to do certain tasks?
  • Did the documentation su er from excessive change of features of the product?

12. What Went Right?

Having dealt with the wrongs, problems, and errors, it is time to deal with the rights.

  • What went right with your project?
  • What are the areas that went on as you had planned and/or anticipated?
  • Where did you beat your estimates?
  • Did the document turn out well despite all the problems that you encountered?
  • Problems for which you had alternative approaches or appropriate solutions.

13. Focus on the Facts

The meeting should not discuss personality or mistake made by any particular participant. It should address the outcome of the project, suggestion for changes to the processes, and alternative methods to perform certain activities. People often react to situations in di erent ways. Different interpretations may cause hard feelings and bruised ego. Hence focus on project related facts and don’t blame individuals.

Wrong: This mistake happened because Ram did not perform the XYZ task.

Better: We would not have made this mistake it we performed the XYZ task.

Note here that the blame on we, not Ram. However at a later stage, the documentation manager or the team leader should talk to Ram regarding this problem in a personal meeting.

14. Create a Report

For maximum benefits, compile the lessons learned from your meeting and create a postmortem report. The report can include the following information:

  • The project information (overview of the project, estimated resources, tools, project schedules, milestones, effort estimates, etc.).
  • Differences in the initial plan and the final plan.
  • What went wrong and how it could have been avoided.
  • Anything that went wrong, but was corrected and taken care of on time.
  • Recommendations for implementing the lessons learned.
  • Any change in the existing process that will be helpful.
  • Alternative approaches of doing certain tasks.

15. List the Lessons Learned

After analyzing the projects, make a list of lessons you learned form the project. For this ask a few questions:

  • What did you learn from those mistakes?
  • Did you nd alternative methods to perform these tasks?
  • Did you find solutions to the problem you had?
  • Where can you apply these solutions and alternate approaches to future projects?
  • Is there any specific factor that you have to change in the process to make the project work better?

The answers to these questions will be the lessons you have learned while working on the entire documentation process.

16. Don’t Ask Demoralizing Questions

The success of a postmortem depends on the manner it is handled. Asking for information in the appropriate way minimizes the risk of blaming or demoralizing the team members. So, frame the questions appropriately.

Wrong: Rita, how did this happen?

Better: How did this happen? How can we avoid such a mistake?

In this manner the managers can give the the writer who made the mistake an opportunity to speak up, share the problems and issues faced, and explain the situation in which it happened. It is a healthy process if the writers are able to self identify the mistakes and own up rather than others pointing ngers at them.

17. Rephrase the Answers Accordingly

When participants in the meeting describe the facts related to problems, those answerscould blame other team members. These answers can be rephrased to communicate the same thing in a better manner.

Wrong: You said you were too busy with your project and could not concentrate on the edits.

Better: We must make the editing a formalized process. It might reduce the possibilities of errors!

This response suggests a solution to the actual problem, without targeting at a particular person. It also informs the writer in a very mild way to take peer-edits seriously. If need be, the manager or the project manager can have a formal talk with the concerned writer on a one-to-one basis.

18. Don’t Take Comments Personally

There can be two outcomes (good or bad) of any project you handle. Similarly, there are two ways you can react at the postmortem meeting. Whatever happens, do not let it a affect you deeply. If any of the team members takes any comment personally, discontinue the meeting until they can handle it in a positive manner.

  • If things go well, you should feel pleased that you have done a good job, but let your feet be firm on the ground. Try to do better the next time.Remember, you had the support of the team members who helped you do your work in a better way by giving you the right advice, by helping you with tools, by informally editing your work, by helping you to clear some issues, and by sharing your workload.
  • If things don’t go well, take it to heart just enough to make you a stronger person. Try to learn from your mistakes and try harder not to repeat them the next time (that is, you should try to avoid those mistakes). If you take it to heart, you will suffer lowered performance, lack of trust, bitterness, betrayal, and a lowered self-esteem.

19. Create Action Items

The postmortem meeting will not be of any use if you are not able to define some core action items. These action items should address the key lessons from the project. For each action item, clearly define an owner and time-line for completion. You can add statements as shown in the following table:

 
 

Holding a postmortem will only be successful if you are prepared, follow a clear agenda, and execute the action items resulting from the meeting.

20. Act on the Conclusions

Turn the knowledge you have collected into action plans and try to incorporate it into your project processes and methodologies. It is a productive way of closing a project because you actually gain enriching experience. Don’t get the e ort in getting people together, documenting experiences, creating action items, and a project postmortem report go wasted by forgetting to act on the conclusions of the report.

An action plan that doesn’t lead to concrete actions is useless.

Postmortem Meetings: Guidelines (Part 1)

Postmortem is touchy issue, but if handled well, it is an enriching process as you can discuss and document all the personal and professional growth you have experienced during the project. You can have a postmortem meeting that improves how you and your team manage projects, or you can have a meeting that demotivates and demoralizes you. The result depends entirely on the spirit with which you take it.

Take it in the right spirits, and you emerge out as a better and seasoned writer. This will help your from repeating the mistakes that can be avoided. This section describes what to do during the postmortem meeting so that it will help you to get the most out of this process. It also describes the guidelines for conducting productive meetings.

1. Don’t Delay the Meeting

The best time to conduct a postmortem is about a week or two after a product is released. This allows you to regain your thoughts good, bad, and ugly about the project without forgetting the details. It gives you enough time to think back and collect your thoughts.

The right time to have such a meeting is when the successes, problems, and mistakes are still fresh in mind. It is the ideal time to discuss what went right and what went wrong. You will be able to see the project as a whole, rather than focusing on the most recent activities of the project (which is fresh in mind).

2. Involve All Contributors

Involve all the contributers of the project in this meeting.

  • Collective meeting: This should involve all the contributers from the various teams (development, testing, documentation, and support engineers, etc.). This could be a generic meeting where you discuss the entire process of the SDLC and the DDL.
  • Team meeting: You also have to arrange a separate project review meeting with everybody in the documentation team who were involved in the project (writers, editor, team/project leader, and documentation manager) to reflect on the project experience.
  • This will give you an opportunity to discuss the documentation specific problems, issues, process, and suggestions for changes.

In either case, note down all the problematic areas and solicit ideas for improving or changing them in the future projects.

4. Use Review Forms

Most of the organizations use a project review questionnaire, which includes a 1-10 rating system to quantify subjective feedback. It contains questions for specific areas that might need improvement and use a comments section for open-ended feedback. A series of postmortem can ultimately evolve into a valuable project review form and use it to record your hard-earned wisdom. Later, a consolidated report should be put up for every one to see, read, and use.

5. Have a Clear Agenda

A planned meeting will help in including all the areas of concerns you may want to discuss and you can get the most out of the postmortem meeting. Certain factors you can focus on while creating an agenda are:

      • Project planning.
      • The processes followed by the different teams.
      • Communication between the team members and between different teams.
      • Clarity of roles within and outside the team.

Project Planning and Process

Look at the success or failure of the project plan, identi ed risks, and the schedules.

  • Were you able to accurately estimate the time required for tasks?
  • Did you coordinate the activities and tasks well?
  • Did you follow the sequence of the tasks effectively?
  • Did you come to a clear consensus as to which tasks had the highest priority?
  • What is the main reason for not meeting the deadline?
  • Were the risk factors taken into consideration during the planning phase? 

Communication

 Examine how well the project members communicated with each other.

  • Were the goals for the project clear to all the teams?
  • Were team members accessible to each other to help answer questions?
  • Did the team come to consensus about the decisions impacting the document?
  • Did the group respect the expertise of the team members and use them productively without disturbing them?
  • Did any team members have to wait for another team member to complete a task?
  • Were there any issues in communicating with colleagues outside the product team?
  • Were you kept in the loop regarding the changes to the product?
  • Was the communication regarding schedules clear?

 Clarity of Roles

 Explore how well roles were defined within the team and outside the team as well.

  •  Were roles within the team clear?
  • Was it clear who had decision-making power at every stage of the project?
  • Were the roles of the other team members known to you?
  • Were the priorities set for the project clear to you?
  • Did the members perform the functions necessary for the success of the project?

5. Don’t Look For Scapegoats

As a rule conduct positive and constructive meetings; do not look out for scapegoats.Postmortem meetings must be honest and should have an open communication. If you have any issues, raise them during the meeting rather than crib about it later. If a project has been diffcult or unsuccessful, expect some emotional venting. However, channelizing that in a constructive direction will benefit you and the team.

But, managers will have to confront non-performers. They will have to discuss it with the specific team member on a one-to-one basis regarding what went wrong and why, and areas for improvement.

6. Discuss What You Wanted to Achieve

Come prepared with your notes and observations for the meeting. Begin the review meetings by refreshing everyone on what you all initially thought the project to be and how you thought things would turn out. It would be helpful to include a brief overview of the project an estimated budget, resources, tools, project schedules (start and finish dates), milestones, and effort estimates.

Then, compare that information with what actually happened with the project. For example, you can compare the time frame and resources allotted to the project in the beginning (assuming ideal conditions) and the time and resources it actually took to complete the project.

7. Review Performance of Team Members

The postmortem meetings (when restricted to specific teams) can also act as performance reviews, because it happens right after the project. This will help you:

  • Focus on the skills that have to be improved or developed.
  • Focus on improving project strategies.
  • Understand the concept of self-review accurately.
  • Assess and improve performances.
  • Make changes to the way you do certain things to make the work process more effective.

The review should be done on a personal basis, where in managers can confront the writers who were at fault and tell them where they were wrong and why. Writers have to look at this as a learning process and learn to take such feedback gracefully.

8. What Went Wrong?

Focus on things that turned out worse than expected, especially the unexpected problems that crept in and took a wild turn. Also focus on problematic areas which you could control. Compile a list of the shortcomings and what went wrong with the project:

  • Were the problems anticipated?
  • Could you have avoided the problem?
  • What were the problems and diffculties that you encountered?
  • How well did you adhere to processes?
  • How accurate were your original estimates?
  • Did you deviate from the original estimates of the plan? If yes, why?
  • Where there any drastic changes in the plan?
  • What kinds of mistakes did you make?
  • What problems were unexpected, but solvable?
  • What issues were unexpected and extremely problematic?
  • Did the assumptions prove incorrect? Which ones did and which ones did not?
  • Were any targets missed?

Identify each and every problem, however small, insigni cant, and irrelevant it might seem to be. Try to nd answers for the the questions that arise with these questions which? why?, how? The answers will eventually help you improve.

9. Identify the Reasons

After identifying the problems, try to identify the reasons for those problem and for the change in the original plans, schedules, or processes. Is it because:

  • The plan was not accurate? or
  • The code changed very often? or
  • You did not receive information on time? or
  • The change in the development schedule? or
  • You were unaware of the last minute changes.

10.  Review the Risk Plans

Analyze the problems and issues faced during the project. More importantly, analyze and discuss the approach taken to come out of it:

  • Did you take risks or did you play it safe?
  • Did you encounter any problems or unpredicted risks?
  • Did you resolve them?
  • If yes, how did you do that?
  • If you did not, why did you not resolve them?

Pay particular attention to how you would change your approach for the next project. The approach should be what should I do in such a situation? Try to make a list of all the aspects that you should avoid that would create problems or hinder the flow of work. Also make a list of possible solutions to the anticipated problems.

Myths About Quality of Documents

There are several myths regarding the quality of documentation. Here, we will discuss a few common myths.

Myth 1: Quality is an Editorial Function

Quality is not just an editorial task. Writers should understand that the only way to improve quality is to prevent introduction of errors instead of xing them. Try to produce quality drafts, with as fewer editorial and technical errors as you possibly can. For this, you should be able to de ne and measure the quality of the document. This can be done by determining company-specific standards, styles, processes, and checklists that have to be rigidly implemented for all the documents.
 
Fact: Quality has to be taken into account in all the stages of the documentation process. 

Myth 2: Quality is Applied at the End of a Project

Technical writing is a meticulous process: gathering information, structuring information, writing, rewriting, reviewing, editing, quality checking, and production. Some of the tasks may have to be done a number of times. Letting reviewers nd mistakes in a document during the reviewing phase. It makes the entire review and rewriting phase a time consuming process. It also makes them form a negative opinion about the quality of the work produced by you.

Try to improve the quality of the document by improving the quality of the input i.e., by preventing the introduction of errors in documentation. For this, quality must be defined and then designed into the document, not evaluated only at the end of the writing phase. To achieve quality and hence customer satisfaction, you have to follow certain styles, formats, and processes to help you work in a more professional manner.

Don’t follow them mechanically, follow them to improve as a writer. This will help to produce documents that are usable and have a high level of quality.

Fact: Quality must be designed into a project, not evaluated only at the end. 

Myth 3: Writers are Responsible for Testing Documentation

Most of the organizations feel there is no need for testing documentation and justify that it is the writer’s responsibility to write an error free and quality document. According to them these aspects should be considered during the writing phase.

They feel that the edits and reviews take care of errors if any and hence there is no need for testing the document. For them, the idea of sparing time to test the documentation seem to be absolutely ridiculous, especially, when there is barely enough time to test the software/product. This usually happens in the following cases:

    • When the decisions of the documentation team is taken by a person who does not know about the technical writing concepts and issues.
    • The persons to whom the documentation manager reports to does not understand the requirements of the testing the documentation.
Fact: Writers are responsible for creating an error free document, but the QA and/or support engineers are responsible for performing the QA of the documents.
 
Myth 4: Only bad writers use standards and guidelines
 
Some technical writers feel that standards, guidelines and checklists are not for them because they are good writers. I remember an instance, wherein a trainee writer declared that she completely disagreed with the measures that are being put forward for quality control (using checklists, guidelines, etc.).

According to her, a system is no substitute for common sense and hence putting a system into place was useless. Now, wouldn’t that mean that all the technical writers around the globe are useless, because not only do they use various quality control systems for documentation, but recommend them as well. This shows how good some writers think themselves to be, but also shows how ignorant they are. What they need to understand is, using guidelines and checklists does  not question their writing skills.

    • It is a proven way of reducing errors and improving the quality of the documents
    • It helps in maintaining consistency in the documentation when multiple writers work on a single project.
    • It avoids unwanted discussions and arguments in deciding what was agreed upon sometime back.

If the writers themselves regard standards and guidelines as useless, we should not blame the others for doing so. Documentation standards is actually a formalized database of the decisions about quality related standard style, language, terminology, document structure, content, and format. Some of them are incorporated directly into word processor templates (font sizes, margins, page layout, indents, bullet formats, and so on).

Other standards (terminology, acronyms, abbreviations, capitalization of headings, preferred spellings, punctuation, and hyphenation) may need to be documented and used by the writers.

Fact: All the writers irrespective of their experience or position in the organization should make use of standards, guidelines, checklists, and follow quality control methods.

History of Technical Writing

It is extremely diffcult to trace the exact origin of written instructions. It is even more difficult to understand and form a history sheet of technical writing events. Technical writing, as you know is systematic writing of instruction for the users to perform a given task. It is also about documenting information that users can use.

Examples of Ancient Technical Writing

If you do a careful study and research, you will realize that this type of writing reflects in many historical and ancient scripts. So it is true to say that technical writing have been around for centuries. We gave this art of writing a formal name only a few decades ago. Some examples of ancient technical writing are:
  • The Code of Hammurabi written in 1780 BC by King Hammurabi, which describes the laws and punishments for of the ancient Mesopotamian civilization.
  • The Art of War written in 500 BC by Sun Tzu, a Chinese general is the world’s first book on war tactics. The principles taught in this book can be applied to all walks of lives business, sports, management, personal lives, etc. Hence, people have been referring to this book for years, even now!
  • The Kamasutra by sage Vatsyayana, which happens to be the world’s oldest and well-known erotic literature.
  • Darwins Origin of the Species, which discusses the evolution.

Joseph D. Chapline is probably the first technical writer to have written computer related documentation (users instruction manual for the BINAC computer). According to some sources, the early books on technical writing are:

  • A Guide to Technical Writing, T. A. Rickard, 1908
  • The Theory and Practice of Technical Writing, Samuel Chandler Earle, 1911

Samuel Earle is hence considered to be the father of technical writing. The gradual, but the steady growth of the field of electronics, motors, engineering, medicine, pharmaceutical, biomedical, finance, and space industries created a big upsurge in the US. This probably increased the demand for technical writers.

Technical Writing—A Timeline

It is true to say that the advancement of technical writing started with the invention of the computer and it took the form of a upcoming and respected career with the advanced use of computers for creating software and software products.

  • It is believed that the first ever published advertisement for technical writer was in the year 1951.
  • By 1960, degree programs in technical (and scientific writing were offered by many colleges in the US.
  • In the 1980s, the U.S. Department of Justice ruled that technical writing is a profession. Hence, this period can be said to be the golden era of technical communication.
  • In 1988, a Globe and Mail article described that the technical writers emerged in response to the explosion in the number of systems being developed.
  • In the mid 90s, new job opportunities for technical writers were created, thanks to the increase in the ISO 9000 certification requirements. It is true to say that most of the organizations initially started recruiting writers to fulfill the ISO requirements more than the documentation requirements.

There has been an increase in the number of desktop publishing tools and page layout software which are used exclusively for documentation purposes—Interleaf, FrameMaker, PageMaker to name a few!

Should We Add Names of Authors in Technical Documents

Very often, students write to me to explore  technical writing as a career option. Sometimes even experienced writers write to me for guidance, ask me queries, and enquire about processes and tools. Most of the time, I write back to them or even talk to them. But at times, I also refer them to other experienced writers to discuss about tools. It is always best that people with relevent experience talk to them.

One of the queries the writers with 1-2 years experience often ask is: “Shouldn’t the new documents, especially those written from scratch does not contain the name of the writers.” They usually ask this question if they have written a new document. About 90-95% of the time, technical writers only get to update the already existing documents. So, writing a new document is usually a rare experience for the technical writers.

Product documentation contain all the details of the product that are to be shared only with the customers (internal and external) who read the document to understand how to use the product. These are usually shipped with the product or is available for download in various formats: PDF, HTML, XML, or CHM.

On the other hand, marketing documents are to be shared with a wider range of audience to create awareness of the product with the idea of advertising the product or the newly added functionalities of the product.

Note: Things may work differently in different organizations. This is my opinion based on a number of disussions I have had with writers working in various organizations.

What Type of Documents Include Names of Authors?

Documents like white papers, technical papers, marketing documents, etc. may contain the names of the authors usually a subject matter expert (SME). In most of the organizations, these documents are handled by the Marcom (Marketing and Communication) team.

Some organizations create brief documents written by SMEs that represent the author’s perspective on a particular topic. It is usually strategy oriented, describing industry trends and emerging technologies. They are basically marketing documents and so contain the names of the authors.

Though such documents contain the name of the author, personalized email address is not added for communication. Instead, an alias containing the names of the editors (or a few marcom team members) is used. They maintain the list of publications across business units (BUs).

Why Shouldn’t We Include Names of Authors?

As a rule, we don’t add the author’s name to product related documents like the user’s guide, installation guide, API documentation, getting started guide, release notes, and so on.

Organizational reasons:

    • Any work done in an organization is the intellectual property of the organization. So, even a new document/manual written by a technical writer won’t be credited by the name of the writer.
    • Credited authors can show off their work outside the company (even during interviews) since they are the authors.
    • In most of the organizations, all employees sign  the Confidentiality and Intellectual Property Agreement when joining according to which they should not share/trade secrets or company specific information
      • of the previous employer with the company they are joining
      • going-to-be employer (at a later stage) with any other new employer.

Departmental reasons:

    • For product documentation/manuals, the organization is considered the author. That is, the users/audience consider the document(s) to be organization specific rather than author specific.
    • Organizations don’t churn out new documents every release. So, even if we mention the name of the author(s) for a new document, we cannot continue giving the credit to the writer if he/she
      • leaves the organization.
      • works on some other project the next release.
    • Most of the documents are updated release after release. So, neither can we give the credit of the entire document to the person updating it nor is it possible to change the name(s) of the author for each release.
    • Considering the fact that most of the organizations are single sourcing the content and also using content management system, writers owning a document may not even write some modules/sections/subsection. They are usually written by other writers and plugged into the document. In such case, there will be a lengthy list of authors.

Making Time for Your Children: Healthy Bonding

Bonding with your children is of importance for their overall wellbeing—physical, emotional, and psychological. It makes a child feel asense of being loved, independence, and security. It is also mutually benefitting because your child learn about your values, beliefs, and expectations. On the other hand, you learn more about your child. This is the best way to nurture their growth and your relationship.

With so many demands on your time, it is often difficult for you to get together with your children for a family meal, let alone spend some quality time together. However, you can put in some conscious effort and follow some methods to build a natural, healthy, loving, and positive bond with your child:

  • Communicate: Talk to your child as much as possible. Make sure there is plenty of communication between you. You need not make an appointment to sit to talk. You can talk to them as you cook, do the laundry, fold the clothes, do the bed—you just need to figure out when. Even when you are doing these activities, give some attention to them and speak in a loving and caring manner, not as though you are doing them a favour.
  • Undivided attention: Spend quality time with your children. Don’t do any activity when they talk to you. When your child talks to you, sit down with your child, make eye contact, and if possible hold your child tenderly and affectionately. In short, give undivided attention to your children when they try communicating with you.
  • Listen to problems: Listen to your child’s problems. Some of them may seem very trivial to you, but do not laugh or tell them to forget about it. Remember it IS a problem for your child. It will mean a lot to them if you pay attention to it as well. Offer sympathy, support, and offer suggestions to overcome it. Remember, sometimes children take a lot of time and courage to express some of their problems with their parents. Ensure to be there when they want to talk with you. If there is really a problem, you can help them. After a later stage when your kids realize that it was not a problem at all, you can discuss it and laugh about it.
  • Say Yes: Instead of saying, “shall get back to you in 5 minutes”, you should say “shall listen to you for 5 minutes”. As a rule, when your child wants to talk to you, stop doing whatever you are doing—working on laptop, talking on phone, even house hold work. Talk to them—give them the first 5 minutes to judge the seriousness of the matter— if they are just telling you about some routine school activities, you may get back to your household chores where in your concentration is still on what they are saying.

If you think the topic is more important (to them, not to you), give full attention. For all you know it is an attempt where the child has gathered courage to talk to you about some serious issue.  Don’t tell the child to wait and teach them tolerance. It is something the parents need to have in the first place. Many suicides could have been prevented by giving a listening ear to the children at the right time.

  • Be there for them: Provide support (emotional or otherwise) and confidence to your children when they face the ruthless realities of life. Children are often scared and concerned about their future. They repeatedly require assurance and reassurance. If as parents, you cannot provide them support and confidence, who else can? If you case you can’t don’t do anything to help them, don’t do anything to strip off the little confidence they already have in them.
  • Don’t ignore: With our busy lives, instead focusing 100% of our attention on what our child is saying to us, we are often thinking about other things. Some parents often pretend to listen to their kids, or tell to talk while they are busy working on their laptops. Some parents just ignore their child’s attempts to communicate with them.

Somehow, I feel extremely sorry for such parents. In their timeless and egoistic life style, they themselves throttle the enthusiasm and confidence of their own children.  If you don’t give time for your children, they will often start to misbehave. Can you then blame the child for misbehaving? No way!! If parents can’t do their work of parenting, they have no right to find faults in their children. Remember, for a child, negative attention is better than being ignored.

  • Appreciate: Do not expect your childen to behave like adults and do not expect too much from them. This may frustrate you both. If your child gets 70% marks, appreciate it, and motivate him/her to do better.  Also, appreciate the things that your child does best—music, dance, sports, arts, etc. If you feel that your child is really intelligent and can easily get 80% marks, give positive encouragement and support and let them know you are there for them. But don’t push the child too much.
  • Play games:Play games with your children. Play games that your children are interested in and is at their level of ability and understanding. Try to introduce different types of games, instead of playing the same thing all over again.
    • Sometimes play games that will help in their development.
      Example: Scrabble improves vocabulary,  monopoly makes them understand finance related matters, Scotland yard makes them think in a structured manner, pictionary makes them think creatively
    • Sometimes play game just for the heck of it: ludo, snake and ladder, etc.