Project Management optimize

Seven fundamentals of IT project success

There are seven points of project success that touch on conflicting agendas, multiple perspectives, and a range of business-oriented conditions.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

Many folks think large projects usually fail for technical reasons -- software that doesn't work as advertised, bugs, and so on. In reality, that's not the case.

In my experience, the most serious project issues come down to misplaced expectations among participants. Fundamentally, problems in human communication lie at the root of most failures.

These expectation and communication mismatches are difficult to detect systematically, because they aren't quantitative or technical in nature. Failures persist despite fancy project management methodologies, precisely because traditional approaches do not isolate and address hidden problems.

These seven points of project success touch on conflicting agendas, multiple perspectives, and a broad range of business-oriented conditions that drive projects to succeed or fail:

  1. Business case
  2. Stakeholder and user engagement
  3. Executive sponsorship
  4. Third-party relationships
  5. Project management
  6. Change management
  7. Resource availability

The Project Failures analysis

It's tempting to dismiss these points as obvious or to believe your projects have few problems in these areas. However, successful project managers dig deeper than that. For example, how do you really know that sufficient executive sponsorship is present? If you only asked one or two stakeholders, then your opinion may well be incorrect.

To gauge sponsorship accurately, you must gather perceptions across the project. After all, someone reporting directly to the CIO may have quite a different view than one working 1000 miles away who has never even met the sponsor.

Please do not ignore these seven fundamentals, thinking they are too "simple" or do not apply to your work. They really are that important.

In future blog posts, we'll explore practical steps you can take to uncover the hidden causes of failure that may be present on your projects.

30 comments
Said.Hadhrami
Said.Hadhrami

They are a key factors but also, project progress plays a big role in this.

alainforget
alainforget

Best way to fail a project... Not having clear requirements and not having a goal.

mahesh
mahesh

Whether you are running an in-house project or an outsourced one, there is a contract between the 'customer' and the 'service provider' that provides for clear agreement on scope, time, cost - and sometimes, quality. Projects change - and various stakeholders are responsible for causing change. While Change Management focuses on scope changes and related 'technical' changes, the project manager is usually hard-pressed to renegotiate the contract with the project sponsor. A focus on Contract Management separate from Project Managemet and separate from and a derivative of Change Management makes it easier for everyone to pay attention to it, define a process to effect contract changes, allows a separation of role between project management and contract management (very often, it is much more beneficial for the project to have two separate people handle those two crucial responsibilities) and makes for a much more objective analysis of the causes of change, the mechanisms to find additional funding for the change and taking emotion out of the overall process of achieving this.

dofek
dofek

every project stands on 4 legs: management, technology (content), budget/logistics and human factor. of course, the latter is behind everything but usually all human dynamics which are dealt with are in the management level. from my experience, MOST issues which challenge IT projects, reside very close to the project floor, where the teams and individual function. there you can find mishaps like: - individuals lack of info about project's purpose, significance - individuals lack of proper knowledge - individual fail to understand, and accept technological solutions - lack of communication among people who depend on eachother in terms of results - political games, tensions, manipulation on the "floor" - more most of PM education and consultancy services are provide for the first 3 legs. the fourth leg, the human factor is left for managers intuition. when IT projects fail (not if...) the management usually fail to put professional attention to the project level human dynamics, where they may find in many cases the small factor which cause the big problem

ernst.snyman
ernst.snyman

Question: Why would you not put Risk Management as a fundamental? I have an idea what your answer will be, but please answer first. Regards Ernst

jmgarvin
jmgarvin

I've seen too many projects fail that were under funded. We needed more consulting time with the vendor (money), we needed more license, modules, doodads, whatever from the vendor, but it was never purchased. The prime example is at a previous job, they didn't purchase a required component to integrate two systems together, so we ended up way worse off than before and we could NEVER integrate at that point because it would be impossible to migrate the current data/content. Pony up up front or expect failure.

jfbauer
jfbauer

As I was reading, I was replying in my mind a number of past IT project failures and was able to quickly link each to one of the seven criteria in this article. If you are interested in a different slant, surviving your role on a project, check out a few articles I've posted on that subject: http://bit.ly/1HddJW

MyPMExpert
MyPMExpert

