Logical Framework Approach /ZOPP /OOPP

http://lgausa.com/logframe_approach.htm#Particip_anal

Logical Framework Approach, ZOPP, and OOPP - What and Why
The two terms Logical Framework (LF or Logframe) and the Logical Framework Approach (LFA) are sometimes confused. The LogFrame is a document, the Logical Framework Approach is a project design methodology.
Note: For most purposes the three terms; Logical Framework Approach, ZOPP and OOPP are terms for the same project design methodology or process. The terms OOPP and ZOPP mean respectively; Objectives Oriented Project Planning and in German Ziel Orientierte Projek Planung. All three terms refer to a structured meeting process which we will refer to as LFA.
The logical framework document is a 4 column by 4 row matrix. The cells of the matrix contain text that succinctly describes the most important features of a project. If the correct process (LFA) was used to develop the content of the logframe, the document will reveal the quality of the design and make flaws readily apparent. (Follow this link for a detailed explanation of the Logical Framework document - often referred to as the "Project Matrix")
Return to top of page
The LFA as a design methodology is described briefly on this page. The design methodology is a rigorous process, which if used as intended by the creators will impose a logical discipline on the project design team. If the process is used with integrity the result will be a high quality project design. The method is not without it's limitations, but most of these can be avoided with carefull use of ancilliary techniques. Many things can go wrong in the implementation phase of a project, but if the design is flawed, implementation starts with a severe handicap. The mind map diagram at the top of this page shows typical steps in the design process. The first few steps are:
situation analysis
stakeholder analysis
problems analysis
We might note that one common misuse of the logframe is to design the project first and attempt to "fill in" the logical framework matrix as an after thought. This defeats the whole purpose of the logical framework and the design methodology.
Return to top of page
Where's the logic?
There is a logical connection between the cells of the matrix. The logic that connects the cells in the left most column, is referred to as the vertical logic; the logic that connects the remaining three columns is referred to as the horizontal logic.
The vertical logic is the hierarchy of objectives of the project.
The horizontal logic is rather more involved. For a given level of objective (equivalent to a horizontal row of cells) the horizontal logic describes:
how the achievement of the objective will be measured or verified
how this information will be obtained
what are the external factors that could prevent the project manager and staff from achieving the next level objective.
Situation Analysis
This is a document that describes the situation surrounding the problem. The source could be a feasibility study, a pre-appraisal report, or be a compilation done specifically for the project design workshop. Typically the document describes the problem situation in detail, identifies the stakeholders and describes the effects of the problems on them.
Stakeholder or Participation Analysis
This stage is an analysis of the people, groups, or organizations who may influence or be influenced by the problem or a potential solution to the problem. This is the first step to understanding the problem. We might say, without people or interest groups there would be no problem. So to understand the problem, we must first understand the stakeholders. The objectives of this step are to reveal and discuss the interest and expectations of persons and groups that are important to the success of the project.
Return to top of page
Problem Analysis
If there is no agreement between participants on the statement of the problem, it is unlikely there will be agreement on the solution. This stage therefore seeks to get consensus on the detailed aspects of the problem.
The first procedure in problem analysis is brainstorming. All participants are invited to write their problem ideas on small cards. (approximately 8 in by 4 in.) The participants may write as many cards as they wish. The participants then group the cards or look for cause-effect relationship between the themes on the cards by arranging the cards to form a problem tree.
Objectives Analysis
In this step the problem statements are converted into objective statements and if possible into an objective tree. Just as the problem tree shows cause-effect relationships, the objective tree shows means-end relationships. The means-end relationships show the means by which the project can achieve the desired ends or future desirable conditions. Frequently there are many possible areas that could be the focus of an "intervention" or development project. The next step addresses those choices.
Alternatives Analysis
The objective tree usually shows the large number of possible strategies or means-end links that could contribute to a solution to the problem. Since there will be a limit to the resources that can be applied to the project, it is necessary for the participants to examine these alternatives and select the most promising strategy. After selection of the decision criteria, these are applied in order to select one or more means-end chains to become the set of objectives that will form the project strategy.
Return to top of page
Activities Planning
After defining the objectives, and specifying how they will be measured (OVIs) and where and how that information will be found (MOVs) we get to the detailed planning phase. We now determine what activities are required to achieve each objective.
Where to start?
This is a little like the chicken and the egg problem. It is tempting to say; always start at the situation analysis stage, and from there determine who are the stakeholders. Another argument is that the stakeholders define the problem so it is necessary to start with identifying the stakeholders. Each problem situation will require a different approach.
Where to go next?
The next step will be implementation planning and implementation.

