When Projects Are in Trouble -- What Pitfalls Could Occur and What Do We Do If They Occur?

Why does Project management Fail?

By Tim Bryce "It must be remembered that project management is first and foremost a philosophy of management, not an elaborate set of tools and techniques. It will only be as effective as the people who use it." - Bryce's Law

There is some specific Reason of which project management fail. They are given below:

Lack of knowledge - employees simply lacks the basic knowledge of the mechanics of project management. I do not run into too many companies anymore with a total absence of knowledge in this regard. The conceptual foundation of project management has been around for a number of years. There is a multitude of training programs in project management, both at the college and commercial level. There are also several discussion groups on the Internet and professional associations dealing with this subject (e.g., the project management Institute of Newtown Square, PA). Hiring or contracting people with absolutely no knowledge of basic project management concepts is becoming a rarity. Lack of organizational policy - the company has not adopted a formal policy for managing projects. Consequently, informal and inconsistent approaches to project management are used with mixed results. This is a much more common occurrence than finding a company devoid of knowledge in project management.

Lack of enforcement of policy and procedures - even though a policy has been established, it is not enforced. As a result, inconsistent results emerge. If a standard and consistent approach to project management is devised by a company, it must be routinely policed in order to assure accuracy and uniform results. It is one thing to enact legislation, quite another to enforce it. Lack of consideration for the magnitude and complexities of project management and attack it in piece meal - People seem to naturally underestimate the magnitude of project management. For example, project planning involves defining work breakdown structures and dependencies which is a precursor to estimating, planning, reporting and control; estimating is a prerequisite to scheduling; time reporting impacts project estimates and schedules; resource allocation is based on availability of qualified people (skills inventory) and current project schedules; etc. There is an overwhelming number of software packages on the market attacking various aspects of project management, but very few addressing it is an integrated whole.

Tips for Coping with Troubled Projects Uncover Hidden Assumptions Hidden assumptions are common and dangerous during project planning and execution. Yes, assumptions are usually identified at the beginning of the project. But what about the assumptions made on a daily basis? - Identifying assumptions by mastering perception and listening skills and having regular conversations with team members in addition to status updates. Lets take, for example, Laura. Laura is a team member who complains about a missed deadline. Laura blames Mark, another team member, for causing the delay. Laura assumes that once a request is sent by e-mail, that request will be acknowledged and completed on time. Because of this assumption, Laura never followed up with Mark on the tasks progress.

There was no communication until the deadline date, which was too late. Unfortunately Mark never noticed the request. To Lauras dismay, the delay resulted in cost overruns. If you are perceptive, the issue can be prevented. To achieve such perception, listen for assumptions during regular conversations with team members. Early detection in this case could have allowed improvements to the internal team communication process.
Accept Accountability

Its easier to transfer blame than to accept ownership. However, when you take responsibility for issues or problems in your projects, it could turn into a learning opportunity that will ultimately benefit you. Accountability reinforces personal ownership of your contribution to a problem. Once you take ownership, the natural next step is avoidance, as no one wants to repeat the same mistake. Think about the last time your project status changed from green to yellow to red. What process could have been managed differently? What roadblock or risk was badly managed or ignored? You should address these types of questions. There can be an infinite number of reasons for a project to change status. For each reason, project management played at least a small role; it could have been communication, risk management, vendor or stakeholder management. The slightest breakdown in any of these areas will cause a negative ripple throughout the project. Accepting accountability for that ripple demonstrates professional maturity and leadership. Striving to never repeat that ripple leads to personal growth and more successful projects.

Adjust Your Attitude Because the project manager owns the responsibility for the projects success or failure, your role is judged the most harshly when things go wrong. So when problems arise and your reputation is in jeopardy, a defensive attitude is common. Unfortunately, this type of reaction can create obstacles. When you have a counterproductive attitude, it can hinder problem resolution. Defensiveness can block your ability to understand what went wrong. Refusing to

accept feedback is a good example. Humans cannot learn without feedback. Disconnecting the mechanism to learn suffocates the ability to make improvements. There are several opportunities during a project when you can collect feedback. Gate reviews, one-on-ones with team members and sponsors, and lessons learned are good examples. Be receptive to making changes that will help create a positive and productive project environment. Remember: as the leader, how you are perceived weighs heavily on your next project assignment or next promotion.

3.Kitchen-sink syndrome (project creep) Scope Creep (also called requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a projects scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence to be avoided. Scope Creep can also be thought of as a process of trial and error for clients to discover what they really want Symptoms Projects that have been going on for a long time Clients who are picky and tend to change their minds often Scattered content and pieces for the website Scope Creep Example 4. Pragmatic project management requires focus to avoid creep:To paraphrase the Beach Boys, be true to your co-workers and clients, just like you would to your process control system and plant. Most engineers, technicians and operators lavish attention on their process monitoring and control systems. However, the actual people that install and operate

these facilities often are neglected or ignored by their supervisors, contractors and each other. To combat some of these persistent problems and bad habits, four speakers presented the Industry Forum on Engineering (for OEMs, engineering contractors and integrators) this week at the 2009 Emerson Global Users Exchange in Orlando, Fla. The main advice given by the forums presenters was that specific and complete requirements and specifications, followed by equally formal and thorough change procedures are the keys to good project management and successful projects. They also presented a variety of advice and procedures from the Project Management Institute's A Guide Project Management Book of Knowledge (PMBOK) and other sources. "A project can be doomed from the beginning if it doesn't have a good scope and isn't planned adequately," said the first speaker, Jim Carlins, PE, PMP, president of Carlins Technology International LLC. He presented "PMI Scope and Risk Management Methodologies." Carlins explained that PMBOK stresses five process groups and nine knowledge areas, and then cross-references them to create a map that engineers, contractors and managers can use to accomplish better project management. The five process groups are initiating, planning, executing, monitoring and controlling, and closing. The nine knowledge areas are project integration and eight types of management scope, time, cost, quality, human resource, communications, risk and procurement. Users need to make sure they address each of the knowledge areas. The second speaker, Manuel Garcia, PE, associate director of the Construction Industry Institute, reported that CCI studied its owners, contactors, suppliers and academic members, and found that people in organizations resist new practices. "People are reluctant to buy in and go into wait-and-see mode or are just neutral to new practices," said Garcia. "The project or change's champions are enthusiastic, but they often lack a clear vision for implementation, and they haven't prepared for the implementation tasks. The greatest barrier is that they don't secure staff acceptance of the change, and they also don't know how to expand their new practice beyond a first implementation to the rest of the organization." Carlins explained that successful projects begin with scope management, which includes:

 Scope planning to describes how scope is defined, verified and controlled, and how a work breakdown structure (WBS) is created; Scope definition, which defines items that are "in scope" and items that are NOT "in scope;" Creation of a WBS that divides major project deliverables and tasks into smaller, more manageable components; and Scope verification for formal acceptance process for completed deliverables;

Scope change control, which establishes a controlled process for changing project scope. Likewise, Garcia added that advocates of new practices must consider what impact their change will have on existing processes, corporate structure and culture and on their business model. They also must audit and update their findings. "Introducing change is like climbing a staircase," explained Garcia. "You must start with a needs analysis, prepare to introduce the change and then initiate it and go after low-hanging fruit to get a win that will prove the value of the idea and grow it. Next, you have do benchmarking to establish the change and get it to be used throughout the organization." To prepare to initiate a new change, Garcia added that its supporters must ask themselves if they have: Formulated a vision for the new process? Provided support from management and staff affected by the new process? Developed a roadmap for implementing the new process? Developed a first communication plan for the new process? Established the necessity for adopting the new practice? Appointed initial champions for the new process?

Empowered appropriate individuals to successfully start implementation of the new practice? Provided for education of relevant personnel in the new practice? "Scope changes will occur, so you need to be prepared and plan for them as much as possible," said Carlins. "Changes can be submitted from any source, but they need to be reviewed within the project scope. The reviewers need to ask: Is this change required for project success? What is its impact on the project's goals or

product functionality? What is its impact on the project's budget and schedule, and does the project have a sufficient contingency allocation? Once these questions are answered, accepted changes need stakeholder sign-off and project manager review and, preferably, approval. Carlins added that another essential element of project management is risk management, which consists of planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning and risk monitoring and control. Risk management planning includes: Next, a risk assessment (RA) table is developed that includes risk description, potential of occurrence and numerical probability rating; risk quantification, impact potential and numerical probability rating; and risk responses, an action plan and whether to accept and how to avoid, transfer or mitigate those risks. These probability ratings can then be used to create a probability and impact matrix. Similar to the other project management procedures, the risk review process includes: Identifying potential project problems, comparing project status with the project plan and activating recovery plans before project harm occurs; Performing a risk evaluation to check a risk's impact on a project's next major milestone and its impact on the final project's product or service delivery date; Completing risk response planning to scrutinize contributing factors, establish a recovery plan and develop a contingency plan and define what activates the recovery plan. 5. Prevent project cost overruns with these four essential processes:1. Establish the scope and features before beginning work Scope creep, according to consultant and author Richard Veryard, is known by various names, depending on the project phase. Early on, its called requirements creep, when the project team is defining problems to be tackled. Perhaps most often, its called feature creep, as more solutions, or functions, are added to the specs.

The primary way to fight scope creep seems simple: Firmly establish the requirements and features of the project before getting started. But too often, inhouse customers believe that an IT project can always make room for one more feature. 2. Prepare your technical team to do its best
The early process of project planning encourages stakeholders to take ownership as they sign off on requirements. The next phase involves getting technical staff to sign off on capabilities and responsibilities. Its critical to have a thorough understanding of the systems and tools that will be used to design and develop the project. The technical staff needs to validate the capabilities and weaknesses of the development environment. This step is so crucial, Nelson explained, because it is at this step where the designers and developers testify to and commit to their own capabilities to deliver. You should also take into account not only the staffs capabilities, but personalities, desires, and styles during this phase. With those factors in hand, you can then assign teams, determine schedules, and even provide working environments that provide the best potential for success. For example, if some people work best between noon and midnight, try to provide the flexibility to work those hours for optimal productivity. The speed, quality, and value of your project is not a factor of the technology nearly as much as its a factor of the technologists.

3. Thoroughly investigate a vendor's capabilities While Nelsons advice can help tech leaders properly prepare the project team , few IT efforts are accomplished without help from an outside vendor. If the vendors are providing hardware or software components, its a good idea to proceed cautiously.

4. Stay diligent about keeping the project on the right path Even if initial planning includes business unit involvement, project teams still have to guard against scope creep after the project is underway. Zink believes that scope creep will always be a problem, due to the very nature of IT.

A New Approach of Project Cost Overrun and Contingency Management: Measuring Cost Overrun
A large number of studies and surveys evidenced the fact that cost overrun affects all kinds of projects in all industries, and in all countries either in the public or in the private sector Cost Overrun = Actual Cost Estimated Cost The problem is that several cost estimates are usually produced during the project life cycle, but there is no standard rule to determine which one must be considered for computing the cost overrun In consequence, the results could be significantly different from one survey to another depending on which estimate is considered

Contingency Management The capacity for flexibility in varying responses and attitudes to meet the needs of different situations. Contingency management may be practiced by both individuals and organizations.

The objective of contingency allocation is to prevent a project from experiencing cost overrun Contingency is an amount added to an estimate to allow for additional costs that experience shows will likely be required. This may be derived either through statistical analysis of past project costs, or by applying experience gained on similar projects (AACE 1998) Contingency covers the costs that may result from incomplete design, unforeseen and unpredictable conditions, or uncertainties within the defined project scope (DOE 1994) Contingency usually does not include changes in scope or schedule or unforeseeable major events such as strikes or earthquakes

7. How to Kill a Trouble Project

8. Project

pitfalls from symptoms to solution:-