Organizational Influence on Project Management

If you are someone who has played the role of a Project Manager in more than one company you would know that the organization has a direct influence on how projects are managed. I have worked as a Project/Program manager in a few companies and I can vouch for this fact. 

In the PMP Exam series there were 3 articles that covered this topic and I have explained in great detail about how Organizational structure & culture impact projects. 

They are: 

• Organizational Influence on Projects 
• Understanding the Organizational Structure
• Enterprise Environmental Factors and Process Assets

Trivia: Some people use terms like Cultural Norms when they talk about an Organizations Culture. 

ORGANIZATIONAL STRUCTURE

Organization structure is the hierarchical relationships of various entities within the organization that collaborate with each other for project execution. Different organizations, by virtue of their objectives and core philosophies, carry different organizational structures. The structure of an organization determines the operational model used in the organization. Organizational structure determines the responsibilities for different functions and entities. 

You could refer back to the article titled Understanding the Organizational Structure to know more details because I don't want to repeat the same details once again. 

FUNCTIONAL STRUCTURE

The structure of a functionally structured organization is based on the functions performed by each component of the organization. Such organizations would have different departments that are responsible for different functions and the Project Manager would work with all those departments to get the project done. From the view point of a Project Manager, this type of organization is the hardest to execute projects. 

PROJECTIZED STRUCTURE

The structure of a projectized organization is based simply on the projects the organization executes. It follows that project managers have complete responsibility over all projects assigned to them. They are provided complete authority to define priorities, use resources, and direct and monitor work making this the best organizational structure for us to execute projects. 

MATRIX STRUCTURE

The matrix structure effectively combines the best attributes of the functional and the projectized structures. 

In a matrix-structured organization, team members report to both their functional managers and project managers. Effective management of this dual relationship is critical to overall success of the project. Thus, matrix structures require clear cut role definition. Also, team building in a matrix-structure organization is often difficult because of the dual reporting structure.

Depending on how close the Matrix Structure is, to either the Functional style or Projectized style, it can be categorized into 3 groups: strong matrix, weak matrix, and balanced matrix 

Strong Matrix

In organizations with strong matrix structures, project managers have greater authority or right to command than functional managers. Such organizations closely resemble those with projectized structures and have full-time project managers and full-time administrative staff for projects.

Weak Matrix

In organizations with weak matrix structures, project managers do not have as much power as functional managers. In a weak matrix, the role of a project manager might be more that of a project expediter or project coordinator, and, as a matter of fact, no official designation as “project manager” exists. The project expediter acts primarily as a staff assistant and communications coordinator and is not authorized to make or enforce decisions, whereas the project coordinator has moderate decision-making powers and reports to a higher-level manager.

Balanced Matrix

In organizations with balanced matrix structures, the powers of the project manager and the functional manager are about equal and in balance. Here, although the need for project managers is recognized, the project manager is not provided full authority over the project and project funding.

COMMON SUCCESS CRITERIA FOR ORGANIZATIONAL STRUCTURES

No matter what sort of Organizational structure your company is following, certain things need to be taken care of, if you want the proposed methodology of handling projects to be successful. Some of them are:

1. High Transparency
2. Strong Management Support 
3. Continuous Monitoring
4. Clear and On-time Communications 

If an organization can take care of the above 4 aspects, chances of their projects succeeding go up considerably. 

ORGANIZATION PROCESS ASSETS

Organization process assets (OPAs) are assets of an organization involved in project implementation that can be used to influence project success. Organizational Process Assets is just a fancy term for documents & templates that your company uses as per the project management & governance structure put forth by the PMO. Read this article about OPAs as I will be skipping the details and move on to key specifics quickly. 

Updating OPAs is generally the responsibility of the project team members as only they would have the complete details of the work they do especially those related to technical artifacts.

OPAs are grouped into two categories:

1. Processes and procedures
2. Project knowledge base — knowledge repository where filled-in templates and other data are available