Learning Expert Blog

http://marciaconner.com/blog/?p=656

Learn, Unlearn, and Relearn

The secret to learning new things is to be willing to unlearn--even if your behaviors previously brought success.

One summer in college I canvassed for a local non-profit. We went door to door telling people about the organization and asking them to sign various petitions. I recited my spiel a hundred times. "Hi, my name is Marcia and I'd like five minutes to tell you a little about..."

Halfway through the season my boss asked me to insert a slice of bologna in one shoe. I followed his request, but only after considering telling him where to stick the lunch meat.

At the first house we visited, I physically couldn't say my opening the same way. The bologna distracted me enough so that I needed to reflect on e-v-e-r-y word. The next day, without the bologna, my approach was still fresh, engaging, and more successful than it had been two days before. I had unlearned, and I had relearned.

Unlearning can be a one-shot (one-shoe?) deal or a daily practice. It can help you become open to new skills, experiences, behaviors, and knowledge. Although you can't physiologically unlearn anything--literally erase existing neural pathways--you can create the equivalent of a mental attic and put a sign on the door that reads, "Things I know no longer so." Then you can shift your focus to the edge of what you knew and transition from managing your knowledge to participating in the flow. Here's how.

Begin at the beginning. In order to pick up a new skill, even if it's similar to something you already can do, learn what makes it different. All of us repeat things that worked in the past, even when they don't apply to the now. Repeating isn't always a bad strategy, but when there is a significant difference, the old approach holds you back.

I'll never forget a husband-and-wife team who came to me to learn how to kayak. The guy was a canoeist and he just wouldn't set aside what he knew about canoeing in order to learn about kayaking. He spent his early lessons trying to compare the two types of boats and tried repeating canoe strokes he was certain would work. As a result, he continually found himself facing the bottom of the swimming pool where our class took place. What he knew already wasn't as useful as what he needed to learn fresh. Meanwhile, his wife, a complete novice, made significant progress from the first day.

Stay open. Unlearning doesn't require you to toss out all your accumulated experiences or presume previous know-how will keep you from success. Rather, it asks that you stay open to different ways of getting things done.

What happens when you begin a new job? You learn about the new organization and the department where you'll work while you unpeel the mindset and procedures of the groups you just left. Your refusal to unlearn old rules (for instance, comparing everything to the way it worked at the old company) leaves you out of the corporate culture and keeps you from getting a clear sense of the job. By thinking, "This is how we did it where I used to work," you miss learning opportunities and you avoid moving in. If you go in looking at how the new organization works, thereby replacing your old activities with new ones, you systematically begin to forget what's no longer useful and you begin to prepare for what's next.

Look for mirrors. Make it easy for your boss, coworkers, employees, family, and friends to give you guidance by asking for it. The more people you have in your life who help you reflect on your behaviors, the greater your chance to gain an accurate sense of how other people perceive you and which actions to unlearn.

During Friday lunch meetings with his team members, John Seely Brown (when he was still working at Xerox PARC) focused on what they did well, what they did wrong, and what they learned from it all. A primary objective was to help the team learn and unlearn. One day, team members remarked that whenever they saw John make a certain face in response to someone's idea, it was obvious that the idea didn't stand a chance. John had the next meeting videotaped. Sure enough, he saw for himself that he did sometimes wear a disapproving expression. From then on, whenever that feeling washed over him, he worked to change his facial expression and to listen more attentively to the other person's views.

