Project Management

Project Termination


• A project can be said to be terminated when work on the substance of the project has ceased or slowed to the point that further progress is no longer possible

• There are four fundamentally different ways to close out a project: extinction, addition, integration, and starvation


Termination by Extinction

• The project may end because it has been successful and achieved its goals

• The project may also be stopped because it is unsuccessful or has been superseded

• A special case of termination by extinction is “termination by murder” which can range from political assassination to accidental projecticide

• Two important characteristics of termination by murder are the suddenness of project demise and the lack of obvious signals that death is imminent

• When a decision is made to terminate a project by extinction, the most noticeable event is that all activity on the substance of the project ceases


Termination by Addition

• If a project is a major success, it may be terminated by institutionalizing it as a formal part of the parent organization

• Project personnel, property, and equipment are often simply transferred from the dying project to the newly born division

• The transition from project to division demands a superior level of political sensitivity for successful accomplishment


Termination by Integration

• This method of terminating projects is the most common way of dealing with successful projects, and the most complex

• The property, equipment, material, personnel, and functions of the project are distributed among the existing elements of the parent organization


Termination by Starvation

• This type of project termination is a “slow starvation by budget decrement”

• There are many reasons why senior management does not wish to terminate an unsuccessful or obsolete project:

– Politically dangerous to admit that one has championed a failure

– Terminating a project that has not accomplished its goals is an admission of failure


When to Terminate a Project

• Some questions to ask when considering termination:

– Has the project been obviated by technical advances?

– Is the output of the project still cost-effective?

– Is it time to integrate or add the project as a part of regular operations?

– Are there better alternative uses for the funds, time and personnel devoted to the project?

– Has a change in the environment altered the need for the project’s output?


When to Terminate a Project

• Fundamental reasons why some projects fail to produce satisfactory answers to termination questions:

– A project organization is not required

– Insufficient support from senior management

– Naming the wrong person as project manager

– Poor planning

• These and a few other reasons are the base cause of most project failures

• The specific causes derive from these, fundamental issues


The Termination Process

• The termination process has two distinct parts

– First is the decision whether or not to terminate

– Second, if the decision is to terminate the project, the termination process must be carried out

• The actual termination can be planned and orderly

• Special termination managers are sometimes useful in shutting down a project

• The primary duties of the manager in charge of termination can be encompassed in nine general tasks

• Duties of the termination manager:

1. Ensure completion of the work, including tasks performed by subcontractors

2. Notify the client of project completion and ensure that delivery is accomplished

3. Ensure that documentation is complete including a terminal evaluation of the project deliverables and preparation of the project’s Final Report

4. Clear for final billings and oversee preparation of the final invoices sent to the client

5. Redistribute personnel, materials equipment, and any other resources to the appropriate places

6. Clear project with legal counsel or consultant

7. Determine what records to keep

8. Ascertain any product support requirements, decide how each support will be delivered, and assign responsibility

9. Oversee the closing of the project’s books


The Final Report- A Project History

• The final report is the history of the project

• It is a chronicle of the life and times of the project, a compendium of what went right and what went wrong

• The required information is contained in the master plan, all project audits, and evaluations

• The precise organization of the report is not of great concern; the content is

• Several Subjects should be addressed in the final report:

– Project performance

– Administrative performance

– Organizational structure

– Project and administrative teams

– Techniques of project management

• For each element covered in the final report, recommendations for changing current practice should be made and defended

• Equally important are comments and recommendations about those aspects of the project that worked unusually well

• The fundamental purpose of the final report is to improve future projects


Project Management

Project Management Processes

Project Management Processes



Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through processes, using project management knowledge, skills, tools, and techniques that receive inputs and generate outputs.

In order for a project to be successful, the project team must:

  • Select appropriate processes within the Project Management Process Groups (also known as Process Groups) that are required to meet the project objectives
  • Use a defined approach to adapt the product specifications and plans to meet project and product requirements
  • Comply with requirements to meet stakeholder needs, wants and expectations
  • Balance the competing demands of scope, time, cost, quality, resources, and risk to produce a quality product.

The PMBOK documents information needed to initiate, plan, execute, monitor and control, and close a single project, and identifies those project management processes that have been recognized as good practice on most projects most of the time. These processes apply globally and across industry groups. Good practice means there is general agreement that the application of those project management processes has been shown to enhance the chances of success over a wide range of projects.


A process is a set of interrelated actions and activities that are performed to achieve a pre-specified set of products, results, or services. The project processes are performed by the project team, and generally fall into one of two major categories:

  • The project management processes common to most projects most of the time are associated with each other by their performance for an integrated purpose. The purpose is to initiate, plan, execute, monitor and control, and close a project. These processes interact with each other in complex ways that cannot be completely explained in a document or with graphics The processes may also interact in relation to project scope, cost, schedule, etc., which are called Knowledge Areas
  • Product-oriented processes specify and create the project’s product. Product oriented processes are typically defined by the project life cycle and vary by application area. Project management processes and product-oriented processes overlap and interact throughout the project. For example, the scope of the project cannot be defined in the absence of some basic understanding of how to create the specified product.

