Why do projects fail? Why are business sponsors so often dissatisfied, even when projects complete on time and within budget? 

The reasons for project failure are numerous. They include misalignment with expected business benefits, misunderstanding of business problem, poor problem definition, poor stakeholder management, scope creeps, changing requirements, unavailability of critical resources, weak infrastructure or architecture, missing or delayed regulation (in regulated environments), poor project management, poor project planning and/or execution, bad choice of methodologies, etc. 

A close look at these reasons reveals that very often failing projects were doomed from the start and had little chance of succeeding. Important pre-requisites were not met, bad choices (of personnel and tools) were made and goals were poorly defined. 

The genesis of these projects often goes like this: A business need (vaguely defined) is brought to the attention of or assigned to a business executive who then turns to a member of his staff and asks him/her to “take it from here and run with it”. This staff member then prepares a business case and submits it for approval by the business planning committee. Upon approval, a project manager is assigned and the project gets underway.. 

This way of getting projects off the ground is fraught with danger and is a recipe for disaster. These projects often go on to spend a vast amount of time and resources just to get bogged down and mired in intractable problems ranging from communication breakdowns with major stakeholders to major project delays and cost overruns to the missing of business objectives. Much worse is the fact that over time, as failure breeds failure, these projects create a poisoned atmosphere within the company, an atmosphere of resentment and mistrust among business units, with external stakeholders, and between business and technical staff, not to mention a loss of credibility and competitive standing for the entire organization. Cross-functional initiatives become nearly impossible to undertake, customer satisfaction dwindles, Quality (of products and services) deteriorates, corporate objectives are regularly missed since very little gets done. This translates into a constant and major erosion of business value for the company. That is why setting projects up for success and preventing them from failing is of utmost importance.

The purpose of a pre-assessment step before a project launch is to take a close look at the project and thoroughly assess whether all the pre-requisites and conditions for success are met. It is an overall risk assessment of the project. Its aim is to set the project up for success and to ultimately meet its business objectives. Its outcome is a “Go” or a “No Go” decision, along with a set of recommendations. If the pre-assessment concludes that the conditions for success are not met at this time, then the project is delayed until such time that they are. It may however recommend a set of corrective actions to remove roadblocks and restore conditions for success before a re-submittal for pre-assessment at a later date. 

This step complements and does not replace the project selection done by the business planning committee, as shown in the graphical representation below. It is an extra step that is more hands-on, detail oriented, targeted and execution focused. 

To evaluate chances for success, the pre-assessment will use a number of tools (Min/Max Analysis, Cost/Benefits Analysis, Ishikawa/fishbone diagram, etc.), and ask a number of probing questions in a number of areas,  such as: 

1-     Alignment with business objectives 

       a.      Who is the business owner and sponsor of this project? Is he involved and firmly backing this project? 

       b.      Have the business benefits expected from this project been stated clearly and unambiguously? 

       c.      Are these benefits specific, measurable, realistic and achievable in the current business environment? 

       d.      Do these benefits align well with the overall corporate objectives and priorities?            

       e.      Are these benefits substantial and significant enough to warrant the investment in time and resources that this project will require? 

       f.       How will these benefits be measured and over which time frame after project completion? 

       g.      Who will be measuring and evaluating these benefits? 

       h.      What will SUCCESS for this project look like? What will be its impact on the organization? Will major business processes be affected and in which ways? 

2-     Stakeholder Management and Coordination with other business units 

       a.      Who are the major stakeholders (internal and external) in this project? 

       b.      Are they aware of this project and its overall time line? 

       c.      Have these stakeholders been contacted and have they committed to participating in this project in this time frame? 

       d.      What (at a high level) will be their level of participation and what will be expected from them?                                                    

                i.     To provide requirements?                                                    

                ii.     To contribute resources?                                                  

                iii.     To test and validate the final product or service?                                                       

                iv.     To supply a number of components?                                                    

                v.     To support and maintain infrastructure?                                                   

                vi.     To provide legal advice?                                                 

                vii.     To facilitate communication with customers? 

       e.      Who in each stakeholder group will be the primary point of contact and/or major escalation point? 

       f.       What are each stakeholder group’s expectations for this project? 

3-     Resource Availability 

       a.      What are the key resources (human and material) needed by this project? 

       b.      Are these resources available or will they be available when required? 

       c.      How realistic is it that missing resources will be found or acquired in time for this project? 

4-     Infrastructure and Architecture 

       a.      Does this project require any specific architecture to be defined or infrastructure to be made available? 

       b.      Are these architectural elements or infrastructure components available now? If not when will they be? 

       c.    . Is the project introducing new architectural and technological choices into the company’s environment? If Yes, are these choices compliant with current architectural guidelines and technological standards? Are they guaranteed to fit into the current environment? If No, what will be done to bridge the gap and ensure smooth communication with legacy systems and business processes and procedures? 

5-     Methodologies 

       a.      Is the project management methodology contemplated for this project the best suited for this business problem and context? 

        

6-     Project core personnel 

       a.      Have the core members of the project leadership (not just the project manager) been identified and are they available? 

       b.      If not when are these core members to be available? 

       c.      Are the project manager and his/her core leadership team qualified for and experienced with projects of this type, magnitude and complexity? 

       d.      Do they fully understand the business problem at hand, and its impact on the rest of the organization? 

