Project Management

Developing the Scope Statement and Project Plan



                        Developing a Project Scope Statement


The project scope statement is the definition of the project—what needs to be accomplished. The Develop Preliminary Project Scope Statement process addresses and documents the characteristics and boundaries of the project and its associated products and services, as well as the methods of acceptance and scope control. A project scope statement includes:


·         Project and product objectives

·         Product or service requirements and characteristics

·         Product acceptance criteria

·         Project boundaries

·         Project requirements and deliverables

·         Project constraints

·         Project assumptions

·         Initial project organization

·         Initial defined risks

·         Schedule milestones

·         Initial WBS

·         Order of magnitude cost estimate

·         Project configuration management requirements

·         Approval requirements


The preliminary project scope statement is developed from information provided by the initiator or sponsor. The project management team in the Scope Definition process further refines the preliminary project scope statement into the project scope statement. The project scope statement content will vary depending upon the application area and complexity of the project and can include some or all of the components identified above. During subsequent phases of multi-phase projects, the Develop Preliminary Project Scope Statement process validates and refines, if required, the project scope defined for that phase.


Project Scope Development Tools and Techniques

1 – Project Management Methodology

The project management methodology defines a process that aids a project  management team in developing and controlling changes to the preliminary project scope statement.


2 – Project Management Information System

The project management information system, an automated system, is used by the project management team to support generation of a preliminary project scope statement, facilitate feedback as the document is refined, control changes to the project scope statement, and release the approved document.


3 – Expert Judgment

Expert judgment is applied to any technical and management details to be included in the preliminary project scope statement.


Develop Project Plan


The Develop Project Management Plan process includes the actions necessary to define, integrate, and coordinate all subsidiary plans into a project management plan. The project management plan content will vary depending upon the application area and complexity of the project. This process results in a project management plan that is updated and revised through the Integrated Change Control process. The project management plan defines how the project is executed, monitored and controlled, and closed. The project management plan documents the collection of outputs of the planning processes of the Planning Process Group and includes:


·         The project management processes selected by the project management team

·         The level of implementation of each selected process

·         The descriptions of the tools and techniques to be used for accomplishing those processes

·         How the selected processes will be used to manage the specific project, including the dependencies and interactions among those processes, and the essential inputs and outputs

·         How work will be executed to accomplish the project objectives

·         How changes will be monitored and controlled

·         How configuration management will be performed

·         How integrity of the performance measurement baselines will be maintained and used

·         The need and techniques for communication among stakeholders

·         The selected project life cycle and, for multi-phase projects, the associated project phases

·         Key management reviews for content, extent, and timing to facilitate addressing open issues and pending decisions.


The project management plan can be either summary level or detailed, and can be composed of one or more subsidiary plans and other components. Each of the subsidiary plans and components is detailed to the extent required by the specific project. These subsidiary plans include, but are not limited to:


·         Project scope management plan

·         Schedule management plan

·         Cost management plan

·         Quality management plan

·         Process improvement plan

·         Staffing management plan

·         Communication management plan

·         Risk management plan

·         Procurement management plan


These other components include, but are not limited to:


·         Milestone list

·         Resource calendar

·         Schedule baseline

·         Cost baseline

·         Quality baseline

·         Risk register


          Project Plan Tools and Techniques

Project Management Methodology

The project management methodology defines a process, which aids a project management team in developing and controlling changes to the project management plan.


Project Management Information System

The project management information system, an automated system, is used by the project management team to support generation of the project management plan, facilitate feedback as the document is developed, control changes to the project management plan, and release the approved document.


·         Configuration Management System The configuration management system is a subsystem of the overall project management information system. The system includes the process for submitting proposed changes, tracking systems for reviewing and approving proposed changes, defining approval levels for authorizing changes, and providing a method to validate approved changes. In most application areas, the configuration management system includes the change control system. The configuration management system is also a collection of formal documented procedures used to apply technical and administrative direction and surveillance to:

o   Identify and document the functional and physical characteristics of a product or component

o   Control any changes to such characteristics

o   Record and report each change and its implementation status

o   Support the audit of the products or components to verify conformance to requirements.


·         Change Control System The change control system is a collection of formal documented procedures that define how project deliverables and documentation are controlled, changed, and approved. The change control system is a subsystem of the configuration management system. For example, for information technology systems, a change control system can include the specifications (scripts, source code, data definition language, etc.) for each software component.


