WHY DO PROJECTS FAIL?

WHY DO PROJECTS FAIL?

                “What we learn from lessons learned is that we don’t learn from lessons learned.” This old saying when comes to projects is not far from the truth. In fact, two times or more numbers of projects are failures, and they fail the same few ways over and over again.

                For a person like me who haven’t yet experienced making big projects (those to be considered complex), the word “failure” of a project is something objectionable and appalling. However, in reality, statistics proved that it is common for projects to fail, but it is not common to know the ultimate cause of the failure. No one sets out to fail, but for some reason people just accept that a lot of projects won’t deliver on time, under budget with the expected scope intact. But talking about what causes failure makes people uncomfortable, because nobody wants to give or take that kind of criticism.

                Many believe that the main reason why projects fail is due to methodology used. Some says because of the Project Managers and others because of the unexpected vast changes. During my class on Project Management, our facilitator said that the reason why projects fail because the people behind the project fail to plan. Do you agree? I do not, and so is he. What he truly meant was that people behind the project plan to fail. He used as an example our admission at the university. He pointed out the reasons why we are in the university studying. Since a lot of my classmates (us for I’m one) were not be going to commencement exercise on time (that means failing the project *see my post about what is a project), was a proof that from the start we actually plan to fail, for if we didn’t, we should be doing our assignments and submitting our school projects prior to or on deadline and attending to class on time.

WHAT IS PROJECT FAILURE?
               

                I’ve read many articles about the reasons why projects fail, but only few define what project failure is. Regular Geek  said, defining what a project failure is determining who’s to blame. A few simple guides are whether a project finished by a planned deadline, whether the project finished within a planned budget or whether the number of production defects. Once the definition is set, then the blaming will be so determinable? If the project is late, then the project manager should be blamed. If the project is over budget, then the customer is to blame because they requested too many features. If the number of defects is too high, then the developers are to be blamed. Nice and simple, right? Wrong. There are two problems with this simple blaming pattern. First, there are likely several things that went wrong during a project. So blaming one thing is never the answer. The second problem is the stigma of failure within software engineering. What if your definition of failure, a late project, is met but your customers love the new system? Is that really a failure? Even if the project meets the three simple definitions of failure, late delivery, over budget and poor quality, blaming someone does not help. Projects and companies fail all of the time. If people stopped at their first major failure, half of the entrepreneurs currently working in Silicon Valley would not be working.

On the PMBOK Fourth Edition, there are now 6 variables being checked—scope, schedule, budget, risk, resources and quality. This may be better than the original 3 variables, or also known as the triple constraints (scope, time, money), however it is likely an effort to keep away from failure than to succeed. Can we really define project failure as a set of measurements?

Defining Failure

The list of failed projects is long than the list of successful projects, however defining failure is not easy s it may seem. Upon reading a number of articles regarding this matter, I wondered why even though we already know why projects fail; we know how to prevent their failure –why do they still fail?”They said when project has not delivered what was required in line with expectations, it is considered a failure, therefore, in order to succeed, a project must deliver to the 6 variables mentioned above to define threshold

Here are. So, let’s look at each one:

Scope – For any given project, scope can be used to determine whether a project is complete. However, feature completeness should not be the criteria for success. Functional completeness, which is whether the users can complete their work using the system, is a better measurement and it is also harder to define. Functional completeness is not known until many users go through their typical work flow in the system several times.

Schedule – If a project goes past its deadline, many companies consider that a failure. I do not believe you can measure the schedule miss without looking at other aspects of the project. Also, you need to look at the reason for the deadline. If the deadline is only the time when all of the work was estimated to complete, then it was not really a deadline. If there was a time to market concern or the users have some other schedule constraints and need the system by a particular date, then the schedule does become very important. Missing an estimated end date and missing a constrained scheduled deadline are two very different things.

Budget – Money is an issue for most companies and is one of the few measures that can be a big indicator or cause of failure. The budget for a project is typically a function of the number of resources over the life of the schedule, unless there are capital expenditures like new hardware. For smaller companies, the budget can be of extreme importance because funding is limited, especially when compared to large corporations. In the most extreme cases, the budget can be the reason a project gets shut down, obviously meaning that the project is a failure.