Examine your beliefs. Your beliefs determine your behavior and it's difficult to act inconsistently with your beliefs for very long. When you believe you already know the right way to do things, everything else can seem wrong. Why then would you want to unlearn what you're currently doing, let alone replace it with something else?

A company I work with needed a way to ready the industry for their offerings and increase the firm's name recognition. Their research and publications team seemed suited for the task. Although widening the market and strengthening brand was far more lucrative than the sales the team brought in by selling papers, the group refused to give anything away. They believed what they were doing was right; that people wouldn't value the research as much if it was freely available, and that clients preferred paper copies to online versions. No matter how many times the CEO told them to blanket the marketplace with information, they continued to do what they'd always done. Then we sent them all to an industry event where they spent time asking questions and challenging their beliefs. Something almost magical happened. The people they met expressed their appreciation for the company's reports, asking if they could have the rights to reproduce and then distribute the research to their customers, too. Within a few days the team developed a new set of beliefs around their value to the industry. They began behaving like a team of market researchers and industry evangelists rather than a product group generating sales for one company.

So what are you going to unlearn first? Create a list of several approaches. Write it your journal or on a sticky note to post on the computer, the television, the dashboard, or your desk--then buy yourself a few slices of bologna.

All Project Management

http://allpm.com/modules.php?op=modload&name=News&file=index&catid=&topic=48

Accountability -
The obligation to report on one's actions.

Activity -
Any work performed on a project. May be synonymous with task but in some cases it may be a specific level in the WBS (e.g., a phase is broken down into a set of activities, activities into a set of tasks). An activity must have duration and will result in one or more deliverables. An activity will generally have cost and resource requirements. See Task.

Actuals -
The cost or effort incurred in the performance of tasks. Also, the dates tasks have been started or completed and the dates milestones have been reached.

Analogous Estimating -
Estimating using similar projects or activities as a basis for determining the effort, cost and/or duration of a current one. Usually used in Top-down Estimating.

Assumption -
Something taken as true without proof. In planning, assumptions regarding staffing, complexity, learning curves and many other factors are made to create plan scenarios. These provide the basis for estimating. Remember, assumptions are not facts. Make alternative assumptions to get a sense of what might happen in your project.

Authority -
The ability to get other people to act based on your decisions. Authority is generally based on the perception that a person has been officially empowered to issue binding orders. See Power.

Baseline -
A point of reference. The plan used as the comparison point for project control reporting. There are three baselines in a project—schedule baseline, cost baseline and product (scope) baseline. The combination of these is referred to as the performance measurement baseline.

Bottom-up Estimating -
Approximating the size (duration and cost) and risk of a project (or phase) by breaking it down into activities, tasks and sub-tasks, estimating the effort, duration and cost of each and rolling them up to determine the full estimate. Determining duration through a bottom-up approach requires sequencing and resource leveling to be done as part of the scheduling process.

Budget -
The amount allotted for the project that represents the estimate of planned expenditures and income. The budget may be expressed in terms of money or resource units (effort).

Business Case -
The information that describes the justification for the project. The project is justified if the expected benefits outweigh estimated costs and risks. The business case is often complex and may require financial analysis, technical analysis, organization impact analysis and a feasibility study.

Calendar Date -
A specific date shown on the calendar (e.g., July 3, 1942) as opposed to a relative date. See Relative Date.

Change -
Difference in an expected value or event. The most significant changes in project management are related to scope definition, availability of resources, schedule and budget.

Change Control -
The process of managing scope, schedule and budget changes to the plan. See Scope Change Control.

Change Request -
A documented request for a change in scope or other aspects of the plan.

Client -
The person or organization that is the principle beneficiary of the project. Generally the client has a significant authority regarding scope definition and whether the project should be initiated and/or continued.

Closing -
The process of gaining formal acceptance for the results of a project or phase and bringing it to an orderly end, including the archiving of project information and post-project review.

Consensus -
Unanimous agreement among the decision-makers that everyone can at least live with the decision (or solution). To live with the decision, one has to be convinced that the decision will adequately achieve objectives. As long as someone believes that the decision will not achieve the objectives, there is no consensus.

Constraint -
A restriction or limitation that influences the project plan. For example, a target date may be a constraint on scheduling. A schedule may be constrained by resource limitations.

Content Expert -
See Subject Matter Expert (SME).

Contingency Reserve -
A designated amount of time and/or budget to account for parts of the project that cannot be fully predicted. For example, it is relatively certain that there will be some rework, but the amount of rework and where it will occur in the project (or phase) are not known. These are sometimes called "known unknowns".
The purpose of the contingency reserve is to provide a more accurate sense of the expected completion date and cost of the project (or phase). Some PMs separate contingency reserves from management reserves while others combine the two into a single reserve. Reserves for changes and issues may be part of the contingency reserve or separate reserves.

Controlling -
The process of monitoring, measuring and reporting on progress and taking corrective action to ensure project objectives are met.

Critical Path -
The path(s) in a project network that has the longest duration. This represents the series of activities that determines the earliest completion of the project. There may be more than one critical path and the critical path(s) may change during the project.

Debate -
A discussion in which the participants exchange information for the purpose of supporting or refuting one anothers' positions. Debates are win-lose discussions, as opposed to dialogues, which are win-win discussions.

Deliverable -
Any item produced as the outcome of a project or any part of a project. The project deliverable is differentiated from interim deliverables that result from activities within the project. A deliverable must be tangible and verifiable. Every element of the WBS (activity or task) must have one or more deliverables.

Dependency -
A relationship between two or more tasks. A dependency may be logical (see Logical Relationship) or resource based (see Resource dependency). Also see Link.

Dialogue -
A discussion in which the participants share their thoughts and gain a better understanding of the subject and, possibly, reach consensus. This is contrasted with debate.

Duration -
The length of time required or planned for the execution of a project activity. Measured in calendar time units—days, weeks, months.

Early Start -
The earliest time a task can begin. The time at which all the tasks' predecessors have been completed and its resources are planned to be available.

Effort -
The amount of human resource time required to perform an activity. Measured in terms of person hours, person days, etc.

Estimate -
An assessment of the required duration, effort and/or cost to complete a task or project. Since estimates are not actuals, they should always be expressed with some indication of the degree of accuracy.

Estimate to Completion -
The expected effort, cost and/or duration to complete a project or any part of a project. It may be made at any point in the project's life.

Executing -
The process of coordinating the people and other resources in the performance of the project or the actual performance of the project.

Float -
The amount of time available for a task to slip before it results in a delay of the project end date. It is the difference between the task's early and late start dates.

Functional Manager -
A manager responsible for the activities of an organizational unit (department, work group, etc.), which provides some specialized products, services or staff to projects. For example, the manager of an engineering group, testing department or procedures development department. Also called a line manager.

Functional Group -
An organizational unit that performs a specialized business function (e.g., design, Human Resource management, etc.) and may provide staff, products or services to a project.

Gantt Chart -
A bar chart that depicts a schedule of activities and milestones. Generally activities (which may be projects, operational activities, project activities, tasks, etc.) are listed along the left side of the chart and the time line along the top or bottom. The activities are shown as horizontal bars of a length equivalent to the duration of the activity. Gantt Charts may be annotated with dependency relationships and other schedule-related information.

Goal -
A desired end result, often synonymous with objective. May be a high-level objective that has less-than-complete definition. See Objective.

Implementation -
May be a phase in the project life cycle in which a product is put into use. Also a term used as a synonym for development.

Incremental Delivery -
A project life cycle strategy used to reduce risk of project failure by dividing projects into more manageable pieces. The resulting sub-projects may deliver parts of the full product, or product versions. These will be enhanced to increase functionality or improve product quality in subsequent sub-projects.

In-house Projects -
Projects performed primarily by performers who are part of the same organization as the client. For example, a product developed by a manufacturing company's own Engineering Department is an in-house project. If an outside contractor developed the same product, the project would be externally sourced. Note that vendors might be used in in-house projects depending on the degree to which they are responsible.

