Going From #Toastmaster to Professional Speaker–Some Things to Know

I have been in Toastmasters International for a little over two years.    I have achieved several milestones during that time: my first Icebreaker speech, followed by my first educational award (Competent Communicator), my first speech from an Advanced speech manual, my first speech contest, my first involvement in Area and Division-level meetings (as Assistant Area Governor), and the first educational award going to the person who was the first person I mentored at our club.

All of these achievements have been very gratifying for me, but none of them were a total surprise because I had planned on  achieving them.   However, a recent speaking opportunity came to me out of the blue, and that was the opportunity to actually get paid to speak.    A fellow Toastmaster was planning on her parents’ wedding anniversary, and was planning a celebration with family and friends.   She was going to be so busy at the celebration that she wanted to get a Toastmaster who a) was a good public speaker and b) was fluent in Japanese, because she is Japanese-American and many of her relatives (especially the older ones) can speak Japanese.   I was the only person she knew within Toastmasters who fit that bill–I am fluent in Japanese because I lived in Japan for five years and have worked for most of my career at Japanese companies.

So I am going to be the Master of Ceremonies at the celebration this weekend, and I have been working on my presentation the past few days.   What tips can I give to someone who is going to give a professional speech for the first time or who aspires to do so?    That’s the subject of this post.

1.  Know your room

You should visit the room or hall where you are going to speak if at all possible.   Second best would be to get a floor plan, but nothing substitutes for physically BEING THERE.    When I went over to discuss my presentation, I insisted on seeing the room the celebration was to be in.    I was shown a floor plan, but realized when I got to the actual room that it was wider than I had envisioned, meaning that I would have be turning to the side more often than I had anticipated to sweep everybody into my eye contact and gestures.

2.  Know your audience

I talked three times before the final meeting with this woman about what the purpose of the celebration was.  Yes, I know it’s a wedding anniversary celebration, but who is coming?   What generations are involved?   What is each generation’s involvement in the Japanese, American, or Hawaiian culture (since many of them live in Hawaii now)?    The answer to these questions would determine for me how much to say in Japanese vs. English, and also how much more to emphasize Hawaiian rather than Japanese culture.   I want to use enough Japanese to please the older generation, but not so much as to show up the Japanese-Americans who may have lost contact with their culture.

3.  Know your hosts

The woman putting on the celebration was going to be busy setting up several commissioned art pieces that celebrated her parents’ anniversary.    My job therefore was to make her job easier by explaining some of the background of these pieces and the significance of the art in terms of Japanese and/or Hawaiian culture.   This would allow her to realize that the older generation would recognize HER effort to keep in touch with their culture, but also clue the younger generation to the beauties of a culture that they might have started to lose touch with.

4.  Know your guest of honor

I had a chance to meet her parents and know how important it talk about the year they were married, 1963, in a way that would evoke memories that would emphasize the long journey they have made since then.   So my remarks talk about leaving a legacy with is … the people sitting in that room, their immediate and extended family.   I know that emphasizing the family connections rather than just focusing on the two of them as a couple would please them more, based on what the host told me about their personalities.

5.  Know your schedule

I have a list of the main events:  the entrance, the dinner, the art work unveiling, the dessert and toast, and I have written remarks for all the places where I need to step in and give a transition.   I have marked some empty spaces as possible areas where I may need to improvise a transition if it is called for and am thinking ahead with remarks that could possibly fill in those spaces.

6.  Know your purpose

I will start with an introduction of myself, not because I want to focus on myself, but because I want to establish that I too have a relationship with the host as a fellow member of a Toastmasters club.    A Distinguished Toastmaster or DTM once told me that as a beginning Toastmaster, you tend to be concerned about getting across your message more than you are about establishing a relationship with the audience, but this is a mistake.   You need to establish a rapport first, and then the message will flow.    If they care about you as a human being rather than as the role that you are playing, then they will truly listen to what you have to say.    Your purpose as the MC is not to draw attention to yourself, but to take the attention that you can and focus it towards the guests of honor, in this case, this woman’s parents.

