§ The development of the project charter: the purpose of this document is to identify the specifics of the project. Topics to be covered in the charter would include:
o
The purpose of the project, why it has been approved, the organization of the project team, and the benefits to be obtained from the project o
The scope of the project
o
Identification of the deliverables associated with the project and also, the identification of those items that are not, within the scope of this project
o
The identification of the project team members and the business units affected by the project
§ A review of the roles and responsibilities of the key members of the project team, including the roles of the project manager and the project sponsor.
§ A review of the concept of the PMO, its function, and purpose.
§ The use of an existing IT system development methodology (SDM). If an SDM
does not exist, one will have to be available for the project.
§ Development of the project standards, be they coding, testing, quality, or other standards.
§ A provision to provide continuing communication to everyone who may have an interest in the progress of the project. That communication process will include timely and accurate project status reports to all interested parties.
§ The development of an “issues list,” which will provide the ability to capture, track, and resolve issues of concern relative to the project.
SELECTING THE PMO PROJECT MANAGER
The person chosen for the role of project manager must be someone who has strong project management experience and is comfortable with the use of effective project management tools and techniques. It is also a good idea to have the project managed by someone who does not have a vested interest in the project beyond seeing the project completed. In that regard, the more objective the person managing the project can be when issues arise, the better. As the project moves forward, being able to maintain an objective view of the progress being made and the issues that are certain to come up is going to be of benefit to everyone involved in the project.
The issue of project scope creep is also tied to the objectivity of the person managing the project. When the project manager can focus on completing the project in accord with the original requirements, within the project deadlines, without undue concern for political issues, it will be difficult for scope creep to get started.
That should not imply that changes or additions will not be allowed once a project begins. Sometimes, there is no choice but to address issues that either were overlooked in the development of the project specifications, or, because of business changes, have to be accommodated within the project. The issue here is that an objective project manager will be able to identify the “nice to have” project add-on requests and to deny those requests without fear of negative personal consequences at some later date.
The project manager must enjoy strong support from the project sponsor. If, after the project gets underway, problems arise between the project sponsor and the project manager, it may be in the best interest of the project to replace one of those individuals. Even with the use of a PMO, there is likely to be some level of project tension. Where tension is generated between the project sponsor and the project manager, the project is going to suffer. It will be better to recognize that the sponsor and the project manager do not make a good team and to correct that situation than to attempt to gloss over the problem.
Once the concept of the PMO has been approved and a project manager appointed, he or she should begin an analysis of the current project management environment within the organization. That analysis should consider the level of apparent project management sophistication within the organization. When considering the
sophistication level, the word “apparent” is one to keep in mind. It may be that many good project tools and techniques are in place, but the question should be, “Are those tools and techniques being used in a consistent manner for the development of IT projects?” It does occur that IT organizations sometimes install the tools and techniques required to successfully manage projects and then fail to enforce the consistent use of those tools.
As an example, there may be a set of project management standards in place, but the issue to be resolved is the extent to which those standards are followed throughout the organization. Too often, unless project standards are tightly enforced within the IT department, they are going to be honored more in the breach than in practice. It is not unusual to find IT installations where a clear set of project management practices are in place but, because they are not well enforced, some projects may be developed using the practices and some may not. In some organizations, the project management standards are seen, not as being mandatory, but as a set of guidelines.
Where such a circumstance exists, there is a clear opportunity for the PMO to become a catalyst to move the organization toward an improved project management development environment. While taking on that responsibility may be beyond the defined purview of the role of the PMO, paying attention to the problem can bring added benefit to the organization. Where the project manager has the skill and experience to incorporate those improvements, it is in the best interest of the organization to take a bit of extra time to begin to improve the ways in which the organization manages IT projects.
PROJECT-RELATED ISSUE MANAGEMENT AND
RESOLUTION
One of the roles of the PMO should be to install a mechanism to capture and manage all project issues. Absent a formal, managed process to capture and resolve project-related issues, several serious project consequences are likely to arise, including:
§ Potentially important project items may be overlooked. It should be seen as certain that those items will create difficulty within the project at some later date.
§ The use of a formal process in which project-related issues are analyzed and prioritized will ensure that the most critical issues are identified, addressed, and resolved in a timely manner.
§ Absent a formal process of issue identification and prioritization, there will be a tendency to address those items that have the most vocal supporters, rather than those that may have the most impact on the project.
§ The use of a formal project issues approach provides a history of those issues, why they occurred, and how they were ultimately addressed.
When an issue management process is put in place by the PMO, someone must be assigned to oversee the process. That role will include the capture of the items, the publication of those items on a regular basis, reporting of progress against the items, and the final resolution of the items. The process should be seen as transcending the
particular project. As the use of an issue resolution process is employed within a number of IT applications projects, the material gathered should be maintained in a database for reference. Over time, the information in that database can be used to develop patterns of project difficulties.
Having knowledge of the types of IT project-related issues and their resolution can prove helpful as the IT department strives to improve the way applications projects are developed and delivered. Over time, it will be seen that projects tend to suffer from a number of the similar problems. Being able to identify the best way to correct those issues when they appear is going to speed project progress and reduce project tension.
THE OPPORTUNITY TO TEST NEW PROJECT
MANAGEMENT APPROACHES AND TECHNIQUES
Given that under the PMO, the project manager can concentrate on the management of the project at hand and avoid distractions in other areas, there should be an opportunity to think beyond the traditional IT project boundaries. Some time can be devoted to the consideration of some different approaches to the management of IT
projects. A number of sound methods exist that can be successfully used to improve the delivery of IT projects. One of the added value aspects of the PMO should be, as the project moves forward, to consider trying some of those different approaches to manage various aspects of the project.
Whether or not those management approaches should be used within the existing project will depend on a number of factors. Those factors will include the status of the project, relative to meeting its completion date, the willingness of the internal customers and senior management to accept a higher level of risk, and the culture of the organization.
In many organizations, the imposition of new or different IT management approaches mid-project is going to represent too much risk. That stance is understandable, particularly in an organization where initiating the PMO concept originally presented some level of difficulty. The project manager must determine whether or not proposing something new during the life of the project is the correct approach.