·         Expert Judgment Expert judgment is applied to develop technical and management details to be included in the project management plan.




[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition

2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

November 19, 2008 Posted by | knowledge areas, PMP, Project Management | | 2 Comments

How to Write a Project Charter

The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities. A project manager is identified and assigned as early in the project as is feasible. The project manager should always be assigned prior to the start of planning (if possible) and preferably while the project charter is being developed.


In my experience this is not always possible, but I highly recommend that you follow this and as the very least, as soon as you (or someone else) is assigned as the Project Manager, draft this document and have it signed off by the stakeholders.


A project initiator or sponsor external to the project organization, at a level that is appropriate to funding the project, should issue the project charter. Projects are usually chartered and authorized external to the project organization by an enterprise, a government agency, a company, a program organization, or a portfolio organization, as a result of one or more of the following:


·         A market demand (e.g., a car company authorizing a project to build more fuel-efficient cars in response to gasoline shortages)

·         A business need (e.g., a training company authorizing a project to create a new course to increase its revenues)

·         A customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park)

·         A technological advance (e.g., an electronics firm authorizing a new project to develop a faster, cheaper, and smaller laptop after advances in computer memory and electronics technology)

·         A legal requirement (e.g., a paint manufacturer authorizing a project to establish guidelines for handling toxic materials)

·         A social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of cholera).


These stimuli can also be called problems, opportunities, or business requirements. The central theme of all these stimuli is that management must make a decision about how to respond and what projects to authorize and charter.


Make sure to have these requirements documented and signed off as they will be used to create the Project Scope Document.


Project selection methods involve measuring value or attractiveness to the project owner or sponsor and may include other organizational decision criteria. Project selection also applies to choosing alternative ways of executing the project.


Chartering a project links the project to the ongoing work of the organization. In some organizations, a project is not formally chartered and initiated until completion of a needs assessment, feasibility study, preliminary plan, or some other equivalent form of analysis that was separately initiated.


Developing the project charter is primarily concerned with documenting the business needs, project justification, current understanding of the customer’s requirements, and the new product, service, or result that is intended to satisfy those requirements. The project charter, either directly, or by reference to other documents, should address the following information:


·        Requirements that satisfy customer, sponsor, and other stakeholder needs, wants and expectations

·        Business needs, high-level project description, or product requirements that the project is undertaken to address

·        Project purpose or justification

·        Assigned Project Manager and authority level

·        Summary milestone schedule

·        Stakeholder influences

·        Functional organizations and their participation

·        Organizational, environmental and external assumptions

·        Organizational, environmental and external constraints

·        Business case justifying the project, including return on investment

·        Summary budget.


During subsequent phases of multi-phase projects, the Develop Project

Charter process validates the decisions made during the original chartering of the project. If required, it also authorizes the next project phase, and updates the charter.



Contract (When Applicable)

A contract from the customer’s acquiring organization is an input if the project is being done for an external customer.


Project Statement of Work


The statement of work (SOW) is a narrative description of products or services to be supplied by the project. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, product, or service requirements. For external projects, the statement of work can be received from the customer as part of a bid document, for example, request for proposal, request for information, request for bid, or as part of a contract. The SOW indicates a:


·        Business need – an organization’s business need can be based on needed training, market demand, technological advance, legal requirement, or governmental standard.

·        Product scope description – documents the product requirements and characteristics of the product or service that the project will be undertaken to create. The product requirements will generally have less detail during the initiation process and more detail during later processes, as the product characteristics are progressively elaborated. These requirements should also document the relationship among the products or services being created and the business need or other stimulus that causes the need. While the form and substance of the product requirements document will vary, it should always be detailed enough to support later project planning.

·        Strategic plan – all projects should support the organization’s strategic goals. The strategic plan of the performing organization should be considered as a factor when making project selection decisions.


Enterprise Environmental Factors


When developing the project charter, any and all of the organization’s enterprise environmental factors and systems that surround and influence the project’s success must be considered. This includes items such as, but not limited to:


·        Organizational or company culture and structure

·        Governmental or industry standards (e.g., regulatory agency regulations, product standards, quality standards, and workmanship standards)

·        Infrastructure (e.g., existing facilities and capital equipment)