7.  Know yourself

The reason why I became a Toastmaster was to be able to touch people, to inspire people, to persuade people, based on the power of words.   But the leadership aspect of Toastmasters gradually becomes more important the more you get involved in the organization, and I can truly say that I am less and less interested in appearing clever and smart in front of others, and more about encouraging others to feel that they are clever and smart by stimulating them to think and feel something that they might not have done otherwise.

I hope my first professional speaking engagement is a success, but I think that all the points I mentioned above are ones that I have learned throughout the two years in speaking at various Toastmasters events.    The difference of someone actually paying me to do it, is a gesture of appreciation that is, of course, very gratifying.   But hearing applause and seeing smiles on people’s faces is a form of repayment that will be gratifying as well!



5th Edition PMBOK® Guide–Chapter 5: Validate Scope

One quick post I wanted to add about the process 5.5. Validate Scope is that in the 4th Edition PMBOK® Guide, the process of checking whether deliverables meet the acceptance criteria is called something different whether it is

–the internal checking within the project done as part of Quality Management, or

–the external checking with the customer or sponsor as part of Scope Management.

  Knowledge Area 4th Edition

PMBOK® Guide

5th Edition

PMBOK® Guide

Internal checking Quality Validate Scope Verify Scope
External checking Scope Verify Scope Validate Scope


In the 4th Edition, the first is referred to as validating the scope, and checking with the customer is verifying the scope.

Unfortunately, in the 5th Edition, the definitions are switched around.  The internal checking is referred to as verifying the scope, and checking with the customer is validating the scope.

I normally don’t like to compare the two different versions of definitions from the 4th and 5th Edition of the PMBOK® Guide, to avoid confusion, but in this case I thought it was important because those who are studying for the 5th Edition test might be taught by somebody who learned from an earlier edition, and you need to know that the earlier terminology is out there.  So be forewarned!

5th Edition PMBOK® Guide—Chapter 5: Work Breakdown Structure

1. Introduction

The Work Breakdown Structure is a fundamental tool of project management which is formed as an output of the process 5.3 Create WBS. It is one of the three elements of the scope baseline.

Table 1.  Three Elements of the Scope Baseline

Element Name Process
1. Project Scope Statement Output of 5.3 Define Scope
2. WBS Output of 5.4 Create WBS
3. WBS dictionary Output of 5.4 Create WBS

The work breakdown structure can be pictured like an organizational chart, with the highest level being the project itself, and the various levels under that consisting of increasingly more detailed breakdowns of the scope of the project.

For example:

Although it can take the form of an organizational chart, it does not show who does the work, but simply displays the hierarchy of the various levels of decomposition of the scope.

2. Decomposition technique

The techniques of decomposition means subdividing the project scope and project deliverables into smaller, more manageable components to the level of work packages. Here’s how the project is broken down through the decomposition process.

Figure 1. Work Breakdown Structure Levels (from program to deliverables)

a. Programs are groups of related projects.

b. Projects can sometimes be broken down into distinct phases.

c. Major deliverables are first identified within each phase.

d. That work which can be outsourced to a contractor is referred to as a subproject.

e. Deliverables are broken down from the major deliverables.

Figure 2. Work Breakdown Structure Levels (from deliverables to activities/tasks)

f. Once deliverables are identified, for large-scale projects planning packages are identified which are basically fill-in-the blank packages for work that has not yet been identified, but will be in the course of progressive elaboration.

g. A control account is a summary level in WBS one level above a work package. Once a group of work packages under a control account are completed, some sort of monitoring & controlling activity is done here to make sure the project is proceeding according to plan.

h. Work package is the lowest level in a work breakdown structure which both defines specific deliverables and those resources (people, equipment, etc.) assigned to complete the work (through the WBS dictionary).

i. The work package, which specifies the smallest unit of deliverables, is further broken down into activities during the process 6.1 Define Activities. In some companies with large work packages, the activities can be further broken down into …

