What are Key Factors in IT Project Management Success

The success of IT project stories may follow the common set of business principles.

There are full of stories of IT project failure and its worrying increase, when the amount of money spent on IT worldwide runs into the trillions of dollars and the average company spend on IT being 4 to 5% of total spend and large corporations spending up to 10 %, it has so significant investment and significant loss when failure occurs, you would think that there would be literally thousands of apps and vendors coming up with software to help with the failure problem. Besides digging through the root causes, more fundamentally, what’re the key success factors in managing IT project nowadays?

Discover success factors, besides digging through failure root cause: Instead of overly focusing on what causes a project to FAIL, why not draw attention to what causes a project to become a runaway success. What are the characteristics of the Project/Program manager, how did the company develop the environment within which the project team could work successfully, how was the conflict between operational duties and project activities/priorities resolved? What do you do with the project team AFTER the project? Listen to the success stories, and  it would be really good to hear what made them successful, as you could use the input to create some of the avoidance strategies.

Clearly define success criteria and have consistent top management support:  Many projects fail due to the lack of clearly defined success criteria. Too many times companies do not take the time to clearly define the overall goal/strategy of an organization. This leads the tactical IT projects to have incorrect targets which leads to the confusion after delivery. Too many times projects are deemed to hit the Statement of works deliverables, however leadership questions what they received for the money spent. Any tactical project should have a direct effect on the strategic goals or they should not be done.  The behavior of top management needs to be consistent throughout the project. In many project failure cases,  they are motivated at the start, but they don't maintain their interest and support throughout the project cycle.

It is planning, not plan, that really matters. A business realist, wrote "In preparing for battle I have always found that plans are useless, but planning is indispensable.” In project management, good plans are necessary, but it is because of all the other factors that continuously change such as stakeholder behavior, requirements, team, etc. , being able to quickly change your plans, based on your change management plan, is extremely important. If you can't react quickly and move your project forward and attempt to get ahead of the project timeline, your chances of failure will increase. Creating a project plan and thinking that it won't ever change is living in cloud cuckoo land, build in the reasonable (such as 10%) contingency to allow for changes or as Peter Drucker once said "Time is the scarcest resource and unless it is managed nothing else can be managed."

Have a long term problem solving mindset and strategy. Many organizations with low project management maturity are fire fighting (knee jerking) by implementing tactical short-term solutions. These activities solve very short term problems and keep the business quiet for a while, but are just creating an even bigger mess to be sorted out in the future as they are not in line with the overall business strategy. Secondly, "if you don't know where you are how can you plan a route to get to your desired location?" The position of business supporting information covering people, processes and technology. Silos of isolated data inhibit the organisations ability to make decisions based on "the best" information available because different systems hold different data about the same item - a customer, etc, so the question is "which system holds the truth." The longer this situation proliferates the greater the task to fix it.

Have a well-defined and agreed Cost Benefit Analysis (CBA). Who failed, IT or the customer, is irrelevant. But aligning IT and their customers is crucial to ensure that there is a stronger understanding of the business by IT so that they can accurately develop stakeholder maps and engage with each to raise awareness of the project and seek their input to requirements. Projects that struggle typically do not have a defined, documented and agreed cost benefit analysis (CBA). Let's face it, most projects will have some level of challenge at some point during a project. A well documented and AGREED cost benefit is a great tool in determining how to navigate those issues. Is getting the project done timely more important than an additional piece of scope? How much incremental value is added with the additional scope? Does it outweigh the delay in delivery and the delay in benefit realization? Having the CBA in place helps with all of these questions. You won't be able to avoid all the trouble, but the CBA can help quickly get you back on path.

Be people centric. There has to be an ease of use, a clear advantage to doing the project versus the old way, and results that justify the change. One cause of project failures is that the projects do not meet customer expectation, they tried to implement an IT Project that failed to show a ROI because at the end users never effectively adapted to it. The project focus is on new tools/software vs. what can the organization do to fix the business issue with the current people, process and technology. A tool is made to support the business process and people, so without understanding the current environment an organization will be looking for a new tool every few years. A true program is built with all of these aspects and without each being reviewed failure is what should be planned on.

Every IT project failure perhaps has different reasons, but all success stories may follow the common principles, such as being long term-focused, people-centric, analytics-driven and process-robusted, learning from others failure and developing your own set of best practices and next practice.

Posted in: Project Management