·        Existing human resources (e.g., skills, disciplines, and knowledge, such as design, development, legal, contracting, and purchasing)

·        Personnel administration (e.g., hiring and firing guidelines, employee performance reviews, and training records)

·        Company work authorization system

·        Marketplace conditions

·        Stakeholder risk tolerances

·        Commercial databases (e.g., standardized cost estimating data, industry risk study information, and risk databases)

·        Project management information systems (e.g., an automated tool suite, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems).


Organizational Process Assets


When developing the project charter and subsequent project documentation, any and all of the assets that are used to influence the project’s success can be drawn from organizational process assets. Any and all of the organizations involved in the project can have formal and informal policies, procedures, plans, and guidelines whose effects must be considered. Organizational process assets also represent the organizations’ learning and knowledge from previous projects; for example, completed schedules, risk data, and earned value data. Organizational process assets can be organized differently, depending on the type of industry, organization, and application area. For example, the organizational process assets could be grouped into two categories:


·         Organization’s processes and procedures for conducting work:

o    Organizational standard processes, such as standards, policies (e.g., safety and health policy, and project management policy), standard product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization)

o    Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria

o    Templates (e.g., risk templates, work breakdown structure templates, and project schedule network diagram templates)

o     Guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific needs of the project

o     Organization communication requirements (e.g., specific communication technology available, allowed communication media, record retention, and security requirements)

o     Project closure guidelines or requirements (e.g., final project audits, project evaluations, product validations, and acceptance criteria)

o    Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions)

o     Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking

o     Change control procedures, including the steps by which official company standards, policies, plans, and procedures—or any project documents—will be modified, and how any changes will be approved and validated

o     Risk control procedures, including risk categories, probability definition and impact, and probability and impact matrix

·        Procedures for approving and issuing work authorizations. Organizational corporate knowledge base for storing and retrieving information:

o     Process measurement database used to collect and make available measurement data on processes and products

o     Project files (e.g., scope, cost, schedule, and quality baselines, performance measurement baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, and defined risk impact)

o    Historical information and lessons learned knowledge base (e.g., project records and documents, all project closure information and documentation, information about both the results of previous project selection decisions and previous project performance information, and information from the risk management effort) and defect management database containing issue and defect status, control information, issue and defect resolution, and action item results

o     Configuration management knowledge base containing the versions and baselines of all official company standards, policies, procedures, and any project documents

o     Financial database containing information such as labor hours, incurred costs, budgets, and any project cost overruns.


Develop Project Charter: Tools and Techniques


Project Selection Methods

Project selection methods are used to determine which project the organization will select. These methods generally fall into one of two broad categories:


·        Benefit measurement methods that are comparative approaches, scoring models, benefit contribution, or economic models.

·        Mathematical models that use linear, nonlinear, dynamic, integer, or multi-objective programming algorithms.


Project Management Methodology


A project management methodology defines a set of Project Management Process Groups, their related processes and the related control functions that are consolidated and combined into a functioning unified whole. A project management methodology may or may not be an elaboration of a project management standard. A project management methodology can be either a formal mature process or an informal technique that aids a project management team in effectively developing a project charter.


Project Management Information System


The Project Management Information System (PMIS) is a standardized set of automated tools available within the organization and integrated into a system. The PMIS is used by the project management team to support generation of a project charter, facilitate feedback as the document is refined, control changes to the project charter, and release the approved document.


Expert Judgment


Expert judgment is often used to assess the inputs needed to develop the project charter. You will see this technique used in many of the Project Processes. Such judgment and expertise is applied to any technical and management details during this process. Such expertise is provided by any group or individual with specialized knowledge or training, and is available from many sources, including:


·         Other units within the organization

·         Consultants

·         Stakeholders, including customers or sponsors

·         Professional and technical associations

·         Industry groups.[i]



[i]  2007 Project Management Institute, Four Campus Blvd., Newton Square, PA 17903

November 16, 2008 Posted by | PMP, Project Initiation | | 12 Comments

Project Process Groups

There are five Process Groups defined by PMI. They have clear dependencies and are performed in the same sequence on each project. They are independent of application areas or industry focus. Individual Process Groups and individual constituent processes are often iterated prior to completing the project. Constituent processes also can have interactions both within a Process Group and among Process Groups.


