August 11, 2010 at 9:31 pm
Comments posted to this topic are about the item Failed IT Projects
August 12, 2010 at 1:58 am
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.
August 12, 2010 at 9:05 am
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).
August 12, 2010 at 9:29 am
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.
August 12, 2010 at 9:52 am
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.
August 12, 2010 at 9:59 am
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).
August 12, 2010 at 10:07 am
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.
August 12, 2010 at 11:08 am
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.
August 12, 2010 at 1:24 pm
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.
August 12, 2010 at 3:07 pm
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.
August 12, 2010 at 8:29 pm
If we could become emotionless then that would likely have a large impact on this problem.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply