Boyle Practical Project Management Consulting
About BPPM
Sample Project
Project Plans
FAQ's Contact

1      Theoretical Framework

At BPPM a theoretical framework has been developed to guide project managers through the planning processes and hence lead to successful projects. This lesson describes how this model has been determined. A review of the project management literature provides no consistent interpretation of the term “project success” (Baccarini, 1999). McCoy (1986) observes that a standardized definition of project success does not exist nor an accepted methodology of measuring it. Baccarini (1999) proposes the use of the logical framework method (LFM) to provide a detailed framework for defining and understanding project success and analyze the concepts of project management success and product success.

Success Framework

1.         Project management success: This focuses upon the project process and, in particular, the successful accomplishment of cost and time.

2.         Product success: This deals with the effects of the project’s final product.

In order to properly define and assess project success, a distinction should be made between product success and project management success, as they are not the same. Conceptually, the determination of project management success disregards product success, e.g., a project has been managed efficiently but eventually does not meet customer or organisational expectations (Shenhar et al., 1997). The focus of project managers on project management success is highlighted by research on IT projects by Wateridge (1998), whereby project managers interpreted a failed project as one not meeting budget and schedule, i.e., project management success; while users placed greater emphasis on the meeting of requirements such as response times and reliability, i.e., product success. This indicates that project managers are focusing on the short-term criteria relating of the project process and concentrating on meeting time and budget constraints, as opposed to the longer-term criteria relating to the product, such as delivering a system with which the users are happy (Wateridge, 1998). The project management approach is to determine stakeholder requirements, and then manage and influence those requirements to ensure a successful project (PMI, 2000). Project stakeholder requirements relate and include both project management and product requirements.

1.1    Project Objectives.

The terminology for the different types of project objectives varies between authors. Conceptually, there is no logical limit to the number of levels of project objectives; however, a common four-level structure can be identified (Couillard et al., 1995; Davis, 1995; Youker, 1993). The application of LFM can become bogged down by semantic arguments over the meaning of words such as goal and purpose. Youker (1993) recommends the use of the word "objective" for each level (i.e., goal objective, purpose objective, output objective, and input objective) and agreement by all concerned on a common understanding.



1.1.1      Project goal

The PMBOK registered mark Guide (PMI, 1996) suggests that all projects should be supportive of the performing organisation’s strategic goals. The project goal is the overall strategic orientation to which the project will contribute and should be consistent with the strategic plans of the organisation. The project goal provides the rationale behind the project and describes its long-term objective. A program of projects can have the same project goal.

1.1.2      Project purpose

The project purpose provides the means toward the project goal and determines the required project outputs. The successful achievement of the project’s purpose can be measured in terms of how well the project’s product satisfies users’ needs. The project goal and purpose together explain why the project is being undertaken.

1.1.3      Project outputs

These are the immediate, specific, and tangible results or deliverables produced by project activities. The outputs explain what the project will produce.

1.1.4      Project inputs

These are the resource inputs and activities required to deliver each output. The activities explain how the project will be done and are defined, by the work breakdown structure, responsibility chart, schedule, and budget. BPPM refers to these as the product work inputs.