Initiating (Project) -
The process of describing and deciding to begin a project (or phase) and authorizing the Project Manager to expend resources, effort and money for those that are initiated.

Kick-Off Meeting -
A meeting at the beginning of the project or at the beginning of a major phase of the project to align peoples' understanding of project objectives, procedures and plans, and to begin the team-building and bonding process.

Late Start -
The latest time a task can start before it causes a delay in the project end date.

Leveling -
See Resource Leveling.

Link -
A relationship between two or more tasks. See Logical Relationship.

Logical Relationship -
A dependency relationship between two or more tasks or between tasks and milestones, such that one cannot start or finish before another has started or finished.

Management Reserve -
A designated amount of time and/or budget to account for parts of the project that cannot be predicted. These are sometimes called "unknown unknowns." For example, major disruptions in the project caused by serious weather conditions, accidents, etc. Use of the management reserve generally requires a baseline change.
See Contingency Reserve.

Multi-Project Schedule -
A schedule of all the work (projects, operational activities, etc.) planned for an individual or organization unit. The purpose is to ensure that resources are not overburdened by inadvertently scheduling project or other work without regard to previously scheduled work. The Multi-Project Schedule is also used to determine the impact of slippage in one project on other projects assigned to the same resources.

Matrix Organization -
A business structure in which people are assigned to both a functional group (departments, disciplines, etc.) and to projects or processes which cut across the organization and require resources from multiple functional groups.

Metrics -
Metrics are quantitative measures such as the number of on time projects. They are used in improvement programs to determine if improvement has taken place or to determine if goals and objectives are met.

Milestone -
A point in time when a deliverable or set of deliverables is available. Generally used to denote a significant event such as the completion of a phase of the project or of a set of critical activities. A milestone is an event; it has no duration or effort. It must be preceded by one or more tasks (even the beginning of a project is preceded by a set of tasks, which may be implied).

Murphy's Laws -
A set of laws regarding the perverse nature of things. For example:

1. Nothing is as easy as it looks. Everything takes longer than you think. Anything that can go wrong will go wrong. If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong, it will happen then.
2. If anything simply cannot go wrong, it will anyway.

Network Diagram -
A graphic tool for depicting the sequence and relationships between tasks in a project. PERT Diagram, Critical Path Diagram, Arrow Diagram, Precedence Diagram are all forms of network diagrams.

Objective -
An objective is something to be achieved. In project management, the objectives are the desired outcomes of the project or any part of the project, both in terms of concrete deliverables and behavioral outcomes (e.g., improved service, more money, etc.).

Parametric Estimating -
Estimating using an algorithm in which parameters that represent different attributes of the project are used to calculate project effort, cost, and/or duration. Parametric estimating is usually used in top-down Estimating.

PERT—Program Evaluation and Review Technique -
A scheduling technique that makes use of dependency analysis and critical path to determine the duration of a project and slack to determine priorities of tasks. In PERT, task durations are computed as (Optimistic + 4xMost likely + Pessimistic estimates) / 6).

PERT Diagram -
A type of network diagram deriving its name from the PERT technique. The term is often used as a synonym for network diagram.

Phase -
A grouping of activities in a project that are required to meet a major milestone by providing a significant deliverable, such as a requirements definition or product design document. A project is broken down into a set of phases for control purposes. The phase is usually the highest level of breakdown of a project in the WBS.

Planning -
The process of establishing and maintaining the definition of the scope of a project, the way the project will be performed (procedures and tasks), roles and responsibilities and the time and cost estimates.

Post-implementation Review -
See Post-Project Review.

Post-Project Review -
An activity to assess and evaluate the way a project was performed, so as to learn from the experience and continuously improve project performance.

Power -
Power is the ability to influence the actions of others. Power may come from formal delegation of authority, reference power, subject matter expertise, the ability to influence rewards and penalties, as well as other sources.

Predecessor Task -
A task (or activity) that must be started or finished before another task or milestone can be performed.

