[CDJSalesPro]

Last week, Allpar reported that Jeep had pushed back the production date of the 2014 Jeep Cherokee from mid-March to mid-to-late-June 2013. Trusted insiders have now confirmed the report, credited to Allpar forum member “longtimeJeep.” The delay will probably allow Land Rover to claim the world’s first use of a nine-speed automatic transmission in a light-duty vehicle. Both vehicles use the ZF transmission; the Jeep version uses a power take-off unit to provide a true low-gear four wheel drive system, at least on the Trail Rated model (which we believe will be called Trailhawk, in line with the most off-road-ready Jeep Grand Cherokee.) The change is not surprising given the extensive renovations at Toledo North, the new nine-speed automatic, the new 3.2 liter V6 engine, and even the new four wheel drive system. The delay might also have been caused by suppliers, who have, in recent years, often found it..

View the original, full post

I am pretty sure the "mid March is a typo...the original launch was for May.....which means the delay is only 1month instead of 2.

 

[Mr.Source]

The front end is starting to grow on me, and I know this is happening to many more.

 

[Mopar392]

The front end is starting to grow on me, and I know this is happening to many more.

Actually the more I look at it, the more I like it and think about it as a good choice if I ever wanted an SUV of that size..

 

[TripleT]

Actually the more I look at it, the more I like it and think about it as a good choice if I ever wanted an SUV of that size..

Can remember how shocked I was with the look of Ram now I cannot imagine it looking anyway else.

 

[GasAxe]

Just to be fair, every post of "I luvz the nu Cherokee" is just as off topic as "Kill it with fire", unless we are open for both.

As far as the delay, I'm getting concerned how the new models seem to keep being delayed. Getting things right is paramount, so wouldn't it be better to announce a date further out then having the new models arrive a bit early if all goes well?

 

[Mopar392]

Just to be fair, every post of "I luvz the nu Cherokee" is just as off topic as "Kill it with fire", unless we are open for both.

As far as the delay, I'm getting concerned how the new models seem to keep being delayed. Getting things right is paramount, so wouldn't it be better to announce a date further out then having the new models arrive a bit early if all goes well?

Most likely the guys in the marketing put out the dates, but then the engineers and factories find out that these dates can't be met either the testing isn't finished yet or the material isn't ready..

 

[TripleT]

New Engine, New Transmission, the 2.4 Tigershark still hasn't seen the light of day. New Assembly line there a few more News .... delays seems understanding the DART GT still isn't out.

 

[mentalicca]

Most likely the guys in the marketing put out the dates, but then the engineers and factories find out that these dates can't be met either the testing isn't finished yet or the material isn't ready..

It seems to be a growing trend (especially in the software industry, which is where I am) that either A. a deadline and features are set before the engineers ever have a say-so on the plausibility, constraints, and alternate ideas, in which case corners get cut (and usually come back to bite you sooner than you would hope), the release is late, or it is cancelled after too much has been invested and a huge loss of time and money has occurred. Or B. The project continues to grow and change scope that it is nothing like the original intent and you are left with something that is basically a compromise that no one really wants or needs and ends up being no better than the previous work-around/solution.

 

[abgwin]

It seems to be a growing trend (especially in the software industry, which is where I am) that either A. a deadline and features are set before the engineers ever have a say-so on the plausibility, constraints, and alternate ideas, in which case corners get cut (and usually come back to bite you sooner than you would hope), the release is late, or it is cancelled after too much has been invested and a huge loss of time and money has occurred. Or B. The project continues to grow and change scope that it is nothing like the original intent and you are left with something that is basically a compromise that no one really wants or needs and ends up being no better than the previous work-around/solution.

As a fellow member of the software industry, I see it somewhat differently. Plans call for specified periods of coding, testing, customer acceptance, and general release. Changes in any of these periods result in pushing the final release date; it's all interdependent. That doesn't mean that one failed QA test or additional requirement immediately requires a release date change; it makes more sense to wait until all changes are wrapped into the final build, especially since sometimes the gap is made up and you meet the date anyway.
So you wait till it's absolutely necessary to announce a date push, usually very close to that original release date.

Plans are made based on the best available information but things change, sometimes daily. It's all too easy to read far too much in a simple date push.

Sometimes a cigar is just a cigar.

 

[TripleT]

It seems to be a growing trend (especially in the software industry, which is where I am) that either A. a deadline and features are set before the engineers ever have a say-so on the plausibility, constraints, and alternate ideas, in which case corners get cut (and usually come back to bite you sooner than you would hope), the release is late, or it is cancelled after too much has been invested and a huge loss of time and money has occurred. Or B. The project continues to grow and change scope that it is nothing like the original intent and you are left with something that is basically a compromise that no one really wants or needs and ends up being no better than the previous work-around/solution.

Ahhhh yes the old project creep, when up stream decisions are made yet the schedule and costs are to remain un-impacted. been there before.

But on a project this complex it only takes a few critical path items to be pushed back to impact the schedule by a month or two.

 

[digitalrailroader]

