Corporate Social Responsibility (CSR) And Project Management

Corporate Social Responsibility (CSR) has gained significant momentum in recent years. The push is on to identify projects that reflect the corporation's sense of social responsibility and to tailor projects to reflect that sense. This is perhaps a step in the right direction when it comes to the corporation's position in the host community but is extremely difficult and complex in its implementation. There are 2 key factors that contribute to its difficulty:


Corporations' main goal is still profits; they owe this to their shareholders. Although profits and social responsibility are not necessarily mutually exclusive, there is frequently a price tag associated with CSR projects and this creates a conflict: choose the CSR project, or tailor the project to meet CSR objectives OR focus on increased ROI? Where a project meets both objectives, the conflict is eliminated but you know intuitively that this won't always be the case and indeed there are more and more news reports about cases where this wasn't the case.

How does the corporation determine what is socially responsible and what isn't? This is seldom clear cut and in many cases different social groups have goals and objectives that are opposed to one another. The corporation can't satisfy the objectives of both groups and will be seen as irresponsible when it chooses one or the other.

These issues are compounded when a corporate citizen of one country engages in work in another with different social values. The chances of a conflict between two social groups who are stakeholders in the venture increase because of the cultural differences between the stakeholders in the home community and those in the foreign country. Companies have invested millions of dollars developing their CSR persona only to see it destroyed by one ugly conflict that gets media exposure. The results achieved by the CSR investment are not newsworthy while the single incident that tarnishes that image is.

Take the recent debate over the behavior of Canadian mining companies overseas and in South America for example. The media exposure was triggered by a private members bill (C-300) proposed by a member of the Canadian parliament. The bill asks that the federal government assume the power to investigate complaints that any Canadian mining company failed to comply with international human rights and environmental standards. On the face of it, there doesn't seem to be anything a socially responsible mining company could object to. The problem is that the bill can't guarantee that the accused mining company would have the ability to confront their accuser to answer the charges and that is what the association representing Canadian mining companies is objecting to.

The debate on the bill has spawned two stories in the Toronto Star about potential problems with mining operations in Ecuador, Argentina, and Papua New Guinea. The stories include responses from spokespeople of the mining companies involved, but the exposure of these allegations in a national newspaper has tarnished the CSR reputation built up by the mining companies mentioned. I won't mention those companies here because none of the allegations has been proven. Some of the mining companies have gone to great lengths and expense to build a reputation as socially, economically, and ethically responsible corporate citizens, only to see that reputation threatened by these stories. Now, I'm not suggesting that the allegations are all false. I have no idea as to their validity. What I do know is that in some cases the situation quoted was a no-win situation for the mining company involved. Let's take the example of a Canadian company operating in Ecuador as an example.

According to the article by staff reporter Brett Popplewell in the Monday, November 23, 2009 edition of the Toronto Star, the company is engaged in a project to build an open pit copper mine in Ecuador. The mine has provided jobs for one Ecuadorian community and is popular with it as a result. Another community is fiercely opposed to the project because they fear the mine will negatively impact their small farms and this has led to conflict between the two communities. The Ecuadorian ministry of mines is on-side with the project but apparently has done nothing to quell the conflict between the two communities. Allegations have been made by members of the opposed community that the guards hired by the mining company have used excessive force in dealing with protests against the mine. The guards, or course, are Ecuadorian citizens. Another story in the same paper quotes an accusation of gang rape at a mine in Papua New Guinea, again unproven. The latter allegation is so serious that the paper did not mention the mining company the accusation was leveled at (they did mention the company involved in the Ecuadorian accusations). A third allegation involved a company operating in Argentina. The allegation is that the company used threats to force an Argentine government official out of office.

The companies claim to have followed all the mining laws, rules, regulations, and standards of the countries they are operating in. They further claim to have followed their own code of ethics. These ethics have been developed and implemented at significant expense in some cases. In some cases the spokesperson answering the allegations on behalf of the companies is the Vice President of Corporate Responsibility which is some indication of the emphasis placed on ethical behavior by these companies. Whether or not these companies have been effective in adhering to the laws of the countries they operate in and their own codes, it is apparent to me that they have honestly tried to do so. What went wrong then?

