Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

CATEGORII DOCUMENTE





BulgaraCeha slovacaCroataEnglezaEstonaFinlandezaFranceza
GermanaItalianaLetonaLituanianaMaghiaraOlandezaPoloneza
SarbaSlovenaSpaniolaSuedezaTurcaUcraineana

AdministrationAnimalsArtBiologyBooksBotanicsBusinessCars
ChemistryComputersComunicationsConstructionEcologyEconomyEducationElectronics
EngineeringEntertainmentFinancialFishingGamesGeographyGrammarHealth
HistoryHuman-resourcesLegislationLiteratureManagementsManualsMarketingMathematic
MedicinesMovieMusicNutritionPersonalitiesPhysicPoliticalPsychology
RecipesSociologySoftwareSportsTechnicalTourismVarious

Project Closure

managements

+ Font mai mare | - Font mai mic







DOCUMENTE SIMILARE

Trimite pe Messenger
Deus Ex Software Development Kit Conversation System
Project Management
Fundamentals of Information Management the Internet, and
STRATEGIC MANAGEMENT PROCESS
Automated Project Management
Performance Assessment: Tracking and Monitoring
Managing Changes to the Project
Information, Communication, Meetings and Presentation Skills
Negotiations - Know what you want
Perspectives inManagement

Project Closure

All projects eventually end. Some end successfully, others end in disasters. Some common reasons why projects end poorly are changing market conditions, lack of cooperation from clients, lack of management support, lack of resources, politics, technical problems, and poor management. Exhibit 18-1 sums up the management reasons for failure, while Exhibit 18-2 lists reasons for success.



Fortunately for Perry, the Smythe Project ended successfully: the wedding proceeded as planned, meeting all milestone dates on time, consuming all monies within the budgeted amount, and giving the Smythe family exactly what they wanted. Unlike other weddings, the team’s morale was extremely high up to the very end.

Despite overwhelming success, not everything worked perfectly. Some communications, coordination, and implementation problems arose, and projects Perry handles in the future will benefit from what he learned.

Exhibit 18-1. Common reasons for project failure.

Leading

Organizing

• Avoiding conflict

• Lacking resources

• Burning out of team members

• Lacking accurate knowledge and expertise

• Delaying decision making

• Having unclear authorities and responsibilities

• Lacking cooperation

• Lacking customer involvement

Controlling

• Lacking senior management support

• Failing to deal with a changing environment

• Communicating poorly

• Failing to manage change

• Setting unrealistic expectations

• Overemphasizing on technology issues at expense of business issues

Defining

• Competing too much for resources

• Having ill-defined, too large, too small a scope

• Having incomplete or unclear requirements

Closure

• Finding errors too late

Planning

• Failing to learn from past problems

• No planning

• Poorly formulating plans

• Having unclear, unrealistic plans

Exhibit 18-2. Common reasons for project success.

Leading

Organizing

• Having the support of senior management

• Assigning responsibility for well-defined deliverables

• Obtaining customer involvement



• Maintaining realistic expectations

• Having a good communication infrastructure in place

• Encouraging and sustaining a sense of owner ship by all participants

• Having clear lines of authorities and responsibilities

• Having commitment and cooperation of all participants

• Having a team with requisite knowledge and expertise

• Promoting integrity

Defining

Controlling

• Chunking the project into manageable pieces

• Having a documented change management in place

• Keep the scope well-defined

• Clear definition of requirements

• Holding regular and frequent meetings

• Focus on customer

• Avoiding scope “creep”

• Clear mission and objectives

• Taking regular measurements of performance

Planning

Closure

• Focusing evenly on technical and business issues

• Releasing people correctly to minimize impacton morale and performance

• Developing meaningful plans

• Having more frequent project milestones

• Having shorter flow time

• Simplifying

Learning From Past Experience

Perry collects and compiles statistics from the project by using the project data repository. Mainly the measurements used during the project, these data help Perry ascertain what did and did not go well. He plans to include the information in a special document.

The lessons-learned document captures the successes, challenges, and other information of a project. Managers of similar projects in the future can refer to what is in the document and, consequently, operate more efficiently and effectively. The lessons-learned document not only communicates useful information to future project managers, but also helps to identify their own strengths and weaknesses. But these advantages can be realized only if the document is well prepared. The outline for a lessons-learned document is shown in Exhibit 18-3. Many times, the document is poorly written, contains unsubstantiated claims and personal grandstanding, and is filed in an inaccessible place. To ensure that these shortcomings do not appear, Perry takes the following actions.

