CIO Magazine – Postmodern Manifesto

CIO magazine 1 may 2006

The Postmodern Manifesto, by Christopher Koch http://www.cio.com/archive/050106/pomo.html

In a 2005 SIM survey of skills that CIOs expect to most value in their IT staffs over the next three years, project management led the list, followed closely by company, functional and industry knowledge. Other skills in demand included business process reengineering, user relations management, negotiation, change management, communication and managing expectations. Only two technical skills (systems analysis and systems design) made the top 15—and both of those skills focus more on architecture and process than on hard-core programming.

[…]
To some extent, the deconstruction of IT has already occurred, especially in big companies where the large scale of IT and the separation of IT functions such as help desk, application maintenance and some programming have made them candidates for outsourcing. More and more jobs in IT will become components in a distributed services supply chain modeled on today’s distributed manufacturing supply chains.

IT departments already have undergone a structural shift. The number of programmers employed in the United States has dropped by 25 percent since its peak in 2000, even though the total number of IT workers has increased slightly since then, according to the Bureau of Labor Statistics. In our “State of the CIO 2006” survey, 76 percent of respondents said they outsource application development, maintenance or support—more than double the next highest category.

In one respect, the distributed services supply chain model is actually creating more work. As pieces of the IT supply chain break off and become more specialized, the need for coordination of the pieces increases. That means the number of internal jobs dependent upon external people is increasing. This shift is reflected by the new emphasis in IT departments on relationship management and project management.
Economists call these kinds of skills tacit work, which requires the ability to analyze information, grapple with ambiguity and solve problems, often based on experience. Tacit interactions are complex and require interaction (such as managing a software development project) rather than being simple and solitary (fielding help desk calls with a script, for instance).

Tacit jobs have been growing three times faster than employment in the entire national economy, according to consultancy McKinsey, and they make up 70 percent of all U.S. jobs created since 1998 and 41 percent of the total labor market in the United States. These roles track pretty closely with the categories where the Department of Labor says IT employment has made the biggest gains since 2000: application engineers, systems engineers and network analysts.

Glass – Standish Chaos Report

Communications of the ACM, October 2006

Robert L. Glass The Standish Report: Does It Really Describe a Software Crisis?

Most academic papers and guru reports cite the same source for their crisis concern—a study published by the Standish Group more than a decade ago, a study that reported huge failure rates, 70% or more, and minuscule success rates, a study that condemned software practice by the title they employed for the published version of their study, The Chaos Report.
So the Standish Chaos Report could be considered fundamental to most claims of crisis.

[…]
Several researchers, interested in pursuing the origins of this key data, have contacted Standish and asked for a description of their research process, a summary of their latest findings, and in general a scholarly discussion of the validity of the findings. They raise those issues because most research studies conducted by academic and industry researchers arrive at data largely inconsistent with the Standish findings.

Let me say that again. Objective research study findings do not, in general, support those
Standish conclusions.

[…]
Standish, please tell us whether the data we have all been quoting for more than a decade really means what some have been saying it means. It is too important a topic to have such a high degree of uncertainty associated with it.

Boehm – Requirements Volatility

Communications of the ACM, October 2006

Barry Boehm One-size-fits-all Methods: the Wrong Solution to new Problems

Requirements Volatility ratings for stable embedded devices are still in the 0.1% to 0.3% per-month range, but the counterpart ratings for rapidly changing competition-driven applications are often in the 10% to 30% per-month range.

Level 5 CMM – India

Communications of the ACM, October 2006

Michael Cusumano, Envisioning the Future of India’s Software Services Business:

In terms of process maturity, the Indian companies are difficult to beat as well: It is well known that, as of last year’s count, 80 of the World’s 117 SEI CMM Level-5 companies are based in India.

Dilbert – project management

Dilbert su PMI Journal (3-11-06 Scott Adams.)

Boss: Yesterday I had a great meeting about project Wombat.
Dilbert: What?! I’ve been managing that project for six months! How can you have a meeting without inviting me? !!
Greta: Have you noticed that meetings go smoother without any knowledge or expertise?
Boss (very small font): Kinda.

Agile and Toyota – Alistair Cockburn

due post il 31-12-2006 e 1-1-2007

Re: [APM] Management lineage of software processes

Interestingly, the Toyota Production System (TPS) was already doing most of what we now call agile, already back in the 1970s.

The west didn’t notice what they were doing and misinterpreted it. (most of) Those of us who wrote the agile manifesto in 2001 were not aware of TPS, and simply wrote what was on our minds. Since then, many of us have looked at TPS — and I for one, can’t see that we’ve added very much to what was already in TPS (test-first comes to mind as an exception).