The problems these companies are currently encountering can be traced back to the factors previously mentioned. Implementing the code of ethics crafted by their CSR organizations will inevitably inflate costs at some point during some projects. Is it possible for a corporation to have two organizations that are in conflict? You bet. Remember we're dealing with people here and as everyone who has worked with others knows, a working relationship leads to differences of opinion. For a team working on a project, the project manager will ask the team members to forsake personal agendas for the good of the project. When the conflicts are operational and conducted at the executive level this approach doesn't always work.

The initiation of the mining project, in the case of the Ecuadorian mine, was enough to initiate a conflict between the two communities in the area of the mine. One suspects that there may have been issues between the two that pre-date the mine. So how does all this concern the project manager? The issues the Canadian mining companies are experiencing demonstrate the difficulties it is possible to face when doing business in a foreign country. These examples are probably extreme. I'm sure that not many software projects will lead to a corporation facing allegations of physical abuse or rape. On the other hand, the underlying factors will affect any project. The question is what can a project manager do to address these factors?

The first step is for the project manager to understand all the issues that can affect the project, including pre-existing local issues. Is it reasonable to expect a project manager to have foreseen the conflict between the two communities involved in the Ecuadorian dispute? I would say given enough education on local issues and the likelihood that the project would only directly financially benefit residents of one of the two communities, the dispute could have been foreseen. How to address the issue is another story. There may or may not have been something the mining company could have done to avoid the conflict but they should at least have anticipated the risk of this happening and if no mitigation strategy was feasible they could then have decided whether they wanted to assume the risk. The object lesson for project managers here is that the exercise of risk identification must be expanded to include not only the risks of a culture clash between the foreign country hosting the project and the corporation's country, but those of different stakeholder groups within the host country. So how would a project manager go about identifying those risks? The answer is that the investigative work required surpasses the activities we normally associate with risk identification. Speaking to members of both communities would have revealed pre-existing conflicts, examining back issues of local newspapers and interviews with local officials would be other sources for the information. The lesson here is that you may have to expand your risk identification exercise to include mining the information that would help you identify risks.

There is another issue that has plagued corporations doing business in foreign countries long before anyone ever heard of CSR, namely the issue of a clash between the laws governing the corporation in the country of origin and the laws and cultural norms of the country hosting the project. The classic example of this clash is the solicitation and payment of bribes. In many countries outside of North America and Europe the solicitation of bribes is not only legal, but is actually encouraged by the local governments. Laws in North America make it illegal for corporations to pay bribes even in foreign countries where doing so is not illegal. This creates a Catch-29 situation for these corporations. If they fail to pay a bribe when one is solicited, they risk incurring costs that might far exceed the bribe solicited. Let's take the case of a bribe solicited to pass imported equipment through customs. The bribe doesn't violate local laws or norms. Failure to pay the bribe will mean that the equipment languishes on a loading dock or customs shed until the project manager either finds an alternative solution that doesn't require the equipment or the project fails. In either case the effect on the project budget is catastrophic. Alternatively, the project manager could pay the bribe and incur criminal charges in North America which will probably include fines the corporation has to pay. So what do you do if you find yourself in this situation?

The answer is simple; don't find yourself in that situation. The situation described above is untenable and no project manager should be asked to expose themselves to that level of risk, regardless of your views on bribes. You can avoid this situation by investing a little time during the initiation phase of your project to investigate the risks. What are the applicable laws of the country the project, or portion of the project, will be performed in? Will the project call for the importation of any equipment? What are the laws in the corporate headquarters country pertaining to conducting business in a foreign country? What are the international laws pertaining to labor and human rights? Perhaps the best way to approach the investigation is to look at the project scope and your project management approach and determine which questions you should ask. Know the risks going in. Normally we think of risk identification as a project planning process, but there are some risks which will have a bearing on whether the corporation wants to undertake the project, or whether you want to undertake managing the process. These are the risks that will be identified by asking the right questions. Once the risk has been identified, such as the risk of being solicited for a bribe, you can then make the decision as to whether there is a mitigation strategy that might work. If you can't identify a workable mitigation strategy, does the corporation want to undertake the project? Do you want to undertake managing the project? Sometimes the situation calls for you to ask the right questions of the right people before you commit to the project.

