June 2001 - Successful Project Management

Overview of Project Management; A Typical Large Project; Managing People, Politics, Process & Property; Implementing the New System; Resources (links, books, articles, humor)
Printer-friendly version

Successful Project Management

Definitions

Project Management is a discipline associated with managing projects.

A Project is any endeavor that has a purpose (or specific goal) and a limited life span. A Project may be large or small. Large corporate projects may involve many people, may change the way the company does things and may last many years. Small projects may be something as simple as setting up a meeting.

The components of a Project include Politics, People, Processes and Property.

Overview of Project Management

This month's article focuses on large projects that involve organizational change. For example, the intended goal of such a project might be installing a new computer system, changing the way the company (or organization) does business, changing the way assets or resources are managed, moving into a new market, or developing a new product or service.

Most managers will have ample opportunity in their career to manage projects, whether they have been specifically trained in this discipline or not. Many people without the title or function of "manager" will also find themselves managing projects at one time or another.

The function of "Project Manager" may be assigned to a specific person whether they have that as their official title or not. Similar titles and functions are "Project Director" or "Program Manager."

A Project Director tends to have more experience than a Project Manager, although that is not necessarily true. A Program Manager usually manages several projects or has oversight responsibility for several projects; they also tend to have more experience than someone managing a single project. Someone who has a title or function of Project Manager may have the skills or experience to serve as a Project Director or Program Manager. Confused yet? The point is that title alone does not define the skills needed to manage projects nor does the title define a person's ability. As we said above, many people manage projects and may never have that title officially.

For this article, we talk about the function of a Project Manager as well as the skills and experience needed to manage projects, without regard to a person's official title.

Most easily available information about the discipline of Project Management deals with the aspects of managing resources associated with the project. Those resources include managing the people directly reporting to the Project Manager, the timeline of the project and the budget associated with the project.

If all you do is manage the direct resources designated for the project, your project will not succeed. In this article, we cover some aspects of successful project management that are sometimes ignored.

In order to be successful, project managers must deal with many different components:

Politics associated with the change effort
People involved in the project
Processes that must be identified and changed in order for the project to succeed
Property associated with the project.

More on each of these subjects later in the article.

Why Project Management is Important

The track record of large corporate software projects has been pretty dismal according to the statistics published by the Standish Group. The success of the worldwide Year 2000 conversion effort and updated statistics indicate that the success rate is improving somewhat.

Summary of recent statistics from the Standish Group:

	1994	2000
Number of Project Starts	175,000	300,000
Percent of Failed Projects	31%	23%
Percent of Challenged Projects	53%	49%
Percent of Successful Projects	16%	28%
Average Cost Overrun	189%	45%
Average Time Overrun	222%	63%

Some of the reasons for the improvement noted in a recent article include the use of Best Practices, which include using more experienced project managers, improved project management techniques, stronger user involvement and executive sponsorship.

A Typical Large Scale Project

An example: a new system is being planned for a company. This new system has many new features, a graphical user interface (also called GUI), hosted on a network that will replace a mainframe system, which is 10 - 20 years old. End users of the new system will use desktop computers with some version of Windows, which will replace old CRT-type terminals (also called green screen or dumb terminals).

For the sake of our article, let's call this project the Mythical Project, our company the Mythical Company and the new system, the Mythical System. The points we discuss apply equally to government agencies and non-profit organizations who call themselves something other than "company."

To set the stage, let's start at the point where Mythical Company's management has decided that they need to replace their old mainframe system with a more modern system.

Some of the reasons might be:

Several of the company's competitors have replaced their mainframe systems
Employees have been complaining for many years about the "archaic" old mainframe system
The old system does not allow changes to be made easily
Adding new features to the system is difficult and very costly
Customer records cannot be searched easily
Customers are complaining about how long it takes for a product to be sent to them
Customers want an Internet method to order products
The old system requires more and more programmers to keep it running because it is so complicated
The cost of the mainframe is very expensive compared to network systems, etc.
Or, supply your own reasons from your own experience.

Management of Mythical Company will allocate some amount of money to get the project going and designate someone to be in charge. Our Mythical Project Manager gets the assignment. This person has prior experience managing large projects successfully and knows the right things to do.

Project Stages

In the early stages of the Mythical Project, the Mythical Project Manager and her team must decide whether to build a new system from the ground up or purchase a system. For large projects, often the fastest route is buying a new system, so we will assume for this article that is the choice made in Stage One.

Typically, Stage One of a large project consists of choosing which new system will be purchased. Stage Two consists of the activities associated with implementing the chosen system and making sure it works properly. Stage Three consists of future enhancements and improvements.

Stage One in a large project can take a year or more. In smaller projects, it may be completed in weeks or months. Stage Two will often take longer than Stage One (sometimes 2 or 3 times as long) and involve many more people. Stage Three is completely dependent on the needs of the company.

In Stage One (selection of the software system), the project team identifies which new software system they will implement. This stage requires the active involvement of key people who will use the new system - possibly supplemented by outside consultants.

Some of the people involved in Stage One will usually continue into Stage Two as part of the implementation team. In long projects, there may be a change in the project manager between Stage One and Stage Two, or there may be a significant time gap before Stage Two begins. The recommendations made for initializing the various components should be followed for Stage Two, even if most of the same team stays with the project.

Initiating the Politics Component

In any large-scale project, many, many people are involved in the project's success, whether they are identified as team members or not.

One of the greatest mistakes made by inexperienced project managers is not identifying and dealing with the politics component early in a project. Our Mythical Project Manager knows this and takes the following actions:

Identifies the political goals and needs of the Mythical Project overall
Identifies the political goals of key people in the organization
Identifies key people in the organization who must be involved in order for the project to succeed
Identifies the organizational power of those individuals and identifies other people with organizational power who must be involved.

An ongoing effort must be made to stay current with changing politics in the organization over the life of the project. During periodic reviews of the project, a look at the political situation is strongly advised. Ignoring the political realities or assuming they will take care of themselves is a common mistake of inexperienced project managers.

Note: Describing exactly how manage the politics in an organization is too much for this article. Specific techniques are covered in our training programs or our corporate consulting practice.

Initiating the People Component

In the beginning, the Mythical Project Manager will have a few key staff members who will likely stay with the project for its entire duration. Once the larger group of involved people is identified, the Project Manager looks at how each person should be involved.

After identifying the politics of the Mythical Project, our Mythical Project Manager's next steps are to designate the roles and responsibilities of various people she wants on her project. She takes the following actions:

Identifies key personality traits, skills and experience of the people identified in the politics component
Identifies all the roles that must exist on her project team
Initially assigns people to roles
Identifies any roles that do not have people assigned and looks for potential people in the organization to fill those roles considering organizational politics.

At this point, she realizes she needs some outside consultants to supplement her team and identifies the roles and responsibilities they must fulfill.

If using outside consultants, we recommend a ratio of at least 3:1 of internal vs. external team members. That means, for every outside consultant you should have at least 3 internal staff involved. Projects with a heavy imbalance of outside consultants put you at risk during or following implementation.

Too few internal staff involved indicates a lack of commitment on the part of the company that will show up when people resist making the changes needed to make the system work. Too many external consultants means the knowledge associated with the project will leave when the consulting team leaves and your staff must make it work. Both situations will eventually be blamed on the project manager's lack of experience.

Our Mythical Project Manager designates her role and people alignment in a draft of the project organization chart and asks the each person if they are willing to be involved in the capacity identified.

Next, she starts a search for appropriate consultants to fill the roles that have no inside staff assigned.

Initiating the Process Component

The overall project goals will help identify the processes that must be changed in the company when the new system is implemented.

Let's assume the processes to be changed in our Mythical System include the way customers order products, the way products are delivered to customers, the way customers pay for products, the way changes are made to a customer's account and the way financial information is transferred from the new system to the company's main financial system.

Initially, these processes are listed in the high-level only. Later, more detailed processes will be identified for change.

Initiating the Property Component

Property associated with the project consists of the company's resources assigned to the project, which include the budget allocated, the physical facilities allocated (office space, equipment, etc.), the new computers that will be needed for the new system and the schedule (or timeline) for the project's implementation.

The initialization of the four components (Politics, People, Process and Property) can occur almost simultaneously. Each of these components will be managed, reviewed and revised over the course of the project.

Moving Forward on the Project

Our Mythical Project Manager has now laid the groundwork for the project. Her team has identified the political realities, identified the project team, identified overall processes to be changed and identified the property they must manage.

Managing the People Component

Maintaining active participation of the people on the team will take diligent effort for the life of the project. This is a fact of project management that is often ignored or misjudged by inexperienced project managers.

Initially, the project manager must get people involved and find a reason for them to make a commitment to the project. Most corporate employees already have more than their fair share of work to do, so adding another project to their already overloaded schedule must be done delicately yet purposefully.

People must feel a commitment in order to gain their energetic involvement; commitment cannot be mandated or dumped on them.

A major challenge in any project is to identify the right people, identify reasons to get them involved, identify reasons for them to want to be committed, nurture their involvement and keep them well informed at all stages of the project. If these aspects are forgotten along the way, people will find many other things to occupy their time and attention.

