Perception, Reality and Project Management

Ann All

Poorly managed IT projects seem to be about as common in many companies as purloined food and other office refrigerator "issues." But how serious are these problems, really?


It's tough to say. It may be that anyone who has had a sandwich swiped or been asked to approve additional funds for a project gone awry tends to overestimate the seriousness of these problems. That could help explain why a study produced by three academics differs so dramatically from the Standish Group's Chaos Report, an oft-cited piece of research that suggested that three-quarters of IT projects were "challenged."


As ZDNet blogger Michael Krigsman writes, business professors Chris Sauer, Andrew Gemino and Blaize Homer Reich used different methodologies than the Standish Group, surveying project managers rather than executives and asking about the performance of only their most recent projects rather than multiple projects.


This may mean the Sauer/Gemino/Reich data -- which suggests that about a third of IT projects fail -- is more accurate, writes Krigsman, as "project managers typically have more detailed and specific project knowledge than do executives." Also, focusing only on recent projects "presumably reduc(es) the effect of poor memory on their finding."


While the Standish Group uses just three categories -- failed, challenged and successful -- to describe project performance, Sauer/Gemino/Reich employ five categories -- abandoned projects, budget challenged, schedule challenged, good performers and star performers. Again, Krigsman thinks this yields a more accurate picture.


Putting aside the differing numbers, Sauer/Gemino/Reich offer some insights that will doubtless ring true for IT professionals. In a nutshell, the odds of project failure increase with the number of changes in size, budget or scope, and with changes in key personnel (project managers and executive sponsors).


They write:

Ambitious-sized projects, moving targets, and managerial turnover present challenges for IT projects that stretch even experienced project managers and result in greater variances. Effective oversight of projects can help project managers respond to these challenges.

No matter which numbers they think are more accurate, IT pros should probably worry more about perceptions than reality. Whether influenced by the Standish Group statistics or their own experiences, an alarmingly high number of folks seem to accept IT project problems as "normal."


As reports, 43 percent of middle and senior IT managers surveyed by Dynamic Markets on behalf of Tata Consultancy Services say business executives expect problems with IT projects and have learned to live with them.


Among the most common problems mentioned by respondents: schedule overruns (62 percent), inflated budgets (49 percent) and higher than expected maintenance costs (47 percent). Another depressing stat: One in four of the respondents report difficulty in getting business users to adopt new systems.

