My person approach to IT management centers around success. Most IT projects fail. Some quite spectacularly, but most in a quieter way. I believe these are the three leading contributors to failure:
Poor Project Plans and Resource Allocation
My personal experience is that most IT departments do not have a good sense for the amount of time they have to spend on IT projects. All of the data I have collected since I have been studying this suggests that only 15% to 25% of total staff time is available to work on new projects. If organizations take on more work than they can complete, everything proceeds at a snail’s pace and nothing ever truly gets done.
The only way to manage resources in a large organization is to have detailed plans for every project and to look at the resource requirements across all of your plans.
Vendor Performance
Just as IT departments over-allocate their resources, so do vendors. Vendor performance issues are usually more related to them not providing services in the time expected (or not having a common expectation with the vendor) than bad software. However, sucky software is still an issue.
Lack of Clear Expectations
If someone’s goal is just to implement some software than, in my opinion, they have failed by default. Each IT implementation should have clear business benefits and those benefits need to remain insight throught the effort.
Am I missing other common contributors to failure?
Candid CIO 
Lack of Business Ownership, Understanding and Engagement
We could probably all agree that we don’t implement systems, develop new technologies, or work on other IT projects and have them be successful without stakeholders from outside of IT having heavy involvement. Even something very technical like adding a SAN to your architecture is done because of the positive impact it will have on an end user. As such, end users or an “end user representatives” should be involved from a User Acceptance Testing standpoint. Yes, they aren’t testing new functionality or a different system, but what is being implemented is critical to their daily lives if it’s increasing application efficiency.
A successful project and for that matter an organization, is driven by people, process and technology and the integration of the three. Proper representation and participation from our business partners is critical to the success of projects. This is includes more formalized process and procedures during the implementation cycle like kick-off meetings, role and expectations definitions and communication plans to ensure we as IT professionals are not “order takers” and instead business leaders. As an IT professional, once you prove that you understand the business and it’s goals, you have the ability to delegate tasks out to business owners and participants and then hold them accountable for executing on those things. It’s been my experience that this is generally a welcome change by executive leadership and has been embraced.
1. Lack of an agreed upon aligned business and technology plan resulting in defined goals for each jointly owned project. How do you know when you have achieved the business goal in mind if you don’t have a start, a few measurement waypoints and ideally an END? Hopefully the END results in success. If success is mutually identified by business, IT and the vendor, then we all know if/when we achieve it and in a perfect world, when to move on to the next set of projects.
2. Lack of defined maintenance schedules. This is a smaller barrier but creeps up and bites you. If you don’t have maintenance schedules defined with your vendor’s software releases based on your organization’s adoption schedule (ex: we wait for the first service pack post major release), with your supporting software packs scheduled (ex: database service packs), hardware lifecycle (ex: we run this server until it reaches x% CPU or memory, gets 5 years old), and for interfaced medical devices – a similar patching calendar as best as it is known. These are the typical starts and stops and sometimes unbudgeted “crises” that eventually wear on our sponsors, ourselves and our project teams.
3. Lack of taking into account the last project’s continual operational requirements which takes away from the 15-25% of the time our business and clinical counterparts have to work with us on the next big thing. Not only are the pure monetary budget implications not always understood, but more often than not, the typical care and feeding of these applications may not be understood. This is especially true with some types of business intelligence applications, clinical applications where content is built and continually modified, collaboration sites where users dump content and many types of supply chain applications.
I was involved once on a project that tried to make the software fit around the requirements and it simply didn’t work. There wasn’t any project planning, and human resources for the project were misaligned. Needless to say, the fallout on human resources was great and the software-it turns out- didn’t meet the needs. I think ownership is imperative, otherwise the project turns into a redheaded stepchild. All points here are pearls, and if planning and expectations are clear then failure or fallout is minimal.
It seems that motivation is necessary part of an IT project. Not necessarily a carrot and stick – More like a reminder of the project, reviewing the goals, and questioning the schedule. What’s the next step? When will that happen?
Everyone in IT provides support to some degree. Putting out fires and responding to company leadership requests is a constant. In my experience, simply asking about a project can put it back on the front burner.
I understand the pain. What things cause IT projects to fail is similar to what things make a person ‘really’ happy; it varies from person to person and what is the perception of happiness.
Or, I would say what makes a project successful – here is my list –
1> Executive management support and leadership
2> Timely user community involvement and input
3> Well defined project goals and requirements
4> Realistic expectations and deadlines
5> Proper planning and right methodology
6> Open and clear communications/directions
7> Motivated team with sense of ownership
8> Watchout for signs of failure – conflict/politics/cover-up
9> Positive attitude – every day and towards everyone
10> Correct estimates (beaware of inflated estimates)
Thanks.
virk
Let me add one you may not think but it has a surprising hand in many delays and failures: “too much caution”. Sometimes people are afraid to make the leap for fear of failure so they come up with every possible problem and incorporate it in the project.
Dear Will Weider,
I am Dhanasekaran, a certified PMP (Project Management Professional) and working as Senior Project Manager in Singapore. I am running a Project Management Forum at http://www.sgpm.wordpress.com foucsing on project management articles and subject matters to assist fellow Project Managers and people who are preparing for PMP Exam.
Your post about the Project Failure is extremely good and I would like to reproduce in my forum. I seek your permission to reproduce this post in my forum.
I will reproduce your post as follows
1. Small introduction about you and link to your blog
2. Reproduction of your post except
3. URL link to your original post.
Appreciate your assistance on your permission.
Regards,
S. Dhanasekaran
I put these thoughts into the public domain. People are free to quote me, mis-quote me and/or disagree with me. Heck, you can even agree with me. Linking to me is always appreciated. I meet new readers that way. Many of whom add great contributions via comments.
Will,
Your comments are spot on. As a consultant focused primarily on Business Intelligence solutions, I have both the accolades and battle scars on my back from project success and failure. I try to analyze what went good and bad during each phase of a project. For projects that failed, it boiled down to client expectation and client participation, the latter being the #1 reason.
Consultants tend to set the bar too high without realizing what is really being asked within a given budget. When the fog starts to clear and they understand what the client wants, they have either ask for more time (aka money) or scale the project back.
Client involvement from the get go is critical. Many times, people relegate a project ot IT, even though it requires hands on and ownership by business units. As a 3rd party with no real power of authority, its hard for a consultant to drive results on a project, this is where a committed project owner is needed.
This is why I have adopted a hybrid version of Agile and Waterfall (PMBOK) project managment. Agile for the short duration of development cycles (Sprints) and the constant communication between team members. Whereas I like the documentation and structure of Waterfall to provide some rigidity. Bringing both of these concepts together has really helped me realize more project successes