Note: During project phases, if a change occurs during the project execution or control, the documents and tools used in the Process groups may have to be revisited. For example, if a change is made to the scope during the project execution phase, the scope document and all of the project plans must be revisited to include the new scope.


An individual process may define and constrain how inputs are used to produce outputs for that Process Group. They are defined in a way that projects of all kinds can be managed with this standard, so some inputs or outputs may not be relevant to every project.


A Process Group includes the constituent project management processes that are linked by the respective inputs and outputs, that is, the result or outcome of one process becomes the input to another. The Monitoring and Controlling Process Group, for example, not only monitors and controls the work being done during a Process Group, but also monitors and controls the entire project effort. The Monitoring and Controlling Process Group must also provide feedback to implement corrective or preventive actions to bring the project into compliance with the project management plan or to appropriately modify the project management plan. Many additional interactions among the Process Groups are likely.


Where large or complex projects may be separated into distinct phases or sub-projects such as feasibility study, concept development, design, prototype, build, test, etc. all of the Process Group processes would normally be repeated for each phase or subproject.

The five Process Groups are:


·         Initiating Process Group. Defines and authorizes the project or a project.

·         Planning Process Group. Defines and refines objectives, and plans the course of action required to attain the objectives and scope that the project was undertaken to address.

·         Executing Process Group. Integrates people and other resources to carry out the project management plan for the project.

·         Monitoring and Controlling Process Group. Regularly measures and monitors progress to identify variances from the project management plan so that corrective action can be taken when necessary to meet project objectives.

·         Closing Process Group. Formalizes acceptance of the product, service or result and brings the project or a project phase to an orderly end.

November 15, 2008 Posted by | PMBOK, PMP, Project Management | | Leave a comment

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.


November 10, 2008 Posted by | PMP, Project Management | , , | Leave a comment

How to Produce a Great Project!

Some folks say that hiring good Project Managers is now more science than art. I have always found that meeting a person and talking with them providing examples of project problems and hearing their approach and final answer to solving the problem is vital.

PMP certified project managers understand Project Management at a certain level as defined by the requirements set by PMI. Those requirements include a number of hours of experience and training before allowing them to even take the certification test. Then they take the test and after passing it they receive their PMP certification.

If the person you are trying to hire has the certification, you can assume that they understand project management, scope management, risks to a project, schedule management, quality management, communications management  and can notify management of potential issues. To see what they are taught you can look at the PMBOK located on

They have had hands on experience creating project plans and all the necessary artifacts to ensure a smooth running project. Certified PMPs have to have a few good-sized projects under their belts before they get this certification. They also have to have 30 hours of PMI certified training.

Sometimes you need to go deeper than the PMP certification. The certification tells you that they meet the standardized requirements of a Project Management Professional, but it does not address style, critical thinking, and approach to challenges, personality and more importantly, motivation. I am a very relational person, and I can usually tell in a few minutes if a person will click with the culture and customer they will be dealing with.

What PMOs need are Project Managers who have a project management core knowledge set and experience with visioning skills, leadership skills, a quality focus and a knowledge of all the PMP tools and tricks.

The Project Manager and the Business Analyst get all the requirements down working with Stakeholders. The business manager signs off on the core elements. The Project Manager creates all of the elements of the Project Plan and then the Project Manager monitors and controls the project on a daily basis.

Engineers often say “we can do it this way to meet the timeline, but this feature won’t be available” and the project manager says “we need that feature and the deadline is immovable.”  This is when the Change Management process comes in. Each Project should have a Change Management team and process. Options are shown to the Change Management team, often trading off either time to market, resources or functionality. Sometimes, if the change is approved, something different than the original project plan occurs and the original Project documentation is updated. If time to market is not changed, the product may be released on schedule, but fizzles. $xx million is not realized and the project is a failure. The project manager did his job. It was released on time and within budget, right?

The Project Manager is so wrapped up in project risk factors, slipping schedule, and budget that he/she can’t see the forest for the trees. Once you are in a project, there are pressures from all sides. The developer can’t do it this way unless he re-writes an entire module causing a two-month delay. Or the developer says that something just can’t be done and pushes back on the Project Manager. Or the business manager cannot articulate why something needs to be a certain way.