Examples of process assets include formal and informal plans, procedures, processes, guidelines, “lessons learnt,” and historical information. Generally, OPAs appear on an organization's intranet site, so that team members can refer the procedure or process easily. Such an intranet may also carry filled-in templates and documents from other projects for reference. 

ENTERPRISE ENVIRONMENTAL FACTORS

Enterprise environmental factors are factors that surround or influence project success – basically the environment in which the project is being executed. Of course, they may have a positive or a negative influence on project outcome. These factors are used as inputs to the planning and initiating process because a project cannot be planned without analyzing available infrastructure, tools, and software. 

An organization's structure and infrastructure are good examples of the enterprise environmental factors that would govern any project management initiatives the organization may undertake. For more info on Enterprise Environmental Factors read this article from the PMP Exam series.

That wraps up the basics of Project Management related topics. The next section would deal with basics of Agile Project Management

Understanding the Project Environment

Before we can do anything useful with respect to managing our project’s risks, it is extremely important that we understand the Project Environment thoroughly. This is because, without a proper understanding of the Project’s Environment, we will not be able to identify all risks or worse handle them appropriately. You might be wondering why I haven’t said anything about understanding the Project itself here. That is because, as the Project Manager it is imperative that we already have a good understanding of the project characteristics like Scope, Deliverables List, Due Dates etc.

What would comprise a Projects Environment?

Anything and everything that can impact or influence the Project or its outcome will be part of the Project Environment.

As Project Managers, we must know the physical, social, cultural and political aspects of the environment where our project functions in order to efficiently manage all the risks that may arise out of these areas.

Project Environment Classification

As suggested in the previous paragraph, a project’s environment includes a whole myriad of factors that can affect its outcome. So, practically speaking we can classify them into as many categories as we want. But, at a high level we can classify the Project Environment’s into two categories. They are:

1. Internal &
2. External

An Internal factor is one that is directly tied to the Project. Ex: Project Stakeholders, Company’s Org Structure etc. Anything that is not an Internal Factor can be considered External.

The following are some internal & external factors that may affect the Project and be considered as part of the Project Environment.

Internal Factors that Influence the Project:

1. Organizational Structure
2. Culture
3. Project Stakeholders
4. Consumers
5. Technologies
6. Etc.

External Factors that Influence the Project:

1. Natural Factors
2. Political
3. Legal
4. Financial & Economic
5. Industry
6. Human Health & Safety
7. Etc.

Let us take a detailed look at these factors one by one… First let us start with the internal factors.

Organizational Structure:
This is a Project Environmental factor that can have a direct bearing on the Project Outcome. As a result it is extremely vital that any good project manager, esp. the one that is in-charge of Risk Management understands them well and can identify and distinguish one from the other. There are 3 main types of Organizations based on their structure:

a. Functional Organizations – These are traditional type of organizations where departments are grouped by their respective functions. Each department has a functional manager who reports to senior management. These organizations have a very well established chain of command. In these types of organizations the PM’s authority is very limited and they report directly to the Functional Manager.
b. Projectized Organizations – These are Organizations that are the total opposite of the Functional org. Here the PM is the king and almost everything in these organizations revolved around Projects. The PM has supreme authority.
c. Matrix Organizations – These are Organizations that are a blend of both the Functional & Projectized worlds. They try to achieve the best of both worlds. In this type of organizations people report to both the PM and the Functional Manager. Matrix Organizations can be split into 3 sub-categories based on who (the FM or the PM) has more authority.

a. Weak Matrix – Cases where the Functional Manager has more authority than the PM
b. Balanced Matrix – A Strong Blend where both the FM & the PM share responsibility & authority
c. Strong Matrix – Cases where the PM has more authority than the FM

In the chapter titled Understanding the Organizational Structure on the PMP Exam Prep series we had taken a detailed look at these organizational structures and how they affect each project. You can Click Here to revisit that chapter to learn more about these. I strongly urge you to re-visit this chapter because knowing this topic clearly is vital for us to not only be better Risk Managers but also to pass the RMP Exam.

Culture:
Culture is one environmental factor that is a blanket word that includes:

a. Company Culture
b. Ethnic Culture
c. Religious Culture &
d. Economic Culture

All these factors vary from place to place and projects that involve team members from different countries/backgrounds conflicts can easily arise out of differences in any or all of the cultural parameters mentioned above.

Stakeholders:

Project Stakeholders are part of the Projects Environment because they can directly impact and influence the project outcome. As the PM we need to know who those Stakeholders are and their level of influence, involvement & authority so that we can handle them accordingly. Based on the Stakeholders interest level and influence on the project, how we handle them will vary. Stakeholder Management is an art and we will be covering it in greater detail in future.

Consumers:
Anyone who is going to use the end product created by our project is a consumer and you already knew that, didn’t you? Knowing what our customer wants is extremely important for the Project’s Success. As Project Managers we need to have a good understanding of the customers’ expectations so that we can try to meet or even beat them.

Technologies:
The Technologies we use, the technologies that are available for us to use and also the technologies that will be created by our project are all part of the Technological factors that might affect our project.


All of the External Factors are self-explanatory and I suppose we don’t need to explain each of them in detail like what we did with the Internal Factors.

Caution:
External factors when they occur can have significant consequences on your project. For ex: In TamilNadu there is significant power shortage and as a result the government has scheduled power-cut time slots. So, every day you will have No-Power for a few hours. If your project needs non-stop power then you must arrange for alternative sources of power or else your production will be affected.

Get the picture?

The political, legal, economic factors are in almost all cases specific to the country where the project is being executed and are of paramount importance where we have an offshore team working with us. As good Project Managers, it is our duty to ensure that we take into account all these factors that might affect our project beforehand so that we can plan ahead to handle all of them. After all, this is what risk management is all about, isn’t it?

Prev: Risk Management & PMBOK

Next: Important Risk Related Definitions

Chapter 3: Organizational Frameworks

Aim: To Explain Organizational and Environmental Factors that might affect Projects

In almost all practical cases, a project usually exists within a larger organization. Some group or organization creates each project, and the project team must operate within the larger organization’s environment. Simply put, no project exists in a vacuum. Every process within every project is affected to some degree by organizational culture and practices.

Working with Organizational Politics and Influences

In many cases, the extent to which the initiating organization derives revenue from projects affects how projects are regarded. In an organization where the primary stream of revenue comes from various projects, the project manager generally enjoys more authority and access to resources. On the other hand, organizations that create projects only due to outside demands (like regulatory or legal requirements) will likely make it more difficult for the project manager to acquire resources. If a particular resource is needed to perform both operational and project work, many functional managers will resist requests to assign that particular resource to the project.

Another factor that influences how projects operate with respect to sponsoring organizations is the level of sponsorship from the project’s origin. A project that has a sponsor who is at the director level typically encounters far less resistance than one with a sponsor who is a functional manager. The reason for this is simple: Many managers tend to protect their own resources and are not willing to share them without sufficient motivation (In most cases, orders from upstairs). The more authority a project sponsor possesses, the easier time the project manager has when requesting resources for his/her project.

In addition to the above mentioned issues, the sponsoring organization’s maturity and project orientation can have a substantial effect on each project. More mature organizations tend to have more general management practices in place that allow projects to operate in a stable environment. Projects in less mature organizations might find that they must compete for resources and management attention due to fewer established policies. There can also be many issues related to the culture of an organization, such as values, beliefs, and expectations that can affect projects.

The last major factor that has a material impact on how projects exist within the larger organization is the management style of the organization itself. Since this is probably the biggest factor that might affect a project, we will look at it in a bit more detail.

Differentiating Functional, Matrix, and Projectized Organizational Structures

Each organization approaches the relationship between operations and projects differently. The PMBOK defines three main organizational structures that affect many aspects of a project. They are:
1. Functional Organizations
2. Matrix Organizations &
3. Projectized Organizations

Each of these 3 organizations differs from one another in the following aspects:
• The project manager’s authority
• Resource availability
• Control of the project budget
• The project manager and administrative staff roles

Functional Organizational Structure

