Project Management

The IT industry is accepting failure as the norm

No project manager sets out to fail. But have project/program managers and leads begun to accept failure as the norm?

I'm sure that no project or program lead sets out to fail in managing a project or program. But have project/program managers and leads begun to accept failure as the norm?

Below are eight facts supporting this assumption:

  1. The percentage of failed projects in the past and the current percentage of projects, small and large, including ERP, are still failing.
  2. People are writing articles such as "Why Is Project Failure Good." My perspective here is that the author and others seem to be missing education and training on project management and its basic life cycle processes and activities (e.g., initiation, planning, execution to close out, risk identification, management, etc.).
  3. Many projects are not establishing a Change Management Process in the beginning of the project or program with a review team/board.
  4. Many projects are not establishing configuration management early and not establishing a configuration control process within the Change Management process.
  5. There is a lack of up-front risk identification and management.
  6. Lessons learned are not being documented and used periodically (e.g., for a phase/process, released functionality, or sprint), and not just at the end of a project (post mortem).
  7. Project managers are not consistently using best practices that have been, or were used, on successful projects and programs.
  8. There is no transferring and sharing of knowledge as a team.

You want to prevent the frequent occurrence of project failures, not celebrate failure!

Why projects fail

Project Failure in the IT Industry is directly related to five areas:

• Scope

• Time

• Cost

• Quality

• Customer/User Satisfaction

Quality and Customer/User Satisfaction are interpreted as meeting or exceeding customer requirements and satisfying the customer's and user's use of the system through two activities:

  1. Customer and user involvement and participation, starting from the beginning and going throughout the entire project or program. You should survey customers, have discussions, share knowledge and lessons learned, and provide feedback.
  2. Use of the system in a production environment, after successful functional and user-acceptance testing is completed.

Here are the top 10 reasons most projects and programs become troubled and/or fail:

  1. The absence of senior management's support and commitment
  2. The lack of competent and knowledgeable leadership
  3. Unrealistic or inadequate planning
  4. The lack of consistent communications and training
  5. Failure to clean up complex business processes (re-engineering) prior to implementing new systems such as ERP
  6. The absence of complete, stable, and mutually agreed-to and approved requirements
  7. The absence of requirements management -- business, user, functional (product/system, application, etc.) -- and alignment of the project to business needs
  8. The absence of a good architecture, or high-level design, to determine priorities and functionality releases for a system or product
  9. Core team not built with the appropriate skill sets, considering availability, retention, backup, and resource planning
  10. Not addressing risk identification and management up front, early and continuing throughout a project and program. Contingency planning being an afterthought. Projects proceeding forward at go, no-go decision points when significant issues and problems existed or had not being resolved. Serious downgrades to meet unrealistic expectations, marketing schedules, and deadlines

This attitude, accepting failure as the "norm," has to change or the IT industry is doomed.

Do you have high expectations for your projects and programs. Understand the discipline of project and program management to plan and execute successful projects and programs. Understand the basic fundamentals and the discipline and/or process (e.g., project management) and how to apply it. Prepare for the worst but plan for success.

Prepare for the worst

Here are four simple steps on how to prepare for the worst (or, in other words, how to be proactive):

  1. Perform risk identification and assessment.
  2. Establish early change and configuration control processes.
  3. Establish early, and in the beginning, QA verification and validation tests.
  4. Select and use a program/project management methodology.

Prepare for the best

How to plan for project success:

  1. Obtain written and documented support and commitment from senior management. (This also ensures that business management, Subject Matter Experts (SMEs), and users will be expected to participate.)
  2. Perform risk identification and management.
  3. Plan to use best practices for the Best Practice Processes (BPPs): Project and Program Management, the Development Process, Configuration Management, and Quality Assurance.
  4. Select an Appropriate Development methodology.
  5. Build a core team(s) with the appropriate skill sets, considering availability, backup, and retention. Make sure that business management, SMEs, users, and third-party stakeholders (e.g., vendors, subcontractors) are considered members of the team.
  6. Perform and develop realistic plans, schedules, and estimates.
  7. Establish early change management and configuration control and include an expedited process for critical and time-sensitive changes.
  8. Ensure client and users are, and will be, involved in the projects from the beginning and throughout the entire project or program.
  9. Consistently use during execution: A) best (and good) practices for all areas, not just for BPPs; B) lessons learned (documented throughout the project and program); C) knowledge transfer activities (for teams that consist of business as well as technology members).

You can decrease project failure rate where it starts -- with your attitude, belief, and resulting behavior and actions.

About

Eddie R. Williams has over 20 years of experience as a project and program manager for system/software engineering and IT development and management. His high rate of success, recognized within several industries throughout his career, is attributed ...

40 comments
Thegrumpyprojectmanager
Thegrumpyprojectmanager

We are often told that up to 70 percent of IT projects fail and from the remaining 30per cent many are challenged. Repeating this over and over again is fatal. People expect that IT projects fail. People almost require that IT projects fail, and so all negative feedback is given high value regardless of the relevance. It is 'safe' to repeat this '70 per cent fact' because then it is OK to fail: a project and a project manager who fails is a normal performer, when a successful project is a 'freak'. And when we study these 'freaks' very carefully it is possible to find some negative feedback and to 'challenge' projects' success. It is true that IT system development activities, 'bustles' which are not run as real projects but as a bunch of random tasks without real objectives and specifications often do fail, and stain the reputation of real projects. Real IT Projects - the ones initiated, executed and closed properly - are often successful; have the same success rate any kind of project has. Most IT development bustles fail. Most IT development projects succeed.

a.pyne
a.pyne

What can I say, all of you are right! What is boils down to is: [1] organisations consistently fail to establish the environments for project or programme success [2] PM Process and Technology are GREAT but have not delivered sufficient success, SO the only thing left is to address the People aspects at the individual and organisational level. [3] Is should be staggering to shareholders that 70% of their investment is wasted and yet............ [4] we professionals should be doing more to convince. We tend to rant at each other and not enough at CX level and we tend to talk about projects and programmes. Personally, when I chat to the exec level I talk about value. So why am I preaching to the converted too?!

Eddie R. Williams
Eddie R. Williams

Thanks, I appreciated all the comments and opinions. I'm sure that no project or program leader plans for his or her project or program to fail. Unfortunately, despite a large and proven project management body of knowledge (BOK), too many expensive IT projects continue to fail. If you are one of the many outstanding project/program managers who routinely manage successful projects, you probably already do most of what this article describes. The "million dollar" question here is "why does so much of the IT industry still accept failure as the norm?," or to quote Pete Seeger, "when will they ever learn?" I wish you all much success. I thank my mentors and coaches, and teams, for I have enjoyed a very successful career. ...and I will continue to mentor, coach, and train others.

blarman
blarman

Successful businesses are those who have figured out how to strategically and consistently control the process of change in their company. Most businesses don't ever think about the process of change itself: if you fail to plan, you plan to fail. Business managers have to understand how change takes place within their business, which means taking stock of three things: where are we now, where do we want to go, and how are we going to get there. Nebulosity in any of these three areas will lead to "failure". It's like an archer shooting at a target. First, You have to know where you stand. How far away from the target are you? Is the wind blowing and how hard? Are there any obstacles in the way? Are you even pointed in the direction of the target? Second, there is the target itself. How big is the target? Where on the target do we want to hit? Third, what are we pointing at the target? Is this a short recurve bow picked up from some local Cub Scouts or is this a heavy compound bow with sights? Are we shooting balanced flight arrows or broadtips? How many shots do we get at the target? Are we using an armguard? Have we even taken any archery lessons or practiced? There are a lot of elements to successful business process change. Many managers get lucky because they get easy shots. The harder shots, however, are rarely made with luck, but are a process of careful planning and execution at an unmoving target.

paul.simmons
paul.simmons

The PM group should develop methodologies to predict success and meeting time and budget prior to starting. Only then will it turn into a true profession. I believe that there are criteria that could help predict. The point of this is to either cancel the project or change the plan to increase chances of success. I belive that a lot of projects are set up to not be delivered on time and in budget with desireed business benefit even with the best people running them.

sng - TX
sng - TX