What is needed here is a Project Manager with the knowledge and the intestinal fortitude to push hard. She pushes herself hard to fully understand the vision of the business manager: All the subtleties, all the subjective qualities and the reasons for each of them. She doesn’t stop pushing herself until she fully sees the vision of the business manager and that vision becomes hers as well. Now you have someone who understands technology and sees the full vision of what is needed to make the $xx million in 18 months.

Now this type of Project Manager pushes back on the developer. She knows if the developer is trying to blow by a fast ball. She also has the leadership skills to push the team above and beyond in order to fully realize the vision. Short cuts and compromises are not part of the process. “Not good enough” is frequently uttered by this Project Manager. If something is more difficult than anticipated, the Project Manager can speak with the change management team and fully explain the benefits of a delay or the impact of adding the feature or function in a follow-up release. If the feature is going to take two months, the Project Manager works her leadership magic and pushes the team to get it done in one month. She examines the critical path; she may move resources around and do whatever it takes to come in on time.

Developers are a very smart and creative group. There are always new ways to approach something to trim a schedule and still meet or exceed requirements. They love to build a Cadillac when the project plan calls for a Volkswagen. They just need to be led appropriately. I’ve never met a developer who didn’t love a challenge. They just hate getting beat up all the time for missed schedules or a buggy product that tends to be out of their control anyway. When you let a good developer be a good developer, you get amazing results.

Now all the tools and tricks the Project Manager learned during PMP certification come into play. These tools combined with leadership skills, visioning skills and a quality focus makes this Project Manager a Seasoned Project Manager.

Finding a Seasoned Project Manager is no easy task, because basically, you’re hiring your replacement. See how succession planning just kind of happens when you hire the right people?

So where have these Seasoned-Project Managers come from? One successful combination is a very good Business Analyst that became a developer and then moved into project management. Good Business Analysts inject themselves into the visioning process when they’re gathering requirements. They just become too far removed during the development from the finished product to really have an impact on product quality during the process. That frustration is typically what drives these Business Analysts to become developers and then Project Managers. This combination has worked six out of seven times for me personally.

During an interview, ask the candidate to define visioning. How has that candidate used visioning in the past? How has this skill led to delivering successful solutions? Have the candidate tell you about a project that failed and why. What were the lessons learned? What would he/she have done differently? Did they keep a record of the lessons learned so that they can use this historical data for the next project?

Ask the candidates to describe their relationship with the technical teams. Find out if it was an adversarial relationship or more of a high-powered team. If it was more of a team environment, you should see a change in the candidate’s face when he/she describes it. These Seasoned Project Managers thrive in team environments. They have an inherent, almost genetic, understanding that things can never be done alone and can describe how, at times; the team members could almost read each others’ mind.

Ask candidates to define “good enough.” When you hear enough of these answers, you’ll know what you’re looking for and more importantly, what you don’t want. This is just an opinion based upon my personal experience. I started out as a Software Engineer and moved on to Manage/Direct engineering groups. When I got my PMP I was well equipped to work with the Software team.

Great projects are like great works of art. They are memorable and live beyond their time!


November 6, 2008 Posted by | Business Analyst, PMP, Project Management | , , , , | Leave a comment

The Role of the PMO in Organizations

Many organizations realize the benefit of developing and implementing a PMO. This is often true of those organizations employing a matrix organizational structure, and almost always true of those employing a projectized organizational structure, especially when the parent organization is involved with the simultaneous management of multiple and/or sequential projects.


A PMO can exist in any of the organizational structures, including those with a functional organization. A PMO’s function in an organization may range from an advisory influence, limited to the recommendation of specific policies and procedures on individual projects, to a formal grant of authority from executive management. In such cases, the PMO may, in turn, delegate its authority to the individual project manager. The project manager will have administrative support from the PMO either through dedicated staff or through a shared staff member. The project team members will either be dedicated to the project or might include staff members who are shared with other projects and, in turn, are managed by the PMO.


Project team members will report either directly to the project manager or, if shared, to the PMO. The project manager reports directly to the PMO. Additionally, the flexibility of the PMO’s centralized management can offer the project manager a greater opportunity for advancement within the organization. Specialty project team members can also be exposed to alternative project management career options in organizations with PMOs.


Project Management System

The project management system is the set of tools, techniques, methodologies, resources, and procedures used to manage a project. It can be formal or informal and aids a project manager in effectively guiding a project to completion. The system is a set of processes and the related control functions that are consolidated and combined into a functioning, unified whole.


