No project manager sets out to fail. But have project/program managers and leads begun to accept failure as the norm?
I'm sure that no project or program lead sets out to fail in managing a project or program. But have project/program managers and leads begun to accept failure as the norm?
Below are eight facts supporting this assumption:
- The percentage of failed projects in the past and the current percentage of projects, small and large, including ERP, are still failing.
- People are writing articles such as "Why Is Project Failure Good." My perspective here is that the author and others seem to be missing education and training on project management and its basic life cycle processes and activities (e.g., initiation, planning, execution to close out, risk identification, management, etc.).
- Many projects are not establishing a Change Management Process in the beginning of the project or program with a review team/board.
- Many projects are not establishing configuration management early and not establishing a configuration control process within the Change Management process.
- There is a lack of up-front risk identification and management.
- Lessons learned are not being documented and used periodically (e.g., for a phase/process, released functionality, or sprint), and not just at the end of a project (post mortem).
- Project managers are not consistently using best practices that have been, or were used, on successful projects and programs.
- There is no transferring and sharing of knowledge as a team.
You want to prevent the frequent occurrence of project failures, not celebrate failure!
Why projects fail
Project Failure in the IT Industry is directly related to five areas:
• Customer/User Satisfaction
Quality and Customer/User Satisfaction are interpreted as meeting or exceeding customer requirements and satisfying the customer's and user's use of the system through two activities:
- Customer and user involvement and participation, starting from the beginning and going throughout the entire project or program. You should survey customers, have discussions, share knowledge and lessons learned, and provide feedback.
- Use of the system in a production environment, after successful functional and user-acceptance testing is completed.
Here are the top 10 reasons most projects and programs become troubled and/or fail:
- The absence of senior management's support and commitment
- The lack of competent and knowledgeable leadership
- Unrealistic or inadequate planning
- The lack of consistent communications and training
- Failure to clean up complex business processes (re-engineering) prior to implementing new systems such as ERP
- The absence of complete, stable, and mutually agreed-to and approved requirements
- The absence of requirements management — business, user, functional (product/system, application, etc.) — and alignment of the project to business needs
- The absence of a good architecture, or high-level design, to determine priorities and functionality releases for a system or product
- Core team not built with the appropriate skill sets, considering availability, retention, backup, and resource planning
- Not addressing risk identification and management up front, early and continuing throughout a project and program. Contingency planning being an afterthought. Projects proceeding forward at go, no-go decision points when significant issues and problems existed or had not being resolved. Serious downgrades to meet unrealistic expectations, marketing schedules, and deadlines
This attitude, accepting failure as the "norm," has to change or the IT industry is doomed.
Do you have high expectations for your projects and programs. Understand the discipline of project and program management to plan and execute successful projects and programs. Understand the basic fundamentals and the discipline and/or process (e.g., project management) and how to apply it. Prepare for the worst but plan for success.
Prepare for the worst
Here are four simple steps on how to prepare for the worst (or, in other words, how to be proactive):
- Perform risk identification and assessment.
- Establish early change and configuration control processes.
- Establish early, and in the beginning, QA verification and validation tests.
- Select and use a program/project management methodology.
Prepare for the best
How to plan for project success:
- Obtain written and documented support and commitment from senior management. (This also ensures that business management, Subject Matter Experts (SMEs), and users will be expected to participate.)
- Perform risk identification and management.
- Plan to use best practices for the Best Practice Processes (BPPs): Project and Program Management, the Development Process, Configuration Management, and Quality Assurance.
- Select an Appropriate Development methodology.
- Build a core team(s) with the appropriate skill sets, considering availability, backup, and retention. Make sure that business management, SMEs, users, and third-party stakeholders (e.g., vendors, subcontractors) are considered members of the team.
- Perform and develop realistic plans, schedules, and estimates.
- Establish early change management and configuration control and include an expedited process for critical and time-sensitive changes.
- Ensure client and users are, and will be, involved in the projects from the beginning and throughout the entire project or program.
- Consistently use during execution: A) best (and good) practices for all areas, not just for BPPs; B) lessons learned (documented throughout the project and program); C) knowledge transfer activities (for teams that consist of business as well as technology members).
You can decrease project failure rate where it starts — with your attitude, belief, and resulting behavior and actions.