Process -
A series of steps or actions to accomplish something. A natural series of changes or occurrences.

Product -
The project's material outcome. It maybe a service, event or any material object (e.g., a machine, computer system, new drug, building, etc.). The product includes all necessary aspects of the deliverable (e.g., training, documentation, etc.).

Product Life Cycle -
The time from the delivery of a product, until the product is withdrawn from use or sale. There may be many projects during the product life cycle.

Program -
A suite of related projects and ongoing operational activities managed as a whole.

Project -
An effort to provide a product or service within finite time and cost constraints.

Project Charter -
A document that describes the project at a high level of detail and is used to authorize the Project Manager to begin work. It may also be called a "Project Brief," or any number of other synonyms.

Project Life Cycle -
The full set of activities from the beginning to the end of a project. Generally associated with a set of phases, which are determined based on the major parts of project performance (e.g., requirements definition, design, construction, deployment) and the need for control by the Client organization (checkpoints for Go/No go decision-making).

Project Management -
The process of managing a project which requires the application of planning, team-building, communicating, controlling, decision-making and closing skills, principles, tools and techniques.

Project Manager -
The person responsible and accountable for managing a project's planning and performance. The single point of accountability for a project.

Quality Assurance (QA) -
Making sure standards and procedures are effective and that they are complied with. Note, in some organizations QA is used to refer to the quality control function.

Quality Control (QC) -
Making sure deliverables comply with acceptance criteria. Includes testing and reviews.

Ramp Down -
Ramp down is the effort required to close or suspend a task. It may consist of filing away information, making notes, clean-up, etc. Ramp down can be significant, depending on the task. For tasks that are suspended the degree of ramp down (e.g., notes and filing away information) performed will reduce the ramp up effort. See Ramp Up.

Ramp Up -
Ramp up is the work required to get ready to do a task. It consists of assembling materials, learning about the task (including new tools and techniques) and the time required getting into an optimum work pace. Initial ramp up can be significant, depending on the task. Each time a task is interrupted there is an additional ramp up—getting back to that optimal work pace. See Ramp Down.

Relative Date -
A date expressed as a number of periods (e.g., days, weeks, or months) from a reference point. For example, two months after the project start date. See Calendar Date.

Request for Proposal (RFP) -
A document that describes a need for products and/or services and the conditions under which they are to be provided. The purpose of the RFP is to solicit bids or proposals from prospective suppliers. Also called a Request for Quote (RFQ).

Requirements -
The statement of detailed product objectives that describes the features and functions and performance constraints to be delivered in the product. The requirements provide the basis for accepting the product.

Resource -
Any tangible support such as, a person, tool, supply item or facility used in the performance of a project. Human resources are people.

Resource Dependency -
A dependency between tasks in which the tasks share the same resources and therefore cannot be worked on simultaneously. Resource dependent tasks can be scheduled at the same time but are limited by the availability of the shared resources.

Resource Leveling -
Resource leveling is the part of the scheduling process in which the start and end dates of tasks are driven by resource limitations (e.g., limited availability of resources or difficult-to-manage resource levels). Among the scheduling objectives, is to ensure that resources are not overburdened (don’t schedule more resources for a period than are available) and that (as much as possible) there are not significant peaks and valleys in the resource schedule.

Resource Loading -
The process of assigning resources (people, facilities and equipment) to a project, usually activity by activity.

Responsibility -
The obligation to perform or take care of something, usually with the liability to be accountable for loss or failure. Responsibility may be delegated to others but the delegation does not eliminate the responsibility.

Responsibility Assignment Matrix (RAM) -
A tool used to relate each project activity in the WBS with a responsible organization unit or individual. Its purpose is to ensure that every activity is assigned to one or more individuals (only one with primary responsibility) and that the individuals are aware of their responsibilities.

Risk -
The likelihood of the occurrence of an event. Generally, the event is a negative one like project failure, but may also be a positive event, like the early completion of a task.

Risk Assessment -
Part of risk management in which planners identify potential risks and describe them, usually in terms of their symptoms, causes, probability of occurrence and potential impact.