j. Tasks, but this is sometimes a confusing term because some companies have tasks at a higher level than activities. So for the purpose of the PMP exam, just focus on activities as the steps taken to produce the deliverable within each work package.

3. Work Breakdown Structure—What is it for?

The work breakdown structure is to the project what the blueprints are to the product, a guide for getting it realized. Although I have listed the WBS under Scope Management, because it helps prevent unnecessary changes to the project (also known as preventing scope creep), but it helps in EVERY knowledge area.

Project Management Area How does WBS help the Project Manager?
4. Integration Management Helps the project management team see the entire project laid out in a single diagram.
5.. Scope Management Helps prevent unnecessary changes.
6 Time Management Helps create realistic basis for estimating schedule.
7 Cost Management Helps create realistic basis for estimating costs.
8 Quality Management Helps focus work on what needs to be done at the right time, increasing quality. If problems do occur, assists process improvement by making it easier to isolate root cause.
9 HR Management Creating the WBS as a team helps build the team and creates a sense of active participation that lasts throughout the project.
10 Communications


Helps explain the project to stakeholders and helps project team members from different functional areas to cooperate with each other.
11 Risk Management Makes it easier to identify risks by making the work steps and work sequence easier to understand.
12 Procurement


Helps identify those work packages which cannot be done with current company resources and/or expertise level.
13 Stakeholder Management Helps manage stakeholder engagement by helping to explain the impacts of changes suggested by stakeholders.

So, in conclusion, with all of these benefits, why wouldn’t you make creating a WBS one of the key parts of your planning process?

5th Edition PMBOK® Guide—Chapter 5: Requirements Documentation

1. Introduction

The Project Scope Management knowledge area contains 6 processes, 4 of them in the Planning Process Group and 2 of them in the Monitoring & Controlling Process Group. The first planning process is that which creates the Scope Management Plan. The next 3 planning processes go from 5.2 Collect Requirements, where the requirements from key stakeholders are collected and analyzed, to 5.3 Define Scope, where the high-level scope from the Project Charter is defined in more detail in the Project Scope Statement, and finally to 5.4 Create WBS, where the detailed scope is broken down through the process to deliverables down the level of work packages.

This post goes into some detail of the two outputs of the first of these three planning processes, 5.2 Collect Requirements: Requirements Documentation and Requirements Traceability Matrix.

2. Requirements Documentation and the Requirements Traceability Matrix

How are these two outputs different?

The Requirements Documentation is the collection of the requirements from various stakeholders. The Requirements Traceability Matrix is the connection between the requirements, the stakeholders who originated them on the one hand, and the project deliverables which will fulfill them.

3. Requirements Documentation

The following is a list of the categories of requirements, together with an explanation of what purpose they serve, and a list of examples of these types of requirements.

Category Explanation Examples
1.1. Business requirements Higher-level needs of the organization. Business and project objectives
1.2 Business rules for the performing organization
1.3 Guiding principles of the organization
2.1 Stakeholder requirements Needs of various stakeholders Impacts to other organizational areas
2.2 Impacts to other entities
2.3 Stakeholder communication and reporting requirements
3.1 Solution requirements Features, functions, and characteristics of product. Functional (behaviors of product) and non-functional requirements (environmental conditions for product).
3.2 Technology and standard compliance requirements
3.3 Support and training requirements
3.4 Quality requirements
3.5 Reporting requirements (with texts, models, etc.)
4.1 Project requirements Actions, processes, or other conditions of product Levels of service, performance, safety, compliance, etc.
5.1 Transition requirements Temporary capabilities required to utilize product Data conversion, training requirements
6.1 Quality requirements Condition or criteria needed to validate successful completion of project deliverable. Acceptance criteria
7.1 Requirements boundaries Describes assumptions behind requirements, and interactions between requirements. Requirements assumptions, dependencies, constraints

4. Requirements traceability matrix