Exhibit 18-3. Outline for a lessons-learned document.

Lessons-Learned Document




I. Present title page, which includes:

A. Document title

B. Document number

C. Original release date

D. Appropriate signatures and date

II. Present table of contents, which includes:

A. Section headings

B. Relevant page numbers

III. Present introduction, which includes:

A. Goals

B. Scope

C. Objectives, like

Technical

Business

D. History/background information

IV. Present events, and what went right; what went wrong, and what was done; and what might have been done otherwise, which include:

A. Activities

B. Critical items

C. Major milestone deliverables

D. Political actions

E. Roadblocks

V. Present summary, which includes a wrap-up of the project

1. He ensures that the data are useful. This task is easy since he has collected reliable, valid measures throughout the project.

2. He identifies other sources of information. Since he collected and organized data throughout the project, this action is easy. He especially uses the information in the project history files.

3. He assigns someone on the noncritical path to do the preliminary work for preparing the document. This includes collecting documents and data, as well as preparing the draft. This approach allows Perry to handle concurrent activities during project closure.

Information Systems Projects: A Lesson for Everyone

Although project failure appears in all industries, information systems (IS) projects seem to get special attention. Their record of successes and failures has been referred to by some as a crapshoot.

It’s no surprise. The news is replete with examples of IS projects having disastrous results. The state of Washington stopped developing a system that would process driver’s licenses and vehicle registration; the project was several years behind schedule and millions of dollars over budget. California had even more disastrous results while developing a large PC-based network—the project was millions of dollars over budget and lasted over twelve years. And as with Washington, California had a Department of Motor Vehicles project that blew its schedule and exceeded its budget. Then there is the Oregon Driver and Motor Vehicle Services project, which has exceeded twice its original cost estimate.

Do not blame the public sector, however. The private sector has had its share of failures. The Xerox IS project, called the Market to Collection Project, passed its scheduled completion date by two years and exceeded its budget.

These examples may be more common than first realized. In the late 1980s, Capers Jones, president of Software Productivity Research, revealed some sobering statistics about projects with more than 64,000 lines of code. He noted that less than 1 percent finished on time, within budget, and met all user requirements. The “average” project was more than a year late and the cost was double the estimate.1 Almost seven years later, the Standish Group announced that IS development projects succeed only slightly more than 1 percent—that is, finishing on time and within budget. If an organization is large, the success rate drops.2


1“Software Productivity and Quality,” System Development, April 1987, pp. 1-6.
2
“Few IS Projects Come in On Time, On Budget,” Computerworld, December 12, 1994.


What are the major contributors to such dismal results? According to the Center for Project management, 73 percent of the companies it surveyed had inadequately defined project plans. Less than 25 percent had well-defined and practical project management processes.3


3“Pesky Projects,” Computerworld, April 11, 1994, p. 118.

4. He solicits input from project participants for ideas and information to include in the document. This ensures a more objective and complete document. He has team members review the draft to preclude any biased content.

5. He submits the document to senior management, whose responsibility is to ensure that it is not forgotten and apply its contents to similar projects in the future.

Releasing People and Equipment

At closure, Perry must release the people who have worked on the project. Releasing people is not simple. If released inefficiently and ineffectively, morale problems can occur. If there’s a feeling of pending disaster, people may depart prematurely and leave tasks unfinished.

Since it is a matrix environment, Perry knows that prematurely releasing people may mean losing them permanently. So he reviews the responsibility matrices and schedule to determine the remaining work. He then releases only those without work, since people sitting idle will in time interfere with the others’ productivity, spread rumors, or add unnecessary labor costs. Perry also ceases use of any unnecessary equipment or facilities.



Recognizing and Rewarding People

No project is complete without recognition for outstanding performance. While conceptually simple, Perry knows in reality its implementation is difficult. He must decide whether to reward individuals or the team or both, what the most meaningful recognitions would be, and what rewards are within his power. These are difficult to determine; still Perry follows some basic principles when giving recognition and rewards.

1. He strives for objectivity. He uses objective criteria for measuring results. It is hard to forget the past or divorce yourself from the personalities of the individuals. The only way to avoid those circumstances is to be as objective as possible.

2. He determines the values and behaviors he wants to reward. He rewards these values and behaviors that best satisfy those of the company.

3. He remembers the expectancy theory. Expectancy theory states that successful performance depends on people’s expectations of rewards, whether extrinsic or intrinsic. In other words, a person’s expenditure of effort depends on his or her expectations of reward. If a person expects a financial reward and receives a nonfinancial one, morale might fall and productivity decline.

4. He appears fair and consistent. If several people gave outstanding performances, he gives them equal recognition and rewards. Even the appearance of being unfair or inconsistent can cheapen a recognition or reward.

5. He is timely. He presents the recognitions and rewards within a reasonable time to gain maximum motivational value. If he gives recognitions or rewards long after completing a milestone, for example, they lose their meaning and impact.

6. He does not rely on monetary rewards. In fact, he avoids them. Money provides only short-term satisfaction and can prove divisive, especially if a person feels shortchanged. He uses a variety of nonfinancial rewards, from plaques to dinners to trips. For many project managers in a matrix environment, such rewards may be all they are entitled to dispense.

Some Guidelines for Future Projects

Throughout the project, Perry kept a balance between the classical and the behavioral aspects of the project. He knew that a detailed work structure or formal change control procedures are simply tools for completing his project. In other words, they are the means to an end, not the end themselves. Using these tools requires good judgment; therefore he was continually asking himself. Did the statement of work give a real portrayal of what had to be done? Was the planning sufficient and could I have anticipated problems better? What procedural changes would I make next time?

These are tough questions and often there are no definitive answers. Project managers must use their judgment, which is based on their knowledge, experience, and expertise. Nevertheless, there are some general guidelines that are useful for making good judgments.

1. The costlier the project, the more important it is that project management disciplines be in place. A large monetary investment indicates a project’s level of importance—for example, a $1 million project is more important than a $10,000 one. It makes sense, therefore, that the monies for the larger project are all accounted for and justifiable. Project management disciplines help ensure that inefficiencies do not occur.

2. The larger the project team, the more important it is that project management be used. Larger project teams present greater challenges for coordination and communication. For example, a fifty-person project is more difficult to coordinate than a five-person one.

3. The greater the complexity of the final product, the more important it is that management disciplines are in place. For example, building a state-of-the-art information system is more complex than building an outdoor shed. The former requires greater coordination of personnel and resources.

4. The longer the project, the more important it is that all procedures and schedules be in place. Along with more time to complete a project is the tendency to overlook the need for good project management. The “we’ll do it later” syndrome takes over and often results in key elements never being implemented or implemented in a mad rush at the last minute. The project managers should identify and implement as many elements as early as possible, before the project gains too much momentum.

5. The more ambiguity there is about a project’s scope, the more discipline needs to be imposed on the project. The project manager must define the goal of the project and develop a path for achieving it. If the project lacks clarity of purpose, then coordination, communication, and other key activities become difficult, even impossible.

6. A lack of precedence requires that more discipline be in place. If a project of a similar nature has never been done, then there’s a greater likelihood that management may be stymied. For example, previous experience leads the way to greater efficiency and effectiveness.

7. The more dynamic the project environment, the more procedures and schedules should be in place. If the environment is constantly in flux, then the project must be adaptable to change yet retain the focus on the goal. Project management tools help achieve focus and adaptability by evaluating the impact of changes as they appear.

The six functions of project management are critical to success; however the degree of application remains a matter of judgment. These guidelines can help the project manager decide what tools and techniques should be applied and to what degree. In the end, however, the project manager makes the decisions regarding management of his or her project.

Questions for Getting Started

1. If collecting and compiling statistics, did you:

Determine all the sources of information?

Decide whether the data are reliable and valid?

Determine what is required to make the data meaningful (if it is not)?

2. If preparing a lessons learned document, did you:

Determine all the sources of information?

Prepare an outline?

Take steps to ensure its objectivity?

Submit it to senior management or other people who might use the information in the future?

3. When releasing people, did you determine the criteria to identify who should remain and who should be redeployed?

4. When releasing equipment, facilities, etc., did you determine the criteria to identify what should remain and what should be redeployed?

5. When recognizing and rewarding people, did you:

Determine whether to reward the entire team or select individuals or both?

Seek to be objective?

Appear fair and consistent?

Determine what recognition and rewards approaches are available to you?

Match the expectancy of recognition and reward with the type sought by the team or individuals?








Politica de confidentialitate

DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 617
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2019 . All rights reserved

Distribuie URL

Adauga cod HTML in site