Risk Response -
Action that can be taken to address the occurrence of a risk event. Contingency plans are collections of risk responses.

Risk Response Control -
Responding to risk event occurrences throughout the project life cycle. Taking corrective action is an aspect of risk response control.

Risk Response Development -
Part of risk management in which planners identify and define actions to be taken in case a risk (positive or negative) occurs.

Schedule -
The project timeline, identifying the dates (absolute or relative to a start date) that project tasks will be started and completed, resources will be required and upon which milestones will be reached.

Scope -
Scope is defined in terms of three dimensions—product, project and impact. Product scope is the full set of features and functions to be provided as a result of the project. Project scope is the work that has to be done to deliver the product. Impact scope is the depth and breadth of involvement by, and effect on, the performing and client organizations.

Scope Change -
Any change in the definition of the project scope. Scope change can result from changes in client needs, discovery of defects or omissions, regulatory changes, etc.

Scope Change Control -
Also called scope change management. The process of making sure that all changes to the project scope are consciously evaluated and their implications to the project plan are considered in making a decision to make the change, postpone it or reject it.

Scope Creep -
The unconscious growth of the project scope resulting from uncontrolled changes to requirements.

Scope Definition -
Breaking down the project's major deliverables into small, more manageable components to make verification, development and project control easier. This may be part of requirements definition and/or design.

Scope Planning -
Development of a statement of the principle deliverables of a project along with the project's justification (business case) and objectives. Part of requirements definition.

Scope Verification -
PMI's PMBOK Guide defines this as the process to ensure that all project deliverables have been completed satisfactorily. It is associated with acceptance of the product by clients and sponsors.

Sequencing Tasks -
A part of the scheduling process in which the tasks are positioned serially or parallel to one another based on dependencies between them. Sequencing results in a task network.

Slack -
See Float.

Specifications -
Detailed statements of project deliverables that result from requirements definition and design. Specifications generally describe the deliverables in terms of appearance, operational constraints and quality attributes. Specifications are the basis for acceptance criteria used in scope verification and quality control. In some organizations and industries, specifications may be qualified as requirements specifications and design specifications. See Requirements.

Spiral Development Approach -
A project life cycle strategy in which prototypes and models are used early in project life to define requirements and design the product. Commonly used when the product being developed is new (as in Research & Development and e-commerce) and the clients do not have a concrete understanding of their requirements and design attributes.

Stakeholder -
Anybody and everybody with a stake in the project - clients, sponsors, performers, the general public and even the family and friends of direct participants can be considered stakeholders. Not to be confused with the guy that holds the stake when the vampire slayer slays the vampire.

Statement of Work -
A description of the scope of a project centered on the major deliverables and constraints.

Straw man -
A tentative decision or solution put forth as a point of reference for detailed critical analysis.

Sub-contractor -
A group or individual providing products or services to the project. Commonly, sub-contractors are considered to be vendors. However there is a growing understanding that any internal group that provides products or services (e.g., an internal technical writing department) is a sub-contractor to the project manager. Of course in this broader usage, the agreement between the parties is not a legally binding contract but it is a contract nonetheless.

Subject Matter Expert (SME) -
An expert in some aspect of the project's content expected to provide input to the project team regarding business, scientific, engineering or other subjects. Input may be in the form of requirements, planning, resolutions to issues and/or review of project results.

Sub-task -
A breakdown of a task into the work elements that make it up. A task must be broken down into at least two sub-tasks for a meaningful decomposition.

Successor -
A task or milestone that is logically linked to one or more predecessor tasks.

Task -
A piece of work requiring effort, resources and having a concrete outcome (a deliverable). A task may be of any size (a project is a very large task). Sometimes the term is used to denote a piece of work at a particular level in a Work Breakdown Structure (WBS) hierarchy e.g., a phase is broken into a set of activities, and an activity into a set of tasks. Except for this hierarchical usage, activity is synonymous with task.

Task Dependency -
A relationship in which a task or milestone relies on other tasks to be performed (completely or partially) before it can be performed. Also referred to as a logical relationship.