A functional organization structure is a classical hierarchy in which each employee has a single superior. Employees are then organized by specialty, and work accomplished is generally specific to that specialty. Communication with other groups generally occurs by passing information requests up the hierarchy and over to the desired group or manager. Of all the organizational structures, this one tends to be the most difficult for the project manager. The project manager lacks the authority to assign resources and must acquire people and other resources from multiple functional managers. In many cases, the project’s priority is considered to be lower than operations for which the functional manager is directly responsible. In these organizations, it is common for the project manager to escalate to the senior management to resolve resource issues.

Advantage: The FM holds accountability for the project.
Disadvantage: The PM holds little or no authority.

Matrix Organizational Structure

A matrix organization is a blended organizational structure. Although a functional hierarchy is still in place, the project manager is recognized as a valuable position and is given more authority to manage the project and assign resources. Matrix organizations can be further divided into weak, balanced, and strong matrix organizations. The difference between the three is the level of authority given to the project manager (PM). A weak matrix gives more authority to the functional manager (FM), whereas the strong matrix gives more power to the PM. As the name suggests, the balanced matrix balances power between the FM and the PM.

Advantage: The PM and FM share the responsibility of the project
Disadvantage: The PM and FM can see each other as a threat and cause conflicts. In some cases, they may even be confused as to who manages what.

Projectized Organizational Structure

In a projectized organization, there is no defined hierarchy. Resources are brought together specifically for the purpose of a project. The necessary resources are acquired for the project, and the people assigned to the project work only for the PM for the duration of the project. At the end of each project, resources are either reassigned to another project or returned to a resource pool. Most IT companies work in such a Projectized Org Structure.

Advantage: The PM has full, or almost full, authority to staff and manage the project.
Disadvantage: The PM holds accountability for the project.

There are many subtle differences between each type of structure. You can visit the chapter on Organizational Structure to understand each of these better by Clicking Here.

Understanding Enterprise Environmental Factors

It is the responsibility of the project manager to understand the project environment. All projects operate within a specific environment or blend of environments. In addition to understanding the organizational structure, a project manager needs to understand the effects enterprise environmental factors may have on projects. The most obvious enterprise environmental factors for projects are
• Organizational culture and structure
• Human resources currently in the company
• Political climate in the country where the project is executed
• Government or industry standards and regulations
• Infrastructure facilities available
• Marketplace conditions
• Stakeholder risk tolerances

Organizational Process Assets

Two of the goals of project management are to make projects repeatable and to do a better job with each new project. To do this, organizations that are committed to effective project management develop shared, and often standardized, resources to help project managers do their jobs well. These resources are called organizational process assets and include formal and informal plans, policies, procedures and guidelines that might help the PM during the course of the project.

These assets could be as simple as a spreadsheet to a fully descriptive document that elaborates on various facts and processes. As these assets are put to use, they tend to be altered and refined. New documents often become necessary or useful as well. All lessons learned from previous projects should be examined to apply any necessary changes to the process assets. This continuous process of improvement encourages the base of assets to become a critical core of resources for any project. You will see organizational process assets mentioned in many of the project management processes. The assets can include many types of documents, including
• Organizational policies
• Operational guidelines
• Templates used to create many project process outputs
• Project closure procedures
• Communication requirements and procedures
• Change control procedures
• Financial control procedures
• Quality control procedures
• Project historical files
• Pertinent organizational knowledge bases

You can learn more about Enterprise Environmental Factors & Organizational Process Assets by Clicking Here

Exam Watch:
Organizational Process Assets are an input to many of the project management processes. Remember that this simply refers to any organization’s central repository of plans, policies, procedures, and guidelines that a project manager can use during his job of managing the project.

Prev: Chapter 2

Next: Chapter 4

Chapter 20: Developing a Project Charter

In the previous chapter we saw how projects are selected for execution by organizations. As the first step towards starting a project for execution, a Project Charter needs to be prepared. In this chapter, we are going to take a look at how to create a Project charter.

So, lets get started!!!

What is the Project Charter?

The project charter is a document that states the initial requirements to satisfy the stakeholders needs and expectations. It is the document that formally authorizes the project.