at least the Headlights and the Turn Signals/Parking Lights aren't MILES Apart on the front end like they are on the Nissan Juke, THAT is what made/makes the Juke Ugly; The Cherokee on the Other Hand, looks one styling Refresh away from having Traditional Headlight Assemblies. of course, we can't really draw conclusions about the Cherokee's Features/Styling/Reliability until its on sale, and been in the hands of Real Consumers and Unbiased Automotive Journalists.

 

[Stratuscaster]

As a fellow member of the software industry, I see it somewhat differently. Plans call for specified periods of coding, testing, customer acceptance, and general release. Changes in any of these periods result in pushing the final release date; it's all interdependent. That doesn't mean that one failed QA test or additional requirement immediately requires a release date change; it makes more sense to wait until all changes are wrapped into the final build, especially since sometimes the gap is made up and you meet the date anyway.
So you wait till it's absolutely necessary to announce a date push, usually very close to that original release date.

Unless you are a game developer for a major publisher, in which case you button it up as it sits and then release patches to fix what you couldn't get to, and then release features not ready but intended for the game as DLC.

(Not saying abgwin has done that. Just saying - it's a trend in that particular line of business.)

We have clients where I work that want 'x' number of systems configured and delivered by 'y' date. Then they make changes to the plan. Then vendors have difficulty providing product. Ultimately my group ends up with a day and a half to perform the work we had previously agreed to perform in 5 days. Everything is flexible except for the client's due date. (Until it's not.)

 

[mentalicca]

As a fellow member of the software industry, I see it somewhat differently. Plans call for specified periods of coding, testing, customer acceptance, and general release. Changes in any of these periods result in pushing the final release date; it's all interdependent. That doesn't mean that one failed QA test or additional requirement immediately requires a release date change; it makes more sense to wait until all changes are wrapped into the final build, especially since sometimes the gap is made up and you meet the date anyway.
So you wait till it's absolutely necessary to announce a date push, usually very close to that original release date.

That scenario isn't the one I was referring to. That being said I agree with what you said. The issue that I was referring to was someone outside of the development team (be it a client or the sales/marketing team, etc.) setting up specifications AND deadlines before any input was received from representatives from the development team (representatives could be a developer, the lead, the manager, etc.). The development team then estimates time requirements and it is determined that what is asked for is an impossibility within the given constraints. Any requests to push are denied due to agreements already being made.

Plans are made based on the best available information but things change, sometimes daily. It's all too easy to read far too much in a simple date push.

On the topic of Cherokee delay, probably correct. However, with regard to software, I was merely referring to what I noticed as a trend (anecdotal, obviously, since this is only from my personal dealings with companies) to avoid/ignore engineers' input since we tend to be the bearer's of bad news.

I think we are agreeing in principle, we probably just have different experiences with the companies we have worked with.

 

[CherokeeVision]

I guess I'm trying to understand why they went with a design that has increased the number of parts, more connectors, four light assemblies instead of two. Why didn't the bean counters have a say with the front end of the Cherokee?

 

[Erik Latranyi]

I guess I'm trying to understand why they went with a design that has increased the number of parts, more connectors, four light assemblies instead of two. Why didn't the bean counters have a say with the front end of the Cherokee?

Because they started with a platform that was unsuitable for the program requirements and they had to compensate with a unique architecture?

As Bob has said, the more you share, the more compromises you make. If you do not accept the compromise, you have just added complexity to the mix, negating a bit of the savings that comes from sharing.

 

[bumonbox]

Because they started with a platform that was unsuitable for the program requirements and they had to compensate with a unique architecture?

As Bob has said, the more you share, the more compromises you make. If you do not accept the compromise, you have just added complexity to the mix, negating a bit of the savings that comes from sharing.

I think part of the issue is that management did not feel the Liberty could be salvaged. And felt the need to replace it ASAP. Had they felt differently, they might have overhauled the interior and given it a pentastar. Had they done that, they might have maintain decent steady sales and given them time to develop a more suitable replacement. It's all history now, but the Cherokee really is starting to feel messy. Like they should have just saved the money, skipped out on the half @$$ed compromises, and made a regular ol' cross over, or actually worked on a bonafide solution.

But, what's done is done, the Cherokee will probably be a fine alternative. It just isn't getting a warm reception from everyone else.

 

[CherokeeVision]

Because they started with a platform that was unsuitable for the program requirements and they had to compensate with a unique architecture?

As Bob has said, the more you share, the more compromises you make. If you do not accept the compromise, you have just added complexity to the mix, negating a bit of the savings that comes from sharing.

I was just talking about the lights in front. I see nothing about a platform that would dictate separating light assembly the way they did. Use the space between the head light and the turn signal/running lamp and make it all one component.

 

[Erik Latranyi]

I was just talking about the lights in front. I see nothing about a platform that would dictate separating light assembly the way they did. Use the space between the head light and the turn signal/running lamp and make it all one component.

No. Deep, deep down you were upset about the platform.

I feel your pain.

 

[Stratuscaster]

So...without having a valid engineering reason for the way the lighting is, the STYLING of the lighting is unacceptable?