I would include in this badly detailed business requirements, and lack of project budget. Actually when you think about it there are so many things which can derail IT project success it's hardly surprising 95% of them fail! Regards Susan de Sousa Site Editor http://www.my-project-management-expert.com

tuomo
tuomo

This is the same picture I was presented over 35 years ago when I started but it wasn't for an IT project, it was for any business project. One thing different from today is that when executive sponsor (often CEO) gave the support he/she at the same time named a person responsible of the project. Today projects often don't have one but many persons supposedly responsible, people come and go, inside fighting is breaking the project, as someone already mentioned - the sponsor is not kept in loop, whatever. All these work against the success, slow the progress, makes people indifferent of the project, creates silos in company, causes delays, etc. Anyhow, yes, that picture if really followed make success much more probable but, unfortunately, many in corporate hierarchy see it as a threat for their own goals.

lisboac
lisboac

Agreed 100%, it's the fundamentals

kanwalmanish
kanwalmanish

I have seen that requirements pose such a risk that managing them can be quite tricky. I have worked on a project where both the personal and professional realtionships got strained because the changes were not managed appropriately

robin
robin

In my extensive experience both successfully delivering but also blowing (and hopefully learning from) projects, I?ve found that lack of executive support usually is blamed as a main cause of failure when in fact it?s often the result of a project failure that?s already occurred but hasn?t been recognized yet by the participants. I?ve found most executives start with support, but many back off when they sense the project is failing. Invariably, the biggest underlying cause of project failures is inadequately discovering REAL, business requirements deliverable _whats_ that provide value when delivered by the product/system/software _how_. Prematurely and overly focusing on what will be created leads to overruns and disappointment when what?s created turns out not to be what?s really needed.

stevex_1999
stevex_1999

I have been on very few projects where there was true executive buy-in, meaning involvement, concern and proactive assistance working side by side with the PM to deliver results, the 'shared ownership' model. All too often, project management is outsourced to an individual contractor who can then be jettisoned at will if the project runs into difficulties. Management expects clear, smooth sailing from day one, even on projects that have been through multiple PMs unable to cut through the red tape and obtain the backing and authorization necessary due to the complete lack of support. It is all too easy to blame the PM and nobody looks to their manager for the root cause problem.

yeoman
yeoman

Having managed (mainly) IT projects for many years and now working for a company that runs project management training workshops, I read all the comments with interest. The Standish Group in the UK has done a lot of research on IT projects over the years and come up with very similar points. These are reflected in the comments. Some may not be aware that these aspects are covered in PMI's Project Management Body of Knowledge (PMBoK(R)). It covers Integration Management - managing stakeholders, co-dependent projects, contractors, as well as various aspects of the project Scope Management - defining the scope (business case and business requirements) and managing changes to the scope (managing scope creep) Time Management - coming up with reasonably accurate estimates for work effort and schedule, monitoring and controlling the schedule Cost Management - as for Time Quality Management - ensuring that we deliver what we promised, to the appropriate standards Communications Management - keeping all stakeholders informed with sufficient information at the right frequency Risk Management - identifying all the things that could go wrong and putting treatment measures in place People Management - includes recruiting the right staff, managing their work assignments, measuring their performance. Includes managing sponsors and contractors as well Procurement/Contract Management - covers services as well as materials and equipment, quantity, quality and timeliness of delivery from outside party Underlying these competencies are the company's maturity. Does management understand there is a need to support project management? Has a sponsor been identified for each project? Does the sponsor understand the need for a valid business case, with real cost justification as opposed to plucking numbers out of the air? Does the sponsor realise that involvement is not just kicking off the project but keeping in touch with it and providing support when needed? Applying PMBoK(R) principles will help us succeed on our projects more often, as opposed to just being lucky.

davidjoots
davidjoots

Over the years i've found project success incorporates all the things mentioned. But the savior tends to be a water-tight business case. The ability to say 'no' to project creep, should stem from this. (esp in large orgs, with multiple & powerful sponsors/stakeholders) As does an 'if needed laborious change control process' to deter exec scope changes in a project. There is nothing that execs/senior managers hate more than having to complete more paperwork ;-) Ultimately, there is no perfect project, but keeping a tight reign on scope/cost sure does help alot. David http://www.joots.co.uk

holger.heuss
holger.heuss