1.2    Stakeholder Satisfaction

 A Guide to the Project Management Body of Knowledge (PMBOK registered mark Guide) (PMI, 2000 p.6) defines project management as “the application of knowledge, skills, tools and techniques to project activities in order to meet project requirements” and indicate that this work involves “stakeholders with differing needs and expectations”. “Project stakeholders are individuals and organisations who are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or successful project completion (PMI, 2000 p.16). Project success is viewed from the components of product success and project management success. The PMBOK registered mark Guide links stakeholders with project success in that "the project management team must identify the stakeholders, determine what their needs and expectations are, and then manage and influence those expectations to ensure a successful project." (PMI, 2000 p.16)  Project management success entails satisfying project stakeholders’ needs where they relate to the project management process (Munns & Bjeirmi, 1996). So stakeholder satisfaction is a crucial part of project success. The days when we could define success in terms of cost, schedule and technical objectives are gone. We must address a much wider range of needs, concerns and issues, which are presented to us by a diverse mix of project stakeholders (Tuman, 1986). Pinto and Mantel (1990) based on a literature survey and after interviews of experienced project managers, reached a similar conclusion. They identified three distinct aspects of project performance as benchmarks against which the success or failure of a project can be assessed: the implementation process, the perceived value of the project, and client satisfaction with the delivered project. The first of these aspects is primarily concerned with the internal efficiency of the project execution process. The second and third aspects are concerned with the project's external effectiveness and impact. In their thought-provoking article, Pinto and Slevin (1988) suggested that the relative importance of project success dimensions changes with time. The important factors in the early stages of a project are internal--meeting budget, schedule, and technical performance. Yet in more advanced phases of the project, external factors such as customer needs and satisfaction become more important. Each success criterion has its own timescale for measurement (Turner, 1993). Baker, et al. (1988) adopted a similar point of view and suggested that overruns in budget and time cease to be important after the project is terminated. Customer satisfaction and its relation to the project organisation continue to be important even beyond project boundaries. Pinto and Covin (1989) tied variations in relative importance of success dimensions to project life cycle, suggesting that not only the relative importance of success dimensions varies with project progress but also the critical success factors, that mostly affect the project outcomes, are different at every phase of the project. In order to assess the level of success achieved it is necessary to have a perspective from the viewpoint of different stakeholders. Stakeholder theory suggests that sustainable success rests, to a great extent, with a systematic consideration of the needs and goals of all key stakeholders (Fraser & Zarkada, 2003).

1.3    Success Criteria

Project success criteria have not been studied extensively, and have not been thought seriously about by many people (Wateridge, 1998). Freeman and Beale (1992), who reviewed the project management literature, identified five criteria that are frequently used for measuring the success of projects;

1          Technical performance

2          Efficiency of execution

3          Managerial and organisational implications (mainly customer satisfaction)

4          Personal growth, and

5          Manufacturability and business performance.

In this context some project success criteria are “hard,” i.e., objective, tangible and measurable. These are usually related to the objectives of cost, time, and quality (McCoy, 1986). Hard criteria are relatively easy to gauge and to reach some degree of consensus. The “soft” success criteria refer to such aspects as happiness, job satisfaction, enhanced reputation, and attention to detail. This dimension is subjective, subtle and more difficult to evaluate. Every project has a wide variety of stakeholders, all of whom will have their own particular subjective perception of success (Stucken-bruck, 1986; Wideman, 1998). Stucken-bruck (1986) points out that the question of project success will depend to a great extent on who is asking the question. Different stakeholders in the project, unfortunately, may have very different criteria as to what constitutes project success. Project success is a topic that is frequently discussed and yet rarely agreed upon. The concept of project success has remained ambiguously defined. It is a concept which can mean so much too so many different people because of varying perceptions, and leads to disagreements about whether a project is successful or not (Liu & Walker, 1998). It is not difficult to understand why the concept of project success is problematic. Each stakeholder will have their viewpoint of success depending on their needs and how well these needs are satisfied by the project. For example, an architect may consider success in terms of aesthetic appearance, an engineer in terms of technical competence, an accountant in terms of dollars spent under budget, a human resource manager in terms of employee satisfaction, and chief executive officers rate their success in the stock market (Freeman & Beale, 1992). To reach consensus of success criteria among all stakeholders is quite unrealistic and so only by establishing common goals can criteria acceptable to all be achieved (Liu & Walker, 1998). Measuring success is complex and a project is hardly ever a disaster or failure for all stakeholders during all phases in the project life cycle. A project can be a success for one party and a disaster for another. A project may be perceived a success one day and a failure the next. Therefore, to think that one can objectively measure the success of a project is an illusion (de Wit, 1988).

1.3.1      Defining Success Criteria

The outputs explain what the project will produce and in so far as possible we shall apply yardsticks to all outputs to measure the success of our projects. To this end we shall use criteria that are SMART- specific, measurable, attainable, realistic and time-based.

S – specific – well defined and clear to anyone that has a basic knowledge of the project

M – measurable – have a yardstick to determine how far away completion is and to know when it has been achieved

A – attainable-  finite and obtainable.

R – realistic – related to scope and subject to project constraints.

T - time-based. Satisfied by a date pre or post product delivery.

1.3.2      Prioritising Success Criteria

Success criteria can conflict with each other, which means there will often be trade-offs that must be agreed by all parties before the project is started (Wateridge, 1998). In many projects there will be a large number of stakeholders, in which there is a need to identify which stakeholders are going to have the most influence in determining project success (Tuman, 1986). From this, attention must be focused on important stakeholders if project success is to be accomplished. The criteria for measuring project success must be set out at the beginning of the project, otherwise different team members will find themselves traveling in differing directions and one or more of them might perceive the project to be a failure. (Baccarini, 1999).

1.4    Triple Constraints


The triple constraints of projects are time, cost, and quality or performance. Extending a project’s schedule may raise costs. Cutting the schedule may affect performance or quality. One of the three constraints is usually the primary driver of the project. Some projects are cost-driven, others are time or performance driven. Unless you have unlimited resources, you'll probably want to minimize the time and cost required, yet maximize the quality. Time, money, and quality known as the "triple constraints" - are your project's boundaries that you must work within. And that least flexible of the three constraints - the "driver" - will be your taskmaster throughout.


Every project has limited resources. There is limited money, people, equipment and other related resources. That is a characteristic of projects. As project managers, we need to determine which of our constraints (time, costs or performance) is the most important and which is the least in order to focus our resources in the most effective way. Additionally, when there are problems, we use the least important constraint (weak constraint) to aid in the solution. The most important of the constraints, the driver, is the last to be compromised.


At this point, people usually asked about the performance specifications constraint. Think of this as a quality issue. If performance is driving your project, it will not be successful unless the project completely meets the performance criteria or specifications of the project. You will spend more time or increase the budget rather than sacrifice quality or features. If performance is the weak constraint, you might consider scaling back on features or quality to meet either time or cost constraints.


The triple constraints can be arranged in a logical order but this logical order may differ among projects. In order to determine the logical order, imagine a current project. Which of the three constraints is the driver? Which is the weak constraint?

If you have problems determining the driver and weak constraint, use the following questions to explore your project:

If I had to choose between spending more time on the project or cutting quality, which would I choose?

If I had to choose between delivering the project on time (and spending more money) or keeping the project on budget, which should I choose?

If the project began running over budget, would I immediately consider cutting features or quality?

If the project is behind schedule, would I spend more money to get back on schedule?

If you ask enough comparative questions, you will develop a hierarchy of the constraints. It is often not easy because everything is important. It can be a matter of small degrees that determine the driver and weak constraints.


The driver may change during a project. That is part of the dynamics of project management. However, you have to know the initial logical order of the constraints before you begin the project-planning step.


Once you understand the order of project constraints, you can begin defining your project goals, sub-goals, objectives and action steps. As you begin the goal setting process you have to focus on the target.

1.5    Critical Success Factors

Critical Success Factors are those that have most impact in determining the success of a project. Projects will have various factors critical for success depending on the type of project. There are however a few factors which seem to be critical for the success of most projects. These are:

Top management support

Clear goals and objectives

Management of expectations

2      Theoretical Framework Application

The basis for the theoretical framework as outlined in the figure below, shows in the centre the CSFs that are required to satisfy the project objectives.

Success Framework

By the same token the theoretical framework displays the relationship between the CSFs and the project success criteria. Critical success factors are represented in the middle of the framework, representing their relationship to achieving both project and product objectives and their influence on satisfying the success criteria. Some authors describe success based on meeting the budget, while others classify success as meeting the deadline for the project. Success can look different when examined at different points in time, on different dimensions or from different views (Larsen and Myers 1997; Markus and Tanis 2000). In this lesson the CSFs and the criteria for measuring success are explored, according to the perception of different groups of stakeholders.


By the end of this lesson you will have a good grasp of the big picture in the management of your project. You will notice that this course will not be dealing with all of the processes involved with project management. This course deals only with the planning processes. The majority of processes fall within the Planning Process Group. (PMBOK)


2.1    Logical Framework Method


The American Aid Agency developed LFM in the 1970s for International Development to improve project management of development projects (Couillard, 1995; Youker, 1993). LFM uses a top-down approach to formulate a hierarchy of project objectives such that, at any given level, the lower objectives are the means to satisfying the next higher level of objectives. The hierarchy displays a series of cause-and-effect linkages between one level of objective and the next higher level and toward a path to the ultimate highest objectives and thus acts as a communication tool, and a clear target for the project team (Youker, 1993)