Project managers must become knowledgeable about their corporation's Corporate Social Responsibility policies so that the goals and objectives of their projects conform to these policies, but they must go further than that. They must determine how well those policies conform to international law and the laws, standards, and social customs in the country where the project work will be undertaken. They must also investigate all the possible stakeholders in the host country to determine if there are any conflicts with the corporation's CSR policies or with each other. There really isn't anyone in a better position to do this when you think about it. The project manager has the best grasp of the project goals and objectives and management approach so is the best qualified person to identify risks to the project.

The suggestions in this article are not meant to contradict the best practices for risk management taught by project management courses such as PMP courses or other PMP exam preparation training, but rather to augment them. The strategy you use to quantify, qualify, monitor, and control the risks once you have identified them should be the same ones espoused in these courses.

The Corporate Advantages of a Project Management Process

A Project Management (PM) process is a process that wraps sound and repeatable structure around a series of events that lead to a projects completion or implementation. In most cases, you will see a structured diagram that lists the project management process groups used to manage a project. I have been fortunate to study and review many PM processes over the years from the Department of Defense to State and Local government processes. In addition, I have studied and reviewed PM processes in business enterprises, banking, health care and nuclear power. What I want to present, is the concept of the Project Management Process and why is it beneficial to have one in place in your organization.

In most cases Project Management (PM) processes actually serve a purpose in an organization by providing a PM process methodology in an environment where one did not formally exist. Though a corporation may have a SDLC (Systems Development Life Cycle) documented, these are specific to systems and application development and not project management. It should be kindly noted that projects are not exclusive to an Information Systems Department. It should also be noted that not all SDLC's properly reflect PM Processes.

According to the PMBOK (Project Management Body of Knowledge), "A project is a temporary endeavor undertaken to create a unique product, service, or result. These temporary and unique characteristics determine if a particular endeavor is a project." With that in mind, projects can exist in many areas of an organization and many times they do, with the caveat that they may not be treated as a project under the guidelines of a "Project Management Process." If projects exist without a PM process to reference, though they can be successful, often times these projects are managed in chaos.

The purpose of a PM process is to provide organizations and project managers with a structure and format that is common and repeatable, the PM process is not specific to a business unit or corporate department. The PM process should be used by all departments for projects specific to them or for projects that reach across multiple business units.

In a corporate process diagram, each process group could refer to associated project templates that can be completed and used for project documentation. Typically project documentation will consist of ...

1. The Project Charter

2. The Project Goals

3. A Case Summary

4. Stakeholder Analysis

5. Project Scope Documentation

6. Project Requirements Documentation

7. A Responsibility Matrix

8. A Project Plan

9. A Communications Plan

10. A Risk Plan

11. Meeting Minutes

12. And Status Reports

This is not an all inclusive list but it gives you an idea of some of the types of documents you should have for a formal project.

Let us review a situation where project management is not used, what are some of the pitfalls? An Information Systems Department is typical in many organizations so a software application will be used for this example. In this case, without any PM processes used, you can expect the project to be poorly documented or in some cases not documented at all, and most likely in a state of constant change. In other words, you start out with a business user meeting with a manager and/or application developer with ... we want the application to do this, and the requester presents what they want the application to do. At some point in time the requester returns and asks for additional functionality. That gets noted and acted upon. This cycle continues until the requester feels satisfied and the application is approved and moved into production.

So far, in the development phase we can see from this example that the project is uncontrolled forcing the developer to be in a reactive vs. proactive state. What can occur next is often expected without a PM process. The application goes into production and suddenly something is not working as expected. This could be caused by several factors. It was not fully tested before it went into production because there was no documentation to reference to create a test script. Or, the requester is looking for functionality that they did not ask for or forgot to ask for and there is no documentation to reference that identifies what did or did not take place. There could be other reasons but the outcome is the same, discouragement, disgruntlement, along with additional time and costs to complete the project.

