Skip to main content

Ten Tips for Writing Effective E-mail Messages

  1. Plan the message before you write it. Before writing, ask yourself, “Why am I writing this – what do I want my reader to know and/or do?” When you have the answer, state it at the beginning of your message – this is your main point. 

  1. Organize the information in your message to support the main point. Delete any unnecessary information. Use short paragraphs and bullet points for lists – these make the message easier to read on a screen. 
  2. Identify the right recipients. Don’t send the message to people who don’t need the information. 
  3. Check the content of the message. Make sure there is nothing confidential, personal, inappropriate, or offensive. 
  4. Check the tone of the message. Make sure it doesn’t sound angry, rude, or abrupt. 
  5. Choose the appropriate salutation and closing. Depending on the audience, salutations and closings can be formal, informal, or casual. 
  6. Proofread the message. Fix any grammar, punctuation, and spelling errors. 
  7. Craft a compelling subject line that will tell the reader exactly what the message is about and allow the reader to file and find the message easily later on. 
  8. Make sure attachments are attached. It’s usually best to include attachments as PDFs. 
  9. Include a signature with your contact information. Be sure to include your name, company name, and phone number.

© Copyright 2008 Write It Well


Natasha Terk,

President of Write It Well (www.writeitwell.com), works with a team of skilled instructional designers and trainers to develop and deliver customized on-site and online training solutions about written communications.

Getting Back To Basics

Second Fundamental: Creating a Common Vocabulary

Right now, there is more information available than ever before about business analysis.

As someone who has dedicated his career to this essential discipline, I find this fact both exciting and a little frightening. On one hand, it demonstrates that business leaders have embraced business analysis as a key element to success. However, on the other hand, I worry that such a mountain of information, opinions and tools may simply be too overwhelming for those looking to bring business analysis to their organization.

That’s why in April I began what will be a series of five articles covering how to cut through the vastness of information and get back to the very basics of effective business analysis. In my first article in the series, I discussed the importance of understanding overall business goals. The next step is developing a common vocabulary to be shared by your entire team.

A Glossary of Terms

At the very beginning of a project, it is absolutely essential that you and your team develop a glossary of terms, which is a type of requirement model that lists in alphabetical order the terms, definitions and aliases that may be required to support the development of your solution. The document will ultimately be the foundation from which all of your requirements are developed.

As obvious a suggestion as this might seem to be, I would estimate – and it’s a generous estimation, mind you – that only about 10 percent of organizations today actually take the time up front to create a glossary of terms.

What is the difference between a client, a user and a customer? What is an executive sponsor? Are sponsors and stakeholders the same? What is the difference between business requirements, user requirements and specifications? And, what about all of those acronyms that we only vaguely understand? What do those mean? These questions and many others should be discussed and agreed upon and then documented in your glossary of terms.

The easiest way to do this is through brainstorming sessions with key personnel. Once everyone is in the same room – either real or virtual – the group should work together to hammer out as many essential terms as possible. In order to build consensus on definitions, the facilitators of these brainstorming sessions should use voting techniques in lieu of all-out dictatorship.

Avoid Confusion Today . . . And Tomorrow

With tight deadlines and demanding stakeholders always a concern, it’s tempting to bypass the busy work of developing a glossary and assume everyone is on the same page.  I can tell you from firsthand experience this type of shortsightedness will do nothing but hurt you – both today and tomorrow.

It’s a simple fact: words and phrases mean different things to different people  -especially when we enter the always-dicey realm of corporate jargon. If terms aren’t understood from the get go, misunderstandings of expectations, wants and deliverables are inevitable, and they could lead to conflicts throughout the life of a project. A comprehensive, well-put-together glossary will save you valuable time and energy, allowing you to focus your efforts not on simply communicating but on developing the most effective solution.

Create a Living Document and Share It

Technology has been wonderful for businesspeople – and not just because it allows us to secretly watch hockey highlights from our desks.  Technology today has made it easier than ever to create, share and store information. A glossary of terms is no longer a bunch of pages that you bind together and then stick somewhere on your bookshelf.  You should always think of a glossary of terms as a living document that has the power to evolve and grow along with projects, programs and organizations.