What I have seen is that it is Scope definition and management that leads to issues with the other 4: Time, Cost, Quality, Customer/User Satisfaction. If we can get a defined scope and it is managed properly, with appropriate agreement from the BUSINESS on proposed time, cost, quality, the customer is satisfied and we can be successful. The challenge is that scope begins changing almost immediately and we are not ALLOWED to manage it properly - not allowed to change time, cost or quality expectations. And, in the end, the customer is not satisfied. Somewhere along the way, our business and our IT Leaders have come to think that if they demand it, it will happen. Reason seems to be lost.

shokd
shokd

PMs aren't accepting failure. What responsible PMs are doing is communicating to their directors that their lofty ideas of doing x number of things at once with y number of resources is just asking for trouble. Directors are "yes men" to their superiors and just say, "Do it!", regardless of the evidence. Don't blame a PM if they offer alternatives that could lead to success, choosing instead to push along with unrealistic expectations. PMs don't promote failure, "yes men" do.

markjstanley
markjstanley

Dammit, I thought this was going to be an interesting look at whether the project management community was basically settling for "managed" failures.

shankarnm
shankarnm

Even when we have sufficient time for initiation and planning before actual implementation programs or projects tend to fail. One aspect is lack of understanding the Scope of Work before program kick-off. Plan inter-active workshops with business users and end-users of IT systems to assess agreed SoW. This will either help to de-scope or add to the scope at the beginning of implementation itself. One can use effective change management (Risk Impact Assessment) to address de-scoping and adding to Scope. One more missing link is most of the IT project teams talk technical language aspects with business users and business users expect how value addition comes to their business process if they start using the IT system. That is there is a Gap in translating the business requirements into IT needs. Here artifacts will not really help as Customers force project teams to implement with constraints. One example is on data integrity especially in data migration programs.

TownsendA
TownsendA

Generally the problem is not enough time on the initiation and planning aspects. Long before the implementation stage. The business seems to think that PM's are a silver bullet for their errors. In the final analysis if anything on a project goes wrong it was because it was not planned. The PM cannot do all the planning or execution on his own either, he needs a team that includes the business.

jvardam
jvardam

Because project managers think they know more and are more important then the people doing the actual work. I've never met a PM who knew his place when it came to running a technical project, and I've worked for Fortune 100 companies. PM's also don't communicate outside their cherished meeting times or any other way then via texting or email, PM's think they are above the skilled technicianas who cash the checks that they write without understanding what in the heck they are even talking about. Thats why projects fail!

Alpha_Dog
Alpha_Dog

Where sales is the driver, I have seen organizations where 90%+ failure is the norm spin this into something to be proud of. "We are the trailblazers" and other such nonsense when what they really mean is that we lack both planning and follow through. Sales will tack on specs (feature creep), promise undeliverable things because they truly do not understand the technology they are selling, and jumping on one trend only to switch horses as soon as the next trend out-shinys the last one or the going gets rough. Tony is correct with the swivel finger... when it comes time to admit the mistake and learn from it, these sales centric CEOs and boards blame the last persons to work on their pet project, generally the IT (or other technical) staff. What they fail to do is direct the blame inward and use this opportunity to learn and grow. Of all types of loss, loss without comprehension is the worst, because it will just happen again. One of the best tools we have for either a successful or failed project is a "post-mortem". This is as important as the planning meetings before the project is kicked off, but the least likely to be held. If it is a success, the teams are generally too busy drinking champagne to talk about how they could have done their jobs better or how they overcame problems. If it fails, human nature is to move on quickly so as not to associate their fragile id with the project now in flames. This prevents critical learning which must be done as close to the definitive moment as possible to maximize the data available and learn as an organization. Does it work? judge for yourself... Our organization is built by and run by engineers and business people, not salesmen. We cherish the war stories of both the successes and failures to learn from them. We never fire people for honest mistakes or mistakes made by the organization, as these people have valuable knowledge and experience. If nothing else, they know what NOT to do! Our projects have a 30-40% failure rate, and in most of those cases we use the project, knowledge, and skill sets from the failed project within another project. This is our culture, and we are looking for ways to improve upon it as well. It's not utopia, but we certainly do our best. Failure is not and should not be accepted as the norm. If something did not meet expectations, figure out why and add to the organization's knowledge. We all accept that personal growth is a good thing, so why accept stagnation and mediocrity in organizations?