LFM is a “how-why” logic chain that displays the relationships between the hierarchy of project objectives. The “why” is the end and the “how” is the means. This logic follows the methodology of a tree diagram. The “why-how” logic linking the four levels of project objectives works as follows: Start with the project goal and ask, “How is this to be achieved?” The answer should be project purpose. Then ask, “How is this to be achieved?” The answer should be project output; and so on. Finally, the logic can be checked by working backward from the inputs by asking “Why?” Therefore, LFM shows cause-and-effect between the hierarchies of project objectives. LFM structures clear thought and judgment as to whether the hierarchical relationships between the project objectives are logical and viable (Davis, 1995). This ensures that the project contributes to the strategic plans of the organisation.


The LFM provides a very useful framework for articulating the concept of project success. The benefits of including LFM in the theoretical framework are:

           for providing a common, clear understanding of the project objectives and thus leading to the identification of project success criteria;

           facilitates increased understanding of the project


A key role of LFM is to provide a step-by-step account of the important elements of a project (Youker, 1993). Whether the project outputs achieve the project purpose and project goal will depend on how well the hierarchy of project objectives has been formulated. It is important to emphasise that LFM is a way of systems thinking, rather than an administrative procedure. Furthermore, its focus is on desired outcomes and not inputs.

The rest of this lesson shall focus on a systems approach relating to our sample project and the application of the Theoretical Framework for the identification of benefits expected to accrue on completion of our project.


2.2    Functional Analysis

A “systems” approach for the “creation of a website for Boyle Practical Project Management (BPPM)” looks at the business as a whole with regard to the creation of the website. This exercise may reveal a number of other avenues to explore and may highlight further drawbacks in the “As Is”. The systems approach looks at the broader picture and examines the interaction of the parts.

Taking our example, the systems approach looks at the whole business of Boyle Practical Project Management and all its parts together with the relationships between the parts and with its external environment.  As outlined above one of the techniques used in this approach is Functional Analysis.

Functional Analysis involves the examination of the product by identifying systematically the functions of the product using a verb and a noun such as “wash teeth” for a toothbrush. The HOW WHY Tree Diagram is generated using the Function Analysis System Technique (FAST) and hence demonstrates the LFM structure. FAST was created by Charles Bytheway and permits people with different technical backgrounds to effectively communicate and resolve issues that require multi-disciplined considerations. FAST builds upon the Tree Diagram by linking the simply expressed, verb-noun functions to describe complex systems.

FAST is not an end product or result, but rather a beginning. It describes the Product and causes the team to think through the functions that the product performs. With FAST, there is no right or wrong. The team members discuss and reconfigure the tree diagram until consensus is reached and all participating team members are satisfied that their concerns are expressed in the model. When studying systems it becomes apparent that functions do not operate in a random or independent fashion. A system exists because functions form dependency links with other functions.

A function is an activity performed by someone or something for the purpose of achieving an objective. “Function” can be defined, as the use demanded of a product.  The first step is to systematically examine and describe the functions that the product undertakes in a Brainstorming session. The question to be answered is “what functions would a BPPM website undertake”?


2.2.1      Brainstorming

The Brainstorming approach aims to achieve the spontaneous generation of ideas in the absence of any criticism or evaluation. The quality of the ideas produced is not initially important; the objective is merely to produce a large number of ideas.

The participants for the brainstorming session generally include representation from all or as many of the stakeholder groups as possible.   The success of the brainstorming session is dependent on establishing an appropriate climate. It is important that all participants appreciate the nature of the exercise and that criticism or evaluation is not allowed. The team member facilitating the session maintains the momentum of the exercise. All ideas without exception are recorded. 

Brainstorming is an excellent way of developing creative ideas. Ideas should deliberately be as broad and odd as possible, and should be developed as fast as possible. When individual members reach their limit on an idea, another member can take the idea to the next stage. Group brainstorming has the potential to develop ideas in more depth than individual brainstorming.

Brainstorming functions:

-           Invites all members to participate.   

-           Ensures that all aspects of the question are considered

-           Encourages creative thinking

The Do’s for Brainstorming:

-           Acknowledge all ideas are good

-           Record all ideas

-           Build on other’s ideas

-           Encourage everyone to participate

-           Conducting an evaluation phase after the brainstorming

-           Do inform non attending stakeholders of ideas generated and seek additions.

The Don’ts for Brainstorming:

-           Ask a broad question

-           Failing to explain brainstorming to your audience

-           Criticized or disagree with ideas are

-           Edit ideas during the brainstorming session


