Is Your Development Project a Sinking Ship? 494
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."
Project Management Authority (Score:5, Insightful)
Later I realized, as suggested by the senior management, that a good project manager should not let that happen had he properly designed and managed the project.
Recently I started to think that maybe all failed projects are due to the delays inevitably imposed by the senior management who requires many policies/protocols/documents/approvals/discussion
These delays introduce deadline pressure to project manager, and allow too much time for client to ponder about other features, and most importantly, give breathing space for competitors to come up with similar products BEFORE we do.
"changing requiresments" less bad than no change (Score:4, Insightful)
I blame perfection (Score:5, Insightful)
the real question is, using their formula... (Score:3, Insightful)
Projects fails because no one ever learns (Score:5, Insightful)
Yet we keep playing the buzzword bingo with our new systems, e.g. "Extreme programming", we still keep promise a schedule we can't keep to, we still allow the customer to shift requirement much later in the project than should be allowed, management still don't have enough dialog with the programmers on the ground floor, the list goes on..
Wake up! We're not special.. the construction industry has been doing huge projects of equal complexity for centuries. Get past your intellectual snobbery and start working together..
Simon.
Ratio of Intelligence to Project Complexity (Score:5, Insightful)
I've done a lot of thinking about this...I've come to the conclusion that too often, management tries to replace good ol' fashioned thinking with process. It doesn't work. People tend to get focused in on what they're doing to the exclusion of all else, and that means the smart people are cubbyholed and only have half the story and can't see where other parts of the project are failing, and dumb people have free reign over their little part.
If the ratio of intelligence to complexity is too low, then the project will fail no matter what process is in place or who is managing it. That's all there is to it. There's a lot of cool stuff out there to be done in development...sadly, most of the good ideas will never make it because the people working on them don't use common sense and best practices...they're just not smart enough to see what's important and what isn't.
This isn't one of those self-important diatribes from a holier-than-thou developer, either...true I'm a developer, but I admit when I'm too dumb to handle the particulars of a project; usually, that means the project is too complex for most people, but they press on anyway. Those projects always go down in flames eventually.
You have to know what the strenghs and weaknesses of your team and its members are, and exploit those to the fullest. Maybe, then, you can barely accomplish a project if the goal of that project is simple enough.
Blame the P.M. - usually (Score:5, Insightful)
We've had people who didn't know how to accurately scope business requirements, get buy in from other departments and generally "play nice" enough to keep everything running smoothly. Your P.M. needs to be able to be a hard ass, but also to be a buddy.
It boils down to excellent management skills and excellent people skills and without both you're setting a project up for disaster. A good P.M. needs to know when to tell senior management it's asking for the impossible too, and a good P.M. needs to know he has kung-fu so he can get away will telling senior management their idea won't be implemented.
Re:Project Management Authority (Score:2, Insightful)
This cannot be emphasized enough. The project manager needs to not only manage the people within your company and what work they're doing on the project, but also the customer and the customer's expectations.
Skill sets for Project Management (Score:5, Insightful)
It's not to say that a good designer or developer cannot be a good project manager; it's just a different job, like asking a plumber to rewire your house.
Re:So... (Score:3, Insightful)
Correct, but there is more (Score:5, Insightful)
i have been part of a project (past tense) where:
- management delivered a much too low cost estimate in order to get win the bid.
- management then expected the project manager and team to meet the deadlines that were doomed in advance.
- the software design lead designed a behemoth of a framework full of performance and design issues.
- management did not understand that if you have unexplained system behavior, you cannot say when you will have solved the problem.
- hardware design was not reviewed, just like software design. this lead to huge problems just before and during acceptance.
-near the end of the project, more and more people were reassigned to a new project that has the ability to make the department manager look good to the head office. he wants to move up. In effect, succes of the former project became a more and more distant possibility until failure was assured.
and there are probably some other things that i either forgot or purposly left out (trying to repress memories maybe
Re:here's a mirror. (Score:2, Insightful)
Anyway, since I can't read the story, I'll just blather on about conditions here where I work... the #1 cause of failed software projects is poor client management. We all know that the client doesn't know jack about making software... if they did, they wouldn't need to hire us. Yet when the client contradicts themself, the opportune moment to flash that consulting brilliance and prove why we cost so much is immediate. It would be so easy to say "what you've just asked for is impossible because it conflicts with this other thing you asked for". Yet from a marketing perspective, that's bad for business. Why? Because our company's goal is to maximize profit, not to maximize software quality. Believe it or not, we often get contract modifications to fix those very problems we could have circumvented because the developers foresaw them coming. Essentially, we get paid to build the same system twice. How's that for consulting brilliance!
Re:Projects fails because no one ever learns (Score:2, Insightful)
Re:Aggressive scheduling (Score:1, Insightful)
It always comes down to people (Score:4, Insightful)
These guys break down the problems into useful categories, which will be helpful for good teams who want to know how to be more efficient. But for my money a group of serious, decidated people who honestly want to get the job done and do it well will usually get there, barring external factors beyond their control messing it up. It might take a while, cost $$, etc. but they'll make it, because they WANT to.
Many (I would even say most) successful open source projects succeed because they have one or several individuals willing to put the work in to make something happen. The tools they use or the way they work are less important than determination to get it done and do it well. Those without that wither on the vine.
In theory, commercial companies and development teams should be motivated by the $$ they are paid, but that doesn't always translate into doing the job well. There are PHBs, lazy workers, unreasonable customers, and all the other joys of life out there. There is no magical "business formula" which can transmute this combination into a good product.
Don't get me wrong, project management and efficiency techniques are a very good thing, but only when you've got the people to make good use of them.
Do you have evidence of this? (Score:4, Insightful)
I have lots of evidence of failed projects due to failure to plan.
It can take months or years of thought and discussion to reasonably avoid extreme catastrophies.
While it is silly to try to plan every detail and anyone who claims to do so is lying, a simple elegant, successful general approach is seldom the first one to pop into the head. It takes a lot of thought. Of course, for those incapable of such forethought, why not fail earlier rather than later.
Smart People (Score:2, Insightful)
Good process is independent of the intelligence of the humans implementing the process.
Good process amplifies the effectiveness of all participants.
Good process generates tracking data that can be used in negotiations between development (reality) and management (theory).
Construction Analogy Fundamentally Incorrect (Score:3, Insightful)
I utterly agree (Score:3, Insightful)
This is the real tragedy of Sarbanes-Oxley. It is being used as a trump card for every process flunky that comes down the pike to implement their favorite process to the fullest. This is going to have a real and very unfortunate effect on companies that become too infected with process to move.
Re:A classic one for me (Score:5, Insightful)
Aaaah, that one is subject to the 95% rule:
The first 95% of the project takes 95% of the time, and the remaining 5% takes the other 95% of the time"
(loosely quoted from some fortune)
Re:Project Management Authority (Score:4, Insightful)
My experience shows this to be quite valid sometimes regardless of how much project control you attempt - a classic scenario goes like this:
1) The customer is invited to a 'proof of concept' or 'milestone' demo of the proposed system
2) The customer requests new features or amendments to original spec
3) The new features are subjected to a cost/benefit analysis by both parties
4) Customer wants the changes and so the contract clause relating to 'additional or amended requirements' kicks in and a new pricing structure is drawn up.
5) Customer complains that they are being 'forced into a corner' with the new charges - they want everything completed but aren't willing to pay the extra but feel that if they don't agree you'll walk away from the project
6) Developers have to decide whether to make the amendments within existing budget, even though it's additional workload, or insist that the customer covers some or (hopefully) all of the charges.
7) Customer complains and says they won't pay - OR they agree, but you just know that at the end of the contract you'll get a serious amount of grief trying to extract the full and fair cost of the work from the customer.
8) Customer pulls plug and takes your proposal elsewhere for someone else to work on, or you decide to cut your losses and jump ship anyway.
Too much PM and not enough sales involvement (Score:1, Insightful)
All too often the PM is some MBA who couldn't keep his job during the .com downturn, and now makes "specs" out of a vacuum, or worse, textbooks from experts; without understanding the customers needs.
At least when the sales guy sold a feature, you know that it's important to the customer.
neanderthal project management methodologies (Score:3, Insightful)
Of course, they hate requirements changes. And of course, their initial requirements are usually wrong - and fail to meet the need.
The answer isn't to stop changes - but to use methods that aren't so vulnerable to impact of change - like patterns, agile methods, passionate & highly skilled staff, etc, etc.
Re:Do you have evidence of this? (Score:1, Insightful)
I've seen companies burn $15 million in "stealth mode" waiting to perfect their product, while competors with "inferior crap" take the whole market.
Unrealistic expectations (Score:3, Insightful)
We expected a web based desktop client wouldn't require configuration; a jinitiator component required numerous desktop visits.
We expected streamlined operation; In fact the replacement product required more end user data entry and provided less critical information ( i.e. fewer metrics the end users have come to expect).
Management drank the marketroids cool aid. They should have asked the end users to evaluate the software before commiting to a purchase, rather than shoehorning the end users into accepting what was the cheapest.
Re:Projects fails because no one ever learns (Score:4, Insightful)
Ok, there is a lot of truth there, but to dismiss the analogy out of hand is to miss some very important lessons. My dad manages large-scale construction projects so I know a little bit about the industry.
Some lessons that may relate
1. The team that designs a project is always different from the team that constructs the project. They are seldom even from the same company. The client gets to arbitrate between the two when conflicts come up.
2. Many projects are extensively estimated after design, but before construction by the constructor (who has much more experience and motivation to accurately assess project costs then the designing company).
3. Design firms, and construction firms often specialize in very specific types of buildings (i.e. one company may construct only clean-room facilities, another company designs only bridges, etc.). When companies take on specialized projects that they have no institutional experience with, they often fail spectacularly.
4. The designing company divides the project design documents into known specialties. Metalwork, brickwork, glasswork, electrical work, etc. There are hundreds of catagories, and the design documents break out the project into those standard catagories. When the construction company builds the project, they hire subcontractors to perform work in each specialty. The company that does the glasswork has lots of experience with glasswork. The company doing roofing has lots of experience with roofing, etc.
5. Changing the design in mid-construction (which always happens) cost big bucks. No exceptions.
There are more, but I'm bored with this post so I'll stop now.
Slips at the beginning of the schedule never count (Score:3, Insightful)
So I worked on a project that spent 8 months getting through "project approval" on an 18 month scedule. Of course by the time it was approved, they still wanted it to be delivered in 18 months (from the start date) so we now had 10 months on an 18 month schedule.
Long story short - we delivered in 13 months, and were blamed for being late... Nothing like marketting and management not taking any blame for taking 8 months to approve the beginning of the project
Re:Project Management Authority (Score:5, Insightful)
In case you can't tell, I'm in the process of reviewing just such a spec from our legal department right now. Specs written by lawyers are pretty but wordy without really saying what exactly they want...
Re:here's a mirror. (Score:3, Insightful)
What planet are you from? If you tell the customer it can't be done for this that and the other reason, you're more likely to get canned as they move on to another consulting firm that can get the job done.
Even in this day and age, most people see software as a magical phenomenon that can do anything provided the magician is powerful enough. Telling them "no" means you're but a lowly apprentice.
Re:I'll RTFA in my next comment but first... (Score:1, Insightful)
The risk based spiral I read about in Rapid Development many years ago has done the job for me (I rarely deliver late). Any changing requirements come in a later version and after an early version is available the customer has a lot more focus on what they actually want (because its an impossible task for them to know before development begins).
Risk based spiral also catches gotcha operational problems early on and forces me to be more formal with the release/unittests. It also keeps the customer onside since they see the project evolving. Any changes are fine and are all part of the process. Although this is only for small projects and YMMV as ever.
Re:Project Management Authority (Score:3, Insightful)
One where real requirements analysis yields the top ten most valuable and requested queries + report templates. This can be handed off to a designer who creates an efficient and highly usable interface.
The second spec is for a generic ad-hoc query and reporting mechanism. Since the need is so very generic and so very unpredictable, prudent analysis concludes that a buy solution would be more practical than a build solution. Therefore, buy a generic reporting solution like Crystal Reports to meet the generic needs of the generic spec.
Finally, create separate cost, development and user feedback tracking for the two reporting subsystems. Review at 3-month intervals.
The winner will be clear sooner rather than later.
Re:Projects fails because no one ever learns (Score:3, Insightful)
Hang on! The whole point of XP is about the fact that customers change their mind and developers never get it completely perfect in the first draft. XP promises a schedule based on the last one or three week iteration so it inherently remains accurate over time.
I've been doing XP properly for about 5 years and it's one of the reasons the company i work for has survived. Massive code changes have been neccessary as we've pretty much changed the product into an entirely different one that is now profitable with the aid of an agile process and tools + those 1500 unit tests.
Please don't blame XP just because it doesn't fix mega-death-march projects overnight or because it's a buzzword used by people who have never even written a unit test let alone pair programmed.
Not a good study: Too much "after the fact" reason (Score:2, Insightful)
Use of an inappropriate methodology: Had they used a different methodology, they might have simply stumbled on different "gotcha's".
Lack of formal project management practices: This reason means they know a number of issues got out of control. They do not know how much more those issues would have been controlled, nor how much additional control might have slowed progress.
In addition, the "Requirements volatility" category begs a big question: requirements DO change over time; how is this category different from "Lack of formal project management practices" that would have planned for requirements changes?
It is interesting that "Project complexity" falls low on this list, because it is the most clearly proven reason why project plans fail. See this website for a fairly formal proof that project complexity cannot be estimated in advance: http://www.idiom.com/~zilla/Work/Softestim/kcsest
This proof has been discussed at slashdot here: http://developers.slashdot.org/article.pl?sid=02/
Lot's and lot's of project failures (Score:4, Insightful)
I'm working for a large Telco doing roughly 80-120 IT projects every calendar year worth about $200M. Most of them get through in one way or another, but some fail spetacularly and all of them have ridiculous overheads, delays and frustrations.
Best example of a crash-and-burn is a transaction engine designed to process a simple text file from another company. Should have been 6 months/$500K, project actually folded at 2 years / $3M and now we're going round for a second bite at the cherry (but with a new project name!!!).
Why do they fail ? Lot's of reasons.
Sometimes the user's requirements are unclear. Sometimes we're using the wrong spanner for the job. Sometimes the team loses the plot and we get a jumbo jet when we wanted a paper air plane. And we're always under pressure on time, but that's business - if we don't get there first someone else will.
What's the root cause?
Complexity. We let our systems get too complex and now a two line code change can cost >$500K because the down stream effects will hit ten other systems that generate $1M/day of revenue.
The moral - KISS. Use the simplest solution for the job. Don't let the sales guy run away with it, don't let your geek-ego run away with it, don't let the user's get over excited and your project might just come in on time on budget. As someone else said... it isn't rocket science... or shouldn't be...
After I RTFAed... (Score:5, Insightful)
Tiwana and Keil were asking MIS directors what *they* thought, not project managers or developers, leading me to believe that this is more based on client perception than someone with experience working on said projects.
That said, they ranked changing requirements last when talking about risk of failure, and actually said that inappropriate methodology was the top reason of project failure.
Now, while a lack of any sort of methodology is a disaster waiting to happen, I have a difficult time believing that a bad fit for a project creates more risk than project complexity and shifting requirements combined, as they suggest.
*sigh*
Do you really believe that a client is going to place shifting requirements as a risk? After all, they're the ones asking for the changes!
Re:Project Management Authority (Score:3, Insightful)
Using a integrated/seperate application is often not an option. Crystal Reports will often cost more time creating custom reports than just building a tool yourself. I always lie to clients and say "I don't know how to do Crystal Reports" despite doing many more than I would like to remember. Crystal Reports often require a lot of time to do outside a simple report especially when you get into nested reports and such.
Re:Project Management Authority (Score:1, Insightful)
"The project manager is ultimately responsible for the success or failure of the project."
Simply put, a project manager is responsible for managing everything from budget to quality to scope changes to communication to record keeping and personnel. If the project fails it is because the project manager did not step up to the duty of changing whatever needed to be changed in order to get the project done. And, yes, I'm a full time professional project manager and have been for the last 15 years. Project management isn't for everyone. It's not easy, it's not an extension of being a coder or network engineer (though I was both in former lives), it's an entirely different discipline.
Re:Project Management Authority (Score:5, Insightful)
I remember reading an article by Joel Spolsky where he advised to deliberately make the UI for demos less than polished. Make it look like something that was knocked together. Make it too pretty and the client will think you're almost done. After all, to the client, the UI is the app. If that looks done, the guts of the thing must be near done as well.
Correct (Score:3, Insightful)
> process
That's because that's what they teach in business schools. Businesses are about repeatability and consistency. It's good if you can make a cup of coffee. It's great if you can sell a cup of coffee for more than it cost you to make it. If you can make a good cup of coffee and sell it profitably one million times, you have a healthy, sustainable business. Obviously, the third action requires a process.
That's why sometimes people make a distinction between management and leadership. Management is about incremental cost reductions and process improvement. Leadership is about changing directions and determining new courses of strategy.
The problem is managers often confuse themselves for leaders and leaders confuse themselves for managers. That's why many start-ups fail: the person who started it had great leadership skills (coming up with a new idea for a product), but poor management skills (taking that product and building a sustainable business out of it).
Management is always looking for a process. The problem is creative people can feel stifled by the process and poor performers can hide behind it. A good idea is to have a mixture of people (managers and leaders) in different roles so you have elements of strategy combined with repeatability. Obviously to do that you have to have effective teamwork and people that can get along with each other. I think the relative scarcity of all those elements (managers, leaders, teamwork) is the reason why failure is so common.
Re:It's not magical (Score:1, Insightful)
Yeah a good old liberal education. That's the ticket!
Then there'll be no need for stringent project requirements. Your design committe can concentrate on making sure the user interface is esthetically pleasing, non-offensive, accessible to the visually challenged, the mentally challenged and all other differently-abled beings regardless of their gender and sexual preferences, culturally neutral, politically correct in all ways, environmentally friendly and completely sanctioned by the UN and Amnesty International and Greenpeace.
Re:Projects fails because no one ever learns (Score:3, Insightful)
Even if you do build it yourself unless you are a complete moron or a glution for punishment you will standard sized windows, doors, electric outlets plumbing fixtures... and so on.
And it may not be possilbe to build what ever you want. In many contries they are very very strick about building codes. In many places in the US you have all sorts of rules.
Re:Projects fails because no one ever learns (Score:1, Insightful)
Thanks for trivializing a large part of our economy. Think about all the details in contruction, down to interior design, financing, legal compliance; do you still think it is less complex than software? The main difference between construction and software is that people don't have much of a problem mortgaging a house, but no one I know would want to take out a mortgage for software! Yet, a software system can cost more than an entire office building! People just have not come to terms with the true cost of what they want. People who would gladly pass up granite counter tops and stainless steel refrigerators still demand all the latest codecs on their new Best Buy wonder machine.
Re:After I RTFAed... (Score:3, Insightful)
Now, the researchers seem to account for that in "lack of customer involvement." However, where is "We just assumed it would do that!" placed? It touches complexity, requirements volitility, and customer involvement.
It also depends on how you define failure. Does an extra six months added to the project count as failure because it wasn't on time due to changing requirements? Or is a project that shifted focus mid-project a success even though the timescale changed?
Mmm. (Score:3, Insightful)
First, a survey based on data "as reported by development project managers" is suspect to a high degree. Obviously their view will differ from that of the senior manager and from the actual developer. SO I will put little stock in that survey.
But the question is valid: why does it always fail?
Personally, I see a mixture of the following:
I am not ranking them in importance, will leave that to others!
Mike
Re:Traceability (Score:3, Insightful)
It may also be that the market is not completely understood and, as such, neither is the solution. If you can say you completely understand any market, you are a better man than I. Or maybe you have the luxury of ignoring your market.
Bottom line, I believe that there is a certain amount of understanding beyond which trying to understand the problem further is wasted effort. This point is reached far before the amount of uncertainty or "lack of understanding" reaches zero. It happens even sooner in rapidly shifting knowledge domains or markets. Unfortunately, that's also where the most profitable use of software lies.
The Construction Analogy is Broken (Score:3, Insightful)
Small teams with a strong vision (Score:1, Insightful)
Re:Correct, but there is more (Score:3, Insightful)
Particularly the "framework" bit - this sort of thing is a particular pet hate of mine. Why do people do this kind of thing continually when it almost never works? Why not just solve the direct problem instead? I have seen it over and over again. People seem to miss the obvious point that solving the class of problem is always going to be an order of magnitude (at least) more difficult that solving an instance of the problem - and you need an appropriately large budget to do it. The final nail in the coffin for the "let's build a framework while we're at it" lunacy is that the "framework" often ends up providing a solution to something that didn't even need doing in the first place - it's just something someone thought might be useful early on. I can't count the number of times we've ripped the bloated, buggy, badly designed, unusable "framework" out of a system and it's then become reliable, simpler, smaller, more efficient, and more extensible and flexible (those two points are often the reasoning for the "framework" in the first place, so it's ironic how that works out).
Sigh. "Frameworks" - it's my anti-pattern of the year. Or maybe decade, or even career. That's not to say it can't be done, it can of course, but only with lots of time, money, careful thought, planning and exactly the right people - certainly not as an off-hand skunkworks inside some other project with no clear purpose or direct problem to solve.
10 year old article (Score:1, Insightful)
Re:Projects fails because no one ever learns (Score:3, Insightful)
In fact most of the XPers I know are also interested in other Agile processes.