Even after a project has been long completed and celebrated, its glossary of terms is still valuable and should still be maintained because it can be used as a baseline for future projects.  Aside from some unique particulars, the terms and acronyms will be applicable to teams throughout your organization.

And, this brings me to the sharing of information. If your organization has an Intranet site or one shared location for information, glossaries of terms should be housed there and made available to everyone. Glossaries are excellent tools for educating new employees and saving them from having to smile and nod at all of your confusing acronyms for their first six months on the job.  Knowledge sharing is an easy, efficient way to help increase another kind of sharing – profit sharing.

Next Time: Requirements Sources

Next time, for my third article in this five-part series, I’ll cover how to determine the sources from which you will extract your requirements.  In the meantime, I’ll allow you to document your own definitions for extract and requirements.

This is the second in a five part series of articles by Glenn Brûlé.


Glenn R. Brûlé

has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI (www.esi-intl.com), he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis (IIBA), Brûlé’s primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.

Is it Time for the BA and the PM to Get Hitched?

My life as a project manager (PM) began in 1963 at Texas Instruments at about the time IBM announced System 360. It was a landmark event in the history of computing and little did I know at the time but it was also the wakeup call that a revolution was about to take place. It was a revolution that we weren’t ready for. If I remember correctly I ran projects but was called a systems consultant.  I don’t recall anyone in my industry carrying the title project manager. There was very little in the way of tools, templates and processes to support me. The only software that I knew about was an old IBM1130 program that I think was called Process Control System. One of my friends in the building construction trade introduced me to it and I thought I was now king of the hill. PMI wouldn’t arrive on the scene until 1969.

As for the business analyst (BA) they weren’t around, at least not by that name. What we did have were computer professionals that were called systems analysts. They were the mystics from the IT Department who could talk to a businessperson about what they wanted, retreat into their space to concoct a solution, emerge to tell the programmers what to build and then hope for the best. Few clients were satisfied with the results but they weren’t involved enough to know what to do about it. Life was tough in those early days of project management and systems development. Clients were kept at arm’s length and only got involved when it was time to sign a document under the threat of a project delay if they didn’t sign. Every one of my colleagues, including myself, was looking for silver bullets.

Fast forward to 2008. The systems development landscape is more mature as are the life cycles employed. We have linear, incremental, iterative, adaptive and extreme projects. In less than 40 years PMI has grown to over 250,000 members worldwide. It is the de facto professional society for PMs. IIBA, launched in 2003, is just getting started and has a membership of over 4,000 worldwide. Size differences aside the two organizations have a lot in common and a lot to gain through collaboration and joint ventures.

The major area of overlap is requirements gathering and management. Both the PM and the BA face the same challenges here. Even under the best of circumstances it is very difficult, if not impossible, to identify and document complete requirements. The reasons are many and well known to both professional groups. Underlying it all is the need for more collaborative efforts.

The next area of overlap is process improvement. In the world of the PM and their management this means applying some variation of the Capability Maturity Model and continuous project management process and practice improvement. For the BA this means business process improvement projects and that means having effective project management methodologies.

The next area of overlap is the skill and competency profile of the effective PM and the effective BA. The two profiles are virtually identical. Some have posited that we really don’t need both types assigned to the same project. We could certainly debate that point of view but, if present trends continue, I would argue that a single person, whatever label you choose to use, will soon be sufficient. In other words the BA should have the requisite skills and competencies to be an effective PM and the PM should have the requisite skills and competencies to be an effective BA. They will have morphed into one professional. Lacking an appropriate name right now, I’ll refer to this single professional as a BA/PM. We are not too far away from that day.

The next area of overlap is the processes, tools and templates that both professionals follow. Again they are virtually identical at the concept level.

I could go on but I think you get the picture. I am led to the conclusion that the support of both the PM and the BA should lie in a single organizational entity that I am going to call the Business Project, Program, Portfolio and Process Office or BP4O for short. Please excuse my taking liberties with the multiple use of “P”. I do that for good reason. PMs have had the Project Management Office (PMO) under various names for a number of years. The BA has not had a similar support organization. Recently I have seen Communities of Practice (COP) and Centers of Excellence (COE) emerging for the BA, but these are more voluntary forums for the BA to network and exchange ideas with their peers than an organized business unit. There is no valid argument that can be given for not expanding the PMO to embrace the BA. That is what I am calling the BP4O and that is the focus of the remainder of this article.