Top-down Estimating -
Approximating the size (duration and cost) and risk of a project (or phase) by looking at the project as a whole and comparing it to previously performed similar projects. The comparison may be made directly using "analogous estimating," through an algorithm as in "parametric estimating", or from the memory of estimating experts.

Variance -
The difference between estimated cost, duration or effort and the actual result of performance. In addition, can be the difference between the initial or baseline product scope and the actual product delivered.

Vendor -
An organization or individuals providing products or services under contract to the client or to the project performance group. Also called outside contractors or sub-contractors.

Work Breakdown Structure (WBS) -
A hierarchical task list created by decomposing the project based on the breakdown of the product into components and the breakdown of the project process into increasingly detailed tasks. The WBS is depicted as a tree diagram (or hierarchy chart) or as a list in outline form with detailed items subordinated to higher-level items.

Work Package -
A task at a low level of the Work Breakdown Structure at which project accounting is performed. Usually a week or so in duration and performed by an individual or small work group.

Troubled Projects

September 2008, Issue 103, Judy Umlas and Frank P. Saladis, Co-Publishers

/ allPM Letters
Date: Sep 16, 2008 - 04:07 PM From the Co-publisher's Desk - Frank P. Saladis, PMP

This month we focus our attention to a topic and a situation that many project managers attempt to avoid – managing troubled projects. The problem we seem to have is that regardless of all of the training that is available, all of the tools and techniques that have been developed, all of the best practices that are shared among project managers and the experiences and lessons learned from years of managing projects, many projects become “troubled.” Along with the troubled project there is usually a long list of troubled stakeholders. There are many reasons why projects develop problems. Any project manager can provide a long list of potential issues that can cause project problems or project failures. It is also well known that despite the efforts of a project manager to work with his or her team to develop clearly defined project objectives and detailed plans that include risk assessments, contingency plans, and other preventive measures, projects can develop trouble in an instant. A healthy project can breakdown at anytime and without much notice.

The intent of project management is to minimize project-related problems through the use of a defined methodology that includes significant interaction between the stakeholders and entities involved in the project. We emphasize the importance of communication between project team members and other stakeholders and the importance of strong leadership and commitment to the project. All of these will help to minimize the probability of experiencing project problems but I believe it is safe to say that every project will develop some type of problem or problems. Sometimes these problems can be managed expeditiously through a preplanned risk management process, an experienced project manager and project team. In some cases serious problems develop that require thoughtful review, patience, wisdom, and a little creativity.

Troubled projects, although undesirable, are a fact of life in the project management world and all project managers expect to deal with issues large and small throughout the project life cycle.

Some key factors to consider when managing troubled projects include:

• All projects develop some problems. These are, in many cases, just inconveniences and “snags” that can be handled without extreme effort. Before declaring a project to be “troubled” and creating a potential managerial escalation domino effect, make sure there is evidence to support that claim.
  
  
• Before escalating the problem, make sure you have gathered all the facts and are prepared to answer questions. Find out why the problem or problems developed. Obtain input from the project team members.
  
  
• Ensure that tolerance levels for variances have been defined. Variances will show up during a review of results. Determine if the variances are actually outside of specified tolerance levels.
  
  
• Determine the potential responses that can be used to resolve the problems and select the best option. Avoid “jumping to a solution.” There are many ways to solve problems. Although there may be severe time pressures involved, look for options, whenever possible.
  
  
• When the root causes have been identified and problems have been resolved, take time to assess the issue. Lessons learned sessions about project issues are invaluable.

In this issue of allPM.com newsletter, we have gathered information from several subject matter experts who have offered to share their experience and their knowledge to assist project managers in developing action plans that will reduce the probability of having to deal with major project problems and to manage through problems if they actually develop. We know that projects can be unpredictable at times and allPM.com is your source for information that can help to smooth out even the roughest periods in your project’s life cycle. Consider allPM.com as your “project psychologist” for all of your project troubles. Just read an issue and email us in the morning.