Trivia:
The project charter is the document that formally authorizes a project, which includes naming the project manager and determining the authority level of the project manager.

Developing a Project Charter

Obviously a Project charter has to be developed/created by someone. Let us see how it is created.

Look at the image below:

The input to developing the project charter comes from the origin of the project and from within the organization that will perform the project. The possible input items for the process of developing a project charter are:

1. Business Case
2. Project Statement of Work
3. Enterprise Environmental Factors
4. Organizational Process Assets
5. Contract

Business case - The origins of the business case are pretty much the same as the origins of a project. The business case is built on the business need addressed by the project that justifies the project. This will determine whether the project is worth the effort and the investment (Money). The business case may contain the cost benefit analysis that compares the benefits that would be received by executing the project to the money invested in running this project. The business case is written by either the person or the group within the performing organization that is proposing the project or by an external organization or the customer who is requesting the project or the product that will be produced by the project.

If the organization that is requesting the project is a separate entity than the organization that is performing the project, both may have their own business cases. In this case, the business case that goes into the project is the business case of the performing organization. The business case of the requesting organization will make its way to the project through the contract or the statement of work.

Project statement of work (SOW) - The statement of work is a document that describes the products, services, or results that will be delivered by the project. For an internal project, the SOW is provided by the project initiator or the project sponsor, whereas for an external project, the SOW is received from the customer as part of a bid document, such as a request for proposal, a request for bid, or a request for information. Alternatively, it could come as part of the contract. The SOW includes or refers to the business need that this project will satisfy, the product scope, and the strategic plan of the organization supported by the project.
Enterprise Environmental Factors - During the development of the project charter, you must consider the performing organization’s environmental factors relevant to this task, that might affect the project execution and outcome.

You can refer to the chapter on Environmental Factors for more details on them.

Organizational Process Assets – As with the Enterprise Environmental Factors, the Organizational Process Assets too can have a profound impact on the project execution and outcome. You can refer to the chapter on Organizational Process Assets for more details on them.

Contract - A project for a customer who is external to the performing organization is usually done based on a contract. This contract will outline the terms and conditions and the monetary aspects involved in executing a project.

You take the available input and apply the relevant tools and techniques to develop the project charter. The most important tool used in developing the project charter is the expert judgment described in the previous chapter.

The output of the Develop Project Charter process is a formal document called the project charter. It is a high-level document that summarizes the business needs, the understanding of customer requirements and needs, and how the new product or service will satisfy these requirements.

Any Project Charter, that is prepared by an experienced Project Manager would contain the following:

1. The project justification, which includes the purpose of the project and the business case for the project, which in turn may include return on investment.
2. A high-level project description that includes the business needs that the project addresses and the high-level product requirements.
3. High-level project requirements based on the needs of the customer, the sponsor, and other stakeholders.
4. Project objectives and success criteria, which are derived from the purpose section. This section explains exactly what will be done by this project and what exactly will be the outcome of this project. The most important point is that the objectives must be measurable.
5. High-level risks, which will be identified during the project planning. However, some high-level risks may be apparent during the time of developing the project charter.
6. Milestone schedule, some kind of high-level schedule.
7. A budget summary, A high-level summary of the project cost estimate with some kind of timeline.
8. Project approval and acceptance requirements , which include the name and responsibility of the person or committee that will approve and accept the project when it’s finished.
9. An assigned project manager, a specified authority level for that project manager, and the influences that the stakeholders might have.
10. Project sponsor, the name and authority level of the project sponsor authorizing the project charter.

Apart from these, the charter might include other elements like the list of functional departments of the organization and their roles (Like the Technical Support Team that would be supporting the Network and Hardware that the project team will be working on). Also, other external assumptions and constraints are outlined in this document.

An assumption is a factor that you consider to be true without any proof or verification. For example, an obvious assumption that any Project Manager might make during this stage is the fact that, his company will have sufficient personnel with the requisite skillsets that he needs to execute this project.

It’s important to document such assumptions clearly and validate them at various stages of the project because assumptions carry a certain degree of uncertainty or risk with them, and these risks can always have a negative impact on the Project if left uncontrolled.