sjok
sjok

A great example of the discussion in Mr. Hiners article occurred recently. There was a security error on face book revision that Mr. Zuckerberg blamed on "sloppy programing". The CEO of Data Doctors stated that he thought that "it was OK since it was inadvertent". My confidence in data Doctors went down the toilet when I read that. I hope "hot shot" teckies like zukerberg and the data doctors CEO are not preparing software (or doing any other design) on automobiles, airplanes, etc. I put them in the 100xers category. (A 100xer is someone whom, it they were one tenth as good as they think they are would still be ten times better than they actually are.)

djh56
djh56

This article on project failure is cliched, and more than a little banal. Morgan, Levit and Malek in their book Executing Strategy point out that 80%+ of all business strategies fail. And their is a plethora of other material pointing in the same direction. It is a systemic failure of business leadership and management at the top that is the real issue; and very little to do with IT projects and management. It is a given these days and has been for some time, that technology is at the centre of society and its activity. It's the enabler allowing us to produce the products and services we have all come to depend on. So why do businesses continue to promote people into senior positions with absolutely no understanding or appreciation of the very thing their businesses depend on? I did a survey of 65 firms a few years ago looking at their IT and business side management. It turns out it does not really matter how good your IT people are, or how experienced, how well trained, or engaged. They will not overcome a culture in which their contribution is trivialised, and the positives of any successful project are hijacked by the commercial wing of the business, as all their doing.

MyopicOne
MyopicOne

Business project budgeting, planning and administration concentrates on 'fast' and 'cheap', and wonders why they don't get 'good'. Seriously? Really?

Tony Hopkinson
Tony Hopkinson

Business defines the goal as good enough. Sometimes their definition of that isn't good enough. Swivel the pointy finger 180 degrees..

agilebrainz
agilebrainz

We are being consistently overfaced, consistently understaffed, expected to perform using our magic wands in place of an actual budget, and usually handed huge projects on a moments notice. When being so persistently set up for failure, why would anyone care to attempt success?

Tony Hopkinson
Tony Hopkinson

are they hearing what you mean by it. Different languages ,same words sometimes.

biancaluna
biancaluna

Fishbone diagram this problem and you end up eventually at the business level. I've been running projects for 20 years, small, large, succesful, failed, partly failed, somewhat successful, hugely successful - every flavor. The common thread - business culture. I keep seeing project risk management that is not considering the assumptions the PM makes about the business - do they reallly want me to be successful, am I assuming governance is in place, am I assuming that they will allow me to bring in discipline. Tony and Alpha are spot on, it is not a million dollar question at all. Life is really quite simple, and so is the answer to this question. KISS, my friend, and to quote Sherlock Holmes with an awfully Australian pinch of literary freedom , if you have excluded all probabilities, the option that is left over, oftentimes, is the murderer.

Tony Hopkinson
Tony Hopkinson

Anyone with some basic knowledge of IT and an IQ in double figures knows that answer....

blhelm
blhelm

It was published by the Project Management Institute (PMI) a number of years ago. It was called the Project Management Book Of Knowlege (PMBOK). Maybe you've heard of it. Those who have utilized it have seen a greater percentage of success than failures - when properly followed of course.

blhelm
blhelm

And BTW - a Scope of Work is NOT a Sales Proposal.

blhelm
blhelm

My earlier post refers to people that are promoted to their level of incompitence. These are the "YES MEN/WOMEN" out for career advancement off the backs of others.

Tony Hopkinson
Tony Hopkinson

Which bit of your post marks a unique and astonishing insight? So given that your approach has been demonstrably failing for decades, perhaps you should consider a rethink of your "It's all them IT peoples fault" approach. Perhaps the fact that this basic stuff still isn't happening indicates some underlying misconception, like business actually sees some value in paying to get it right?

CharlieSpencer
CharlieSpencer

Look at the reasons listed for project failure. Every one of them is a planning issue. This is typical of American culture. We don't want to do the preliminary work; we want to jump in and get started.

shokd
shokd