Once again, in this example we see the project resources in a reactive state, uncontrolled by any formalities thus chaos exists. The reality of this example is the fact that the resources are not being effectively utilized and the corporation will pay for those additional costs financially and emotionally. Trust me, if the majority of your corporate resources are operating in this chaotic state, it will have a work-life balance drain on them. Additionally, the quality of the product is not managed effectively, thus the corporation will end up paying for that also. The productivity of the project resources is also at stake, and yes, there is a cost associated with that.

If we take this example and wrap a PM process around it we end up with different results. We would create and maintain solid and documented project requirements. Project requirements will be used to develop your future test methods, with the requirements fully documented, the information you need to test for in your application is already in your hands. The project manager could begin with the end in mind and work backwards to complete the project schedule. With software applications, incorporating the SDLC structure into the plan is good but be sure to gather the business user(s) needs and requirements and get those into the plan as well.

At this stage, we have already improved the process, documentation can be referenced to develop the application and the same documentation can be used to create the test cases. Suddenly, it is realized that we need to add a function to the application that was not in the initial project scope, this is where process kicks in. This is commonly referred to as change control, used effectively, a change request is made and before it is acted upon it needs approval. Once approved, this change is documented as part of the project requirements, so that it can be developed but also tested in the application testing process. It is also added to the project plan and monitored accordingly. (Please note that I have not gone into the risk factor discussion here, that is the subject of a future article)

PM processes provide a structure of managing information needed for the successful completion of a project. When I say "successful completion" I am referring to the triple constraints of project management which are the project cost, schedule and scope which wrap around project quality. If the outcome of a project is not up to par with the quality objectives, no matter how well things went, the project could be categorized as a failure.

In my research I have learned that as an organization implements a PM process or methodology, there are associated corporate REAL DOLLAR cost savings. For example, the median cost of a project can be reduced by up to 75% over an undocumented process. The project schedule can be reduced by close to 40%. The project resource time can be reduced by up to 75%. Then there is the quality consideration, the number of defects can be reduced by 80%. These cost, time and quality savings occur when an organization is diligent in the implementation of a sound project management process. As an organization matures in the use of project management there are additional cost, time and quality savings.

Let's take a moment to put the above savings into the actual numbers. The studies indicate that if you use a project management process, that your $100,000 application could have been developed for $25,000. That is quite a substantial savings just on the budget, and you have $75,000 to spend on other initiatives. If a project schedule can be reduced by up to 40%, which means the 20 week project schedule can be reduced to 12 weeks. With this in mind, now you have money and time to work on other initiatives. Next is project resource utilization, with up to a 75% savings, what took your resources 800 hours to accomplish now takes 200 hours to accomplish. Now you have additional time, money and resources for other initiatives. But wait, there's more (as this sounds like an info-mercial), the number of defects is reduced by up to 80%. What may have been 20 product defects ends up to be 4 defects. You end up with additional time, money and resources with less product defects. What is going on in your enterprise?

We are in a time when enterprises look specifically to increase business efficiencies by streamlining processes. IT managers are asked to maximize a systems ROI and align Information Systems with the goals of the business. In order to effectively accomplish this, C-Level executives down the ranks to IT managers need to understand how processes such as project management and others, impact the overall cost of systems and applications.

In challenging economic times, corporations that have sound PM processes in place (in addition to other sound business processes) are capable of focusing their efforts on controlling corporate costs and increasing profits using traditional methods. Compare this to organizations that need to control costs and increase profits in addition to improving business performance, improving business information, improving security, improving efficiencies and improving service to customers, suppliers, partners and employees. The operational costs for the latter corporation will be staggering compared to the corporation that has sound processes in place. Without sound PM processes in place, while projects are developed in chaos, they may be completed by sheer heroics. There is a corporate cost to operating under this method, my recommendation is to know the difference and make the right decision.

In my next article, I will be discussing project management solutions that can help alleviate some of the pains that corporations can endure during a time of financial concerns. More information about me is available via Linkedin, feel free to look up William M. Thom - MISM, PMP.