The World Class BP4O

On the surface the world class BP4O won’t seem much different than the traditional PMO. The world class BP4O offers an expanded portfolio of support functions as compared to the typical PMO but if you look under the hood, you will see that I am proposing that there be a significant difference. In organizations that see the handwriting they see that project management, program management, portfolio management and business process management are all converging on a single strategic role with enterprise-wide scope. The world class BP4O that I envision is a central participant in that role. It helps define strategy and through its infrastructure provides for the enablement of that strategy too. And so here is my first shot at a definition of the world class BP4O.

Definition of the World Class BP4O

The world class BP4O is an enterprise-wide organizational unit that helps formulate and fully supports the strategic, tactical and operational initiatives of the enterprise. The world class BP4O is characterized by:

  • Led by the VP BP4O who has a voting seat at the strategy table
  • Fully participates in the formation and approval of the business plan at all levels
  • Establishes the processes for and monitors the performance of the project portfolio
  • Has authority and responsibility to set priorities and allocate resources to projects
  • Establishes standards for the tools, templates and processes used by BAs and PMs
  • Monitors compliance in the tools, templates and processes used by BAs and PMs
  • Establishes an integrated BA/PM position family with defined career paths
  • Provides a complete program (training and human resource management) for the professional development of all BA/PMs
  • Assures that the skill and competency profile of the BA/PM staff is sufficient for the realization of the project portfolio
  • Allocates BA/PMs to the approved portfolio of projects
  • Offers a full range of support services to executives, sponsors and project teams
  • All BA/PMs have an approved professional development program.
  • Performance metrics:
    • The project management and business process methodologies are assessed at CMMI Maturity Level 5 
    • On average the practice maturity level is at least CMMI Maturity Level 3
    • The project failure rate is less than 10%

As you can see the VP BP4O is an integral part of the enterprise from the strategy formation level to tactical planning to execution at the operational level. It is that unit’s responsibility to make the most effective use of the enterprise’s human resources towards the realization of the business plan.

Mission of the World Class BP4O

To provide a comprehensive portfolio of strategic, tactical and operational support services to all project teams, sponsors and executives in order to assure the delivery of maximum business value from the project portfolio.

Objectives of the World Class BP4O

  • Define a project life cycle with stage gate approvals.
  • Design, develop, deploy and support a comprehensive portfolio of tools, templates and processes to effectively support all projects.
  • Design and deploy a project review process to support project teams and monitor compliance to established standards and practices.
  • Establish a project portfolio management process to maximize the business value of project investments.
  • Establish a decision support system and dashboard to support executive management’s project decisions and provide for the timely monitoring of the project portfolio status.
  • Design, develop, deploy and support a comprehensive HR Project Management System.
  • Design, develop, deploy and support a continuous process improvement program for the BP4O.

Organizational Structure of the World Class BP4O

The only structure that makes sense to me is one where the BA/PMs are close to their client groups. That structure is what I call the “Hub & Spoke. At the Hub we have the enterprise level unit that is responsible for policy, process and staff development. At the Spokes are the various divisions and departments with their own staff of BA/PMs. They might establish tools, templates and processes specific to their needs but in compliance with the enterprise policies and processes.

Staffing of the World Class BP4O

There are five staffing models that come to mind:

  • Virtual BP4O

The Virtual BP4O does not have any BA/PMs assigned to it. Instead they are deployed throughout the enterprise where they are assigned on an as needed basis by their organizational unit. These are not fulltime project managers but are professionals in other disciplines who have project management skills and competencies as part of their toolkit.

The BP4O staff consists of a manager and one or more assistants who support BA/PMs as required. They may be BA/PMs but that is not necessary. The important thing is that this staff has the necessary expertise to provide the support needed. The support services may span the full list but are often quite restricted because of staff limitations.

  • BA/PMs are assigned to the BP4O on a rotating basis

