Talk:Lean IT

Recessionary Pressure to Reduce Costs says there are higher taxes?

I find it funny that the article has a citiation to prove that there are/were "higher taxes" and points to a WSJ article about the Tea Party. There may be some uproar about the size of goverment and deficit spending, but I can't find anything that states taxes were raised in or around 2007. Not only that, but what taxes? Sin taxes were raised to no uproar, income taxes are set to go up, but not until 2011. That whole paragraph seems biased and not well written/cited. The "higher taxes" citation should certainly be removed. —Preceding unsigned comment added by 66.194.90.20 (talk) 18:44, 17 November 2010 (UTC)[reply]

External link www.sm-s.org

This Californian website claims to be a Society for Service Management but based on the details supplied on the website I can see no sponsors named and no official affiliations. I suspect this website is a fraudulent con. If replace again I suggest it is removed immediately as it contravenes WP:ELNO #4 and #5 and probably #10.—Ash (talk) 08:13, 22 August 2009 (UTC)[reply]

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Resolved

– The consensus was not to merge. Ash (talk) 09:31, 6 March 2010 (UTC)[reply]

I think Lean software development and this article cover similar areas and should be merged. 2aprilboy (talk) 13:39, 10 January 2010 (UTC)[reply]

Oppose Probably more useful to develop the differences between the articles. It could be argued that one is a content fork of the other but it's a pretty darn large content fork and so the main article could point out to the scion.—Ash (talk) 14:25, 10 January 2010 (UTC)[reply]
- What differences should be there? I think no principle or method applies to the Lean software development only and does not apply to the Lean IT, so all the content of the "scion" should be part of the main article. 2aprilboy (talk) 14:59, 10 January 2010 (UTC)[reply]
  - I don't disagree that the content could be made part of the main article. However the articles are not equivalent and the wide topic of Lean IT could usefully point out to the specific article on Lean software development. The two articles have quite a distinctly different focus and at 8 or more screen-pages long, the Lean IT article does not really benefit by expansion of detail.—Ash (talk) 15:08, 10 January 2010 (UTC)[reply]
Oppose Please don't merge these articles. Lean-related aspects of the content will necessarily be similar. However 'IT' and 'software development' are worlds apart, just as 'cars' and 'car design' are. It wouldn't make sense for a reader seeking information about Lean IT to find it in an article about Lean software development; and the alternative of incorporating Lean software into the Lean IT article, would make a reader burrow through a mountain of irrelevant content to get at what they want. If the articles are considered too similar even though they cover Lean application in two utterly different areas, then by extension all other articles relating to application of Lean principles would need to be merged too, with the result being unwieldy and in my opinion unnecessary.Amberlapwing (talk) 03:34, 6 March 2010 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Origin of the Lean Concept

I'd like to remove this section from article and point to Lean manugacturing, because it was completely rewriten there after discussion. 2aprilboy (talk) 14:39, 16 January 2010 (UTC)[reply]

That would probably be an improvement, I cannot see much benefit in repeating the general non-IT background of the Lean Concept in the current article.—Ash (talk) 14:47, 16 January 2010 (UTC)[reply]

done 2aprilboy (talk) 13:36, 17 January 2010 (UTC)[reply]

Service catalog and request catalog are two different things

The example in 2nd paragraph of Deployment and Commercial Support mistakes Service catalog for request catalog

User:Ejrrjs says What? 13:32, 9 November 2014 (UTC)[reply]

Agile methodologies as a fix to CMMI, RUP and PMBOK.

This article reads: "Agile Software Development is a set of software development methods that originated as a response for the indiscriminated use of CMMI, RUP and PMBOK creating fat and slow software development processes."

But the article about Agile software development do not even mention CMMI and PMBOK; and, in that article... the Unified Process is even mentioned in its History section as a lightweight methodology that preceded the Agile Manifesto!!!

The history page of the Manifesto for Agile Software Development only mentions that they were looking for "... an alternative to documentation driven, heavyweight software development processes..."

I added a citation needed template. I wrote some more additional insight there, too.

If after some reasonable time no support is provided, that sentence must be deleted as it is original research or a conjecture.

George Rodney Maruri Game (talk) 09:30, 1 May 2017 (UTC)[reply]

Complementary methodologies

This fragment is very strange:

Typically a grand overhaul is not recommended because of the previously mentioned fragmentation issues. Companies that choose to internally source their developers, reassigning them to software support functions can run into many waste causing scenarios. For example, this can lead to highly skilled employees effectively becoming customer support representatives. The employees previous salary requirements would still need to be met, potentially accumulating millions of dollars in waste. A side effect may be overloading AD teams who need to handle the same amount of development work. Also, since these employees are not usually cross trained with business and/or other specialized IT areas there is a steep learning curve and adjustment period. This can be a primary contributing factor to fragmentation. This can lead to customer support issues actually taking longer to resolve and becoming less efficient, due to constantly searching for or transferring issues to a support team's "expert" in a particular field. Another downside is employee resistance. For example, an employee trained in Java programming who is now supporting customer issues will likely start searching for another job in his/her field. Especially if they are no longer being asked to use their perceived primary skill set.

Making software developers work as customer support representatives is such a stupid idea that it doesn't feel like a realistic example of a "grand overhaul of an existing process". And anyway, what does it have to do with the complementary methodologies, which the paragraph is supposed to introduce? — Preceding unsigned comment added by 193.157.238.16 (talk) 13:38, 30 August 2018 (UTC)[reply]

Thank you for pointing this out. The content was added in a good-faith edit in May 2015, but is original research based on personal knowledge (WP:OR). Of course such information could be added somewhere in the article, if it is relevant for the topic. But: 1) it must be referenced to published reliable sources and 2) it should be written in a more encyclopedic tone, not as a personal analysis or essay. Removed for now - the content is available in article history, if any interested editor would like to completely rewrite and source it. GermanJoe (talk) 13:46, 30 August 2018 (UTC)[reply]