interesting as the picture seems to be copyright now to the company the author represents violently agree with comment - a good project starts in the business and nowhere else consultants portraying the picture of "IT project" "help" to achieve failure as it is most likely that not the right sponsor is engaged...not the stakeholders are consulted with, not the real business requirements are gathered, etc, etc

kesseleejay
kesseleejay

This is very common with running IT projects in Africa. I have working as an IT consultant in Ghana and my experience of the getting management to buy-in to IT or engage with IT, understanding the risks associated with IT and putting in place good change management system that will bring benefits to their organisations, despite liking flabouyant IT, can be a very difficult undertaking.

Tony Hopkinson
Tony Hopkinson

You get in that situation and you didn't have a project that became a failure, you had a failure you called a project. Nebulous scope, ill defined requirements and unrealistic expectations, are all executive failures. I mean what half wit okayed it and on what basis?

PMO Weasel
PMO Weasel

All too often the projects I see have a business case attached, but one where the assumptions are so off the wall that the rest of the document is nonsense. The business case says we will save $5 mil. per year, so the project gets enthusuastically approved, but there is no way on Earth the project can ever do that, so you are doomed from the start.

Ian Thurston
Ian Thurston

Robin, I have often found that executive support is limited to the project initiation phase. Thereafter, many executives I've consulted with act as if they believe they can delegate their support for the project. On more than one occasion, I've been told in effect "I don't want to have to be bothered with this any further". This is not delegation, this is offloading, and when it happens, without exception, these projects have, at best, proceeded very slowly, and more often than not, failed. The only way I've found to handle this problem is to make it clear (as often as needed) that without executive buy-in and on-going support, I can go no further. If the executive seems disinterested in the project, then it's time to close the books on it.

kirk.bare
kirk.bare

I really liked this post. My only comment is that if Executive Management has 'seen the writing on the wall' regarding the project; then, why haven't they stopped it or changed the direction from where the project was going? To me your reply says "lack of management involvement and intervention" by executives make the project fail. Maybe they didn't make the intially conceived project fail, but they certainly make the possibility resurrecting the project near zero.

vh396001
vh396001

How about clearly communicating what you expect from the executives at the beginning instead of just asking for buy-in and support? Perhaps in their world attending the first meeting and approving the project is like cutting the ribbon which comes at the end of a project

tonycopp
tonycopp

Politics is the key to a rewarding experience. It's like your project was proving to the client they should quit smoking tobacco when they had insufficient commitment to change. Frustration and lack of brand-building success. Interview for your life, not a paycheck.

LightVelocity
LightVelocity

What exactly were you looking for from the executive support? If they kicked off the project, committed and provided the resource, budget etc., why or what else would you want to bother them for?, other than requesting them to be present at the updates or during discussion on the progress (or lack of). The only place I have seen the need for continued executive involvement is when authority or influence needs to be exercised across different departments or groups - such resolving issues, priority conflicts, customer or beta references etc., Even in these case, it is the Project and Group managers who need to follow, pursue and drive.

mkrigsman
mkrigsman

The connection between recognizing the problem and fixing it is sometimes weak. I think the operative word is "denial." Denial is associated with almost every failure, and piercing through it is one of the biggest challenges.

jmasters1
jmasters1

Too often, project managers don't exactly share the news of the risks or failures of the projects. PM'ers don't want to look bad. PM is already tough enough without the (often self-imposed) stigma of failure to cloud things further. But there should be good communication already occurring with executive sponsors. And PROPER appraisal of status garners respect. Sponsors don't want to look bad either.

rudada1
rudada1

The flip side of the coin is when they are too much involved. I have seen them changing direction of the project unilaterally, expecting the Project Manager to continue with picking up the pieces. Or in most cases they are confusing "strategic" with "Operational" decisions.

Tony Hopkinson
Tony Hopkinson

..... The support we really need is highlighted in one of your statements. "Discussion of lack of progress" If that's what you are discussing, you've already failed to manage. You don't suddenly lose a couple of couple of weeks do you? One minute it was there, now it's not, as though someone put the clocks forward. Why wasn't impending failure communicated? If it was why was it ignored? Dashboard approach to Project Management = Documenting failure. One of the key failures that PMs have to deal with is lack of authority to deal with impending failure, and that is lack of executive support in 120 point bold capital letters.