This is an excellent model for deploying the BA/PM methodology, skills and competencies throughout the organization. In this model BA/PMs from the business units are temporarily assigned to the BP4O as a sabbatical from being on the firing line too long. A sabbatical might last from 3-6 months during which time they might conduct a specific process improvement project or simply act as mentor and coach to other BA/PMs.

  • BA/PMs assigned to the BP4O

In this structure the BP4O BA/PMs manage critical mission or enterprise-wide projects. Usually not all BA/PMs report to the BP4O. There will be several who are assigned to business units to work on less comprehensive projects for their unit.

  • BA/PMs assigned at the division level

BA/PMs assigned at the division level work on division-wide projects. These may be projects that span two or more departments.

  • BA/PMs assigned at the department level

Same as the division level except they are assigned within a department and only work on projects contained within their department.

Summary

This article is an opening gambit for me. My hope is to expand on some of the ideas expressed above in future articles. I hope that this article has provided food for thought and that you will take the time to let us have your comments.


Robert K. Wysocki, Ph.D.
, has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3nd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

The Perils of Poorly Written E-Mail

Poorly written e-mail can sabotage careers, threaten productivity, and negatively affect a company’s image, while effective e-mail increases productivity and improves the workplace environment. It is an important skill that helps people advance their careers and keeps businesses competitive.

E-mail has become the primary method of business communication, surpassing the telephone as our preferred communication tool in the workplace (Datamonitor report, September 2007). While most people already sense that this is the case, we often don’t stop to consider the implications for our careers. It’s time for employers and employees to face the reality that e-mail writing skills could make or break a career. While most of us understand that poorly written e-mail can waste time, we forget that poorly written e-mail can also create costly misunderstandings, catapult deadlines, delay deliverables, impact people’s opinion of you, and sabotage your career.

Employers should also take note: A Write It Well survey found that more than half of American workers spend a third of their day reading and responding to e-mail and nearly 75 percent said that they could make better use of that time.  Wasted time affects a company’s overall productivity and financial statements and in today’s increasingly global economy, companies rely on e-mail to allow large teams across various time zones to work together efficiently on projects. When extreme time differences are combined with various languages, poorly written e-mail can be detrimental to a project’s results and deteriorate team dynamics, both of which directly affect a company’s bottom line. Poorly written e-mail can also affect a company’s public image. In a recent Write It Well survey, a whopping eighty-eight percent of respondents said that badly written e-mail leaves a poor impression of not only the writer, but the writer’s organization as well.

In addition to image, productivity and financial problems, poorly written e-mail can have serious legal implications. IT security and control firm, Sophos, recently found that seventy percent of businesses are concerned about data leakage via e-mail, and fifty percent of employees have sent e-mail with sensitive information to the wrong person causing corporate embarrassment, compliance breaches, and the loss of business-critical information. Whether by accident or because they didn’t think carefully, people send inappropriate and damaging e-mail everyday.  “In high stakes business litigation, the first place I look for smoking gun evidence that may win (or lose) the case is the e-mail server,” said Jonathan W. Hughes, a director of the San Francisco law firm Howard Rice Nemerovski Canady Falk & Rabkin. 

Even with so much at stake, more professionals are entering the workforce without the ability to express themselves clearly in writing. According to The National Commission on Writing for America’s Families, Schools, and Colleges, schools and colleges today neglect writing and, as a result, many college graduates enter the workforce with poor writing skills. Yet, writing is a fundamental business skill. In fact, a recent survey by the Commission found that half of all companies assess writing skills during the hiring process and when making promotion decisions.

The solution is for companies to invest in business writing skills – and specifically, e-mail writing. E-mail writing is a specific skill that needs to be learned explains Terk. Our book, E-Mail – A Write It Well Guide, is a training tool designed to improve the reader’s e-mail writing skills in a very practical way. With a six-step writing plan and a focus on job relevance, readers are rewarded with immediate results. Designed for use by individuals, teams, or as part of classroom training, E-Mail – A Write It Well Guide is cost-effective and flexible.  A facilitator guide allows trainers, managers, and team leaders to lead their own e-mail workshop, and customized training programs are also available.  