Apologies for the horrific PMs you folks employ. To think some high and mighty PM isn't collecting your input on the plan, just sort of doing as they please, with no one at any level realizing they're not the subject matter expert of the project. That that sorry axx PM should just be there at your beck and call. Surely your arrogance and probable obstinance have nothing to do with failure.

blhelm
blhelm

When ever a company is run/managed/lead by a "Sales" oriented approach, there is always...always...ALWAYS a discontect between the Pre-Sales and Delivery team. Too often a PM is staffed to the engagement ONLY after the SOW/Contract is signed by the customer. That is too late to properly set the customer expectations with the reality of the Best Practices we PM's have been indoctrinated to utilize. We are then placed into a hole and forced to fight our way back to realism by beating up on the technical resources (we also didn't have a choice on) to get them to perform extraordinary levels of effort and sacrifice - all to make the Account Team look good by delivering what they promised to the customer. God help us if that SOW (already signed by the customer) contains vauge language that the customer can leverage to milk extra time and deliverables out of the scope.

biancaluna
biancaluna

My experience as well. But what do I know, I've just been doing this for 20 years

blhelm
blhelm

My experiences exactly

blarman
blarman

"So why do businesses continue to promote people into senior positions with absolutely no understanding or appreciation of the very thing their businesses depend on?" Great observations.

blarman
blarman

Software development axiom: You can have it cheap, fast, and bug-free. Pick TWO. The reality is that whichever of the two your company focuses on will come at the expense of the third. It isn't something that can be avoided, either, much to the chagrin of non-IT managers who believe that all IT's magic comes by waving a wand.

blhelm
blhelm

Often time business people are out of touch when it comes to the "real" level of effort it takes to develop a quality application or the true cost and time needed to implement the "correct" infrastructure. Instead, they set unrealistic expectations on a staff already overburdened, understaffed and under qualified. Underqualified due to the budget cutting they undertook to justify their end of year bonus on running the IT shops with fewer and cheaper resources.

tonycopp
tonycopp

Consider that the cloud-free space has already hit the iceberg in 2008 and second-stringers at best are filling the moved-on leader's uniforms.

pamwezvinoita
pamwezvinoita

@ agilebrainz you so right.! especially considering fact that your project manager is non Tech..you will be diametrically opposed all the time

biancaluna
biancaluna

Cause it can't be that simple. Can it?

blhelm
blhelm

If a good PM follows a standard methodology for proper planning early in the project, and the SME does their job by providing accurate and timely input into the planning process, then there shouldn't be an issue between PM SME. I always harken back to the old PM axiom "Lack of planning on your part does not constitute a crisses on my part". Too many SMEs want to jump in and "get the job done" with out proper planning. This comes from a culture of wanting to please the customer and look like a knight in shining armour come to save the day for the customer. After all, all the other risk identification & mitigation planning, customer communications, dependancy identification, hand-off coordination and deliverable tracking is just a PM thing and doesn't require anything from an SME - right?

blhelm
blhelm

Too many executives are promoted/hired based on politics and the "Chrony Culture" (ie. hiring of close personal friends). These individuals have no clue what they are doing, make an art of using deligation and holding others accountable, and passing the buck when they make bad decisions. These are the same people that will filter and condense good detailed information that should be considered when making good decisions - such as Risk Identification and Mitigations.

Tony Hopkinson
Tony Hopkinson

They do know they are under resourcing, they know they are setting a geater than practical expectation, though a lot of that is IT managers and PMs telling them what they want to hear. Hence my response rubbish, even a claim of incompetence on our part is bollocks, after all which halfwit hired us.... Try not to confuse me with the numpty who came up with the original article OK, it's irritating.

Tony Hopkinson
Tony Hopkinson

you can make a better profit in the short term, by not taking the long term into account....

AnsuGisalas
AnsuGisalas

Is a crucial skill in IT it seems... ;) [Our boy Tony reading the corporate requirements] : "Bla bla bla ... excellent .... bla bla ... innovative ... bla bla bla seven flavors... bla bla buzz buzz buzz" - "Ok, one 'mediocre, good-enough-to-scrape-by, same-old-same-old bland vanillin' app coming right up".