The requirements are traced back to the stakeholders who originated them. This is so that these stakeholders can be consulted if there is any change to the project which would affect these requirements. The requirements are traced to the external business needs and the internal strategic plan of the organization.

Finally, the requirements are translated into the overall project objectives, and then the detailed deliverables. Within the organization, the requirements are linked to the various life cycles of the product development and the functional areas of the organization that handle them.

The purpose of this matrix is to enable the analysis of the potential impact of any changes in the scope of the project as the project goes forward.

The requirements of the stakeholders are translated into the deliverables of the project through the creation of the Work Breakdown Structure, or WBS, which is the subject of the next post.

5th Edition PMBOK® Guide—Core Performance Concepts #CPC Webinar

On March 13, 2013, the PM training and education company Core Performance Concepts put on a webinar in which Kristine Munson, PMP, presented a summary of the changes involved in the 5th Edition PMBOK® Guide. I have already written extensively on these changes, but I attended the webinar to get a project management professional’s viewpoint on the subject.

1. Changes in the 5th Edition Guide

The changes to the PMBOK® Guide reflect the current consensus regarding project management knowledge and practices, so there is emphasis on the role of PMOs, and the practice of agile methodology (especially in IT). There has been an attempt to create consistency between the Project, Program, and Portfolio Management standards, and clarity of terminology within each standard.

2. New Knowledge Area

The biggest change, however, is the creation of a 10th knowledge area, Project Stakeholder Management, which is the first new knowledge area in over 10 years. This was previously included as part of Project Communications Management.

So in essence, Communications Management in the 4th Edition was split into two, creating the Communications Management and the Stakeholder Management knowledge areas in the 5th Edition.

The goal is not just to communicate, but to effectively engage the stakeholder in key project decisions as early as possible in the development of the project.

Communication and engagement with stakeholders are separate but intertwined subjects. Now Communications Management focuses more singly on communications needs and activities on a project.

Here are the processes involved in Stakeholder Management.

Process No. Process Name Explanation
13.1 Identify Stakeholders Same as before in 4th edition when it was under Communications Management.
13.2 Plan Stakeholder Management Having identified stakeholders in process 13.1, you now develop strategies on how to engage stakeholders and manage their expectations. This determines what information needs to be distributed to the various stakeholders.
13.3 Manage Stakeholder Engagement Communicating and working with stakeholders to increase support and minimize resistance. Issue logs and change requests are tools of this process.
13.4 Control Stakeholder Engagement Monitoring and controlling (adjusting) stakeholder engagement strategy.

Now the Communications Management processes are as follows:

Process No. Process Name Explanation
10.1 Plan Communications Management The stakeholder register from process 13.1 Identify Stakeholders is used as an input, and the output is the Communications Management Plan.
10.2 Manage Communications

(previously called Distribute Information)

Creation and distribution of project communications such as:

  • Performance reports
  • Status reports
  • Costs incurred
10.3 Control Communications (previously called Report Performance) Monitoring of communications to make sure stakeholder information needs are met.

3. ITTOs (inputs, tools and techniques, and outputs)

The business rules on how ITTOs are handled have changed. An input is now any document used in the process. An output must map as an input to another process. The sequence of the listing of inputs has changed: first subsidiary plans, then project documents, then the “generic” inputs of EEFs and OPAs.

Meetings were added as a tool in many project management processes.

4. New Planning Processes

Four planning processes were added: 1 of them having to do with stakeholder management (see process 13.2 Plan Stakeholder Management in chart above), and the three planning processes for the three main constraints of scope, time, and cost.

5. Process Titles Harmonized

The titles of many processes were harmonized so that they are more consistent internally (i.e., Monitoring & Controlling Processes are now often called Control “X”, where “X” is the name of the knowledge area covered).

6. Changes (by chapter)

Finally, Kristine went through each chapter of the 5th Edition PMBOK® guide and demonstrated the changes in each chapter.

Chapter Title Changes in 5th Edition
1 Introduction Definitions are harmonized between