The materials used in brainstorming can vary depending on requirements and availability. The normal tools are flip chart, colour markers, post-it notes, and note pads.

Brainstorming Session – Ideas Generated

The Brainstorming question. What function would creating a Website for Boyle Practical Project Management Consulting, undertake?

Participants in brainstorming session.

Padraig, (sponsor),      Sean (project manager),         Joe (contract website designer).

Ideas Generated.

Promote_business                  transact_business                    look_professional    access_audience              give_information                     sell_material              receive_requests                        advertise_services                   share_knowledge          build_profile                                     make_money                           sell_space                  target_audience                       get_customers                         make_transactions          give_access                          entice_surfers                          expand_horizons     generate_interest                         receive_payment                     answer_questions         ask_questions                                     get_feedback                          create_awareness        register_clients                        show_existence                       provide_links                  keep_clients                                     give_samples



2.2.2      Tree Diagrams

To create a clearer understanding, related ideas may be grouped together. The functions discovered by the team can be grouped and recorded using a Tree diagram.

The tree diagram is horizontal in direction and describes the HOW-WHY properties. The HOW and WHY questions are asked to structure the logic of the system's functions. Starting with a function, we ask HOW that function be performed to develop a more specific approach. This line of questioning and thinking is read from left to right. To test the logic, we ask WHY that function is performed. This line of logic is read from right to left. When undertaking any project it is best to start with the goal of the project, then explore methods to achieve the goal. When addressing any function on the diagram with the question WHY, the function to its left expresses the goal of that function. The question HOW, is answered by the function on the right, and is a method to perform that function being addressed. A systems diagram starts at the beginning of the system and ends with its goal. The HOW/WHY Tree Diagram, reading from left to right, starts with the goal, and ends at the beginning of the "system" that will achieve that goal.Tree diagrams allow the ideas of the team to be structured and recorded in a logical chart. The top of the tree is characterised by the over-riding objective of the entire project “Promote BPPM”. This is then progressively broken down into sub-objectives. Evaluating the ideas from the brainstorming the team was able to identify three key sub objectives after eliminating the duplicates namely:  

1. Attract customers

 2. Transact Business

3. Give Information

These objectives can be further broken down using the ideas from the brainstorming, branching out the tree diagram using the HOW/WHY method. The HOW WHY Tree Diagram allows the ideas of the team to be structured to show relationship between objectives. On completion, the tree represents all the variables to be examined.








Tree Diagram

Create a Website for Boyle Practical Project Management Consulting

Sample tree diagram for creating a website

2.2.3      Sample Project goal

The project goal is to Promote BPPM

2.2.4      Sample Project purpose

The project purpose is to Attract Customers, Transact Business, and Give Information.


2.2.5      Sample Project outputs

The outputs to be produced by project activities are Look Professional, Provide Access, Target Audience, Sell Material, Encourage Registration, Advertise Services, Answer Questions, Seek Feedback, Share Knowledge, and Update Material. The project Management outputs are to have the Website Live on or before the 11th April, 2012 and at a cost of €6,000 or less. The costs associated with the uses of internal non–pay resources are not included in this amount.

2.2.6      Sample Project inputs

Depending on the complexity of the project it may be necessary to only have selected stakeholders with technical product knowledge involved with this stage of the process. For our example Sean and Joe will continue the brainstorming to determine the project inputs, which we shall outline during the next lesson.

2.3    Sample Success Criteria

The criteria used to determine the success or otherwise of the project “Create a Website for Boyle Practical Project Management Consulting” are based on the project outputs as outlined in the table below.

Project Outputs

Success Criteria Specification

Time Base

Measurement Unit.

Look Professional

Opinion of stakeholders

end July 2012


Provide Access

%  of total time site is accessible

end July 2012


Target Audience

The number of visitors

end July 2012


Sell Material

The number of sales made

end July 2012


Register Clients

the number of clients registering for course

end July 2012


Advertise Services

No of pages viewed per visit

end July 2012


Give free Samples

number of downloads

end July 2012


Answer Questions

number of questions asked

end July 2012


Seek Feedback

number of reviews left

end July 2012


Share Knowledge

Requests to include more information

end July 2012


Update material

Number of site updates each month

end July 2012


Website Go-live Date

The Date the Website

11th April, 2012

   11th April, 2012


The cost of Creating BPPM Website






 Comment Form