Predictors of Project Failure
- 1. Predictors of Project Failure Imagine this scenario: Global Wide Area Networks (WANs) with hundreds of remote sites composed of both carrier managed private networks and Internet links must be collapsed into one WAN within 10 months. As with many IT projects that have well defined deliverables, reasonable deadlines and the necessary funding, this is a completely achievable task. Many seem to think that all a good Project Manager has to do is follow the organization’s implementation process, report as necessary to the PMO and aggressively track activities and dates. But despite this things do not go well; the execution is clumsy, deadlines are missed and the implementation exceeds budget. There is a lot more to managing projects. In addition to having a reasonably good understanding of what it is that you are delivering, you must manage organizational deficiencies or mitigate the effects of counterproductive behaviors. Following are eight problems to recognize and resolve early before they destroy your ability to successfully deliver: 1. A limited technical understanding of the current and future state or topology: This is where the project should begin, with a good understanding of how things currently work and how they will work in the future. Forget about process, dates or PMO requirements for now (and for the next two items). Hopefully the current state of your network or other IT environment will be clearly documented to allow someone new to the project to readily understand how it operates. If not your team needs to spend time at the white board and capture the results of those discussions. This is paramount in order to draft a credible plan. 2. No clearly defined strategy to achieve the deliverable: After the environment is understood go back to the white board and define what needs to happen from a technical perspective to allow for the least disruption and risk to the overall effort. The strategy will provide the structure or an outline for your plan. 3. An insufficient understanding of any technical impacts from changes: No one wants to explain costly outages to customers or the executives. Making assumptions about the effects of changes to a network or application can be disastrous. When you sense gaps in people’s understanding and a thorough investigation into the effects of a change is dismissed by others - beware. Corroborate what you think you know. Also add any likely significant risks to the plan to show what will happen if they are realized in addition to adding them to a risk register. 4. Collaboration is DIScouraged: This is sure to cause failure and it is likely because personalities and politics have more leverage over how things are done other than the importance of the project. The first three items cannot be accounted for without an open exchange from all involved. A good manager will encourage contributions from all who are technically inclined regardless of personality differences. The goal is to deliver the solution (nothing else!) so leverage the insight and information from those with experience in other implementations. Culling from their knowledge is extremely valuable especially if you lack experience in the effort in which you are involved. Discouraging collaboration or feedback will force team members to simply be spectators. This will prevent the dissemination of critical information before it is too late to act on it. In addition, critical knowledge about your project that is only known by one or two people is a huge risk - what if something happens to them?
- 2. 5. A poorly structured plan: A plan’s structure should be dictated by important steps required for the successful implementation of the strategy. It is a tool to convey issues, risks and of course progress to the organization as the strategy unfolds so make it clear. Even if it is 10,000+ lines, there are ways to organize it so that important aspects are emphasized. Be careful with using “canned” formats. For example, do not use a plan tailored for software deployments if you are implementing infrastructure, or one for developing a new application when the deliverable uses “off the shelf” software to be used in a way that is commonly understood. 6. Not recognizing when project plans are broken: If hours are regularly spent updating hardcoded dates in a plan something is wrong. Or instead of informing people, does your ~10,000 line project overwhelm those who look at it? If the plan does not make the best use of the automated functionality within your project software, or the logic and associations within a project are not discernable, or it is confusing and treated as nothing more than an “artifact” for auditing purposes you do not have a credible plan. 7. Team leaders faking it – they have never been involved with this type of project before: Emphasis is on the “faking it” part. It is OK if you have never previously been involved with an effort as long as you leverage those engineers or others that have the necessary insight to fill the voids in your own understanding. Do not be afraid to ask questions that will reveal what you do not know. Gaps in your understanding will come out one way or another and it is much better to swallow your pride than to have a failed project validate any suspicions about your deficiencies (and cost your customer a lot of money!). 8. Way too cozy with vendors: Building strong relationships is important but do not treat vendors like family or best friends. Uncompetitive pricing or issues with a vendor’s ability to deliver will likely be overlooked. If carrier X provides your MPLS and Internet connectivity BUT knows that carrier Y also provides some of your Internet access, it constantly reminds them that you are sensitive to price and that you have another option if they fail to deliver. In addition, carrier diversity makes good sense from a technical perspective. What if attempts to influence decision makers or correct the issues above fail, or the politics overwhelm the organization’s ability to do what is best for the project, or it is too late and significant delays or cost overruns are unavoidable? There are two additional things to keep in mind, first is to always remain professional. Occasionally people will “lose it” in dysfunctional environments, either quietly as they complain to others or in the form of a tirade during a meeting. As a wise Project Manager once told me “words and actions can be criticized and used against you, but professionalism can’t.” It does not matter how difficult or inane the task or environment is. Suggest your better alternative to the decision makers and if your approach is rejected do not take it personally (and keep a risk register), just focus on the best way to deliver what they want because that is ultimately what you are getting paid for. And second is that you can still look for ways to make progress. Despite the difficult personalities and setbacks, if you can make progress even in small ways despite things not unfolding the way you want or it being difficult to measure progress, it still gets noticed. It will also help to minimize or avoid your association with the failures caused by the areas covered above while you build valuable experience and better prepare yourself for your next engagement. – Paul Gozé