I have been blessed to work in the IT industry now for over 12 years and have been part of numerous projects. I have worked with both IT and business people and taken part in many projects. Throughout this journey, I have used both the traditional project approach and Agile approach (read Vanilla scrum). One thing that I have learned is that projects can easily be derailed and can easily fail even when the project team believes that they have done their best.
Often, there are early pointers that are not heeded until it is late and that is why projects easily fail. Frankly though, there are times when the project team has done their best, but then other circumstances beyond their control leads to project failure. As a project manager, Product owner or Scrum master, there are certain things which you can spot, that can help you to take action early enough to avoid such failures. In traditional project management, initiation and planning is always done upfront, which helps to reduce uncertainty but then the project becomes rigid to mid-stream changes. This can both be good and bad for the project depending on the project type, stakeholders, organizational strategy and culture, project duration and so on. Agile on the other hand introduces flexibility to accomodate change and reduce uncertainty. It’s inbuilt monitoring and control integrates risk management which reduces failure rate but then this is not feasible in all kinds of projects. From my experience, the following are the common major reasons for project failures regardless of whether the project is plan-driven or value-driven:
Failure to focus on business value and focusing instead on technical detail. This is quite common where the project team is highly involved in the project management and the project manager/product owner cedes some authority or is under involved. In the worst case scenario, the team could be comprised of inexperienced members, unaware of what is expected of them. In a past project, I have experienced project teams working without understanding their contribution to the business value. As a developer, one easily slides into technical field where one is familiar with the working of the project and easily sidelines the business part. The end result is that there is no well-established and clear link between the project and the organizations key strategic practices. The project plan needs to cover the planned delivery, the business change required and the means of benefits realization.
Lack of properly established clear accountability for measured results. The management (PMO) must support project managers by creating a clear view of the interdependencies between the projects, the benefits, and the criteria against which success will be judged. It is necessary to establish a reasonably stable requirement baseline before any other work goes forward. Requirements may still continue to creep. In virtually all projects there will be some degree of “learning what the requirements really are” while building the project product.
Inconsistent processes for managing unambiguous checkpoints. Projects are often marred with unambigous checkpoints , from procurement to complex decision making. Successful large or medium sized projects usually have software measurement programs for capturing productivity and quality historical data that can be sued to compare it against similar projects in order to judge the validity of schedules, costs, quality, and other project related factors. The lack of effective quality centered mechanisms can be a major contributor to both cost and schedule overruns. project managers should learn how to use their lessons learned register or scrum masters should also used retrospectives and daily scrum meetings to gather information and use the PDSA Deming’s cycle throughout the project to ascertain project progress.
Poor and inconsistent methodology for planning and executing projects. There should be a detailed plan developed before any release date of a project is announced. both plan-driven and value driven should incorporate this in their working processes. It is not unusual to hear extremists insist that agile is not about planning. I differ with this and underline that agile actual has more planning than traditional project managerment. The difference is that they don’t do alot of upfront planning, rather it is “just-in-time” planning and with less documentation. But it has numerous integrated planning processes in a project lifetime. Again, inadequate planning is one of the major reasons why projects spin out of control, whether early or in the latter phases of the project.
Include the customer at the beginning of the project and continually involve the customer as things change so that the required adjustments can be made together. It has been observed that successful projects occur when end users (customers) and the project members work as teams in the same cubicle, although this is not always possible. Projects are less likely to fail if there are informed customers giving meaningful input during every phase of requirements elicitation, product description and implementation. The customer needs to be asking, “how are the project result used over time and what do I get out of the results?
Failure by the project manager or Scum master to manage and motivate people so that project efforts will experience a zone of optimal performance throughout its life. This involves managing and retaining the most highly skilled and productive people. Knowledge is money. A project team made up of higher paid people with the right specialized skills is worth more per dollar than a group of lower cost people who need weeks or months of training before they can start to be productive.
Lack of tools and techniques to produce consistently successful projects. The project team must be skilled and experienced with clear defined roles and responsibilities. If not, there must be access to expertise which can benefit those fulfilling the requisite roles. This reinforces the first point above on the damage that incompetent team members have on a business.
There are definitely other reasons that could underline why projects fail, depending on several other parameters. However, this article has focused on the most common ones that override the project type, organizational size and so on. So what made projects fail in your team, in the past? Please share.
Project Management 