Developing Project Management Competency
by Alexandre Rodrigues, Senior Consultant, Cutter Consortium
The success of business models is increasingly dependent on project management as a core competency within organizations. Just as human resources management, quality management, IT management, and other emergent disciplines gradually conquered their place within the spectrum of formal core competencies of successful business models, over the last few years, we've been entering the era of project management in the mass market.
Project management is no longer the private property of large-scale construction or military projects. It has become a crucial element for the survival and prosperity across all industries. It is applicable to any and all application areas in which projects take place -- from construction and pharmaceuticals, through telecommunications and consulting, to the IT industry.
Despite its wide range of applications, project management appears to have a strong natural link to the IT world, which goes much beyond the IT industry itself. The chain is clear: business models depend primarily on the IT infrastructure; the development and sustainability of an effective IT infrastructure depends primarily on the success of IT projects; and in turn, project success depends on project management competency and maturity.
Across all industries, companies struggle to make a good investment out of their IT expenditures. Among other things, they quickly learn two things:
1) IT projects need to be conceived, evaluated, prioritized, and selected for success. That is, companies must find a way to do the right projects (or good projects).
2) IT projects must be executed to meet their scope, cost, time, and performance expectations. That is, companies must do the project right.
Often mistakenly seen as addressing only the latter, the project management discipline starts at the conception or initiation phase of a project and is highly concerned with program management and project portfolio management. Another key concern is, during the execution phase, to continuously review and drive the project scope toward addressing the business need for which the project was undertaken. A narrow focus on a single-project view, with a sole concern of meeting the initial specifications, can only be blamed on poor project management knowledge.
When organizations realize these facts, they often find the answer (or are encouraged to do so) in implementing project management offices (PMOs) and/or enterprise project management (EPM) systems -- the latter being a complex IT system that, to be properly implemented and used, requires well-developed project management skills.
Setting up a PMO has many facets. While a worthwhile endeavor, PMOs have a number of associated threatening risks that need to be managed effectively. To play a significant role, the PMO almost always needs some form of an EPM system as the main IT infrastructure that supports the project management methodologies. Because the implementation of an EPM system is apparently a much more tangible effort (ending up with fairly complex software installed in an application server, being used by almost everyone in the organization), companies often start from here or, even worse, call this the "PMO project." When they do this, they have started out wrong and typically more serious mistakes follow.
For someone with a process view of the business, it is easy to understand that the EPM effort should be framed as part of the PMO effort. It is nowadays widely accepted that tools must be designed to fit the processes, and not the other way around.
Starting from a PMO perspective, one would initially identify the existing types of projects in the organization and would then develop a project classification system that allows for an easy and effective means of modeling organizational efforts as "projects" (i.e., "projectizing" work efforts). Project management methodologies are then identified and tailored to the needs of the different types of projects. An iterative spiral process of evolving these methodologies would be devised, sequencing the adoption process so that it would start from those tools and techniques that address the most immediate needs. The size of the PMO would be defined and an expected growth would be planned for, based on expected support needs. A training plan for project management would be prepared across the whole organization, delivering different levels of detail and perspectives to executives, project managers, and team members. The EPM project would be conceived within this process to fit and support the overall approach.
This right view does not need to be heavy or daunting. It simply needs to be done, because it sets the vision for the benefits and devises a realistic and well-thought-out process to achieve them.
Unfortunately, some companies think they can get there simply by buying an EPM software package, asking the supplier or their IT department to install it, and then merely telling people to use it.
Imagine a situation involving competency on medicine within a company that works in an environment in which the risk of health hazards is high. The organization realizes it needs to develop an internal medical center. One would think that proper planning would be needed to train some employees to become doctors or to hire outside doctors, as well as to identify the required equipment and so on. Now, imagine that instead of this, the company decides to buy all the required equipment plus embedded software, and asks the logistics and IT departments to install it. Then, software engineers, accountants, architects, and secretaries are asked to go and use it in the case of an accident. This is just one example. We could also think of an accountant being asked to design a building after AUTOCAD is installed on her PC.
Project management as a science, profession, and competency within the organization is not much different. It is more recent, less known, not so well mastered by most professionals, but must be handled in the same way. From the wrong perspective and wrong start, a series of mistakes follows. Briefly, these are some of the key guidelines to remember:
a) Don't try to do too much at once. It is a capital mistake in process improvement initiatives "to bite off more than what you can chew." Evolve the adoption process iteratively. In any iteration, each technique, or small set of techniques, must be simple enough for people to focus on and not to develop resistance based on excuses that "it's all too complicated!" Remember that complexity is a strong excuse. Projects are not simple nor is the solution to manage them, at first sight. Complexity is directly proportional to -- and in great part a result of -- ignorance.
b) So start the process with training. Train, train, train! Make sure that everyone in the organization has a good grasp of what project management is about. Make sure that future users of the EPM system know why they will be asked to follow certain standards and procedures for project planning and control, and value these. You don't want the recently promoted doctor to complain that the preparation procedures for a surgery (like sterilizing the instruments) are too tedious and that the supporting software is too complicated because there are too many views available on the information.
c) Top management support, commitment, and involvement throughout is an imperative. You started it, so have the determination to follow it! It will require effort from others, including you. Don't tell your staff to go and do it, throw some consultants in, and then stay at a distance, looking only now and then. This is not an experimental aquarium, and your staff and the consultants are not nice exotic fish. This is costing you money and results are expected. Top management must get involved, if nothing else because they too are crucial stakeholders within the project management arena.
d) Don't leave it in the hands of the IT manager (unless, by a fortunate coincidence, he or she also happens to be a project management expert). Like in any other project, the IT manager is a supplier of resources and services. In other words, he or she is a functional manager who is supposed to deliver resources to the initiative that are competent on IT issues, and coordinate with the project manager the performance and scheduling of those resources. The IT manager probably knows very little about project management. Just because it all appears centered around the installation of an IT system (i.e., the EPM), the IT manager does not become a project manager. If you were to install a medical center with a lot of hardware and software, imagine what it would look like in the end if the IT manager was to plan and control the project. As a functional manager, the IT manager will most likely be concerned with:
1) Spending as little as possible in software and hardware, so that costs at his or cost center are kept low
2) Trying to simplify the software as much as possible, preferably going for one-size-fits-all types of solutions, so that he or she is not going to have a lot of users asking for support in the roll-out phase
3) Getting rid of the hot potato as soon as possible, because it's not about the IT manager's expertise
Doing good IT projects, and doing them right, is key to almost all business models across the various industries. Project management offices and EPM systems can deliver great value to the organization, providing for the development, sustainability, and growth of the project management competence. EPM systems allow for senior executives to quickly develop quantified big pictures of project investment. They also allow for the project manager and his or her team to manage projects toward the expected benefits. However, implementing PMOs and EPM systems itself requires a project management approach, moving the perspective much beyond a simplistic and dangerous tool mindset.