A constraint is a restriction (or a limitation) that can affect the performance of the project. For example, there could be a schedule constraint that the project must be completed by a predetermined date. Similarly, a cost constraint would limit the budget available for the project.

The project charter provides the project manager with the authority to use organizational resources to run the project. Remember that formally speaking, project charters are prepared external to project management by an individual or a committee in the organization. In other words, the actual project management starts from where the project charter ends. But practically speaking, the project manager who is going to manage this project might actually be involved in writing the project charter. The project approval and funding will still be external to the project management boundaries.

Once you have the project charter, you know the high-level product (or service) requirements that the project will satisfy. However, a high-level requirement written in a certain way might mean different things to different stakeholders. So, after you get the project charter, your first task is to develop a common understanding of the project among the project stakeholders. You as the project manager must ensure that each stakeholder knows what is going to happen and what he/she can expect out of this project at the various timelines.

Once the project charter is developed, the project manager has enough information to identify all the project stakeholders.

Previous: Understanding Project Selections

Next: Identifying Project Stakeholders

Important Terms & Definitions - Introduction to Project Management

Before moving on to the next big topic on Initiating a Project, lets quickly cover the important terms and definitions we learnt in the preceding chapters. This would help you recollect what you learnt in those chapters!!!

• Enterprise environmental factors - Factors internal or external to the performing organization that can influence the project’s success, such as the organization’s culture, infrastructure, existing skill set, market conditions, and project management software. These are input to both the project charter and the preliminary project scope statement.
• Knowledge area - A knowledge area in project management is defined by its knowledge requirements related to managing a specific aspect of a project, such as cost, by using a set of processes. PMI recognizes a total of nine knowledge areas, such as cost management and human resource management.
• Organization - A group of individuals organized to work for some purpose or mission.
• Organizational process assets - The processes and process-related assets of the organizations participating in the project that can be used to perform the project successfully, such as templates, guidelines, knowledge base, and policies and procedures.
• Performing organization - The organization that is performing the project.
• Portfolio - A set of projects, programs, and related work that is managed in a coordinated fashion to obtain business objectives in the strategic plan of the organization.
• Portfolio management - The centralized management of one or more portfolios, which includes identifying, authorizing, prioritizing, managing, and controlling projects, programs, and other related work in order to obtain specific business objectives in the strategic plan of the organization.
• Process - A set of interrelated activities performed to obtain a specified set of products, results, or services.
• Program - A set of related projects managed in a coordinated fashion to improve overall efficiency and effectiveness that may not be obtained by managing the projects individually.
• Program management - The centralized coordinated management of a specific program to achieve its strategic goals, objectives, and benefits.
• Program management office (PMO) - An entity in an organization that is responsible for providing centralized coordinated support to the program managers managing programs and unrelated projects.
• Progressive elaboration - A technique used to continuously improving a plan by working out more details and better accuracy as more detailed and specific information becomes available as the project progresses.
• Project - A work effort made over a finite period of time, with a start and a finish, to create a unique product, service, or result. A process consists of three elements: input, tools and techniques, and output.
• Project management - Application of knowledge, skills, and tools and techniques to project activities in order to meet project objectives. You do this by performing some processes at various stages of the project.
• Project management office (PMO) - An entity in an organization that is responsible for providing centralized coordinated management for projects in the organization.
• Project stakeholder - An individual or an organization that is positively or negatively affected by the project.

Previous: Summary - Introduction to Project Management

Next - Introduction to Project Initiation

Chapter 12: Environmental Factors and Processes Assets

In the previous chapter, we took a look at how the organizational structure can affect a project and how it affects the life of a Project Manager. In this chapter, we are going to take a look at the two other things that would affect us (we are the project managers, right?)

1. Environmental Factors
2. Process Assets

So, lets get started!!!

Identifying Environmental Factors and Process Assets

