|
Seems like it...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
but that won't stop them.
|
|
|
|
|
The reasons why deadlines fail are usually lack of consultation and preconceived ideas. In these cases the customer (internal or external, it doesn't matter) has a vague idea about how something might work and the implementor has a fixed idea about how it should work. In cases where there's no ongoing consultation (discussing project plans, resource plans, design, implementation and deployment details as well as commissioning plans and remedy), the project will fail.
|
|
|
|
|
I had (have?) a project which was "only" a month late due to the client not having time to review it. It is, if you base your timing on a go-live release date, now eight months late.
But wait - didn't I say I was one month late?
Here's the cause: it can not be tested/installed on any system without the explicit OK of the IT director - who quite simply ignored several requests to these ends. So, it calmly sits on my system. As he is 'the director', the upper management (that requested the application) do not want to trump his decision-making, as it could set a bad precident.
(For those of you who are about to ask the question: yes - it is some weird personal vendetta he has with me - and mgmt acknowledge his lack of people-skills). I've been given the consolation that I'm not the only one who'd not mourn his passing . . .
Anyone else have something as weird as this?
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
Ditto here, with the added bonus that the ‘director’ is an ex business partner of mine. 
|
|
|
|
|
My manager talk to the customers, and when I get into some decisionmaking during coding, and have to call the client, I often get a very different version of how the software is meant to work, be it desktop or web-apps.
My billinghours is quickly raising because of this, and I end up with pissed off clients, who think I am a bad coder.
The upside is that when I explain the specs to the client, and why this and that have happened, I redirect the support / upscale / whatever to me personally, and things are back on the rails...
Then the clients are happy, and many clients have started to ask for products made by me, and no one else. This alone generated a 100 000 $ profit for my company, and when I leave the company, the clients still have my cell-number.
Keep up the good work and leave 'em dead!
Balboos HaGadol rule!!
|
|
|
|
|
I follow this Scotty (Star Trek) advice when it comes to make up a schedule.
That is to keep marketing expectations as low as possible, and buy time to let developers’ over deliver.
More seriously, the reality of the majority of software driven company is to build up expectations as high as possible to beat competition, and over course to deliver yesterday as the market window is fading quickly.
The Market and creativity factor plays a large role in software development, and that turns projected estimates behaves closer to random statistics. It is just plain normal that the software specs change, as the developer is always selling a feature that does not exist yet.
|
|
|
|
|
The problem is that they may not.
|
|
|
|
|
And the solution is that they may not get 
|
|
|
|
|
Projects continue to fail for all of the reasons cited; many of the project failures the result of a combination of such reasons.
However, the most predominant cause of all project failure comes down to mismanagement by technical managers. Technical managers on the whole are too much in a rush to do too much simply to meet the expectations of non-IT management. Instead of learning the skills required to properly negotiate with non-IT personnel so that proper resources, personnel, and time are appropriated to each project specifically, such managers tend to lump all such work into a continuous blur of enhancements and updates which practically always results in messy systems that over time become impossible to maintain and thus cost excessive amounts of monies to rewrite or upgrade substantially.
Of course, none of this is ever the fault of such managers and the result is a massive increase in stress on technical personnel which leads to its own set of project development issues...
Steve Naidamast
Black Falcon Software, Inc.
blackfalconsoftware@ix.netcom.com
|
|
|
|
|
I worked with two very different teams at my company. At one team, you have to get code done two months before release date, at the other, you get change request two days before release date. One thing in common is, developers start doing the work too late (they are not allowed to start early even if they know what need to be done). Here are the things I find that adversely affect development work:
1. Management waisting too much time making a decision (to do or not to do).
2. Project managers waisting too much time on things that don't really matter.
3. Developers get used to (familiar with) the "processes", they can safely do one day's work in three days without any consequence.
|
|
|
|
|
Mostly I agree. I am working on a project at the moment that is about 1 year behind schedule after running for about 18 months. Our bit is fine and sorted and ready to deliver, but the rest of the project team is way off target and still revising specs and arguing about feature creep.
We knew after 2 months on the project what we were going to deliver to the customer, but were not allowed to even start design work for months, and development was delayed even longer. In reality, what we have implemented has probably changed only by maybe 5% from what we thought at the end of the second month of the project. We really did waste maybe 6 months arguing over pointless trivia and revising the spec. The reason was simply down to people trying to specify the project in too much detail when the whole business process was still not understood. The only way to cut this Gordian knot was to quietly and unofficially develop a prototype system which helped people to crystalise their otherwise very fluid ideas. At the time of writing people on the rest of the project are still arguing about which controls go where on which screens in the UI...
|
|
|
|
|
Incomplete/missing specs leads to all of this. Incomplete/missing specs are part of the problem with changing specs since nobody can analyze the impact of the change or the spec wasn't sufficiently well thought out and thus requires a change. A lack of understanding as to the scale of the work is the result of poor specs (and proper research of technologies planned to be used) and of course results in underfunded projects--insufficient budget/resources. If the deadline is decided by marketing, well, so what. Scope the project to meet the deadline. R&D rarely sets deadlines, what they do is spec in so much feature creep nobody would accept their deadline. In either case, it comes down yet again to people agreeing to the specs when dealing with the reality of time, budget, and resource constraints. Same with asking developers how long it'll take--again, the better you spec, the more accurate developers will be, and hence their judgement will be useful. However, developers are notorious for underestimating development time. It'd be better to use some standard of measure, based on the number of tables, the number of UI's, the number of business rules, etc., and fine tune that process as you go through different projects. But alas, that requires specs! And if there are proper specs resulting in a proper timeline, it would be obvious as to the impact of an interruption. As to plain old bad estimates, well, don't estimate! Know!
It all comes down to better specs. Even when specs change (and they do, obviously), having better specs at the start lets you understand better the impact of the change, which lets you negotiate time/cost, remain profitable, and more often than not, figure out a solution that doesn't affect the overall project--in fact, it may result in a better product.
Marc
|
|
|
|
|
While better specs might appear to be the solution, in my case it wouldn't work. We routinely produce detailed specifications that describe work to be done. Our specs call out, line for line, each item mentioned in the requirements document from Marketing. We explain how the functionality we are implementing supports each requirement. Sounds ideal, doesn't it?
The trouble starts when you distribute the document.
At the review meeting to discuss the document, you find out most of the participants haven't read it. You'll hear the term "techno-babble" used, even though the document is conscientously written with as little technical jargon as possible. At least one major requirement, not mentioned in the original requirements spec, will come out of the review. It will be brought forth, hot and steaming, by a P.H.B. three or four steps up from you in the food chain. There will be no choice of not implementing the new requirement, even if it breaks existing functionality or architecture.
In the meantime, you've been busy developing the new feature. You can't wait to get started until after the review process is completed. If you do, you have no hope whatsoever of meeting the schedule, which was determined by people who have no clue or stake in the work itself.
The one pathetic hope you have is that most of the work you do applies somehow to what the customer really needed.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: you find out most of the participants haven't read it
Yeah, but that's problem with the process, not the spec. Something about "come to the meeting prepared", right?
I guess like anything, if you work with idiots you can do nothing about it. So yes, specs requires that people aren't idiots.
Feel free to use my response as fodder for an anonymous email sent to those idiots. They are clearly not using the spec as it is intended to be used.
Marc
|
|
|
|
|
Gary Wheeler wrote: At least one major requirement, not mentioned in the original requirements spec, will come out of the review.
Which is why specs are so important, and reviewing them even more so.
And THEN, after the specs are accepted, a time line is produced.
Unfortunately, marketers and P.H.B's remember the first time estimate that is produced, and hang on to that one. "But I already committed to the customer" is a common excuse, like somehow that is our problem.
Gary
|
|
|
|
|
I think in most cases discussed above, the scope and budget are defined well before any estimates and budgeting, and specs, etc. There is a customer that wants "this", and the resources ( = money ) are what they are. After that, everyone tries to squeeze in the 3 year work into 1 1/2 years.
It's a risk taking from everyone in the chain, kind of "fingers crossed" attitude.
|
|
|
|
|
There is a development process that claims to solve these problems: Agile Manifesto[^]. An iterative process does seems to fit with the normal evolution of software. The challenges are the same no matter what the process though -- buy in and commitment by all stake holders.
|
|
|
|
|
Robert Nadler wrote: There is a development process that claims to solve these problems: Agile Manifesto[^].
I humbly disagree. Agile development is steeped in refactoring which itself is used as an excuse (if I may use that word) for [edit] not [/edit] writing specs up front. Otherwise, Agile is great.
Marc
|
|
|
|
|
Marc Clifton wrote: for [not] writing specs up front.
No argument here. We do some "Agile-like" iterations early in a project, but I work in a highly regulated environment (FDA) which has a V&V process that forces a BDUF[^]. I guess the grass always appears greener on the other side.
|
|
|
|
|
I think this question is one of those that demands something like "Choose all that apply".
As the question is "What's the main reason" I believe it's a lack of a full & deep book of specifications. From this we get all sort of problems... nothing good can be expected from a bad specification 
|
|
|
|
|
I agree, incomplete specifications are often the main problem.
|
|
|
|
|
AlexCode wrote: I believe it's a lack of a full & deep book of specifications.
Bu how could we set up the specs if neither we programmers nor the customers have more than a general idea about what to produce.
R&D is the very process of getting this idea!
So, a full, detailed spec is pure poison! What is needed is a highly iterativem flexible, lightweight process. Probably involving prototypes destined to be scrapped.
During the time the full, in-depth-spec is grunted out by the concerned several comitees (involving any number of high, medium and low managers), one could have prototyped the relevant parts, decided the set of features and maybe started the real design.
To me it seems as if programmers crying for specs are crying for help, desperatly fighting their management process.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
jhwurmbach wrote: Bu how could we set up the specs if neither we programmers nor the customers have more than a general idea about what to produce.
R&D is the very process of getting this idea!
So, jh, you're saying it's okay to give a deadline when no one knows what needs to be done? Let the design changes begin!
NO ONE should be quoting times on a project defined with just "a general idea about what to produce."
If design-by-prototype is the methodology, then payment and time for the prototype development should be in the cost and paid up-front, and only after development, sign-off and payment for the prototype is a final price and time estimate produced.
A full, detailed spec defines the requirements, leading to a decent estimate of the development effort, and therefore time and costs, leading to a decent quote. The spec also defines when you're done, or at least a reasonable facsimile of it.
"Programmers crying for specs" are like builders looking for architectural drawings - let me prototype your house, give me a sign-off, then we'll start for real.
Or manufacturers looking for a sale estimates - I'll build a gazillion Edsel's, see if you can sell them.
Or better yet, a surgeon wanting for a diagnosis - let me take out your kidney, and if it doesn't help, I'll take out the other one, then maybe the spleen, then a little lypo on the tummy, remove a few brain cells,...
Don't worry, we'll get something you like as long as your cash holds out.
Gary
|
|
|
|
|
ghle wrote: So, jh, you're saying it's okay to give a deadline when no one knows what needs to be done?
Well - it depends 
But in principle, there is always the Triangel consisting of resources, features, and time.
Pick the two you want to keep fixed.
Normaly, when the deadline is really fixed (e.g. the underlying hardware is already in production), then the features will be clipped.
ghle wrote: let me prototype your house, give me a sign-off, then we'll start for real.
You did not ever work with an architect to build your house, right?
Because looking at prototypes is the one methodology by which an architect(-company) sells ist products.
You get to look at a whole lot of houses to see the architectural details you wwant to have included.
Precise because you, the customer, can not possibly make all the relevant decisions up-front in an informed manner.
ghle wrote: Or better yet, a surgeon wanting for a diagnosis -
I dont know what "Schnellschnitt" is in english, but I describe you the procedure when prostate cancer is to be removed:
The prostrate is cut out, as are the firse level of lymphatic knots sitting "downstream".
Then a pathologist is cutting it for microscopy, determinig if the cancer penetrated the outer capsule of the prostrate and whether there are signs for cancer in the lymph-nodes.
If both are negative, the surgeons close the wound.
If any one is positive, another layer of lymphatic nodes is inspected.
If these are also positive, metastasis can not be ruled out and the wound is closed, but the pationt will get chemotherapy.
ghle wrote: A full, detailed spec defines the requirements, leading to a decent estimate of the development effort,
In the business where I am working, we are building measureing-machines with a evaluation software.
Thats probably different from the n+1th business-logic.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
