Abstract
For many organizations, building project management from one department's point of view is a headache Companies also face the challenge of designing different levels of maturity in many units. In light of this, how should the organization that wants to manage projects on a whole-company scale look like? What role should the project management office take? How should a project portfolio be managed? And, finally, how do you build a culture with different perceptions of business or IT projects? These questions are the basis for this paper and presentation. Answers to these questions were prepared based on case studies from Polish and international companies.
Introduction
The development of project management and the ever-growing popularity of project approaches has led all departments in organizations to want to create their own methodologies and standards of project management. The lack of proper communication inside the company is the main cause of a situation in which everyone builds his or her own “island of knowledge about project management.” My own experience shows that organizations tend to have all the knowledge and competencies in management needed for their development; an integrated approach and a general view of the organization enable effective development in project, program, and project portfolio management. The following points present some aspects of integrated project management in an organization.
Integrating Project Management Processes in a Company's Environment
What Came First, the Process or the Project?
The ultimate question of “What came first—the chicken or the egg?” is often easily paraphrased into “What came first—the process or the project?” This is done by many organizations; some of them are process oriented, and want to implement project management into their businesses, others are project oriented, and want to use process approaches in some of the areas. This problem grows when we look for different departments and different project management practices. So, an organization should answer the following two major questions:
- What is the level of complexity from which an initiative should be treated as a project (and when there is an official project manager role)?
- Which initiatives should be treated as a process and which as a project?
Examples from Polish companies show that a higher level of a company's maturity impacts the level of use of the standard processes for initiating, planning, executing, monitoring and controlling, and closing projects. An interesting observation is that the level of the project manager's authority doesn't give the project manager the power to change the processes used in his or her projects.
The Connection Between the Process and the Project
In one of the Polish telecommunications companies, a team of business analysts was formed and its goal was to monitor (in a process way) the markets, products, and opportunities from the business side and their findings were to be sent to IT to be developed as projects. Ideas for projects were stored in IT, which had to analyze them in an “IT way,” check for available resources, and, eventually, proceed with project work. The estimated time to “pick-up” a business initiative after its arrival to IT was three months Needless to say, the telecommunications market is very turbulent, changeable, live, so after three months there wasn't much from those initiatives that could be executed as projects. The lack of balance between the process approach and the project approach was a major issue in this case.
Where is the Start of the Project and Where is the End?
The previous examples show that it is very important to define the start and end of a project. The answer differs depending on the branch of the company and even on its departments. Usually, we have three project decisions: after the initiation phase, when the project is allowed to be planned; after planning, when it gets the green light to be executed; and, at the end, when its products are accepted and it is formally closed. The problem in this case was: When do we end the project? When delivering the product or after supporting it for a while? Maybe the project should be prolonged for a while longer in order to reduce its later maintenance costs, which would be much higher, if a new team would start maintaining it instead of the former project's team? These are very difficult questions and can partially be answered by the implementation of a project manager's competency model. Examples from Polish companies show that a good balance between a project manager and a maintenance manager role is very important for the long-term success of an organization.
Air China — A Near Tragedy
What Can We Learn from an Aviation Incident?
19 February 1985 was a day that almost ended tragically for the passengers and crew of a flight from China to the United Stated. Suddenly, during that flight, one of the four Boeing 747SP-09 engines stopped working. To make the situation even worse, the plane turned on its back, and the other engines shut off. Then, the plane started to descend 9100 meters, with a 5G overload, and just above the ground, its pilot managed to straighten the aircraft and perform an emergency landing at nearby San Francisco Airport.
After the flight, it was quite obvious that the pilot had been a hero—he saved all the passengers and the plane (which suffered some damage nonetheless). It was impossible to recover data from the moment of the accident, because at that time, flight recorders, (i.e., “black boxes”) were only capable of recording the last half hour of a flight. So, why collect other “lessons learned” then?
The background investigation took more than half a year. First, the experts eliminated potential weather influences. Second, they found that all the engines were safe to operate, although only one had some minor problems. Finally, the cause was found: pilot error. Instead of focusing on the flight, the pilot intervened personally when one of the engines had problems; he should have left this proble to the mechanic and continue monitoring all the strategic indicators of the plane. Failure to do so resulted in the aircraft turning onto its back, because the autopilot couldn't stabilize the flight when all engines weren't operating.
The lack of strategic perspective has led to a situation in which the crew didn't noticed that three engines were working perfectly well and were switched off because of the plane's unnatural position. Further investigation showed that the pilot changed time zones several times, and lack of sleep resulted in fatigue and poor concentration. As a result, airlines have since introduced new rules for determining flight schedules.
This accident shows us that even when our project is in trouble, we cannot lose our strategic perspective and start personally taking over, and that organizations should implement experience from the lessons learned.
Reporting in the Organization
How Much Do We Need to Report?
As we all know, there are several people in our organizations to whom we need to report our project status each month. Usually, we report to a steering committee or a sponsor. Other bodies in the organization that like us to provide reports are the Project Management Office (PMO) (in this case, business and IT PMOs), project manager supervisor, IT coordinator supervisor, resource managers, controlling/accounting, headquarters, and even the company's board of directors (Exhibit 1). Unfortunately, in many cases, each of these bodies requires different types and levels of reporting, which is a great deal of work to be done each month. I suggest that one, larger report, like the one created for a PMO, set the standard for the whole organization and be sent to each stakeholder.
Exhibit 1 – Project Management Reporting
The Combination of Project Porfolio Management and Project Management
From Project Management to Project Portfolio Management
The implementation of project portfolio management in an organization usually goes something like this: we have some projects executed in our organization and most of them are managed in Microsoft Project®, so we migrate all of them into a PPM (project portfolio management) system in order to get an overall view of the situation. What happens then? Some projects have actual data, some have old and outdated data, whereas some don't have any data at all. It is not important to have very precise data in all projects, but the data should at least be real and actual.
The key for the organization to better understand its portfolio is to look at it from the cycle of time aspect: we prepare a budget each year, we plan our resources for each quarter, and then the resources are checked for availability each month. From an organization's point of view it is important to show only some key factors of each project in order to monitor the entire portfolio efficiently.
So, in the beginning of PPM implementation, organizations shouldn't really care how the project is managed; the only important thing for them is to make the project pass the next “gate,” or decision (e.g., from planning to realization). Organizations should answer this question: What is the minimum amount of project data that is enough to make a project portfolio management decision?
Levels of Competencies
What are the Most Important Competencies?
Different positions in projects and organizations require different competencies. Examples from companies show that the competencies of a project coordinator are much different than those of an experienced project manager. A project coordinator should be able to create a good schedule but he or she doesn't have to manage people; however, what should the project manager's competencies be? Examples of many companies show that these competencies are not standard. Some organizations require project managers to spend their time drawing Gantt Charts, whereas others require more responsibility. Organizations tend to move from the “project coordinator low responsibility” approach to the “project manager high responsibility” approach.
A Complete Project Manager
An example of applying an analysis of project manager competencies in a company from the financial sector shows the differences in how project managers are prepared to do their jobs. Analyses have been conducted on project managers from both IT and business departments, in which each person was assessed in the areas of technical IT, technical project management, hard and soft management, and business competencies. The results, as shown on the chart below, are not very surprising: IT project managers are usually lacking management and, especially, business skills, whereas business project managers are very weak in technical project management and have almost no knowledge of technical IT (Exhibit 2).
Therefore, it is even harder to choose the right moment to end the project and hand over its results to a new (most likely) business team, which will continue to maintain it. If a company would implement some of the techniques of knowledge sharing and have business project managers train IT project managers (and vice versa), it would be possible to create “a complete project manager.”
Exhibit 2 – Project management competencies chart
The Project Management Office
Role of the PMO as an Integrative Element
Another element of integrated project management in organizations is the integration of project management methodology. Every type of project executed by an organization has its own manufacturing layer, which makes the knowledge and experiences from separate projects are not being shared inside the organization. An example of the implementation of project management methodology in a PMO, on the level of an entire company, has shown that the company had to create separate methodologies for seven types of projects. This has been achieved through defining the common life cycles of projects for the entire company. The effects on the organization were the abilities to monitor and control all the projects and define the standards and methods of initiating and closing them.
One of the elements that enable companies to integrate their project management is an implemented PMO. The office has to be implemented on the level of the entire company, not just one department, because in this case, the PMO will optimize and define projects locally, not globally. It is, therefore, much more efficient to take the “PMO as the nerve center” approach.
In the context of integrating the company in terms of project management, there is a challenge that pops up with the following question: Where will the PMO will be and what will be its future role? One of the risks here is that the PMO will cease to exist in organizations, because the training of project managers will be handled by human resources, controlling project costs will be handled by the controlling department, accounting will track all the expenses, and business will handle the rest.
An interesting example is from a construction company, in which the management of external projects is included in the company's processes, while managing internal projects is handled separately by the PMO. There is no PMO for external projects; therefore, it is very important to look closely at the following:
- Methodology and project management knowledge integration,
- Competencies and knowledge of project management integration and sharing, and
- Integration of project management processes with other processes in organization.
Conclusion
The very rapid development of project management practices in the departments of many companies shows that we should focus on the organization as one entity. The integration of company processes, competencies, and structure can significantly increase the effectiveness of project and portfolio management. We should focus on such areas as company strategy in the project management field, company integrated processes and structure, and company culture in project management.