Risk – At this point, I ask that all project managers skip to the next bullet. Risk and the implications of that risk is something that can be managed but should not be evaluated in terms of the success or failure of a project. There are very few cases where risk should matter, and those are projects where the defining feature is to reduce risk in the business itself. Risk is a good measurement to determine the possibility of failure or other bad situations, so from the management perspective it is a good window into the health of a project.

Resources – Staffing of a project is typically not used as a measurement of failure, but it can be a very good indicator of impending doom. For example, if a project was estimated to require 5 software engineers for 6 months, and after 2 months another 5 engineers are added, that is a significant indicator that something is wrong. It may mean that a large amount of scope was added to the project, or that the project or its complexity was severely underestimated. Additional resources will also affect the budget; probably add more risk due to communication difficulties and likely impact the quality of the software delivered.

Quality – As I mentioned before, quality should be a huge determining factor in the success of a project, but it should not be the defining factor. A high defect rate is always a bad thing, and will have long lasting effects on the application. Thankfully, agile processes like test driven development, and basic automated unit testing have helped developers ensure some level of code quality. The only problem with quality is that you can never rid a system of all defects, you can only be rid of known defects. It can also become fairly expensive to ensure the highest levels of quality.

At this point, you are probably asking where the definition of failure is. Technically speaking, failure is very specific to your environment. I have limitedly defined success and you could say that failure is not matching or exceeding the success criteria. The most important thing is defining success and failure in the context of your business. If you know what these definitions are, then you can actually determine whether your project was successful and how you can drive towards success in your projects.