project, program, and portfolio standards.

2 Organization Influences and Project Life Cycle Reorganized for clarity. Emphasis on necessity to understand business case for project. Lifecycle descriptions added: predictive, iterative, incremental, adaptive (agile).
3 Project Management Processes Process details now in appendix
4 Project Integration Management Differentiates between project management planning documents (subsidiary plans) and project documents (issue logs, stakeholder registers, etc.)
5 Project Scope Management Plan Scope Management is a new process. Collect Requirements includes categories of requirements: business, stakeholder, solution, transition, project, quality. Traceability matrix added to make sure all requirements for a deliverable are met.
6 Project Time Management Plan Schedule Management is a new process. Example of critical path calculation is given. Distinction made between resource smoothing (does not impact critical path) and resource leveling (delays project).
7 Project Cost Management Plan Cost Management is a new project. Management and contingency reserves more clearly differentiated. Earned value calculations and definitions are now summarized.
8 Project Quality Management New figures describe the 7 quality tools in detail. More care taken to distinguish quality assurance and quality control. Mapping between plan-do-check-act (PDCA), initiate-plan-execute-control-close (IPECC), and 5 PM process groups.
9 Project Human Resources Management Updated definitions. Expanded discussion of advantages and disadvantages of virtual teams.
10 Project Communications Management Old Communications Management knowledge area split into new Communications Management + Stakeholder Management (processes described in previous chart).
11 Project Risk Management Shifted terminology from “positive risk” to “opportunity”. More expansive definitions or risk attitude, appetite, tolerance, thresholds.
12 Project Procurement Management Former “Administer Procurements” process name changed to “Control Procurements.
13 Project Stakeholder Management New knowledge area (processes described in previous chart).

I think Kristine Munson did an excellent job of encapsulating in 1 hour the changes that took PMI 4 years to make! I also thank Diane Altweis and Janice Preston of Core Performance Concepts for putting on this series of webinars, which are very informative and give great capsule summaries of many subjects in Project Management. I definitely recommend that you subscribe to the series!

5th Edition PMBOK® Guide—Chapter 5: Process 5.6 Control Scope

This process is probably one of the most crucial when it comes to maintaining the scope baseline and only changing it when necessary. If the scope is expanded in an uncontrolled manner, this is called “scope creep” and something which the Project Management Institute wants project managers to avoid.

The following is a summary of the inputs, tools & techniques, and outputs of the 5.6 Control Scope process. The inputs have to do with the scope, change, configuration and requirements management plans, the only tool and technique used is that of variance analysis, and the outputs have to do with updates to the scope management-related plans and documents.

1. Project Management Plan The following elements are inputs to the process:

  • Scope baseline—compared to actual results to determine if a change request is necessary
  • Scope management plan—describes how the project scope will be monitored and controlled
  • Change management plan—defines the process of managing change requests on a project
  • Configuration management plan—defines items that are configurable, those items that require formal change control, and the process for controlling changes to such items
  • Requirements management plan—describes how project requirements will be analyzed, documented, and managed
2. Requirements Documentation Well-documented requirements make it easier to detect any deviation in the scope agreed for the project or product.
3. Requirements traceability matrix Helps detect the impact of any change or deviation from the scope baseline.
4. Work performance data Number of change requests received, the number of change requests accepted, number of deliverables completed.
5.. OPAs
  • Scope-related policies, procedures, guidelines
  • Monitoring and reporting methods and templates
1. Variance analysis Used to determine the cause and degree of difference between the baseline and actual performance.
1. Work performance information How the project scope is performing compared to the scope baseline.
2. Change requests Analysis of scope performance can result in a change request to the scope baseline, or a change such as defect repair, corrective action, or preventive action.
3. Project management plan updates
  • Scope baseline updates
  • Cost and schedule baseline updates
4. Project documents updates
  • Requirements documentation
  • Requirements traceability matrix
5. OPA updates
  • Causes of variance
  • Corrective actions taken
  • Lessons learned from scope control