Alistair

Re: [APM] Management lineage of software processes

Thanks, Boris. Well, I have three times visited a place in SLC(O.C.Tanner) where they are implementing TPS pretty strictly in their awards production, and I am unable to to suggest anything that they haven’t already been doing for over a year. I.e., TPS already leads them to everything I know.

Personally, I think it’s pretty nifty that we in software managed to reinvent our own localization of the ideas of TPS without knowing first about TPS. It doesn’t bother me if Toyota got there first (over a 60-year period). I think the ideas are there to be found by multiple groups of people … the math adds up, reflection and inspection lead there.

But the only reason I brought this all up was that someone asked about the sequencing of ideas and influences. AFAIK, we software people were not particularly influenced by Deming or TPS in coming up with the agile manifesto (I can speak for myself — my information came strictly from staring at my interview results and management attempts in the early/mid 1990s … I suspect the same was true for at least most of the people at the Snowbird meeting). And still, looking at time sequencing, it is clear that lean manufacturing got there first. I still don’t know about Deming’sstuff.

Lean and contracting situations – Mary Poppendieck

post il 3-1-2007 RE: [leandevelopment] Budgeting a Lean Project

Tal,

It seems that you are in a contracting situation, as opposed to developing software for use within your own organization. If I can make that assumption, then I would suggest that lean principles are not particularly viable unless lean contracting is also part of the equation. When you reach organizational barriers and lean organizations run up against non-lean organizations, it is often impossible for the supplier to act in a lean manner.

As an example, many automotive suppliers have adopted lean practices in order to supply Toyota. The lean areas of their plants are much more efficient and cost-effective, but they are usually not able to supply other automobile companies with the lean area of the plant – they have to maintain a non-lean (and less efficient) area of the plant to serve those other customers. Why? Because the Detroit automotive companies still want parts delivered in large batches – they thin the economies of scale are the dominating factor in their business, despite decades of evidence to the contrary.

Similarly, if you have customers that believe that accumulating huge batches of detailed requirements is the most efficient way to contract with suppliers, then you may have to operate in a non-lean way with those customers. When you find customers that want a lean supplier, you can partner with them in a lean way, and as the automotive suppliers found out, deliver better, more cost effective software. However, in general, the choice lies with the customer, not the supplier.

Mary Poppendieck

Università, in fila per filosofia. “Così si diventa buoni manager”

Corriere della Sera, cronaca di Milano, 26 agosto 2006

“Consiglia a tutti gli studi filosofici Franco Tatò:

‘Ai ragazzi dico: non abbiate il complesso dell’ingegnere. Con la filosofia si sviluppa la capacità di sintesi, si confrontano le situazioni, si imparano le lingue (molti testi non sono tradotti). Sono questi i requisiti di un buon manager. […] Anche perché le nozioni acquisite diventano presto obsolete, tanto vale imparare un buon metodo di lavoro e avere una testa che funziona.’

L’utilizzo del prodotto fa emergere nuovi requisiti

da “Mondo Digitale” anno V n° 2 – Giugno 2006 – articolo “La comunità virtuale degli esaminatori ECDL”, di Daniela Maria Ricco, Giuseppe Giliberto, Giuliano Russo, pag.51:

“[…]l’uso di strumenti e le modalità di esecuzione dei compiti si influenzano a vicenda. Carroll e Campbell [Carroll J.M., Campbell R.L.: Artifacts a psycological theories: The case of human-computer interaction. In “Behaviour and Information Technology”, 1989 – sic -] hanno messo in evidenza il carattere circolare della relazione artefatti-compiti (task-artifact cycle): le persone svolgono determinati compiti, con maggiore o minore soddisfazione, usando determinati strumenti. I nuovi strumenti, una volta adottati, alterano i compiti per cui vennero progettati e modificano le situazioni in cui i compiti venivano svolti in precedenza. In questo modo lo strumento nuovo crea un nuovo compito e una nuova situazione sociale in cui si svolge il compito. Questi ultimi generano poi a loro volta il bisogno di ulteriori miglioramenti che sarebbero possibili grazie ad una nuova famiglia di artefatti da inventare per svolgere meglio il nuovo compito e così via.”

In “Communications of the ACM”, June 2006, l’articolo “A Systematic Approach in Managing Post-Deployment System Changes”, di David Kang e Roger Chiang, affronta l’argomento in modo più operativo, e fornisce indicazioni utili per un’implementazione organizzativa della gestione dei cambiamenti.

Mary Poppendieck insiste ripetutamente sull’esigenza di passare da una visione per progetti ad una visione di product development.