While exploring the environment of the performing organization, you should also identify the environmental factors and the process assets that will influence your project. Some of these assets and factors can be used to help the project; others may have a negative influence. As project managers it is our responsibility to identify them and ensure that we use them in the best interest of the project and mitigate any and all risks they might pose to the success of our baby (The Project)

Enterprise Environmental Factors

The enterprise environmental factors are related to the environment internal or external to the performing organizations and can potentially impact the project. They may originate from within the performing organization, from any external organization participating in the project, or from both. These factors may have positive or negative influence on the project, and some of these factors may give rise to constraints for the project.

Organizational environmental factors include the following:

Culture and structure

1. These refer to the culture and type of structure of the performing organization.
Processes and standards:
1. The organization may have specific processes in place do certain things in certain ways.
2. There may be government and industry standards to follow, such as legal requirements, product standards, and quality standards relevant to the project.
3. Personnel administration information, such as guidelines for hiring, firing, and performance reviews.

Infrastructure and resources:

1. Facilities and equipment to do the project
2. Project management information systems, such as software tools for scheduling tasks and meetings
3. Human resources currently available in the organization, such as skills and expertise
4. Commercial databases, such as standardized cost estimating data and risk databases
5. Work authorization system of the organization, because the project needs to be authorized
6. Communication channels and tools available in the organization, such as email systems

Internal and external conditions:

1. Risk tolerances of the project stakeholders
2. Marketplace conditions relevant to the project
3. Political climate

Note that the environmental factors can be internal to the performing organization, such as the organization’s culture, or external to the organization, such as market conditions.

Organizational Process Assets

These are the processes or process-related assets from any of the organizations involved in the project that can be used to help the project succeed. Some processes might look like an overhead or overkill but as responsible project managers, we are supposed to follow them religiously, period…

The organizational process assets are typically grouped into two categories:

1. Processes and procedures for conducting work, and
2. A corporate knowledge base for storing and retrieving information.

For example, the performing organization might have its own guidelines, policies, and procedures, whose effect on the project must be considered while developing the project charter and other project documents that will follow. Another example of an organization’s process assets are the knowledge and learning base acquired from previous projects.

Let us now take a detailed look at these two things.

Processes and procedures

This category includes processes, procedures, guidelines, and requirements as described in the following:

• Standardized processes and procedures. Examples are organizational-level policies, such as health and safety policies, ethics policies, project management policies, and quality policies and procedures, such as quality checklists and auditing processes.
• Standard guidelines and criteria. Examples are:
      o Project closure guidelines, project acceptance criteria, proposal evaluation criteria, performance measurement criteria, and so on
      o Guidelines and criteria for tailoring the standardized organizational processes for the purposes of the project
• Templates. Examples are the templates to support some project management tasks, such as risk management, project schedule network diagrams, and work breakdown structure.
• Requirements. Examples are:
      o Communication requirements, hiring requirements, and safety and security requirements
      o Guidelines and requirements for project closures, such as final mandatory project audits and product acceptance criteria

You need to follow these guidelines and accommodate the requirements while working out the details of the project management processes that you will perform. As you are a part of the organization you need to be aware of them in the first place and include them in all your plans to ensure that you do not violate them. Processes are put in place for a reason and as a leader who leads by example, we must use them properly to motivate our team members to follow rules as well.

Knowledge base

This category includes databases, which allow you to store information and to retrieve the stored information when needed. Some examples are:

• Project files. The documents and files related to the project, such as the project charter and the scope statement.
• Historical information and lessons learned. Archives of files from previous projects and lessons learned from them.
• Issue and defect management. Database that allows you to manage issues and defects, such as to log, control, and resolve an issue or defect. You can also find the status of the issue or the defect from this database.
• Financial database. The financial information related to the project, such as budget, work hours, and cost overruns.
• Configuration management database. This contains the change history: different versions and baselines for the company standards and policies and for the archived project documents.

We are all either project managers or people who aspire to be good and efficient project managers. Any project manager would have to interact with two neighbors with whom we share our life as a manager. They are: Program and Portfolio. We will be looking at them next.

Previous: Understanding the Organizational Structure

Next: Relationship between Project, Program and Portfolio