Avoid These Ten Common Resume Writing Mistakes Next Time

Re-publishing the original article published at JobsFeeder.com for the informational purposes of the viewers of my personal blog.

Preparing a winning resume found to be daunting task for many and it needs couple of day’s effort to make it fine-tuned to deliver the correct impression to its audience. Your resume delivers the first impression about yourself to recruiters when assessing whether you are a good fit for their organization or not.

When preparing a resume, it’s easy to make mistakes. Once you make a mistake it’s exceptionally difficult to repair the damage once an employer gets it.

Therefore prevention of following common mistakes found to be critical for your success, whether you’re writing your first resume or revising it for your next job search. Check out these resume guidelines to the most common pitfalls and how you can evade them.

1. Typos and Grammatical Errors

Resume needs to be grammatically impeccable. If it isn’t, recruiters will come in to conclusions about you, like: “This person can’t write,” or “This person obviously doesn’t care.”

In order to avoid these common mistakes, you can use the built in spelling and grammar feature on your word-processing software. Still if you are not convinced with the content, call for a help. Probably a friend of yours could add value to your resume by reviewing it. Else contact a resume fine tuning service such as JobsFeeder.com.

We at JobsFeeder.com offer no cost quick review service for the first comers. If you are happy with the review outcomes, there is a fee based service to convert your resume in to stylish and winning resume.

2. Lack of Specifics

Employers always after what you’ve done and accomplished already. Look in to the following examples;

• I worked for a blue chip fortune 500 company as an Operations Manager.
• I worked at Infosys as an Operations Manager between 2003 and 2005. During the period I recruited, hired, trained and supervised more than 40 employees for the business unit. Grew the annual sales values from $2 million to $ 6 million.

Both of these phrases could describe the same person, but the details and specifics as in example B will more likely attract the employer.

3. Attempting One Size Fits All Approach

Whenever you try to develop a one-size-fits-all kind of a resume to send to all employers, you always end up with something employers will throw in the recycle bin. Employers want you to write a resume specifically for them based on the opportunity. They expect you to clearly show how and why you fit with the announced position in their organization.

4. Highlighting Duties Instead of Accomplishments

It’s easy to make a mistake by simply start listing your job duties on your resume. As an example:

• Attended meetings and recorded minutes.
• Worked as a team member.
• Updated project documents.

Employers, however, don’t pay any attention so much about what you’ve done. Their interest is towards what you’ve accomplished in your job roles. They would be more happy to see statements more like these:

Used a voice recorder to record weekly meeting minutes and compiled them in a Microsoft Word-based file for future organizational reference.

Proposed and developed a company-wide knowledge base to maintain the meeting minutes and any other materials required for continuous development.

Identified a major performance drawback within organizational processes. Worked with the relevant departments to update them over the issue and rectify it to increase the productivity levels.

5. Too Long or Too Short

Regardless of what you may read or hear, there is no real principal resume length. Reason: human beings, who have different favourites and anticipations where resumes are concerned, will be reading it.

That doesn’t mean you should start sending out 200 page log resumes. Generally resume lenghth need to limit yourself to a maximum of two pages. But don’t feel you have to use two pages if one will do. On the contrary, don’t cut the meat out of your resume simply to make it conform to an arbitrary one-page standard.

6. Poorly written Objective

Employers do read what’s on your resume as the objective, but too often they come across with similar objectives, “Seeking a challenging position that offers professional growth.”

Making your objective unique or giving employers something specific and, more importantly, something that focuses on their needs as well as your own. Example: “A challenging entry-level managerial level position that allows me to contribute my skills and experience in company’s retail operations.”

7. No Action Verbs

Avoid using phrases like “responsible for.” Instead of that, use action verbs: “Resolved user questions as part of an IT help desk serving 100,000 doctors, nurses, therapists and the academics.”

8. Leaving Off Important Information

You may be tempted, for example, to eliminate mention of the jobs you’ve taken to earn extra money for your higher education purposes or to cover your college fees. Typically, however, the soft skills you’ve gained from these experiences (e.g., work ethic, time management, teamwork) are more important to employers than you might think.

9. Visually Too Busy

If your resume is wall-to-wall text featuring five different fonts, it will most likely give the employer a headache. So show your resume to several other people before sending it out. Do they find it visually attractive? If what you have is hard on the eyes, revise.

10. Incorrect Contact Information

Double check whether entered phone number, mobile number or the email address is still active. If possible disclose a time to contact over the phone number avoiding your other responsibilities. Make sure to keep your phone switched on during the disclosed hours. In case if you are not available to take the call, ask someone to answer it, disclose the identity and the relationship, explain your unavailability with a reason and collect a time to call back. If not ask them to take down the message clearly.

If Warren Buffet, Bill Gates, Larry Page & Steve Jobs were Sri Lankans

Warren Buffett (L) speaks while seated beside Microsoft founder Bill Gates (R) at the opening of a new Dairy Queen.

As a thirteen year old kid I queried my then science teacher, "can’t we use the running trains to produce electricity". My question was based on few things;

• I saw the dynamos attached to foot cycles generating little electricity to lit front lamp
• Heard that hydro power plants too generating the electricity in a same manner
• Most of the Sri Lankan trains ran with either one or two diesel powered engines with 6 – 12 passenger cars by that time, my whole idea was to attach a super efficient dynamos to these cars and generate enough electricity to power the engines

By hearing this idea, my science teacher laughed at me…

He said it can’t be done and it’s not practical…

But I am glad to see the hybrid vehicles running on the roads nowadays…
Some research papers too started discussing the same method;

1. https://www.technologyreview.com/s/420734/subway-trains-to-generate-power-for-the-grid/
2. http://www.ijcns.com/pdf/8.pdf

By the age of sixteen, I queried my computer tutor whether we can host a website using a dynamic IP… with a smile, he mentioned the fact that we can’t and it need a fixed IP and blah.. blah.. blah..

In 1999 world saw the first router with the Dynamic DNS support and it answered my question…

When I was doing the A/Ls (by age of 18), I’ve asked my Chemistry and Physics teachers, whether we can use radioactive materials (either Thorium or Uranium or Plutonium) to run passenger vehicles… Again the answer was very simple and said “No”… Their answer was, “Can you fix such a large reactor to a car?”…

But this too became possible thanks to the extensive research:
http://www.caradvice.com.au/132921/the-thorium-powered-car-eight-grams-one-million-miles/

These are just examples of “How lack of research and support affects the futures of different countries”. Some countries and individuals are so lucky and having the access to all the supportive sources while some struggles to get the concept out of the box.

Now the country is talking about a “Knowledge Economy” and ”One Billion Dollar” revenue within few years time. Sadly there is no support for the young entrepreneurs or to the IT/IS industry.