Natasha Terk is President of Write It Well, a training and consulting company that helps people in the workplace communicate clearly and work together effectively. Write It Well offers step-by-step techniques to improve business writing through onsite and online training courses, as well as business writing books with companion facilitator guides. E-Mail – A Write It Well Guide, ISBN 978-0-9637455-9-0, is now available at amazon.com and bookstores nation-wide for $21.99.  Visit http://www.writeitwell.com/ for more information about Write It Well’s books, on-site training, and facilitator guides. 

Failing to Plan is Planning to Fail

There is a popular adage often attributed to Benjamin Franklin, the father of time management, “Failing to plan is planning to fail,” The quote may sound like music to your ears but planning for business analysis work is a key area which tries to zero in on the importance of planning in a software development project. Sadly, it is a step that is often overlooked.

The absence of proper planning can detrimentally affect timely meeting of the on-going project deliverables. To avoid such a failure it is vital that a project manager ensure that the requirement planning activity is given due importance, so that everything is under complete control.

So, how can a project manager ensure that a business analyst (BA) is given the power of execution to get the things delivered with the required level of quality and within the defined time frames. Let’s examine some of the key pointers essential to effective business analysis planning.

The Planning Stage

The planning stage gives a high level understanding of the intended software product. It gives the project team a pulse of the current systems and processes, while evaluating the existing deficiencies and identifying the key objectives that need to be addressed in the proposed software development activity.

The planning stage also helps the stakeholders identify the risks that may be associated with the project. Over time, the business requirements keep growing in an attempt to enhance the existing functionality. The objective of the planning stage is to make it absolutely clear – working in partnership with the client and the development teams – what full range of functions and content will be addressed.

The Kick-off Meeting

The kick-off meeting is the opening play of the project. It is an ideal occasion for the project team and the client to introduce them selves and set the project expectations and milestones. The meeting should identify the team roles across the entire spectrum of project related activities, in order to ensure that these activities get completed smoothly.

Requirements Tools and Templates

The business analyst analyses, documents, manages and presents the project requirements for review and approval to the client in a comprehensible manner. As part of the planning process, and early in the project, the BA should communicate to the customer the standard templates and requirement management tools they will adhere to, in order to document the requirements specifications.

For projects large in size and complexity, it is important to make use of requirements management tools to manage version change, track requirement status, communicate with stakeholders and reuse the requirements wherever possible.

Define Points of Contact and Escalation Hierarchy

Should there be any queries or concerns regarding any aspect of the planned project activity, it is important to define a clear process to identify the key points of contact in the project engagement with proper escalation mechanism.

The steering committee is responsible for advice on strategic direction, overseeing planning and implementation, resolving open issues, achieving the project deliverables and milestones, and for preparing a weekly project status report giving updated and accurate information as the project progresses.

The Requirements Sign-off: A Project Milestone

It is imperative that every project participant understand what the Requirements Sign-off means, and its associated impact on the project. Clients should not dismiss sign-off as meaningless, but rather consider it as an important project milestone.

Requirements sign-off means a formal agreement with the project stakeholders, stating that the contents of the requirements document, as drafted, are complete to the final projections and that there are no open issues left to be addressed.

Obtaining a requirements sign-off is typically the final task within the framework of Requirements Communication, which is an expression of the output of requirements gathering to all those concerned with the project.

Conclusion

A holistic approach is absolutely essential and indispensable for the success of the project. It takes effort to leverage and climb the ladder of success. The journey is indeed rewarding and also a voyage of discovery.


Nilesh A. Raje is a Sr.Consultant (Functional) with SYSTIME Computer Systems Ltd. SYSTIME (www.SYSTIME.net) is a leading global business provider delivering reliable, high-quality, cost-effective IT solutions and services. Nilesh has extensive experience in Business Analysis. He has a Bachelor’s Degree in Engineering and is also pursuing his Master’s in Business Administration. He has also been published earlier with International Institute of Business Analysis, a leading association in the world of business analysis, as well as in a previous issue of Project Times. In 2007, Nilesh represented his country as “The Youth Icon of India” in Brussels at the First CCS World Youth Forum in the European Parliament. Nilesh can be reached at [email protected].