The project management plan describes how the project management system will be used. The project management system content will vary depending upon the application area, organizational influence, complexity of the project, and availability of existing systems. The organizational influences shape the system for executing projects within that organization. The system will adjust or adapt to accommodate any influence imposed by the organization.


If a PMO exists in the performing organization, one of the functions of the

PMO would typically be to manage the project management system, in order to ensure consistency in application and continuity on the various projects being performed.[i]


[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition

2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

November 5, 2008 Posted by | PMO | , | Leave a comment

Organizational Influences on a Project

Projects are typically part of an organization that is larger than the project.

Examples of organizations include corporations, government agencies, healthcare institutions, international bodies, professional associations, and others. Even when the project is external (joint ventures, partnering), the project will still be influenced by the organization or organizations that initiated it.


The maturity of the organization with respect to its project management system, culture, style, organizational structure and project management office can also influence the project. The following sections describe key aspects of these larger organizational structures that are likely to influence the project.


I have worked as a Project Manager in all of these types of organizations. There are pros and cons of each listed below. It is vital that the organizational structure is clear and known to all for the project to run smoothly.  


Project-based organizations are those whose operations consist primarily of projects. These organizations fall into two categories:


Organizations that derive their revenue primarily from performing projects for others under contract – architectural firms, engineering firms, consultants, construction contractors, and government contractors.

Organizations that have adopted management by projects. These organizations tend to have management systems in place to facilitate project management. For example, their financial systems are often specifically designed for accounting, tracking, and reporting on multiple, simultaneous projects.


Non-project-based organizations often may lack management systems designed to support project needs efficiently and effectively. The absence of project-oriented systems usually makes project management more difficult. In some cases, non-project-based organizations will have departments or other subunits that operate as project-based organizations with systems to support them. The project management team should be aware of how its organization’s structure and systems affect the project.


Organizational Cultures and Styles

Most organizations have developed unique and describable cultures. These cultures are reflected in numerous factors, including, but not limited to:

Shared values, norms, beliefs, and expectations

Policies and procedures

View of authority relationships

Work ethic and work hours.

Organizational cultures often have a direct influence on the project. For example:

A team proposing an unusual or high-risk approach is more likely to secure approval in an aggressive or entrepreneurial organization

A project manager with a highly participative style is apt to encounter problems in a rigidly hierarchical organization, while a project manager with an authoritarian style will be equally challenged in a participative organization.


Organizational Structure

The structure of the performing organization often constrains the availability of resources in a spectrum from functional to projectized, with a variety of matrix structures in between.


The classic functional organization is a hierarchy where each employee has one clear superior. Staff members are grouped by specialty, such as production, marketing, engineering, and accounting at the top level.

Engineering may be further subdivided into functional organizations that support the business of the larger organization, such as mechanical and electrical.


Functional organizations still have projects, but the scope of the project is usually limited to the boundaries of the function. The engineering department in a functional organization will do its project work independent of the manufacturing or marketing departments. When new product development is undertaken in a purely functional organization, the design phase, often called a design project, includes only engineering department staff. Then, when questions about manufacturing arise, they are passed up the organizational hierarchy to the department head, who consults with the head of the manufacturing department. The engineering department head then passes the answer back down the hierarchy to the engineering functional manager. These organizations are good for having a clear career path for project team members when the project ends.


Projectized organizations have team members that are often collocated. Most of the organization’s resources are involved in project work, and project managers have a great deal of independence and authority. Projectized organizations often have organizational units called departments, but these groups either report directly to the project manager or provide support services to the various projects.


Matrix organizations are a blend of functional and projectized characteristics. Weak matrices maintain many of the characteristics of a functional organization and the project manager role is more that of a coordinator or expediter than that of a manager. In similar fashion, strong matrices have many of the characteristics of the projectized organization, and can have full-time project managers with considerable authority and full-time project administrative staff. While the balanced matrix organization recognizes the need for a project manager, it does not provide the project manager with the full authority over the project and project funding.

Such a team may have many of the characteristics of a project team in a projectized organization. The team may include full-time staff from different functional departments, may develop its own set of operating procedures and may operate outside the standard, formalized reporting structure.[i]


[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition

32 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA


November 4, 2008 Posted by | Communications Management, Project Management | | 2 Comments