This is the last process in the Scope Management Area.

5th Edition PMBOK® Guide—Chapter 5: Process 5.5 Validate Scope

The basic idea of the process is to take the deliverables which have been internally checked in process 8.3 Control Quality to see whether they meet the customer’s requirements, and then actually present them to the customer for formal acceptance, which means to validate them. These are the interim deliverables, of course; the final deliverables are formally accepted as part of the 4.7. Close Project or Phase Process.

NOTE: The 5th Edition PMBOK® reverses the definitions of verify and validate scope that were used in the 4th Edition. In the 4th Edition, validate means to check internally and to verify means to verify with the customer; in the 5th Edition, the reverse is true.

Here’s a summary of the inputs, tools & techniques, and outputs of the Validate Scope process.

1. Project Management Plan Contains Scope Management Plan which specifies how formal acceptance of the completed project deliverables will be obtained.
2. Requirements Documentation Lists all the project, product, and other types of requirements for the project and product, along with their acceptance criteria.
3. Requirements traceability matrix Links requirements to their origin and tracks them throughout the project life cycle.
4. Verified deliverables Completed and checked internally for correctness through the Control Quality process.
5.. Work performance data Includes degree of compliance with requirements, number and severity of nonconformities.
1. Inspection Measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria.
2. Group decision-making techniques Used to reach a conclusion when the validation is performed by the project team and other stakeholders.
1. Accepted deliverables Deliverables that meet acceptance criteria are formally signed off and approved by the sponsor or customer.
2. Change requests Deliverables that do not meet acceptance criteria are documented, along with the reasons for their nonconformance. These deliverables may require a change request for defect repair.
3. Work performance information Information about which deliverables have been started, their progress, which deliverables have been finished, or which have been accepted.
4. Project documents updates Documents that define the product or report status on product completion.

If the deliverables are accepted, then the project continues as before; however, if the deliverables are not accepted, then change requests are generated which will bring the deliverables in line with the customer’s requirements.

The next process is 5.6 Control Scope, which is covered in the next post.

5th Edition PMBOK® Guide—Chapter 5: Process 5.4 Create WBS

The WBS or work breakdown structure takes the scope as outlined in the project scope statement and breaks it down into more manageable components called deliverables.  It serves as a graphical illustration of the structure of the project and is thus useful as a communication tool for explaining the project to key stakeholders.

Here is a summary of the inputs, tools & techniques, and outputs of the process.

1. Scope Management Plan Tells how to create the WBS from the project scope statement and how the WBS will be maintained and approved.
2. Project Scope Statement Describes the work that is to be performed and the work that is excluded.
3. Requirements Documentation Essential for understanding what needs to be produced as a result of the project and what needs to be done to produce the final product
4. EEFs
  • Industry-specific WBS standards
5.. OPAs
  • Policies, procedures and templates for the WBS
  • Project files from previous projects
  • Lessons learned from previous projects
1. Decomposition Technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts.
2. Expert judgment Used to analyze the information needed to decompose the project deliverables down into smaller, more manageable parts.
1. Scope baseline Consists of three elements

  • Project scope statement
  • WBS
  • WBS dictionary
2. Product documents updates
  • Requirements documentation

It is a hierarchical decomposition of the total scope of the work, with the lowest level of the decomposition being work packages. The activities to create these work packages are done in the first process of the Time Management Knowledge Area, 6.1 Define Activities, and so process 5.4 Create WBS and 6.1 Define Activities are often profitably combined into one process.

The next process in the Scope Management knowledge area takes us to the Monitoring & Controlling Process Group with the process 5.4 Validate Scope. That is the subject of the next post.

5th Edition PMBOK® Guide—Chapter 5: Process 5.3 Define Scope

After the process 5.2 Collect Requirements, which takes the high-level requirements and needs of the key stakeholders and analyses them, in the process 5.3 Define Scope they are then used to create a detailed description of the project and product, which is called the project scope statement.

