When it comes to the issue of project discipline, one of the duties of those who have responsibility for the eventual success of the project must be to very carefully assess the size and complexity of what is being proposed within the project. Although there is a natural tendency to want to accommodate any and all requests for features and functions within a particular system, that tendency must be modified by the reality of the possible. Accommodating every request should not be the goal of the project; rather the goal should be to deliver a reasonable set of functions and features on time and within budget. If project discipline is in place at the beginning of the project, and is consistently maintained throughout the project, the eventual result is much more likely to be what everyone had expected. When that occurs, everyone benefits.
Assessing proposed IT development projects in terms of the size, features, and functions to be delivered within the established project funding and schedule should be seen as being a joint effort between the IT department and those business units in which the new applications will be used. To be effective, the work associated with coming to a realistic project size cannot be done through a process in which the members of the IT department attempt to mandate project size. The approach has to be to include every area that has an interest in the ultimate result of the project and to work out a compromise that comes as close as possible to meeting the needs of all the areas. Those needs must be met within the context of maintaining reasonable project size and complexity.
What constitutes “reasonable” project size and complexity? There will be a different answer to that question for every organization and every project. Each time an IT
project is proposed, except for small projects, the issue of reasonableness is going to have to carefully considered. Taking the time to make that consideration should be seen as one component of improved project management discipline.
It is understandable, given the pressure on everyone involved to deliver more function and features at an increasingly rapid pace, to want to be as responsive as possible. The apparent way to do that is to include as much as possible into a single project. That issue can be compounded by the need for various features and the very real possibility that, if they are not included in the current project, the opportunity to get them may simply be lost. Where the need is recognized, along with the often real situation that now may be the only time to obtain the particular features, it is very
difficult to resist loading as much into the project as possible. However, the important question here has to do with the probability that the project, having grown too large to effectively manage, will fail, and nothing (or perhaps very little) will be delivered.
Having come to a realistic assessment of what can be delivered in terms of IT
projects within an organization, IT management has both an obligation and a duty to set and hold the line on project size and complexity. If developing the project in phases or as several or even a series of smaller projects makes good business sense, that route should be taken. The idea has to be to assist the organization to avoid making project mistakes.
CONCLUSION
Although IT projects are inherently complex and difficult to manage, and the larger and more complex the project the more difficult effective management becomes, steps can be taken to mitigate the potential difficulties associated with IT projects.
To begin, there must be an awareness within the IT department that project size and complexity represent the primary factors with regard to project success or failure.
Organizations must come to some level of understanding as to what the particular culture can successfully absorb in regard to project size. When that understanding has been reached, everyone involved has to be willing to cooperate to make certain that proposed projects do not exceed a size and complexity that presents a reasonable chance for success.
Restraining the natural tendency to add as much function and as many features as possible onto every new IT project must be seen as a discipline that must be accommodated within the organization. The goal has to be one of balance, between obtaining the most value possible from the project while avoiding a risk of failure that is too high for the organization. One of the problems is that in many organizations, the ability of the IT department to meet the needs of the organization has been constrained by the use of arbitrary IT funding levels. Those funding levels are usually too low, and the result is that IT cannot meet the business needs of the organization. Where that circumstance has existed over a period of years, the result is often to try to gain at least some of the needed business items through IT project overloading.
An important aspect of making the changes needed to reduce the risk of IT project failure must be to recognize the cultural issues involved in dealing with the problem.
Making the needed changes is going to have to be a joint effort between all areas involved in IT projects. In order to begin the process, IT management should provide the needed leadership. Preparing and presenting factual information highlighting existing IT project development approaches that lead to difficulty, coupled with a factual analysis of the level of development capability within the organization, constitutes the first step in moving to improvement.
The next and more difficult step is going to be to “sell” the benefits of making needed changes throughout the organization. Doing that, as is the case with any cultural change, will not be quick or easy, but IT managers should see making it happen as one of their mandates. In many organizations, developing a case that the current processes are not working will not be difficult. Using that case as the basis of a presentation to senior management for support to begin to take a different
approach to the way IT projects are considered and structured within the organization should provide support for needed changes. Where there is a clear, well-presented review of the facts, coupled with a well-developed plan to move to improvements, the probability of the support of senior management will be high.
Chapter 40: Designing an Effective Project Management Office
Leigh Hardy and Tom Chaudhuri
OVERVIEW
An organization setting up or developing a project management office (PMO) must necessarily consider a range of dimensions and responsibilities such as those discussed in this chapter. In many cases, organizations unsystematically grapple with the design process. This chapter proposes that a group setting up a PMO can shortcut the process of designing a PMO, that will match the requirements and priorities of their organizations, by systematically evaluating the dimensions listed herein and adopting the design options that best meet their needs.
As the move to “manage by projects” becomes more popular in organizations, there is also a move to set up PMOs to support project management. The role of these PMOs is diverse and varied, but commonly includes setting standards and methodologies for project management. Often, this role is expanded to include aspects of project human resource management and sometimes to include responsibility for the execution of projects.
Confronted with the task of setting up a project office, the responsible executive or group must define the roles and responsibilities of the office. Some authors have identified several types of project office design such as the PMO as repository of project management knowledge, or the project office as a functional group responsible for managing projects. However, these models oversimplify the variety of designs that are possible. This chapter contends that there is an almost limitless variety of possible designs.
A framework is presented for designing a project office that is appropriate to the needs of an organization. A number of key dimensions and responsibilities that should be considered are identified. These have been subdivided into: organizational factors; human resource responsibilities; responsibilities for setting project management standards; project execution responsibilities; and strategic responsibilities. These dimensions and responsibilities are discussed in terms of the choices that are available, and the reasons for adopting a particula r design. This chapter takes the position that there is no one ideal design for a PMO and that the design of a PMO within an organization should (and will) evolve over time as the organizational requirements and priorities change and the organization’
s project
maturity and competencies change.
ORGANIZATIONAL FACTORS
A starting point in setting up and designing a project management office is establishing the organizational role and power of the office. Some of these organizational factors may be mandated by the executive or group setting up the office, but frequently they are refined as a PMO evolves. These factors are pivotal to
the roles and responsibilities of a PMO. The following are some of the core design factors to be addressed in establishing and designing a PMO.