I was just introduced to a company in Durham, NC that has spent more than 900 hundred hours with a software developer trying to get a custom order entry system developed. It’s taken nearly 3 years and they are still unable to launch the tool because of inconsistencies in the way the system handles sales transactions. Their biggest questions: Why did this happen and how do we fix it?
In my experience, there are some common culprits that cause projects to fail:
1. Missing or lousy requirements
A lot of times the customer tries to reduce costs and some of the first places they look to are Business Process Review and Optimizations and Requirements Gathering.
2. Scope Creep
Too often, the vendor’s project manager is not experienced enough to lead the customer through the Change Management process and allows “little requests, just this once” to morph into larger monster which consume time and resources.
3. Lack of End-User Involvement
Typically we see companies delegate mid-level managers to Core Team roles. I completely understand the thinking behind this – these are the people who have proven that they can get things done. However, they are also usually removed enough from the daily transaction of business that they can’t effectively serve as subject-matter-experts. Without the right people in the right roles, bad decisions can easily be made.
4. Ineffective Change Management
As mentioned regarding Scope Creep, allowing changes to occur in the scope can easily derail any project. But Change Control is not the only consideration here. Change Management within the culture of the organization is a huge ship to sail. Our old friend FUD (Fear, Uncertainty, Doubt) shows up and infiltrates the ranks with ease. I have heard the following impressions expressed “This is just another management bright idea that is going to fizzle”, “This is another way of eliminating jobs”, “Another whiz-bang system from the IT guys! Remember when we couldn’t ship for a week when they built the last one?”, “I’m an old dog, I don’t know nothing about these computers”. All of these are statements that I have heard more than once and they can all lead to resistance or infrequently, sabotage.
5. Poor Quality Control
Technologists left to their own devices may or may not have tight, disciplined quality control mechanisms. A misapplication of Agile Development could be seen as a developer releasing small pieces of code that escapes integration testing. Data validation and report validation that is not done in a comprehensive manner with controls will, of course, lead to errors in the system after GoLive.
Recognizing these characteristics early can help prevent your project from derailing, but what if it’s too late? In my next article I will review the steps necessary to assess, take control and rein-in a failing project.
As always, I’d love to hear your thoughts or comments below. Have you had similar experiences? What approaches have you taken to remediate?
