Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Failed IT Projects Expand / Collapse
Author
Message
Posted Wednesday, August 11, 2010 9:31 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:05 PM
Points: 31,284, Visits: 15,750
Comments posted to this topic are about the item Failed IT Projects






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #967917
Posted Thursday, August 12, 2010 1:58 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, September 22, 2014 7:51 AM
Points: 24, Visits: 54
Most projects fail because they have time scales that are too long. The importance of early delivery is underestimated and the larger consultancy gain from continually tweeking specifications, endless meetings and never closing the requirements door.
Post #967976
Posted Thursday, August 12, 2010 9:05 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, October 29, 2014 1:53 PM
Points: 65, Visits: 261
We use test driven development, continuous integration, acceptance test driven requirements and SCRUM to develop our software.

Does all that help to make a project successful? Yes.

Does all that mean we will succeed and the project will not fail? No.

Why no? Because we are continually given a date and a scope and told that we have to hit that date with the scope intact because the company doesn't want to invest more money to get that particular product to market and they've promised the customer base that they will have the product at that time. Is this realistic? No. Management's response to the catch 22 is to tell us to find the solution that fits the time given, which is, of course, not realistic.

This process results in everything being pushed along so fast that an adequate job of describing and analyzing the product requirements, let alone architecture and design, is impossible except for the smallest of projects.

To make things worse, we have teams spread across three or four time zones.

Software development used to be fun before companies decided that they really don't like paying for it, despite the fact that they make good money from their investment (when they do it right).
Post #968265
Posted Thursday, August 12, 2010 9:29 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 2:47 PM
Points: 132, Visits: 114
I think that MS's success is that they have the timeline first, then figure out what to fit into it.

The problem comes when the functionality and the delivery date are announced at the same time. This violates a law of nature: the more you know the delivery date, the less you know what will be delivered, and the more you know what is to be delivered, the less you know when it will be delivered.

This urge to violate said law of nature comes from a very reasonable place: the desire to know how long and how much a project will cost. Ultimately, however, I think that many if not most failed projects come from that place.
Post #968307
Posted Thursday, August 12, 2010 9:52 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:05 PM
Points: 31,284, Visits: 15,750
I think MS has the timeline, and some functionality, but they have a sliding funtionality target. If things don't appear that they will fit inside the time, they get moved out. Perhaps that's something that more applications should do.






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #968338
Posted Thursday, August 12, 2010 9:59 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, October 29, 2014 1:53 PM
Points: 65, Visits: 261
It is all a matter of negotiation and prioritization. However, these two concepts have no value when a line has been drawn in the sand.

By the way, TDD and CI, if done correctly, guarantee that at any given point in the project you are capable of shipping what you have. This is especially useful for giving alpha and beta releases to customers that have high quality and help boost customer confidence and increase customer feedback (it is hard to give feedback on a beta release that crashes frequently).
Post #968350
Posted Thursday, August 12, 2010 10:07 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Tuesday, November 18, 2014 9:54 AM
Points: 499, Visits: 981
The basic definition of a "failed" project is that the results didn't meet the expectations. The problem here is the expectations of management:

1."If it looks simple on the surface, it must be simple to get it done."
2."If it's simple it must be easy."
3."If it's easy it must be cheap."



The most important job of the project manager is helping management understand that point 1 is just not true.

Steve G.



Post #968364
Posted Thursday, August 12, 2010 11:08 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, October 25, 2013 12:22 PM
Points: 363, Visits: 147
I believe you are correct when you say, "To a large extent I believe that we really don't understand exactly how we should build software, and highly underestimate the complexity." I see several parts to this problem:

1. The "how" part: Since the late 1960s, there has been a movement toward the idea of software engineering. This was an attempt to apply the discipline of engineering to the writing of software. Although this made great strides, it has ultimately fallen short because the user of the software is often not a machine.

2. The "complexity" part: Many, if not most, of the simple tasks have already been computerized. Think of calculators, cell phones and such. Businesses are now attempting to solve very complex planning and logistical problems. They do not yet understand what type of solution they want, nor how to implement it as a "people process." The business management types are trying to define what results they want as they look at the results of the latest computer output. This leads to one of two cases: the software is never good enough or the software is never done.

We, as software developers, lose. We are blamed for these shortcomings (management NEVER blames themselves). We need to develop better tools for ourselves which allow us to better understand and model what the business management types want. We also need to develop better tools for rapidly providing ad hoc results to show for the next cycle of goal revisions.

Adding to our dilemma, our budgets are constrained. We cannot buy or develop the tools we really need. Sales, marketing, legal and the executive offices get what they need. Production, IT, accounting and such have to make do. In order for this "software" problem to be solved, business management types must understand and appreciate the importance of all parts of the organization as important components in solving the problems of running a modern business.
Post #968425
Posted Thursday, August 12, 2010 1:24 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, October 29, 2014 1:53 PM
Points: 65, Visits: 261
Software solutions have become so complex that a software engineer often must help the business stakeholder understand what they really want. This is more of a social engineering task than a software engineering task and can require many different techniques to finally narrow the requirements down to something that can be understood and which adequately defines what the expectations are. Verbal and written communication skills are the number one tools of the trade these days.
Post #968525
Posted Thursday, August 12, 2010 3:07 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, August 12, 2010 2:59 PM
Points: 1, Visits: 0
Ahh. Management needs to do a better job. What does that mean? One thing it can mean is that development managers need to help their delivery team become self-directing, self-correcting, self-critique-ing leaders. No easy task. Then the delivery managers need to manage up to stakeholders making promises to customers. They need to train stakeholders to understand velocity. And function backlogs. And from that, what can happen and when. You want a date? Then this is what you can have. You want something? Then this is the date you can have it. You want both? Then we need more resources. It can become more factual, like that. Overtime? Extra effort? Let me show you the mountain of evidence that that doesn't produce what you want.

Yes, management is a big part of the answer. But it's not a simple or easy answer.
Post #968579
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse