Business Email Etiquette

What Do Your Business Emails Reveal About You?

Email is quick. Email is convenient. Writing an email often takes less time than conducting a telephone conversation. But most importantly, email gives you an electronic record of your communication with clients, employees, partners, and vendors; which makes it easy to refresh your memory by easily referring back to the electronic conversations.

In our line of work, where we probably send and receive literally hundreds of emails a day, we are frequently subjected to poorly written, unprofessional business emails. These are often rife with spelling and grammatical errors. Should we be concerned about this?  Well actually, yes this should be something that concerns us; if for no other reason than because it portrays the company in a poor light!

In business, you are constantly being judged by your customers, your employees, your investors, your partners, and your peers. If your emails give the impression that you don’t put much thought into composing your message or that you are too busy to be bothered or that you choose not to use a spell-checker, what do you think that says to the person on the other end?

Email is quickly becoming the business correspondence medium of choice for the reasons we covered above, and if you don’t take the time to learn how to effectively use email in a professional manner, it will come back to haunt you.

There are rules that should be followed when sending business emails. They are not complicated – most are just common sense!  Here are BIG’s Top 10 Rules of Email Etiquette that every entrepreneur, executive, and employee should follow:

1. Make It Short And Sweet – An email isn’t a letter, so don’t drone on any longer than necessary. Keep in mind that reading an email on a computer screen is harder than reading printed communications, so keep it brief and to the point.

2. Use Proper Spelling, Grammar & Punctuation – This is important because bad spelling, grammar and punctuation give a bad impression of you and your company; it is also important to make sure your message is not misconstrued. Emails with incorrect punctuation are difficult to read and can sometimes even change the meaning of the message. Most email programs have a spell checker so there is really no excuse for bad spelling.

3. Include a Signature Block In Every Email – A signature block in an email is the same as the signature block you would use to end a letter. You should include your name, title, company name and address, telephone number, email address and website address.

4. Reply Quickly – Fast response is especially important if the email is from a customer or contains time-sensitive information. Customers send an email because they wish to receive a quick response. If they did not want a quick response they would send a letter or a fax or talk to your voicemail. Each email should be replied to within 24-hours, and preferably within the same working day. If the email can’t be answered in full immediately you should at least send a reply saying that you have received their email and that you will get back to them ASAP.

5. Read Every Email Before You Send It – There’s no better way to embarrass yourself than through a hastily sent email. A lot of people don’t even bother to read an email before they send it out, as evidenced by the many spelling and grammatical errors most emails contain. Apart from this, reading your email through the eyes of the recipient will help you send a more effective message and avoid any misunderstandings or inappropriate comments.

6. Do Not Discuss Confidential Information – Sending an email is like sending a postcard. Once it leaves your computer, the end user can do whatever they want with it, so if you do not want a documented record of your comments or the information shared with others, don’t send it. Moreover, never make any libelous, sexist or racially discriminating comments in emails, even if they are meant to be a joke. There have been court cases where email correspondence has been used as evidence. That’s a road you do not want to go down.

7. Don’t Use ALL CAPS – In email terms, IF YOU WRITE IN CAPITAL LETTERS IT SEEMS AS IF YOU ARE SHOUTING, so please tone it down. ALL CAPS are hard to read and can trigger an angry reply if the recipient mistakes the intention of your email. Emails should be written in standard sentence style.

8. Avoid Abbreviations and Emoticons – In business emails, try not to use abbreviations such as BTW (by the way) and LOL (laugh out loud). The recipient might not be aware of the meanings of the abbreviations and in business emails these are generally not appropriate. The same goes for emoticons, such as the smiley :-) and his depressed pal :-( . If you are not sure whether your recipient knows what an acronym means, it is better not to use it.

9. Don’t Use Backgrounds or Silly Graphics – The use of such graphics is simply inappropriate for business use so avoid them at all costs.

10. Remember That Email Is A Formal Business Communication – A proper business email should be structured like a short letter. It should have a salutation, the body of the message, a sign off, and a signature.

One final thought – if your company doesn’t have a formal email policy then it may be advisable to introduce one. Providing guidance on how staff should conduct themselves will ensure there is no doubt about your expectations. This will ultimately help to protect your company’s reputation.


Project Management Best Practices

What are the top 7 best practices at the heart of good project management?

The term ‘best practice’ refers to the actions which countless project managers have performed on thousands of projects; from past experience they are deemed to be the ‘best practice’ because they tend to help you to achieve the best results. In the PRINCE2 methodology, this falls under the principle of the project team learning from past experience.

The top seven best practices can be summarised as:

1. Define the scope and objectives

Firstly, understand the project objectives. Suppose your boss asks you to organise a blood donor campaign: is the objective to get as much blood donated as possible or, is it to raise the local company profile? Deciding the real objectives will help you plan the project.

Scope defines the boundary of the project. Is the organisation of transport to take staff to the blood bank within scope or, should staff  make their own way there? Deciding what is in or out of scope will determine the amount of work which needs performing.

Understand who the stakeholders are, what they expect to be delivered and enlist their support. Once you have defined the scope and objectives, get the stakeholders to review and agree to them.

2. Define the deliverables

You must define what will be delivered by the project. If your project is an advertising campaign for a new chocolate bar, then one deliverable might be the artwork for an advertisement. So, decide what tangible things will be delivered and document them in enough detail to enable someone else to produce them correctly and effectively.

Key stakeholders must review the definition of deliverables and must agree they accurately reflect what must be delivered.

3. Project planning

Planning requires that the project manager decides which people, resources and budget are required to complete the project.

You must define what activities are required to produce the deliverables using techniques such as Work Breakdown Structures. You must estimate the time and effort required for each activity, detail dependencies between activities and decide a realistic schedule to complete them. Involve the project team in estimating how long activities will take. Set milestones which indicate critical dates during the project. Write this into the project plan and get the key stakeholders to review and agree to the plan.

4. Communication

Project plans are useless unless they have been communicated effectively to the project team. Every team member needs to know their responsibilities. There also needs to be regular and efficient communication between all parties involved in the project.

5. Tracking and reporting project progress

Once your project is underway you must monitor and compare the actual progress with the planned progress. You will need progress reports from project team members. You should record variations between the actual and planned cost, schedule and scope. You should report variations to relevant parties and take corrective actions if variations get too large.

You can adjust the plan in many ways to get the project back on track but you will always end up juggling cost, scope and schedule. As project manager, if you change one of these, then one or both of the other elements will inevitably need adjustment. It is juggling these three elements – sometimes known as the project triangle – that typically causes a project manager the most headaches!

6. Change management

Stakeholders often change their mind about what must be delivered. Sometimes the business environment changes after the project starts, so assumptions made at the beginning of the project may no longer be valid. This often means the scope or deliverables of the project need changing. If a project manager accepted all changes into the project, the project would inevitably go over budget, be delivered late and might never be completed.

By managing changes, the project manager can make decisions about whether or not to incorporate the changes immediately or in the future, or to reject them. This increases the chances of project success because the project manager controls how the changes are incorporated. Resources can then be allocated accordingly and plans drawn up to show when and how the changes are to be made. Not managing changes effectively is often a reason why projects fail.

7. Risk management

Risks are events which can adversely affect the successful outcome of the project. For example, risks might include: staff lacking the technical skills to perform the work, hardware not being delivered on time, the control room at risk of flooding and many others. Risks will vary for each project but the main risks to a project must be identified as soon as possible. Plans must be made to avoid the risk, or, if the risk cannot be avoided, to mitigate the risk to lessen its impact if it occurs. This is known as risk management.

It is not necessary to manage all risks – there could be too many and not all risks have the same impact. So, identify all risks, estimate the likelihood of each risk occurring (1 = not likely, 2 = maybe likely, 3 = very likely). Estimate its impact on the project (1 – low, 2 – medium, 3 – high), then multiply the two numbers together to give the risk factor. High risk factors indicate the severest risks. Manage the ten with the highest risk factors. Constantly review risks and look out for new ones as they have a habit of occurring without warning.

What does BIG recommend when it comes to ‘best practices’?

It is essential to adopt ‘best practices’ in order to give your project the best chance of a smooth and successful delivery. That said, we must be sensible and recognise that following best practices alone, cannot guarantee a successful project. However, they will certainly provide a better chance of success than if we do not use them. In fact, disregarding them will almost certainly lead to project failure.


Managing Small Projects

Should we apply large project ‘best practices’ to small projects?

A common question about project management is whether the best practices that are applicable for large projects can be applied on smaller projects. This is a really important question and one which all project managers must face up to when managing small projects.

Focusing on project delivery

One of the arguments against using project management methodologies is that they are very process-centric resulting in vast quantities of project documentation which are simply not practical or desirable on small projects. This is a powerful argument and any method which focuses on producing documentation at the expense of delivering the real business benefits of the project will be a hindrance rather than a benefit. After all, the name of the game in project management is delivering business objectives, not producing reams of documentation. That said, the crux of this particular arguement often stems from a misunderstanding about how project management methodologies should be used. One of the principles of the PRINCE2 methodology, for example, is that it should be tailored to the project environment; project managers should therefore tailor the amount of paperwork generated, to the requirements of an individual project.

There is an ongoing and active discussion within the software development community about the best way to produce software on projects. More recently, some software professionals have argued for more agile methods of producing software rather than the more traditional heavyweight methods which focused on producing vast quantities of documentation.

Agile methods focus on delivery of software rather than documentation. With this in mind, project managers everywhere can learn something from the agile methods employed in software development. In short, this leads us to focus on project delivery rather than project documentation, although the critical choice project managers everywhere need to make is how much documentation is really necessary?

Apply the best practices

The simple answer is that you should only be producing as much documentation as is necessary to deliver your project successfully; nothing more and nothing less. A simple rule of thumb states that if it is useful in helping us to deliver the business objectives of the project, then we should produce it. If it is not useful in helping us to deliver the business objectives of the project, then do not waste time with it. With this in mind, we should aim to apply in all projects, regardless of their size or scope, a minimum number of project management best practices.

Let us consider the best practices in turn and see whether or not the overhead lost in applying best practices is worth the benefits which can be gained.

Defining objectives and scope

Even on the smallest project there will be objectives which must be achieved. As a project manager, it is in your interest to define what these objectives are since you are likely to be assessed on whether the project meets those objectives. It is your responsibility to ensure the project meets those objectives and you are accountable for this. In short, as our friends in America would say: the buck stops with you.

Now suppose you do not define and write down what the objectives are? You are always going to be at the mercy of the project sponsor or of any stakeholder who decides they want more from you. The defined and documented set of objectives is your insurance policy against anyone later coming along and saying you did not meet the objectives.

However, there is another reason why you still need to define and document the objectives even on a small project. You want to satisfy the needs of the stakeholders since that is what you are paid to do as a project manager. If the objectives are not defined, then you will not be able to meet those needs through your project.

The same can be said about defining the scope of your project as this forms the boundary of your work. If you do not define what it is, the likelihood is that it will grow as the project progresses. Although you might have started managing a very small project, it could become very much bigger than when you set out.

You still need to document who the stakeholders are on a small project as well. By defining who they are, you can ensure that you cover all of their needs when you define the objectives and deliverables.

Defining deliverables

Somebody is going to have to carry out the actual work to produce whatever is delivered from your project. Even if the deliverables are small and do not take much time to produce, they should still be written down. By documenting these things and then having them reviewed by others allows any errors to be identified at an early stage. Your aim should be to document a detailed enough set of descriptions so there can be no doubt about what products are to be delivered.

These descriptions will then be used by the people who will produce the deliverables. Even if these descriptions take no more than a page of text, it is important to write them in a clear and unambiguous way. If you do not write down a description, it means that the person making the deliverable can interpret what is required in unexpected ways. This will only result in work being done later to correct the mistakes. So, always define and document the deliverables.

Project planning

If you were to walk up Mount Everest, you would never do it without a considerable amount of planning. Even if you walk up the hill at the back of your house, there is probably some planning involved: what time do you go and what should you take with you? It is the same on even the smallest project. You will still need to work out which activities are required to produce a deliverable, estimate how long the activities will take, work out how many staff and resources are required and assign activities and responsibilities to specific people.

All of these things need to be written down and communicated effectively to the project team members. It is easy for a project manager to become unstuck because they think they need to use some kind of project management planning software such as Microsoft Project. This may be an unnecessary overhead on a small project. An alternative for small projects could be to create a bar chart in Microsoft Excel or even just running a timeline within a spreadsheet. This approach is simple and often more than adequate for small projects – the most important thing is that the information is being tracked in a professional, organised way that can easily be shared with other members of the team.

Regardless of which piece of software you use, do not forget to document the milestones on the project. Milestones are the dates by which you need to deliver certain things, or the date on which a major activity ends. The responsibilities of each project member should also be documented in the plan.

Communication

Even in the smallest project team, where there may only be a project manager and one other person, the project manager will still need to assign tasks and responsibilities to the other person. It cannot be assumed that they will know what they should do without it being communicated effectively. If the project manager does not assign them specific activities, then the chances are they will go ahead and work on things which are not needed by the project. So, either the project will end up delivering the wrong things, or it will get delayed since time will need to be spent later on doing the activities which should have been done earlier.

You can communicate the plans via email, or give a print-out of the plan to your project team member(s). Better still, call a meeting and run through the plan with everyone. Remember, if the plan changes, you will also need to communicate the changes to your team as well.

Tracking and reporting progress

If we still consider our two person project team – the project manager and one other person – the project manager will need to know the progress of the activities which the other person is working on. This can be done in a variety of ways: a short daily email detailing the work completed, the work still left to do, and a list of any issues or problems. In most cases this will be sufficient.

Alternatively a short 15 minute meeting (either by phone or face-to-face) can accomplish the same thing. Or a combination of the two things might be best. In any event, the project manager needs to be fully aware of the progress that is being made so that deliverables can be tracked effectively.

Change management

Even on our two person project, changes are likely to occur. Requests for change usually come from stakeholders and it is your responsibility as project manager to assess the impact of accepting these into the project. To do this, you need a good estimate of the impact the change will have in terms of the extra effort and cost involved. This will often impact the schedule as well. By having a clear understanding of how the schedule and budget will be affected, you can make the decision as to whether or not you will accept the change into your project.

On a small project there should not be any need for a change control board to decide if the change is accepted. A quick discussion with the key stakeholder(s) should be sufficient for you to come to a decision, providing you have worked out the impact on cost and schedule.

One thing you should never do is simply accept the change. Even if you think the change is small, you should never accept any change(s) without fully understanding what its impact will be on cost and schedule. That is a recipe for what we call ‘scope creep’ where the project grows bigger and bigger as more and more changes are added into the project. Before you know it, your small project has become a much larger one and you will inevitably fail to deliver your project to your original budget and schedule.

Risk management

There will be risks even on a small project but the overhead in managing risks is very low. Make sure you have thought through all the potential risks at the beginning of the project, monitor the top ten risks each week (or top five if the number of risks is small) and keep looking out for new ones. Failing to manage risk properly is one the main causes for projects to fail.

With a little up-front and ongoing effort, you get a big pay back if you manage the risks throughout the project, as your work will run so much more smoothly.

What are BIG’s tips for using best practices?

Applying the best practices, even to a small project, can be done without creating too much paperwork or overhead. The best practices are the things which countless project managers have done on thousands of projects and are deemed to be the ‘best practice’ because they tend to help you to achieve the best results. In the PRINCE2 methodology, this falls under the principle of the project team learning from past experience.

Do not make the mistake of thinking that, just because you are managing a small project you can ditch these best practices. If you do, you will almost certainly regret it later when your project inevitably gets into a mess.