Is Your Development Project a Sinking Ship? 494
Posted
by
michael
from the down-down-down-and-the-flames-went-higher dept.
from the down-down-down-and-the-flames-went-higher dept.
gManZboy writes "Everyone knows that some software development projects succeed and other fail -- the question has always been 'why'? I'm sure we all have our favorite (likely anecdotal) explanations. Well, these guys decided to actually go out there and do a formal survey, and they've got some real data on why projects actually fail (as reported by development project managers -- care to guess where 'changing requirements' ranks?). They've developed a diagnostic formula people can use to gauge the likeliness that the project they're working on right now is (or isn't) going to fail."
Yeah but... (Score:3, Interesting)
Changing requirements blah blah blah not my fault blah blah blah...
Re:Project Management Authority (Score:4, Interesting)
All too often, some sales guy will toss in a requirement like "must run on Win98"; and thousands of man hours will be wasted trying to meet something that wasn't even important to the customer.
If the original spec calls for "turn lead into gold", it's a very good thing if the requirements can evolve as technical issues are identified.
Aggressive scheduling (Score:4, Interesting)
Re:A classic one for me (Score:2, Interesting)
That usually means the UI isn't done. Unfortunately, the UI consists of 905% of the remaining work.
I blame the If statements (Score:3, Interesting)
Re:Sigh. (Score:2, Interesting)
An estimate is done based on assumptions and scope. If your client changes the scope, that should cash in your pocket the moment they say "Yes" to the proposed change and resultant cost.
Part of my job is process improvement. One of the first things I find useful to teach development teams is how to say "No" or "It'll cost this much and take this long. Do you still want it?"
Re:I blame perfection (Score:3, Interesting)
"A good plan, violently executed today, is better than a perfect plan tomorrow."
Re:Projects fails because no one ever learns (Score:4, Interesting)
Umm no they have not. Construction is one of the slowest to change industries on the planet. Take a hotel It is really just room after room. You design one room and then multiply that out to make a floor. Then you stack the floors and you have a building.
The key is standardized everything. Look at your average home. It is still built out of sticks or concrete blocks. Very little has changed in a very long time. The latest thing is metal studs but it took decades for them to become commonplace in homes. Very little changes and very little in really innovative.
And if you think that building projects are always on time and on budget.... Ha Ha Ha Ha Ha Ha
Not on your life.
This has already been done (Score:5, Interesting)
We've gone from about 25% of projects being "successful" (on time, on budget, meeting stated needs) to about 31%. So translated, that means 2/3ds of the time you get into your car or get on an elevator, it'll work as you want.
Consistently, the top reasons for projects failing, for the past 10 years?
1. Unclear, poor requirements
2. Lack of user involvement
3. Lack of buy-in and support by upper management
I have to agree with other comments made, this isn't rocket science. We just need some time and maturity as an industry. Civil and mechanical engineering have had thousands of years to work out their kinks. The software engineering science has had to deal with technology and implementation far outpacing our understanding of the basics and principles involved.
But we're getting better.
Honestly, if the world at large knew how brittle, fragile and reliant on heroism most of the critical financial and industrial software was, there would be a huge outcry. It's one of the shameful aspects of our industry.
Re:Blame the P.M. - usually (Score:3, Interesting)
If your project manager is completely constrained, then it's not his fault that he can't push back on poorly defined business requirements or ridiculously unreasonable timelines.
The solution is your sales team needs to buy-in to the idea of properly qualifying customers and setting expectations reasonably, or not setting expectations at all until project management has been brought into the sales process. The "lie, cheat, do anything to close the deal" technique often fucks small companies over leaving these disastrous projects in its wake. And yes, bad project management, poorly defined requirements or changing requirements and other factors can certainly ruin a project too.
It's not magical (Score:5, Interesting)
There are a million and one books and surveys and they all say the same thing. First, there is a formal process for the development of anything (not just software). This starts with the formal documentation process and meetings to discover functional and non-functional issues. Second, there is a very strong sense by everyone to want to adjust it a little more. From senior managers who allow scope creap to managers who want steps to be cut to make up time to programmers constantly who rewrite the code because they think they can squeeze 5% more time out of a loop that runs for less than a second in a process.
Most people do not realize that in a successful formal process that the actual time in a software project that is used to build the software should amount to only about 30% of the project's development time. The other 70% is time spent on documentation, meetings, and testing to ensure that the 30% of time used on software delevopement is actually what the company is needing. And, it is discipline that keeps people on the project process in the face of the fear of not getting the project done right. The process has to be allowed to work, both to reach a project end point and to have unobstructed process from which to learn.
The part I get a kick out of is that just because people write software or run a company that they somehow think they just ought to know why projects work. If complex systems were just so easy, why would we need formal training? After all, anyone can build a bridge successfully without training, right? I am not being hard on people, though. I had this exact same though years ago and what I figured out is that the vast majority of the software industry is so poorly trained that it doesn't even realize that it poorly trained.
Successful software development books have been around for more than 30 years. Go read! Better than that, get a university degree. The more liberal the better. Honestly, it is worth it. Here is a good place to start: Systems Analysis and Design by Kendall and Kendall (ISBN 0-13-041571-5)
Remove cloud cover (Score:3, Interesting)
Look at a schedule as just one component of a (good or bad or in absentia) process. Look at a process as just one component of the product. Then non-vetted schedule changes (aggression without responsibility) become product defects.
What do you do with defects? You track them. You test for them. You fix them. Data (evidence) is needed for tracking, testing and fixing schedule defects. Collect the data in advance so you can fix the schedule in retrospect.
Otherwise, every day will be Groundhog Day.
Please check my math (Score:3, Interesting)
Quote1: nearly $1 trillion was wagered on underperforming projects
Quote2: A large number of underperforming projects ultimately fail
Quote3: costing U.S. companies more than $75 billion each year
How does 7% failure become a "large number" of projects failing?
I would expect 7% to fail just from bad ideas alone.
A little gloom and doom?
Interesting survey results... (Score:3, Interesting)
I think the true crux of the problem with software development lies in understanding requirements. A methodology will most definitely HELP find the requirements, but I don't think it's directly the biggest risk driver.
In my experience the biggest problem is getting the users engaged in the requirements gathering. This is the most critical piece- no matter what methdology you use (and they will come and go) you still need to make sure that you understand the requirements. In most business environments, software development tends to a discovery process. In some cases the users can visualize a system and what it should look like, in others they cannot and it just may take a lot longer time. In that case, expectations should be properly managed by the stakeholders. PM's come in to play and should explain what is likely to happen- requirements will change, development or design may take more time, etc. Investigate other options for requirements gathering and understand not all of it may be able to be done on paper.
I've found that most business applications work best when I have users who have had some level of experience with Information Systems, who are committed to walking through what the system should do, and have support from management to do so through the entire development cycle. Technology and development tools are usually the issue, especially if you have competent developers.
We're waaay beyond sinking... (Score:1, Interesting)
In the end what management estimate would take six months (which engineering insist can't be done in less than a year) took a year and a half, and is entirely unmaintainable.
A cow-orker uses the bulldozer metaphore to describe our project(s); every short cut we take is like dirt collecting in front of the bulldozer. At some point we either need a bigger bulldozer or we start from scratch...
Dissimilarity and Some Insights. (Score:3, Interesting)
The most unexpected result here, and the most insightful to me, is "Similarity to Previous Projects." This is a factor that I think deserves more attention - you can have a great staff, great management, and all the resources, but stick them in unfamiliar territory and your chance of failure goes up.
I don't think people pay enough attention to this factor, and thus it sneaks up on them easier than the obvious ones.
I have witnessed very talented people completely screw up an simple application because they had no previous experience with a project of that particular kind and neither did the management structure. Thus they all did their best, worked hard - and still produced a massively flawed product.
In these cases, I asked myself "How could they mess up like this when the solution was obvious." Now I realize that the solutions were obvious to me as I was more familiar with the kind of software they were trying to design.
Lack of focus (Score:3, Interesting)
The lack of focus made testing difficult because it wasn't particularly clear what the testing metrics should be. A library system I know of was so overwhelmingly bloated trying to meet a variety of interoperability specs that when the testers saw some 2 megabytes of data cross the lan to handle a single checkout/checkin transaction, they didn't realize they had a problem.
Another salient feature of successful projects I've worked on is technical competence. The managers of the successful projects tended to be ex-coders and had a feel for what made sense vs what didn't. The bloated projects were run by people from all manner of backgrounds and hence, didn't have the cut-to-the-quick feel when something was going awry. One time, I was working on an air defense project for a country in the middle east and the project manager started getting antsy when he saw all his developers waiting on the compiler. We were using the machine we were going to deliver the product on and it was having a tough time just compiling code for some 12 developers. He sat down and wrote a bare-bones air defense system that did nothing more than establish a client server relationship and had the client simulate the required number of radar contacts per second while the server did nothing more than ack said contacts. The machine couldn't handle a load as simple as that which led to some back and forth with the hardware company until they upgraded the hardware to handle the problem. Had he not had the tech background, he wouldn't have realized that there was a problem until it was too late.
The number of projects failing now will probably rise because Moore's Law isn't there anymore to bail over-speced projects out. The code written today won't run any better on tomorrow's machines primarily because it doesn't look like tomorrow's machines are going to be much faster. Knocking that crutch out from underneath projects will tumble more than a few projects.
death march projects... (Score:4, Interesting)
someone else in our organization (at another geographical location), happened to be better aligned with the top management group, and used this to their advantage to eliminate competing projects, or in some cases eliminate the internal competition and take the projects over as their own.
of course at the time i had no idea what i was getting into(or who my "competition" was). no matter what our team did to produce a superior product, our project was cancelled for reasons beyond our control. i ended up stressing out and nearly damaged my health and my relationship...
then i read a book call Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects. i soon realized that we were set up as an ugly style project, doomed(in fact designed) to fail.
it's good to understand why projects fail, i have not yet RTFA, but i'm sure it will compliment some of the discussions/concepts in the death march book. good read.
Traceability (Score:5, Interesting)
One result of government regulation has been the emergence of requirements management tools like Borland's CaliberRM and Telelogic's DOORS.
These tools trace every functional requirement back to a business requirement. They also track the risk (schedule, safety, robustness, performance) of every functional requirement to the rest of the system.
Vague specification, like vague design is an indicator of not understanding the problem. The first step towards understanding the problem is categorization of ignorance, such as unexpected consequences already experienced by the project.
Good requirements management tools incorporate practices that have been proven to flush out vague specifications. Good traceability educates upstream participants so they can produce better specs in the future. Better specs yield better products, including better spec management tools
Re:This has already been done (Score:3, Interesting)
Re:Projects fails because no one ever learns (Score:2, Interesting)
Just because architects made big blocks of apartments that were the same does not mean you can't make a little house made of foam and popsicle sticks that no one else has ever thought of.
The analogy to software is a good one, as you have very different projects in size and scope. The main difference that everyone points out is that you can sort of see how much more a building needs, but software can be "99% done" forever and you can't really know when you will be ready until you are.
Anyway, my 2 cents.
"Software Engineering" is not yet "Engineering" (Score:4, Interesting)
Re:Project Management Authority (Score:3, Interesting)
If you'd like to look at it (I've got no problem sharing code/ideas...I don't work for a corporate outfit) shoot me an email myth @ my homepage minus www.
Sources of open source project failure (Score:4, Interesting)
It would be interesting to see such an analysis done with an open source-centric viewpoint: why open source/free software projects fail.
It would be necessary to structure the survey carefully to avoid the obvious results that don't contain useful information. For instance, Sourceforge is littered with old projects that never got past alpha or pre-alpha because no one was interested except for the project initiator (who never created enough of a start to encourage significant involvement from others), and the project initiator eventually lost interest him/herself. That may be the way in which most open source projects fail -- but that knowledge is of little use to someone running a project and looking for tips on management. There are of course books about aspects of this topic; but it would be nice if someone were to do a similar survey of open source projects that did get their legs underneath them, that did produce something that enticed involvement and an interested user community, only to eventually fail.
Out of Control Projects (Score:4, Interesting)
Chris Peters (former Microsoft VP) wrote an interesting documented called "Is Your Project Out of Control". It seems to have appeared on the net in various [stanford.edu] formats [brightwork.com].
Re:Interesting survey results... (Score:2, Interesting)
And I think the reasons for these psuedo-failures is directly due to methodology. Developers think users will just "do it the right way", when software testers and business people are telling them that they won't. But the developers, those all-knowing gods and godesses of everything technical, come up with 5 major reasons why "well it would take a LOT longer to code that! I guess we can't deliver the product to you then..." This twists the arm of the business who NEEDS that software app to be delivered on time.
If the methodology of software programming were different, and developers actually talked to "users," and worked with (instead of against) software testing groups, business analysis groups, and senior management the failures would happen with much less frequency.
Re:Project Management Authority (Score:2, Interesting)
Sadly QUEL was far better than SQL.
my experience (Score:1, Interesting)
1. No source code control. Particularly a problem if there is one key engineer holding things up.
2. Your in a start up company. The sales and marketing departments in your company make a deal with a large customer. The customer changes the requirements on a weekly basis. The changes result in practically a new product being created. Later, you find out that the important customer is not paying a single dime for the project. They a jerking your chain. In fact, they might be mining info out of your company.
3. The project manager does not know jack. A paper pusher but knows the lingo. e.g.. "flow", "process", "milestone","power point".
4. Too many consultants or third parties involved. They don't want the project to end because it means no more $$$.
5. Mergers in service companies. Typically there is hacked code on a back end nobody has ever seen. The managers want to create one system. You get a hodge podge of incompatibility.
6. Lack of documentation and specs. Nobody even knows what to build or how to update/merge the systems.
OK, thats my 2 cents.
Bias (Score:3, Interesting)
I also think that the chosen dimensions are not orthogonal. The methodology chosen is influenced by experience with similar projects... If your architects have done something similar before, then a structured approach will be extremely effective, if they haven't, then an iterative approach as they work out how to do it.
All in all, a pointless study that will do more harm than good.
Bad Idea? (Score:3, Interesting)
Seriosuly, how many of you have worked on a project (probably you were assigned by someone who wanted to get rid of you), where you thought from the beginning of the project 'this is a terrible product?'
Even if the product ships (which is unlikely, because your coworkers probably also think the product is terrible, thus morale plummets, thus productivity plummets, thus
Re:Traceability (Score:2, Interesting)
History and Future (Score:3, Interesting)
Agree on the value of tracking estimates and actuals. I've not had the experience of working on a project that was mature enough to track both. But even a mental comparison of estimates with personal observation was invaluable in understanding developer strengths/weaknesses.
Do you think there is a place in the market for an open-source requirements management system? E.g. if someone started such a tool, would any home-grown tool owners contribute expertise or code?
Have you seen a good tool that is more affordable than CaliberRM/DOORS? The market seems to have an absent low end (excluding MS Office). Microsoft plans some process management for their developer tools, e.g. "Visual Studio Team System" is mentioned in a comprehensive description (with photos) [msdn.com] of their internal build+test environment for ASP.NET.