7-     Regulation (in regulated environments) 

       a.      Does this project require any new regulation to be introduced or existing regulation to be amended? 

       b.      Has this been done already? If not when will it be? 

       c.      Can the project start before these regulatory changes are in place? If Yes, at what risk to the project and at what cost to the company? Can we afford this? 

These questions are understandably only an example of questions to ask during a project’s pre-assessment. They are neither exhaustive nor complete land should only serve as a guideline. Each industry is different and so is each organization within a given industry. It therefore stands to reason that more specific questions are added to the list and/or current questions are modified and tailored to your specific business environment. The overall goal however is to be thorough and probe deep enough to unearth and reveal all major issues and roadblocks up front in order to have them addressed or removed before the project gets underway. Your guiding principle in drafting this questionnaire should be to always ask yourself: Is this project set up for success? What is likely to derail and make it fail?  

Now let’s turn our attention to roles and responsibilities. Whose responsibility is it to conduct these project pre-assessments? 

For stand-alone projects, the Project Management Office (PMO) should be the unit conducting this pre-assessment. It brings together the knowledge, mandate for project governance, level of authority, overall understanding of the organizational structure, and independence from the project itself that is required to make a sound and unbiased judgement about the project’s chances for success. 

This task should not be left to the project manager. He/She is too deeply involved in the project and too eager to go on with it to be impartial and unbiased. He/She will tend to overstate the project team’s capabilities, overlook major obstacles, minimize looming problems, and deny or rationalize differences with stakeholders. Nobody is more blind that someone who does not want to see. Furthermore he/she may not have the level of authority and/or the level of influence required to secure commitment from the business units and other stakeholder groups. 

For projects belonging to a program, the Program manager should work with the PMO to conduct the pre-assessment.

In environments where there is no PMO, the business sponsor should step In and handle the coordination and supervisory role that is typically the province of the PMO. He will certainly need help from technical experts (architects, engineers) on technical issues.   

Some organizations may decide to set up separate structures dedicated to conducting these pre-assessments, especially if their projects are large, very strategic in nature and central to their business. One thing to remember however is that for these structures to be successful, they must bring together great business acumen, solid understanding of company's goals and priorities, mastery of project management principles, high level of authority and influence, architectural and technical expertise, great independence from the projects, and intimate  knowledge of the corporate structure and dynamics. Their decisions must be knowledge and evidence-based, unbiased, fair and free from any conflict of interests. In a nutshell, they must be above corporate politics and driven solely by the company's best interests.

Conclusion 

A pre-assessment of projects before they launch goes a long way in improving their chances for success. Like an airline pilot going through his/her checklist of plane, flight and weather conditions before a flight, it seeks to launch projects only when conditions are favourable and success most likely. Furthermore it helps identify and remove major roadblocks from the onset in order to set projects up for success.    

 

Prince2, PMI, Agile/Scrum, Waterfall, DMADV, LEAN, DFSS, DMAIC, etc. The literature is filled with Project Management Methodologies that all claim to be the nirvana of project management, the one and only methodology that will ensure your project’s success, keep your customers happy, and minimize project costs. But are they? Really? 

The truth is that there is no panacea and no "one size fits all" methodology. They all have weaknesses and may not be suited to your specific business context.

In this post, we describe a decision-making logic that will help you choose the right methodology for your business problem, one that is aligned with your business requirements and will give you a leg up in your quest to solve that business problem. This logic is then summarized visually in a chart available at the end of the post.

First let’s start with the business problem. How well is it understood? Has the root cause been determined? Does a known solution or fix exist for this root cause?  

A- KNOWN SOLUTION TO THE PROBLEM’S ROOT CAUSE 

If a known solution exists for the root cause, then a traditional methodology can be used to implement the solution. But which one to choose? This depends on how stable and well defined the solution’s features (i.e. Customers’ requirements) are at this stage: 

A.1-  FEATURES FULLY DEFINED AND STABLE 

A waterfall methodology (preferably PMI) is best suited to the problem. An example of such contexts includes construction projects, and projects with a strong architectural component that has to be fully defined and set from the start.

A.2- FEATURES NOT FULLY DEFINED OR STABLE  

However if the solution features are not fully defined or are likely to change significantly during the project, An Agile/Scrum methodology works better as it is best able to handle changing and evolving requirements. An example of such projects includes product design initiatives (website design, User Interface design, etc.). Architecture is less of a concern here.  

B- SOLUTION TO THE ROOT CAUSE IS NOT FULLY KNOWN 

 If the solution to the root cause is not fully known, then the next step is to find out if the business problem is a process or a product problem. 

B.1- PROCESS PROBLEM 

If it is a process problem, then we need to find out if the process already exists or if we need to create a new one. 

B.1.1- PROCESS ALREADY EXISTS 

The recommended methodology is the LEAN methodology. It is better able to streamline the process, eliminate waste and render it more efficient. 

B.1.2- NEW PROCESS NEEDED 

The recommended methodology is the DMADV methodology. 

B.2- PRODUCT PROBLEM 

If it is a product problem, then we need to find out if the product already exists or if we need to create a new one. 

B.2.1- PRODUCT ALREADY EXISTS 

The recommended methodology is the DMAIC methodology. It is better able to reduce or prevent defects, improve accuracy and product quality. 

B.2.2- NEW PRODUCT NEEDED 

The recommended methodology is the DFSS methodology    

             DECISION LOGIC; PROJECT MANAGEMENT METHODOLOGY