1. None of the local Banks or the VCs having the desire to fund real startup concepts
2. All taks about risks, but no one is willing to take the risks
3. Except few sharks, no one shows real interest to create a start up fund, actively invest on the real seed scenarios than those who known to their circles
4. Country’s only genuine incubator facility collapsed or discontinue their operations after 3 years of operations
5. Laws and regulations affecting the real estates too hurting the entrepreneurs (Banks are valuating the lands and properties using centuries old calculations. Lets say you bought a property worth 15 million and reach the bank next day to mortgage it. They will value it at well below the 10 million and then check your credit worthiness before granting the loan. If this property comes under vihara devala act, your luck will be “0”.
6. Then let’s talk about the stock market. Everyone knows the secret of Warren Buffet’s success is from the stock market. In Sri Lanka, this sector too is corrupted and full of cronies. If a dictator (someone dictates the CSE) notices someone (a new comer) gains sharply, there will be a master plan to chase him out from the market.

Let’s get back to the topic. If these guys were Sri Lakans, none of them would achieve their goals and would become success stories. 😷

Do you beleive "Agile" for everything?

Agile? Agility? Scrum? Hmm… These are the words in most of the software professionals’ mouth in these days… Better to know what it is and how to apply it… Else story would be similar to this… I still feel that people should know when to apply agile concepts and when it should not… Just see the video… You can get an idea about the whole point… Lets start the conversation trail from there onwards….

BAs Adding Value to Projects

Nice article. Decided to share it with my friends.
Especially with the those who willing to pursue a career in Business Analysis, Consultancy and Testing. 

Written by Ian Partridge 

I'm sure there must be a thesis somewhere on this question: How do you know whether a specific decision or action definitely influences the actual event? I like soccer analogies - in a pre-World Cup game against Argentina, Sven-Goran Eriksson then manager of the English national team, was praised for his tactical decision to bring on Peter Crouch and the 3-2 victory that resulted. Yet, Eriksson was slated for poor substitution decisions during the actual tournament when those decisions did not lead to a more positive outcome. In truth, can you really prove these decisions have either a positive or negative outcome? England may have beaten Argentina without the introduction of Crouch and, during the World Cup, the outcome of the games could have been even worse if the substitutions hadn't been made!

I would like to think deliberate decisions and actions can influence a positive outcome, and I especially believe this is the case when business analysts work on projects and are able to play an effective role.

Too often I have experienced misunderstanding of what the business analyst role is and what it can add to a project. This article looks at how business analysis activity can have a massive impact on the outcome of a change program.

Context and Challenges

Following an earlier company acquisition, a leading telecommunication company initiated an IT project to decommission a legacy billing and customer care system and migrate to the company's strategic systems.

Similar projects in the past had taken at least 18 months to complete, were poorly managed, and had run over time and budget. This particular project had been initiated twice before, had not progressed, and there was no documented output. However, expectations had been set by IT that the project would be completed in five months.

Contractual arrangements with the vendors of both legacy and target systems were driving accelerated delivery time scales, and a staff rationalization program was underway in the impacted business area in preparation for the new system.

No resources had been allocated to the project - apart from me, the lead business analyst.

I am a strong advocate of best practice; however, proven methodologies, training and technical skills very rarely provide a ready guide for dealing with challenges such as these!

Scope of the Project

The company's project methodology was to undertake an initial feasibility phase or, what it was to be in this case, an unfeasibility phase! There was a view among senior management that the changes would impact about 5,000 customers and could be achieved by manually keying customer details from one system to another. In fact, the scoping activity completed as part of the analysis made clear that this was a business transformation project, migrating systems that were at the very heart of the acquired company, and involving very significant changes:

• 100,000 customers would be impacted, and nearly every interaction they had with the business would change: changes to bills and billing dates; the company brand they were familiar with; changes to the TV channels they received; and other services gained or lost
• The opportunity to adopt a standard operating model - based on virtual contact centers, centers of excellence and consistent national processes.

Managing Expectations ... or Trying To

At a meeting to discuss the way forward that involved senior stakeholders and the recently appointed project manager, I highlighted the issues regarding scope, risks regarding previous projects of this type, and the opportunities the project provided. Although the stakeholders took the issues on board, the time constraints remained, and it was agreed to undertake a five-week impact analysis.

It would be nice to recount that the business analysis view was readily accepted, but this wasn't the case. Often, the task-focused, project management view of implementation conflicts with the business analysis objective of a quality implementation that delivers value and business benefit. This was the case here. Again, best practice would say that success factors would be agreed upon and defined at initiation, yet this had been ignored The first two bastions of project management - time and cost - were being pushed hard with little consideration being given to the third - quality!

With business analysis resources increased to three and a remit to engage technical staff, a framework was agreed upon to carry out a gap analysis between target and source systems. An aggressive schedule of workshops was planned, and senior managers across the business were consulted to ensure the project scope fully addressed the benefit opportunities and business goals. This also provided the chance to get commitment from areas supplying subject matter experts (SMEs) to the project, as well as re-setting expectations around required activity and time-scales.

A key success for the gap analysis was fully engaging the SMEs attending workshops. The approach we took was to be clear about:

• The drivers of the project
• Why we were doing this work in a tight time-scale
• Why we needed their involvement

This simple, yet often overlooked, approach had immediate benefits: contact centre staff were surprised at the high cost of extending the support of the legacy billing system. They thought the motive for the change was purely headcount reduction. Involving staff in the decision-making reduced resistance to change and led to more motivation and commitment.
 

The output of the gap analysis highlighted two things:

1. The impact of replacing these legacy systems was extremely broad and deep. More than 100 sub-systems and interfaces would need to be changed or decommissioned. No simple keying of customer details!
2. The work was estimated to take 10 months to complete.

Business Requirements and Detailed Analysis

I'm still surprised that in many organizations, and on many projects, the benefit of doing analysis and undertaking requirements is not better understood. I won't go into the pros and cons of various techniques other than recommending that the activity needs to be:

• Fit-for-purpose
• Appropriate to the organization
• Communicated, in terms of its value, to relevant stakeholders

The output of doing this work on a major project is, undoubtedly, documentation. There were two main concerns we had to counter: the perceived lack of value of the analysis, and that this was seen as the reason to extend the project timescale by five months. I have often seen that tight project timescales lead to under-analysis; business managers sometimes prefer "doing" to understanding the "what" and the "how." I'm sure many people have experienced solutions to problems that weren't properly understood, or delays due to extensive change requests. Moving to "doing" too quickly only creates a false sense of progress. With good analysis, you reap what you sow.
 

The concerns were addressed by briefing the main project stakeholders on what we were doing and why, covering all the detail that would underpin the project plan and providing visibility of the work to be carried out. We also highlighted how independent research supported the link between clearly understood requirements and success - especially for complex projects.

Documentation

We couldn't avoid the fact that a reasonable amount of documentation would be produced due to the breadth of work. To make this as pragmatic as possible, a document template was defined from scratch to ensure that only the relevant information was captured, that it was easy to populate, and that it would be consistent and easy to read. The format was agreed upon by major stakeholders, ensuring expectations were managed and avoiding resistance to receiving documents.

As for the gap analysis, we were to engage many SMEs and would need to cover a fair degree of technical input. The work was divided into work streams, each assigned a lead BA and a lead technical analyst (TA) with my role as an overarching lead. Excellent relationships were fostered between the BAs and TAs, helped by the co-dependence of our roles, to make the work a success.

Relationships

I have always believed the softer skills are a far greater asset to a business analyst than the more technical ones. Interpersonal skills make the difference when resolving issues, managing conflict, communicating, influencing, etc. Active relationship building proved really effective on this project. Just as engaging workshop attendees had encouraged participation, and two-way communication helped address resistance to change, good relationships with TAs helped gain more buy-in from SMEs. In the end, more than 100 SMEs contributed to this phase of the project. I have seen situations where BAs and TAs do not work well together and have even heard a TA accuse BAs of "sucking out what we know and then documenting it." This is perhaps a little extreme, though there is some truth in it when you consider what BAs do in terms of facilitating understanding.

The lead TAs on the project were given joint responsibility on authorship of documents produced. This was not only to address the workload but also resulted in their feeling fully bought into the analysis work and championing the output. As well as being another benefit of having a clearly agreed and pragmatic template, this also really helped in achieving sign-off for the work.

Sign-Off

Whilst communicating the template and approach for documenting the analysis, I also defined and gained acceptance for a sign-off process from the managers who were acting as operational sponsors. They were the people who would be committing their resource to the project, would be receiving the change into their areas, and their approval would be the measure as to whether the analysis was fit for purpose and a success. Attitude to formal sign-off can vary greatly within organizations, even where this is part of the internal governance of project methodologies and frameworks. I really believe that without proper sign-off you don't have commitment, true buy-in or a proper baseline to manage further change by.

Reviewing the sign-off process led to a better understanding of the issues faced by sponsors, principle of which was the appearance of large documents in their inboxes with no real clarity of what they were really being asked to sign off, little understanding of impacts and insufficient time to review. The answer was a clear schedule of when each output document would be completed. The schedule had been agreed to by the BAs and TAs to ensure it was realistic but challenging, with each document being completed in three stages:

1. A final draft, quality reviewed with the document authors and work stream leads
2. A structured document walkthrough with BA and TA leads and nominated SMEs and managers
3. A final issue for sign-off by the sponsors

This proved really effective for the following reasons:

• Everyone was focused on delivering work to meet the time-scales in the schedule. Involvement in planning this and agreeing to it achieved commitment from everyone.
• The quality review sessions made sure work was a good standard, consistent across all the areas, and that there was acceptable coverage of analysis.
• The structured walkthroughs ensured all feedback was captured together and facilitated challenge and understanding of different viewpoints. You knew everyone had read the document as you were going through it with them.
• Sponsors signed off documents quickly as their direct reports were heavily involved in agreeing to them during the walkthrough sessions.

Summary

Following the approval of this phase, the project moved into development and implementation and went live over a weekend with no problems of any significance. Although it was a month late due to data migration issues, it was described as the most successful migration project undertaken by the company.

A review of lessons learned highlighted the appropriateness of the approach taken to analysis. The effectiveness of working relationships between BAs and TAs, clarity of scope, division of work across functional areas, and the actual documentation were credited as contributing to project success.

The company used the analysis approaches described above as the blueprint for a subsequent migration project that had been on the back-burner for a number of years, and without doubt, the experience of this project gave the company the confidence to undertake it.

Given the opportunity, business analysts can make a real difference to the projects they work on, and the success that follows is no accident.

Don't forget to leave your comments below

---

Ian Partridge is an experienced BA manager and business change professional. Currently working as a contractor/BA consultant, Ian has more than 12 years of experience, including media, asset management, telecommunications, banking and retail. For more information visit www.2broconsulting.com.

Ian can be reached at ian@2broconsulting.com and ianbpartridge@blueyonder.co.uk.

Are we gathering or eliciting the requirements?

Most of the BAs using the term "Gathering" against the requirements. The exact term is "Requirements gathering". While reading some articles, found an interesting article on the "Requirements gathering". Here the author is arguing against the term gathering. According to Jill Liles we are not gathering but eliciting the requirements.

This was on the BA Times web site. I am adding it my blog post to save your time from log in to BA Times and search for the same.

Methods for Eliciting - Not Gathering - Requirements
Written by Jill Liles

The word "gather" does not truly communicate the nature of the Business Analyst's (BA) job. You do not gather requirements-they are not just lying around on the ground waiting to be picked up.

The word "elicit" more closely matches the job, because it connotes a more active role for both the BA and for those with whom the BA works. The dictionary defines elicit as:

1. To draw forth or bring out (something latent or potential)
2. To call forth or draw out (as information or a response)

There are many ways to elicit requirements from your stakeholders. A BA should be proficient in all of these: interviews, workshops, focus groups, brainstorming, observation, and surveys/questionnaires. While all of these methods involve three basic parts: preparation, conducting, and follow-up, they do have differences.

Interviews

Interviews, either with an individual or with a group of people, offer the opportunity for rich, detailed communication.

Prepare

• Define interview goal: Determine exactly why you are holding the interview and what you want to achieve in it.
• Select participants: Decide who needs to be involved in the interview in order to achieve that goal.
• Determine logistics: When and where will the interview be held, and how will the interviewees be invited?
• Design the interview: Decide on the format that is most appropriate for the interviewees and the goal. Should it be structured with a detailed agenda and formal set of questions, or unstructured with a looser agenda, depending more on ad hoc interaction? Should the questions be open-ended requiring sentences or paragraphs to answer, or closed-ended requiring short, even one-word answers?

Conduct the Interview

Take time at the beginning to ensure that the interviewee(s) knows the purpose of the interview, who you are, and what your role is. Wrap up the interview with questions like "Is there anything else you would like to add?" and a hearty "Thank you!"

Follow up

Like any other meeting, interview minutes should be published. This allows the interviewees to see what you learned in the interview and validate that what you heard is what they intended to say.

Workshops

A workshop is a structured method for interacting with a group of people. Workshops can generate much information quickly if well facilitated and if participants are active.

Prepare for Workshop

• Define purpose: Determine exactly why you are holding the workshop and what you want to achieve in it.
• Select participants: Decide who needs to participate in the workshop in order to achieve that purpose. Make sure to consider the personality types involved and ensure that you'll get participation from the entire group, not just a few dominant people.
• Determine logistics: When and where will the workshop be held, and how will the participants be invited?
• Conduct preliminary interviews: Some workshop methods include collecting some information from the participants before the workshop to provide a starting point. Such methods provide specific guidance about what preliminary information should be collected.

Conduct the Workshop

Be sure to accurately capture all of the information that the workshop produces. Depending on the size of the group, you may want to assign a record-keeper so you can focus on facilitation

Follow up

Some types of workshops result in the assignment of action items to the facilitator or participants, in which case, they must be managed to closure. The workshop results should be published so the participants and other interested parties can see what you learned in the workshop.

Focus Groups

A focus group is an interactive session with a carefully selected group of people designed to capitalize on the synergy of a group.

Prepare for the Focus Group

• Select participants: Decide who needs to participate in the focus group in order to achieve its purpose.
• Define roles, topics, and logistics: Define who (among the people running the focus group) must do what, and the specific topics that the participants will discuss. Also define the basic logistics such as when and where the focus group will be held, and how the participants will be invited.

Run the Focus Group

Carefully facilitate the group to ensure free and open interaction among the participants. Participants must feel free to interact openly or the focus group could fail.

Follow up

The focus group report records what was learned, including both agreements and disagreements among the participants.

Brainstorming

Brainstorming is a method of quickly generating many creative ideas from a group of people.

Prepare for Brainstorming

• Define topics and time limits: Define precisely what will be the focus of the brainstorming session, and how long it will be allowed to go on.
• Select participants: Decide who needs to participate in the brainstorming session in order to achieve its purpose.
• Determine evaluation criteria: Decide how the ideas that come out of the brainstorming session will be judged afterward. Be sure that the evaluation does not go on during the brainstorming session.

Conduct Brainstorming

Encourage a free flow of ideas. This requires careful facilitation to ensure that participants feel comfortable with adding any idea to the list, and that no criticism or even discussion of the ideas goes on during the brainstorming session.

Follow up

Apply the evaluation criteria to the ideas that were generated to reduce the list to only those ideas that are reasonable or viable.

Observation

Observation is watching people as they go about their jobs. Observation can be an effective way to gain a realistic and detailed understanding of how work is done in the production environment; however, it is time consuming and may disrupt work.

Prepare for Observation

• Define goals and individuals to be observed: Decide what you are trying to accomplish in the observation and who you should observe in order to achieve those goals
• Decide on mode: Observation may be done in either of two ways:
  • Passive/invisible: Observing in a way that does not disturb the workers. "Invisible" refers to the fact that the workers are not even aware that observation is taking place.
  • Active/visible: Interacting with those who are being observed. For example, asking questions and having them describe what they are doing and why.

Observe

If people believe that they are being evaluated, they are likely to do the work "by the book," instead of the way they normally do it. So those who are being observed must be assured that the observation is not for the purpose of judging them. As the observation goes on, keep detailed records of what is observed and questions that must be answered later.

Follow up

After obtaining answers to any remaining questions, publish the results of the observation.

Surveys/Questionnaires

Surveys allow you to collect information from many people in a relatively short period. A survey can be an effective way to collect quantitative information; however, writing the questions requires great skill and care to avoid ambiguity that could compromise the utility of the results.

Prepare for the Survey

• Define purpose, target people, and logistics: Decide what you are trying to learn from the survey, who you should target in order to achieve those goals, and how the survey should be distributed (for example, paper, e-mail, internet, telephone).
• Choose survey type:
  • Open-ended questions vs. closed-ended questions: Open-ended surveys are more difficult to analyze, yet closed-ended surveys limit the responders' options.
  • Anonymous vs. signed vs. optional: People may be more forthcoming if they do not have to provide their names, but anonymity does not allow for any follow-up questioning.
  • With vs. without pre-survey or post-survey interviews: Pre-survey and post-survey interviews increase the valuable data that you can get from the survey, but add significant effort.
• Define target response level and follow-up activities: Getting many people to respond to a survey is difficult. If you are expecting more than a small minority of the target people to respond, it will require follow-up work beyond merely distributing the survey.
• Write questions: This step is more challenging than it sounds. Writing questions that cannot be misinterpreted (resulting in misleading results) requires great skill and concentrated effort.
• Test the survey: Because it is so difficult to write questions well, it is advisable to test the survey to see if people misinterpret any of the questions, and to see if it provides the information that is sought.

Distribute the Survey

Get the survey into the target people's hands, and encourage them to respond. If follow-up activities are planned to increase the response rates, do them.

Follow up

After the response period has ended, analyze the data, and summarize and report it to the appropriate people.

Jill Liles is the Senior Product Marketing Manager at Global Knowledge, where she primarily focuses on marketing activities for Cisco training courses. She also coordinates all marketing for Canada. In her spare time she volunteers with her local Susan G. Komen Foundation affiliate and crafts jewelry. This article draws from Global Knowledge's Requirements Development and Management course.