(Reference: http://regulargeek.com/2010/11/08/defining-project-failure/)

COMMON REASONS WHY PROJECTS FAIL

From the discussion on our Project Management class, our facilitator presented us these 10 reasons why projects fail.

-poor estimates

Poor estimate refers to the bad associations of plans. Bad estimates lead to bad cost projections which ultimately equate to poor delivery. The problem being when estimates are needed for efforts to be completed to project costs. Often a project is estimated for resource effort before it is budgeted. Therein lays the problem. The estimator is rarely the individual doing the work and the amount of work may not be fully understood. This is one of the reasons why the estimator must be well knowledgeable and skilled. Estimations involves time (influenced by the scope of the project) and planning. In estimations, one must understand the project outcome. Since it is only estimations, one would not think that it will be perfect; however, accuracy plays an important role.

-scope changes

Defining scope is perhaps the most important part of the upfront process of defining a project. In fact, if you don't know for sure what you’re delivering and what the boundaries of the project are, you have no chance for success. Managing scope is one of the most critical aspects of managing a project. However, if you have not done a good job of defining scope, managing scope will be almost impossible.

The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be.

Defining and planning a project is only the first step in successfully managing a project. After you plan the work, you have to work the plan. You must make sure that the work you agreed to deliver is completed within the timeframe and budget allocated. Part of the work-the-plan process is preparing for the inevitable fact that, once the project starts, the client will probably end up asking for more (or different) work than what was originally agreed to. This is when you must use scope-change management. If you don’t, you will end up trying to complete more work than what was originally agreed to and budgeted for. In other words, you will be heading down the road to trouble.

-work breakdown failures

Projects don't just happen they are planned. The whole project team should develop the plan not just the project manager. This ensures that the teams' experiences are taken into account and that everyone is fully committed and has ownership of the plan.

Running a project without a plan is foolish. Working without knowing where you are going is likely to lead to problems and possible failure. Running a project without a plan is like trying to find your way in a strange city without a map. As the saying has it, "If you fail to plan, you are planning to fail."

In order to identify the individual tasks in a project it is useful to create a Work Breakdown Structure. The WBS is the foundation for the detailed project plan. Get the team together and brainstorm all of the tasks and sub-tasks in the project, in no particular order. Write them down on sticky notes and put them on a whiteboard. Once everyone has thought of as many tasks as they can, arrange the sticky notes into groups under the major areas of activity. Add, modify, remove and shuffle the sticky notes until the WBS is accurate, complete and logical. The purpose of a WBS is to decompose the project into steps and sub-steps.

www.projectsmart.co.uk/planning-a-project-using-a-work-breakdown-structure-and-logic-network.html

-not enough time/ resource allocated

Sometimes managers are not given the opportunity to plan because time pressure from senior management take over and most of the time the project is on it’s way before it has been clearly defined (New Zealand Management, 2003). In such cases, people see planning as a waste of time because they believe that time is better spent doing something rather than planning (Fichter, 2003).

 -incompetent project manager

According to the experienced failures, one of the major major reason of projects failure is due to the incompetence of the project manager. Project mangers have a lot of responsibility to handle just to make their projects successful. One of the responsibilities of project mangers is about communication. Since Project managers get busy, many times they don't make time to manage project communications properly. Also, the project manager may think they are doing a good job communicating, but that may not be the case. Project managers must remember that the project team is made up of individuals. Each person on the team has a preference for the types of communication they like to receive, and each person processes communications differently. Poor Communication leads to poor project team, and this matter considered to be a fault of the project manager. There are a lot of incompetent project managers that are hurting our profession because they either refuse to alter their communication styles or are too arrogant to change.

-ineffective use of PM discipline and processes

Every step of business succession progresses according to project plans. So project management becomes very important part of succession because a small mistake may result in wrapping up the business plans forever.

During one project management study, the working methodologies adopted by project management professionals employed with management consulting firms were analyzed. The conclusion drawn was that most of these project management professionals employed at these management consulting firms used the project management techniques which were perfected with the trial and error methods and deep understanding of the business rules.

Project management is all about calculating the pitfalls and creating outlets to avoid the consequences. All the projects share a common aim – following ideas and activities to shape them into working realities. Even if the project is well planned and carried still the possibility of encountering dangers exists.

Project management progresses by following methodologies

§ Plans

§ Organizing

§ Staffing – employing right people who can do justice to the job

§ Guiding – Guiding people to do follow things

§ Monitoring – Monitoring the flow of project at each step

§ Innovation – Introducing new ideas to add uniqueness to project

§ Completion – Setting deadlines for the completion of project

Any project which lacks to identify its objective can be compared to going on a fishing trip in a dry river. An objective goal will always give direction and lead to the project. The objectives should always be concrete, not something vague as improving customer satisfaction or improving the popularity etc. Such objectives are immeasurable whereas you can set objectives like easing out the process by introducing some value addition etc. Often project management teams proceed to work towards achieving some selected objectives because setting many objectives may hamper the quality of work.

(http://www.selfgrowth.com/articles/Importance_Of_Project_management.html)

 -lack of proper management support

The project manager is the interface between the business and technology sides of the company (The Standish Group, 1999). Without executive support project managers in the organization find difficulty in aligning business with their projects. The executive management also needs to be straightforward if they have reservations about the project. Otherwise, once problems are encountered in the project their support will weaken (Glaser, 2004).

Most projects will change the work life of many users and require that they participate in design and implementation. Without user involvement nobody in the organization feels committed to the project. User involvement requires time and effort, but the staff might be already stretched and unable to find time for a new project on their schedule. That is why executive management support is important to make priority clear to the staff.

-wrong use of technology

Information technology should be an asset to a business and support the business through a clear definition of the role technology will play in the business. This is defined in the business plan.

Implementing a full technology strategy can have benefits that cascade throughout the organization.  Wrong use of technology would somehow lead to the failure of the project.

Conclusions

The past failure need not discourage project managers from future efforts. Past examples of IT project failures gives us the opportunity to point to the relevant lessons that can be derived from recognizing areas where IT projects is more likely to fail.

Project managers can position themselves to reduce the possibility for project failure by considering the following recommendations:

• Make sure to plan before starting the development or implementation.
• Pay attention to tasks in the critical path.
• Set up the necessary processes to calculate and inform the risk.
• Ensure that the IT project has clear objectives.
• Understand project trade-offs when making decisions regarding objectives change.
• Use the duration instead of the time on task to estimate schedule.
• Avoid using linear approximation when estimating time or resources.
• Get the support from the executive management and ask them to be open if they have any reservations about the project.
• Ensure and communicate regular about the progress, even if it seems invisible.
• Require that users participate in design and implementation of your project
• Make sure you have the appropriate planning, communication, and technology skills.

(http://www.projectperfect.com.au/info_it_projects_fail.php)

Other causes of failure could be added ad nauseam, but the existence of additional factors is not the point. The factors of successful project management have been documented for years—they merely need greater attention. But if this article has helped serve as a reality check for your project, it will have served its purpose. If you violate any of the principles noted by the consultants and practitioners in this article, you should not expect to succeed in spite of yourself.