Project management is an integrative undertaking. Project management integration requires each project and product process to be appropriately aligned and connected with the other processes to facilitate their coordination. These process interactions often require tradeoffs among project requirements and objectives. A large and complex project may have some processes that will have to be iterated several times to define and meet stakeholder requirements and reach agreement on the processes outcome.

Failure to take action during one process will usually affect that process and other related processes. For example, a scope change will almost always affect project cost, but the scope change may or may not affect team morale or product quality. The specific performance tradeoffs will vary from project to project and organization to organization. Successful project management includes actively managing these interactions to successfully meet sponsor, customer and other stakeholder requirements.

The PMBOK describes the nature of project management processes in terms of the integration between the processes, the interactions within them, and the purposes they serve. These processes are aggregated into five groups, defined as the Project Management Process Groups:

  • Initiating Process Group
  • Planning Process Group
  • Executing Process Group
  • Monitoring and Controlling Process Group
  • Closing Process Group.



أخاف انا يطول الزمن بي يا دمشق

أخاف انا يطول الزمن بي يا دمشق .. اخاف ان اعتاد الترحال …

أسهر كل مساء وأنظر للقمر وكم أتمنى لو أنني أرقبه من ذرا قاسيون … أشاهد الأمطار تهطل وكم أتمنى لو انها تنزل من مزاريب درانا العربية .. كل امسية ماطرة تذكرني بكستناء يشوى على مدفأة قديمة …

أخشى أن ينساني تراب دمشق وياسمينها … أخاف أن تلفظني أرض دمشق …

أخاف ألا يعرش الياسمين فوق أصابعي بعد اليوم …  أخاف أن يجف حبي لدمشق كما جف بردى …

كفانا بعداً يا دمشق … كفانا جفاءً … أريد ان أعود وأحضن كل ذرة تراب في قاسيونك … فهل تفتحين لي أحد أبوابك السبعة ؟

أخاف أنا أنسى صوت مآذن الأموي والشيخ محي الدين يقيم آذانه خمس مرات كل يوم … أخاف أن انسى باب كيسان وأجراس الكنيسة المريمية تقرع…

رفعت مرساتي يوماً من دمشق … ولا أريد أن أنزلها في المرة الأخيرة إلا عندها … فهل سأجد مينائها مفتوحاً !!

 أريد أن اجثو على ترابها وأقبله …  هل أنسى الدار العربية … هل أنسى حارتنا الشامية !!

هل أنسى هررة دمشق تتدافع عند اللحام عند الصباح الباكر … هل أنسى رائحة خبز التنور الطازج …

هل سيصبح حبي لدمشق سيفا مزروعا في خاصرتي لا أدري سبيلاً لأوقف نزيفه .. هل ينقطع حبل مشيمتي بالشام ؟

أتضيع الأحرف يوماً على رصيف الغربة … ام يغرق المركب الدمشقي في عاصفة هوجاء !!

سنرجع يوماً … سنعود يوما حيث انطلقنا أول مرة … سنعود إلى مرفئنا الأول حين نفضنا الغبار عن اجنحتنا أول مرة لنطير نعانق السماء ونصنع مجداً لدمشق في الخارج وننشر رواية عشق مدينة الياسمين… ولكن متى ؟

Samer Odeh

Project Management

Devil’s advocate


I am sure all of us have come across the phrase “devil’s advocate”. In general terms this is used to identify a person who keeps on arguing against the popular choice of the majority. In a decision making process if a person is keep on arguing in favour of another alternative, when there is an obvious answer available he is referred to as a devil’s advocate. This phrase has originated from Roman Catholic church in the process of declaring a deceased person as a saint. In the process of deciding whether he is worthy to be a saint or not (a process known as canonization), the church appointed a person, to argue against. His job was to look for negative aspects of the candidate’s character and prove that he is not worthy of recognising as a saint.  This function is now known as the promoter of justice.

In management studies, there is a debate among groups about the effectiveness of having a devil’s advocate in a team, when making a decision. Some say this improves the decision making process and especially brings out creative alternatives. The counter argument is that it makes a negative impact on the team since it brings in endless arguments. I agree with the first argument since it prevents a group from coming in to conclusions without considering all the available options. I am a firm believer of this and I try to implement the same as much as possible. However this is a very painful process and needs the commitment of the whole team especially the leader. Many of the times the process could end up with unpleasant arguments so the leader needs to be aware of all possible outcomes and act accordingly.

According to IMC (The Institute of Management Consultants) USA, a similar process could be adopted to review a project plan or a proposal. A person / group called as a “murder board”  or a “read team” can be used to review a project plan to identify possible break points of the plan. Obviously this is more applicable for larger complex projects involving multiple disciplines than a simple project. I will write about how we can use this concept when planning a ECM project in a separate post.

If you haven’t experienced this yet, wouldn’t it be an interesting challenge for you to be a devil’s advocate and experience the difference ?