Here is an overview of the inputs, tools & techniques, and outputs used in the process.

1. Scope Management Plan Establishes activities for developing, monitoring, and controlling the project scope.
2. Project Charter Provides the high-level description and product characteristics.
3. Requirements Documentation This will used to select the requirements that will be included in the project.
4. OPAs
  • Policies, procedures and templates for a project scope statement.
  • Project files from previous projects
  • Lessons learned from previous phases or projects
1. Expert judgment Used to analyze the information needed to develop the project scope statement.
2. Product analysis For projects that have products as a deliverable, product analysis can be a useful tool for translating high-level product descriptions into tangible deliverables.
3. Alternatives generation Develops many potential options as possible in order to identify different approaches to perform the work of the project.
4. Facilitated workshops These intensive working sessions help to reach a cross-functional and common understanding of the project objectives and its limits.
1. Project scope statement Detailed description of the project scope, including major deliverables, assumptions, and constraints. It documents the project scope and the product scope, and describes the project’s deliverables and the work required to deliver them.
2. Project documents updates The following project documents may be updated as a result of this process:

  • Stakeholder register
  • Requirements documentation
  • Requirements traceability matrix

One of the things to realize about the Define Scope process is that the process 5.2 Collect Requirements represents the “universe” of requirements from which the final project requirements will be chosen.

The Define Scope takes the high-level product descriptions, assumptions and constraints, which were documented in the process 4.1 Develop Project Charter during the initiating process group, and creates from them a more detailed description of the scope in the Project Scope Statement.

It is possible that in the first pass through this process, the project scope may not be fully defined. As additional risks, assumptions and constraints are added, so the project scope may be revised or updated as necessary as part of the iterative process of developing the project scope.

So the process goes from high-level requirements to detailed requirements from the customer and major stakeholders, and these are translated into major deliverables and then detailed deliverables which the organization will deliver as the goal of its project in order to fulfill those requirements.

I have included the numbers of the project management processes above the stages of the development of the scope.

The next process, 5.4 Create WBS, goes to the final level of the development of the scope, the deliverables in the form of work packages which are the components of the Work Breakdown Structure. The overview of that process will be the subject of the next post.

#FSI Language Courses Are Restored!

On March 3rd I wrote a blog post about the fact that the Foreign Service Institute language courses website fsi-language-courses.org was down.  I found I was not alone in noticing this and missing the access to these courses that were in the public domain.

As I mentioned in my previous post, I had used the Advanced courses for various European languages and was now going through the various modules of the Standard Chinese: A Modular Approach course.

Jennifer Wagner at the website ielanguages.com commented on my blog today telling me that the foreign languages, including the audio files, were now available at a site called fsi.antibozo.net.

I checked this site out, and it is true that the courses and audio files are all there from the original FSI site. I’m putting this blog post out as a public service to those who had linked to my recent blog post lamenting the disappearance of these courses.

I just linked to the site and downloaded the files for the Module 4 of the Standard Chinese course, and was preparing to do some housework while listening to the files. I find that, besides language learning, the audio files for the course are great for practicing in the following situations:

  1. Commuting—I live in LA where the daily commute is one of the banes of our existence. However, if you listen to FSI language course audio files and practice them while you drive, the drudgery of waiting in traffic goes away. And if you do get frustrated, you now have the choice of another language in which to curse at the other drivers!
  1. Housework—Another task that is necessary but boring is housework. I have found that if I schedule myself to complete one audio tape while doing housework, that it causes me to get the work done more efficiently because my mind is occupied with language learning and doesn’t have any mental room left to complain about what I have to do.
  1. DMV and other bureaucracies—When you have to wait in line at a government office, or a doctor’s office, just plug in your iPhone and practice your language while you are waiting to be called. The time goes by so much more quickly that way!

These are just some ways that you can carve time into your day for language learning, which so many of my friends say they want to do, but they can’t because they don’t have it. If you don’t have the time, create it!