Add Comment      Leave a comment on this blog post
Dec 11, 2007 9:20 AM Paul Wallis Paul Wallis  says:
We should look towards other industries for a lead here.After all, how could we build other complex things like skyscrapers or bridges without blueprints or engineering diagrams?The number of project failures will decrease when IT is fully documented and its interactions with the business are easily communicated via simple pictures. Reply
Dec 19, 2007 3:48 AM Dr Carl Clavadetscher Dr Carl Clavadetscher  says:
The Chaos study, a series of projects starting in the mid- 1990's, does indicate ,based on interviews with very large numbers of subjects (>8000) , that most IT projects fail. This is no anomoly because their data is corroborated by extensive outside data from commercial and governmental sources. Senator (later SECDEF) Cohen published a report in 1994 also entitled 'Chaos' which drew very similar conclusions to the Standish study. Authors who cite the new study should note that the sample is UK not US. We have reason to question if that might make a difference. And the original Standish Chaos study defined small medium and large projects by the size of the company within which they were completed and the average size of projects in that firm group.(sm~=$450,000, med~=$1.3mil, large ~=$2.4mill)By DoD standards, you get ~2 people years of work in a classified environment out of a budget of ~$450,000. There is still reason to believe that size and complexity and technical newness remain the big unclimbable mountains. Size, complexity, technology are still eating our lunch where I work. Reply
Dec 19, 2007 4:12 AM BCooper BCooper  says:
An important "key" to project success or failure should lie in an upfront definition of what is considered "success". Success or failure to a IT technical team is likely quite different that the measures of success by IT or business executives, as the article touches on. Example: an IT project could be going quite smoothly yet a beta test or pilot test could be a misable failure - which is a GOOD thing because it gives the PM and project team (as well as management governance) the opportunity to step back and take a deep breath and ask, "Ok, now what?".Also, a typical historical project lifecycle for IT projects places little time in indepth planning, requirements gathering, design, testing which results in an overwhelming amount of time (translating to costs) in implementing and post-implementation fixes. The better approach is do MUCH MORE planning upfront, better design, and thorough testing of systems/applications to see more smiles on the faces of project teams and business executives. Comparing IT projects to general construction projects (I've worked both industries) is comparing apples to oranges as they are quite different in many respects. Reply
Dec 19, 2007 5:36 AM Concerned Business Owner Concerned Business Owner  says:
I would love to see some coparisons of non-IT project success/failure to IT run projects. I think the major issue is the exclusion of the business from the process. Most IT organizations have defined System Development Lifecycles. They use these as a road map to their process. When dates are at risk (the number one thing IT manages to) they stay from the SDL faster than one could ever imagine. One of the other posts refers to making sure to define "success" properly up front to make sure you are tracking to the goal. I would also suggest the "success" of the project is not defined by the IT organization (add scope to this spot too), rather it is defined by the business outcome. IT might have milestones or check points for success, however those mean nothing if the business results are not met. More and more you read about this IT - Business relationship and honestly it is just getting worse and worse each year. Companies continue to pour money into IT project management neglecting to see it is the business that needs to own the procjects. IT can deliver whatever they would like and without the buy in the project will fail. If the business was tasked with running the projects and IT was a partner in the delivery, it makes it very hard for business owners to point the finger elsewhere for the failure and thus the projects would fail less often. Unless you are talking strictly about IT implementations of hardware or networks. Is there really even and IT project? Reply
Dec 19, 2007 6:28 AM Anthony Arcabascio Anthony Arcabascio  says:
I do agree that setting expectations for measuring a projects success is necessary. Unfortunately, as we all know, projects tend to take on a different scope due to changes during the life cycle. Consequently we don't take the time to adjust our expectations and therefore the project's success is measured based on the original scope and understanding by management. A projects failure or inability to achieve its original agreed upon success is largely due in part to lack of senior management support or lack of interest by senior management. Once that occurs, cooperation and effort seems to decrease rapidly for the supporting cast on the project.A Project Manager need's to be first and foremost the leader and then the motivator, cheerleader, and coffee boy. It's not an easy job if your a successful one, that's why there are so few. Reply
Dec 19, 2007 6:52 AM Ed Johnson Ed Johnson  says:
Perhaps the prevailing reductionists style of Project Management itself is the reason for so many IT project failures. PM and Software Development Lifecycle might be perfect for the Newtonian world, a deterministic world. Problem is, business exists in a systemic world, and the parts of any systemic world are highly interdependent. Nonetheless, PM typically calls for breaking a systemic world down into discrete parts or tasks (e.g., work breakdown structure), often ignoring, corrupting, or downright destroying the interdependencies between the parts. Thus PM and SDLC often gain a limited and limiting grasp of affected business, making it impossible for project "success." Thats the irony. Reply
Dec 19, 2007 7:01 AM Juan Bernab� Juan Bernab�  says:
Hi,Its incredible how our current "body of knowledge" on project management is pushing for more detail & fixing scope upfront, and the people that is pushing this dont know, or remember, that waterfallish SDLC methods were already documented as a SHURE failure in 1972, leading to 100% in cost and time overrun.Is anybody aware of Agile Project Management & Agile Software Development?Cheers,Juan. Reply
Dec 19, 2007 7:29 AM Don Mendelson Don Mendelson  says:
Despite the fact that IT practitioners like to think of their field as an engineering discipline, there are fundamental differences from other industries. While a bridge designer has strict industry standards and immutable principles of physics to draw upon, business demands drive us to use new technology in practically every project. Yes, planning is essential, but in a knowledge-based field it is impossible to know all the facts up front. Rather we learn as we go, and if were smart we reduce risks by not committing resources until needed and make good mid-course corrections if we have to. With the right controls in place, you can see more successes and the cost of failures are more easily absorbed by the stakeholders. Half the battle of project management is setting realistic expectations. The other key to success is to involve all stakeholders in every step, and not just proxies representing the real stakeholders. I have also heard of systems being built that intended users do not want to use. This suggests that no one asked them directly what would help them do their job, or at least did not pay enough attention to responses. We wrote a white paper about this exact topic. If you are interested here is the link Reply
Dec 20, 2007 1:01 AM Tekgirl Tekgirl  says:
Agile is better applied to small and medium sized projects. In my experience when trying to apply this method to a large project, the requirements are inadequate or non-existent and there is no foresight of what is coming down the pipe or where the project will be or what the project needs will be weeks or months down the road. I agree that business and IT need to interface more on projects and the business definitely and obviously needs to be consulted and decisive on things, however I think we need to be careful in saying that the business is "running the project". Again, in my experience, this has meant that the business called all the shots, including technological decisions that they should not have been making on their own. Each line of business typically has its own agenda and best interest in mind. The enterprise view is not always taken into account; what is best for longterm and for the company as a whole for future leverage and scalability on the technologies being implemented. Reply
Dec 21, 2007 12:34 PM Terry Dexter Terry Dexter  says:
My experience has taught me the following hard won lessons:1. End-users and their leadership have bought into the concept that software, because it is just that 'soft-ware' can be changed far more easily than hardware. Thus, a Project Manager should not be flumoxed when the rate of Change Requests increases as End-users keep thinking of new features.2. The Project Manager is not sufficiently well placed to prevent incipient 'scope creep' as stakeholders and company management will most likely want additional features at the same cost estimate. It takes a brave PM to buck the system to produce the original project goals.3. The Art of Software Project Estimation is just that, a Black Art. Methods such as Function Point Analysis, COCOMO and the like expect individual software developers to produce the same results all the time. Cognitive Psychology research suggests such a goal is difficult at best and impossible at worst as each developer assimilates 'how to' concepts into their experience base differently.4. The IT needs of an organization morph on a continuous basis. The rate of such changes increases as technological solutions enter the organization's awareness. The usual depreciation schedule of 5 years for hardware and 3 years for software creates a cycle of new technology introduction before the IT applications can be thoroughly rung out for the business process they were meant to satisfy.5. The typically American 'financial quarter view' is too short to provide sufficient experience in new technology and applications. The 'How much revenue can we realize this quarter' mindset further drives business managers to expect more for less from over worked IT resources.6. Government, at all levels, should not be in the business of creating or modifying IT applications. Government employees have no incentive to complete a project on time or on budget. It is far better for government contracting to be used for a project. By conducting proper Due Dilligence and Contract Management, the government can oversee the project, but not affect the outcome if the contract is sufficiently structured.Will IT Projects fail? Of course they will. It is the nature of the beast. Reply
Dec 27, 2007 3:28 AM Warner Gouin Warner Gouin  says:
I agree with Mr. Arcabascio's assertion, "A projects failure or inability to achieve its original agreed upon success is largely due in part to lack of senior management support or lack of interest by senior management. Once that occurs, cooperation and effort seems to decrease rapidly for the supporting cast on the project."But would add that what may appear to be a lack of support or interest could really be the observable part of a 'Hidden Agenda' to Outsource those projects. Middle level managers within the State of Minnesota have used 3rd Party IT Contractors to expand the scope of employees work beyond initial estimates. Then those same middle managers would use a single Project Management Metrics, planned vs. actual, as the sole criteria to disqualify existing State Employees so that the work could be Outsourced to those same contractors at 4 times the rate of pay. In this case, Management creates the results needed to justify layoffs and reduce the management function to one of Contract Administration. While this practice is highly unethical within the Project Management profession, it is not illegal. Reply
Jan 1, 2008 11:05 AM Jed Simms Jed Simms  says:
So many points have been made, where do I start?Firstly, the definition of success. Projects are designed to deliver 'project outputs' which are not the same as the 'business outcomes' expected. There is a gap between the project deliverables and expectations that is usually unseen and not acknowledged until the project is finished.By then, the project is seen as a failure.The only true measure of success is that the business outcomes and associated benefits are acheived otherwise why are we doing the project????However, projects don't deliver these outcomes and benefits see the problem? But unless the project team makes visible, enables, supports and plans for the gap to be filled, projects will continue to be seen as 'failed'Now business support/involvment. Managers don't get involved because, not least, they don't know what their role is. They are not project managers, so there is little information out there to help them know how to set the scope correctly, how to evaluate scope change requests, what to look for at steering committee meetings, etc (Something I am addressing)Unless it is a technical upgrade or an IT department improvement, most projects are business projects. If the business won't own them and take accountability for them, the business itself should not start it (and IT should refuse to take it on.)Expecting IT to pick up the slack has been shown for 50 years to not workSolution? Educate the business that projects are THEIR projects; this is how you behave as a business owner, sponsor, client; and this is what you're accountable for.Until we get INFORMED business involvement projects will continue to fail on one or more project dimensions, and most business dimensions. Reply
Feb 4, 2009 12:14 PM PM Hut PM Hut  says:

It's not Project Managers though who decide on whether a project failed or not, it's the executives. Additionally, will you get an objective response from the Project Manager and how and why the project failed?

Project Managers treat their projects as their pets, and I have yet to see one Project Manager assuming the responsibility of a failed project. The way the Standish Chaos report works might not be the ideal way, but I think this "improvement" will only get you answers like "Lack of the Executive Support". Project Managers have to protect their jobs when answering, executives do not (well, most of the times).

Now for the definition of success in Project Management, is it when the project is on time, on budget, and on scope? Or is it when the project delivers something of real value to the end user/customer (even if the time/budget/scope criteria is not met). I have published an article fairly recently on this particular issue, success and stakeholders; the article's point is that success can only be achieved if the stakeholders are satisfied with the end result.

Aug 12, 2013 10:52 PM Angela West Angela West  says:
Hi, Ann! What a great post!! Well done! I really love what you've done here and it makes so much sense! It's great to see such enthusiasm for leveraging Ever note for both tasks and reference related materials! Keep up the great work and I'd love to see more posts from you on Ever note! Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.