Over the life of a long project, people may change. They may get promoted, move to a different department or leave the company. New people must be brought in to replace them.

People want to be involved in a new project for their own personal reasons: it looks good on their resume, they feel it is a sign of prestige, they think they are an expert in their department or they want to do something new. None of these are valid reasons for assigning someone to your project.

Reasons that are valid for assigning someone to your project are that they have expertise or experience you need on the project, they have political power you need on your project, they have skills you need on your project, they have personality traits you need on your project or they are a key person in a department you need represented on your project.

Early in the project, our Mythical Project Manager schedules a project orientation meeting where everyone involved is one room. She gives an overview of the project and introduces the small team of people who have been involved in setting up the project initially. She gives everyone a draft of the organization chart for the project showing everyone's role and the timeline. She discusses her management philosophy and style for the project, the role of any standing committees, her expectations of time involvement for each person, how she plans to communicate during the project and where she needs specific help in moving forward.

Then, the forum is opened for questions and discussion. During the discussion, people may express concerns or reservations about their ability to participate or concerns about their willingness to change as needed. They may ask questions that cannot be answered at that time.

Following the meeting, unanswered questions must be answered as soon as possible. The dynamics of the team must be reviewed to make sure everyone is in the right role on the team.

A regular communication vehicle must be established. Some suggested methods include:

Regular meetings of steering committees, advisory committees and functional task groups
Individual meetings with key team members
Regular conference calls with field offices
E-mail distribution of information, meeting schedules and follow-up
An internal website for the project
A Frequently Asked Questions document or website
Formatted newsletters (printed or electronic)
A project telephone number hot line
Daily conferences calls with the implementation support team during parallel testing, implementation and post-implementation
A common method of reporting system bugs, errors or inconsistencies as they arise.

In successful large projects, all of these methods are used.

Fairly early in the implementation stage of the Mythical Project, anyone who may need extra help is identified. Extra help consists of people who have never used a mouse or a Windows-based computer, those who are in remote offices, anyone with language difficulty or a disability, and those who have been in the same job for a very long time and may be reluctant to change.

Also identified are people whose job will be greatly impacted by the new Mythical System. A plan for dealing with all of these conditions is prepared early in the project and attention paid to each of these situations as the project moves forward.

Failure to deal with these aspects of the people component is a common reason that large projects do not meet their goals.

Training is often short-changed in large projects or left until it is too late. Our Mythical Project Manager's training team knows this and sets up training schedules for the SMEs, people needing extra help, pre-implementation training and post implementation training in addition to standard training needed for the system itself. Additional training sessions are scheduled to deal with specifically with process issues.

Managing the Politics Component

Regular meetings of the Executive Steering Committee helps our Mythical Project Manager stay abreast of corporate politics that affect the project. Each member of the committee has a vested interest in helping the project succeed. Occasionally, they become so focused on other priorities, they may forget their commitment.

The Executive Sponsor also helps manage the politics. Our Mythical Project Manager must remain alert to any organizational changes that may affect the delicate dynamics of her project and deals with them as soon as possible.

As soon as feasible, key departmental representatives on the project team should be actively involved. We like to call these people Subject Matter Experts (or SMEs) to acknowledge the expertise they bring to the team. The SMEs will have the new desktop computers installed with early copies of the new Mythical System to learn about and become familiar with. If changes are being made to the software, SMEs will get the first releases after they are tested and should be actively involved in end-user testing of any changes long before actual implementation. SME testing is in addition to the technical-level testing done by the programming team, the quality assurance team, the business analysts and the training team.

Subject Matter Experts provide invaluable assistance in helping identify potential process issues since they know how their department works. Their active involvement on the project provides enthusiasm for the new system, local leadership and communication to others in their department who will eventually be asked to use the new Mythical System. SMEs direct questions and concerns back to our Mythical Project Manager as well as help adjust project schedules, training schedules and process changes as needed.

The project's SMEs become the project's ambassadors, local representatives and "eyes and ears" in the field. Choosing the right people to serve as SMEs is a critical component of our Mythical Project Manager's job. If selected well, the SMEs will be a critical part of the project success at implementation. If chosen poorly (or not chosen at all), they will help the project fail.

Managing the Process Component

Managing the process component involves looking at all processes that may change with the new system. This includes looking at the job descriptions of the people who currently do the process that will change.

When Business Analysts show up in a user department, people may be afraid of losing their job. Business Analysts must be sensitive to the political dynamics and people dynamics to avoid creating organizational problems. They must be honest about what they are doing and why. They must already have the full support of the department's management, which is represented on the Executive Steering Committee.

