These techniques have recovered over millions in potential lost investments and increased profits. The recent economic downturn and global competition have drive the need of companies to successfully implement every single IT project. However, recent statistics have shown that only 1 of 3 IT projects is successful. The proven project management techniques, outlined in this paper, will most likely generate successes out of the projects that have become stalled. These techniques, throughout my career, have prevented over millions in potential lost investment.
Moving from Chaos to Success
- Distinguish Between Symptoms and Root Causes
- Strategize A New Project Approach and Take Corrective Actions
- Re-sell the Project: The Human Factor
- Focus on Strong Project Controls and Measurements
- Poorly defined applications (miscommunication between business and IT) contribute to a 66% project failure rate, costing U.S. businesses at least $30 billion every year (Forrester Research)
- 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
- 50% are rolled back out of production (Gartner)
- 40% of problems are found by end users (Gartner)
- 25% – 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
- Up to 80% of budgets are consumed fixing self-inflicted problems (Dynamic Markets Limited 2007 Study)
Distinguish Between Root Cause and Symptoms
Never . . . Never . . . Never . . . Never Give up!
Winston Churchill
When a project begins to stall, symptoms of problems (ie delays in meeting milestones, overspend of budget, etc) will begin to emerge. Attempts will be made to only fix and focus on these symptoms and quickly move on. However, solving symptoms do not get the project back on track because the root cause(s) still hasn’t been addressed and new symptoms will begin to emerge.
What is the source of these root cause(s)? Root causes originate in the insufficient depth by which the project management methodologies are applied during the phases of a project, a missing or incomplete project management methodology practice, and / or missing key critical success factor(s).
For example, an issue management process is in place. Issues are documented but they are not tracked and given immediate priority. As a result, these issues delay project progress and cause a symptom of a missing milestone.
Another example points to vague requirements. Most people will assume that vague requirements are normally a root cause for a stalled project. Unfortunately, vague requirements are symptoms of an incomplete requirements gathering process. Most project teams do not validate their requirements by developing high level test scripts in the form of use cases. By going through the sequential steps of a requirement, gaps and insufficient details can be determined in the functional requirements.
As a rule of thumb in stalled projects, there is usually more than 1 root cause. Focus on addressing the root causes.
Define Critical Success factors – The first technique is to interview all stakeholders and project team members to collect their understanding of what factors must be present in order for the project to succeed. Factors may include communications/ information sharing in the form of Governance and project team status meetings, senior executive involvement, availability of resources, etc. Then hold a meeting to collectively define the 10 most important critical success factors and determine if they are present in the current stalled project.
Perform gap analysis – The next technique is to review the project management processes, deliverables, schedule, budget, etc. to perform a gap analysis. Determine the gaps and develop a plan to fill these gaps. For example, are key project plans such as a communication plan and stakeholder analysis documented, communicated, and implemented?
Coordinate the deliverables among the project sub-teams – A common understanding of the quality of deliverables among the various project sub-teams is extremely important. For example, the project design team must provide a template that describes the level of details, the exact information and format that the project analysis team should provide them. Another example occurs in data integration projects in which it is best practice for the system owner that is sending data to another system and the system owner of the receiving system to sign off on a formal integration document that outlines the list of data that is being integrated.
Define Success Criteria – Define what success for the project would look like. Define the measurable criteria that the customer will judge as success for the project. Success criteria example could include the number of defects and the level of defects that are allowed before the system is approved to be in a production mode.
Distinguish Between Root Cause and Symptoms
If you do not look at things on a large scale, it will be difficult to master strategy.
- Miyamoto Mursashi
Develop new project strategy – One of the first pieces of project artifacts to review for a stalled project is the project execution strategy document. If it doesn’t exist, then the project did not have the proper amount of time and details of a planning phase.
Get a Quick Win – As quickly as possible, show some tangible results from the project, such as a small piece of working functionality.
Re-energize the project team – IT professionals take great pride in their work and when they are faced with a stalled project, decline in morale and negativity can set in quickly.
The first technique to reverse this situation is positive reinforcement. On a blackboard during a project team meeting, write two columns: “what went well” and “what didn’t” for the project. Have each project team member go to the blackboard and list his or her viewpoint. What may be surprising to the team members will be that the list of “what went well” will far outnumber the list of “what didn’t”. Expect an a-ha moment.
The second technique is a team building exercise to get all matrix project team members and possibly vendor consultants to feel as one united team.
The third technique is another kick-off meeting to re-establish the new project strategy, schedule, budget, and expectations. Roles and responsibilities should be discussed.
The fourth technique is the clearing of obstacles to productivity. Multi-tasking has a negative effect on productivity. According to one research study, a college student was given a complex task to complete, then another complex task was given, and the college student was told to return to the original task. The result was a 40% drop in productivity. For each project team member, reduce the number of projects or daily tasks that are assigned. Also, instill a policy of checking on emails no more than twice daily. As the number of interruptions is reduced during the workday, team members will begin to work in a zone where awareness of time is lost and productivity will increase significantly. High noise level also has a negative effect on productivity. Find ways to get team members into quiet areas.
Reduce Complexity – The effects of complexity in a project can generate significant under-estimation in schedule and cost.
The first technique is a reduction in customization. In medium or large size vendor product implementations, significant customization to the base product can add a layer of unknown complexity. Evaluate and simplify the business processes that are being developed or consider adopting the processes of the base product.
The second technique is the development of a prototype to work out the unknowns on a new technology platform.
Re-baseline the project – A new project schedule and budget should be created with a new baseline. However better estimating techniques should be implemented. One of the most common factors in a stalled project is either poor estimating technique or the approval process.
Here are techniques to improve the estimating process for the re-baseline project. The focus of these techniques is to strategically establish a realistic schedule. As you recall in the statistics in the introduction of this paper, there is a 70% or higher probability that the schedule is too aggressive. The first technique is to increase estimates for report generation. Developers are usually inaccurate in estimates for generating reports, especially in understanding the complexity of creating triggers.
The second technique is the use of critical chain project management methodology. Schedule buffers should be added when major pieces of functionality come together. The third technique is the allowance of time to handle the resolution of defects during various testing phases.
During the original approval process in the planning phase, management might challenge the project team’s estimates for schedule and might reduce the overall budget by 10 to 20%. The problem occurs when the Theory of Optimism is utilized. The theory is that IT developers are most likely to give the most optimistic timeline estimates. Reduce these estimates by 10 to 20% and the project is already set to stall before any work begins. For the re-baseline projects schedule, management should seek to understand the processes by which the project team is completing the tasks. Once those processes are understood, then the project schedule should be challenged as still too aggressive or too conservative.
Take Some Corrective Actions Now and then Wholesale Changes at one time– A stalled project is a very difficult situation, and stakeholders are looking for immediate turn-around results. In these situations, the project manager should take immediate corrective actions on the most obvious areas. However, to avoid more chaos, time should be allocated to planning the new project strategy. Once the new strategy is understood, then implement all changes or corrective actions at one time.
Re-Sell the Project: The Human Factor
The very essence of leadership is that you have to have a vision. It's got to be a vision you articulate clearly and forcefully on every occasion. You can't blow a weak trumpet.
Theodore Hesburgh, President, Notre Dame University, Time, May 1987
Decline in enthusiasm and support for the project will create a significant risk for a complete shutdown of the project. The project must be marketed again as significant value-add to the corporation. One, all, or none of the following techniques can be applied to re-sell the project and generate a perception of a future win for the organization. People always want to be associated with winners.
The first technique is to engage the stakeholders to generate ownership. More frequent governance meetings should be held with an escalation process and a formal change management process for scope changes. Assign and escalate issues up to senior executives. Lack of senior executive support is a common cause for stalled IT projects.
The second technique is the publication of success. Too often the project manager may always bring problems to the stakeholders, which creates a perception of negativity. Market and sell the small project successes first and then talk about problems or issues.
The third technique is the renewal of support by the business champion. The business champion must demonstrate support and focus on the project successes to the end users. Faith must be restored that the project will meet or exceed their expectations. Lack of user involvement is a common cause for stalled IT projects.
Focus on Strong Project Measurements
You must do the thing you think you cannot do
Eleanor Roosevelt
In my experience, several hundreds of thousands of dollars have been wasted when people assume that outside expensive consultants and/or vendor consultants know the details on how to execute a project. Installed IT projects with participation from either outside consultants or vendor consultants, very strong vendor management processes had been missing. Ask the tough questions and have actual peer reviews of their deliverables.
Seek Open Honest Communications
The single biggest problem in communication is the illusion that it has taken place.
George Bernard Shaw
These techniques generate open, collaborative communications and processes that may have not existed for the project. Stalled projects thrive in an organizational culture where the problems are minimized, accountability is not held, business and IT are not aligned, or everybody is expected to say “yes”.
