The Lifecycle of Terminology Projects

There are many useful components, tools, and

processes involved in PM in order to manage a project successfully, from getting to know your stakeholders to
managing time and costs and developing soft skills. So it is not surprising that new processes and tools are
created as people learn and obtain experience. That is why, if you go to the leader in PM training—the PMBOK
Guide—it is not surprising that their latest 5th Edition has added more processes to their lifecycle. But where am I
heading to?
Well, as I mentioned in an introductory post, the PMBOK Guide was created based on learned lessons from
project managers typical of almost all projects, and their creators say that in order to manage any project
successfully we need to follow generally recognized good practices. Those practices are divided into 47
processes that overlap and interact (PMBOK Guide 4 had 42). All those processes are also divided into 5
process groups, as follows:

 Initiating: Includes the processes to create and define a really preliminary version of your project’s
scope.

 Planning: how you’ll manage all aspects of the project including scope, risk, time, cost, quality, and a
few more.

 Executing: Here’s where all the work is done.

 Monitoring and Controlling: All the stuff that was produced in the executing process is monitored and
compared to the plan and decisions are made on how to stay on track.

 Closing: Filling out the paperwork and recording what has been achieved and team is released from
responsibilities.

Many trainers, though, use 4 process groups Concept, Develop, Execute, Finish, because it’s easier to
remember C-D-E-F. And you will find that process group names also change from trainer to trainer.
If you are curious or are familiar with the previous version, Alexander Stanisic made a short presentation
explaining the changes from PMBOK 4 and 5 (see for example the new definition for stakeholders).
Also, along with the processes, there are 9 knowledge areas that describe the key competencies that project
managers must develop: Core: Scope, Time, Cost, Quality; Facilitating: Human Resources, Communication,
Risk, and Procurement; and Integration, which affects and is affected by all of the other knowledge areas.
The reason why it is important to talk about this now is because I have already talked about stakeholders, which
is part of Initiating and Executing, and I will start talking about things like the core knowledge areas such as time
and budget (cost) and quality (known as the triple constraints) that are usually mentioned in every terminology
course that you take.
 So there you have it, little by little I will be discovering a bit more about PM that will hopefully peek your curiosity
to read more.

Writing Your Terminology Project Goals

Most trainers explain the PM process using the cake analogy, and when it comes to goals it is useful to see it
from that perspective, too.

1. The goal to make a cake might seem easy, but is it?

2. Why are we making the cake? What type of cake do we want? Where will it be made? How much
money can be used on ingredients? What is the time frame for making the cake? How many people want a slice
of the cake? A simple goal of “make a cake” no longer seems sufficient.

3. Ask the questions and understand the answers to set a far more realistic and specific goal.

4. Write your goal in short, simple sentences: “Make chocolate mud cake to feed 50 people at a
birthday party in 1 month, decorated and finished one day prior for transporting to venue and at a cost of $150”.

5. There are many ways to assess goals, but the most popular and easy to use is the SMART analysis.
 A specific goal (a chocolate cake for 50 people) allows us to measure it and assess if it’s realistic given your
resources (ingredients+kitchen), allocated budget ($250), and time frame (1 month). If you don’t have an oven or
have never baked a cake, or the cake needs fancy decorating, you probably need to change your goal. It is a
simple example but the same principles apply to every project; that’s why it is used by PM trainers.
Can you extrapolate this SMART goal to a project that you have started or completed? The design of a simple
termbase, for example, could have the following SMART goal: “Design a 5-category termbase on photovoltaic
systems for x client to be completed January 31st, 2015.” What about this goal: “Our team will design 10
termbases on renewable energy, 10 of which will be completed by March 31st, 2015 and the remaining 10 on July
31st 2015, with an approved budget of $4.500, following ISO standard 704 (Terminology Work and Principles).
Follow-up meetings will be held every other Friday.” You have who, what, when and how (specific), concrete
numbers (measurable), resources, knowledge, workload (achievable), the termbase will improve efficiency
(relevant), within reasonable schedule and follow-up (time-bound).
[...] Also remember that you can always adjust your SMART goal as needed; just make sure it stays SMART.
The next step would be to properly justify your goal by writing a business case to assess the reasons why the
project should be run and prepare a feasibility study with a cost-benefit analysis. My next PM post will touch upon
that.
Sources (copied/adapted from):

1. Head First PMP, by Jennifer Green and Andrew Stellman (see my PM resources)

2. Open2Study. Principles of Project Management free online course. (Highly recommended).

3. Top Achievement. Creating SMART goals.

4. Learn Marketing SMART goals, with example.

5. Set SMART goals Wikihow (clear explanation with illustrations and examples)

Make sure you go to my PM resources to discover more.

How to Justify Your Terminology Project

Goals
In a previous post I talked about how to identify and write your SMART goals. Now we need to talk about how we
go about justifying them.
First, you need to present yourbusiness case: a start-up document for your boss/client with the pros and cons of
your project, based on the resources allocated, presenting the business issue (for example create a termbase),
identifying project options (design it yourself/expert or buy CAT tool), benefits (see my section on the benefits of
managing terminology), costs, risks, and scope. See also my section on the Terminology Business Case for
more info.
In general terms, your business case should:

1. Establish background to the proposal and its objective

2. Identify the need or problem to be addressed

3. Carry out cost-benefit analysis to decide if the investment is worthwhile

4. Include preliminary requirements and estimates

5. Analyze options and recommendations

 A project feasibility study and a report of its findings should also be carried out: Technological (do we have
enough resources?); operational (does it solve problems/are there people/social issues?); legal (are there
privacy, security conflicts?), schedule (is the timeframe reasonable?); and financial (cost-benefit analysis).
The cost-benefit analysis (CBA) is probably the most challenging of all feasibility studies. It includes an
assessment of the return on investment (ROI). You can check my section on ROI and benefits of terminology for
more information. I’m sure they will be useful if you need to prepare your case.
Once a project goal is properly assessed and it is decided that the project is indeed feasible and will benefit
you/company/client/stakeholders, then a formal authorization document is usually drawn up: the project charter,
which will lead, in its turn, to another important topic: The Triple Constraint of projects. More on that to come.
Sources and further reading:

1. Principles Project Management free online course. (Highly recommended).

2. Developing a Business Case – Fact Sheet. Tasmanian e-government

3. Factsheets and templates for initiating projects, including feasibility and business case templates.
(Tasmanian e-government).

4. Feasibility Study Fact Sheet. Tasmanian e-government

5. Sample Feasibility Study and Cost-Benefit Analysis. Vermont Government Health.

6. Excellent PowerPoint outlining main steps of Feasibility Study and Cost Benefit Analysis