By also working closely with the SMEs in the department, individual fears about the new system should be manageable. Special attention must be paid to people who may need extra help. Following the analysts' findings, suggestions for new processes should go back to the SME and their department head for their review, confirmation and approval.

An iterative process of working with management and staff to come to the best new processes helps people overcome their initial fears of the coming changes. Good Business Analysts involve people by asking for their ideas and using their suggestions in developing new processes.

Changing business processes is a long-term effort that cannot be done in a few weeks. In our experience, it takes at least 6 months to accomplish - with small changes made along the way with the active involvement of the people who will be directly affected by any change. Proposed changes may be revised many times before everyone is satisfied with the results.

Therefore, effort toward changing the processes should begin as early as practical in the project.

Managing the Property Component

Good use of company resources is a balancing act for our Mythical Project Manager. She must manage the budgets against all known costs, as well as manage against unforeseen costs that almost always occur. As people become more knowledgeable about the new Mythical System, they may want to change the original specifications. Delays may occur that raise the overall project cost and extend the implementation date.

Over a long project, vendors may raise prices or go out of business, new vendors may be added, equipment may become obsolete, new models may become available, office space may be scarce or more space than planned may be needed.

In large projects, the technical teams must stay abreast of the latest developments to make sure any new computer equipment is the most appropriate and keep the project manager informed of any changes needed.

The Executive Sponsor and Executive Steering Committee should approve any significant changes in the project plan.

Implementing the New System

Skip forward in time.

If our Mythical Project Manager has done her job well, the day will come when it's time to switch over to the new Mythical System.

At that time, good management of the Political component pays off because everyone is committed to the success of the new system and stands ready to help if there are any unexpected events.

Good management of the People component pays off because people have been trained properly and have had enough hands-on experience to know how to operate the new system. The SMEs have been the local champions in their offices, division or departments and are available to answer local questions.

On the day of the switchover, there is a team of people at the main office ready to address anything unexpected and to make sure everything goes smoothly for the first few weeks. If there are remote or regional offices, members of the training or implementation team should have been onsite for 30 days for final training using parallel or prototype systems. Normally, this implementation team stays on alert for at least 30 days following a switchover.

Good management of the Process component pays off because new processes have been instituted, new forms have been ordered and are ready, jobs have been changed as needed and people know what they are supposed to do.

Good management of the Property component pays off because the appropriate equipment is in place and well-tested. Everyone who needs a new computer has one and the budget has been spent in the right places or appropriate budget changes have been made.

Celebration

Once all the inevitable early kinks are worked out, it's time to schedule a project celebration - usually at least 30 days following the switchover.

Our Mythical Project Manager has reserved some of the budget for an appropriate party. The Executive Sponsor and Executive Steering Committee also contribute to the party budget and planning. The project party may be simple or elaborate depending on the company's culture. It is important to celebrate the hard work that goes into a large project and to recognize the efforts of everyone involved. Most project parties will distribute mementos of the project and award certificates for each person's particular contribution.

Review of Lessons Learned

A review session should be conducted as soon as practical following implementation. Project changes or failures should be discussed to see what might have been done differently. Project successes should be discussed as well, with the reasons why they were successful. This helps clarify what happened and why so that people's knowledge is reinforced.

Any changes for future projects should be noted. An overall document with Lessons Learned should be circulated to appropriate people for any follow-up action that may be needed. It also provides a reference document for people involved in future projects.

Project review sessions are often forgotten or ignored by inexperienced project managers.

If you have comments about this month's topic, please let us know or take our newsletter survey.

Resources

Internet Resources

Project Management Institute http://www.pmi.org/
Project Manager Training, Tools, Techniques & Textbooks http://www.4pm.com/
Project Management Forum http://www.pmforum.org
Project Management Glossary http://www.pmforum.org/library/glossary/index.htm#Index_Section
Business Process Reengineering & Innovation http://www.brint.com/BPR.htm
Management Resources http://www.meetingtomorrow.com/cms-category/management-resources
Strategy Zone (lots of links here) http://www.projectzone.com/strategy.html

Books - Disclosure: We get a small commission for purchases made via links to Amazon.

The Change Monster: The Human Forces that Fuel or Foil Corporate Transformation & Change. Jeanie Daniel Duck, 2001. Crown Business, New York, NY. ISBN 0-609-60771-5
The Other 90%: How to Unlock Your Vast Untapped Potential for Leadership & Life. Robert K. Cooper, 2001. Crown Business, New York, NY. ISBN 0-8129-3287-0
The Man Who Mistook His Job for A Life: A Chronic Overachiever Finds the Way Home. Jonathon Lazear, 2001. Crown Business, New York, NY. ISBN 0-609-60846-0

Articles