James Robertson of Column Two consistently provides useful insight and resources on knowledge management and information architecture topics. Recently, Robertson had a series of posts that compiled an inventory of available standards on knowledge management.

• Metamap - an interesting graphic on metadata standards and their relationships
• Knowledge management standards, and the like?
• Knowledge management resources on the web from a lawyers perspective.

10:00:54 PM •  • comment  

WhatIsFailure

agile

15 May 2003

CHAOS report says only 34% of projects succeed.

The Standish Group's CHAOS report has been talking of billions of wasted dollars on IT projects for many years. The 34% success rate is actually a improvement over 2001's figure of 28%.

But what do we really mean 'failure'? The chaos report defines success as on-time, on-budget and with most of the expected features. But is this really success? After all Windows 95 was horribly late yet was extremely successful for Microsoft's business.

Rather than saying that a project is failed because it is late, or has cost overruns - I would argue that it's the estimate that failed. So the CHAOS report isn't chronicling software project failure, it's chronicling software estimation failure.

So what counts as success? If we could measure it the answer has to be Return on Investment. Sadly this is usually next to impossible to measure. In the end it's a fuzzy sense of business satisfaction relative to the cost of the project. This may be an unsatisfactorily fuzzy definition, but many business activities are just as fuzzy. Otherwise computers would be CEOs.

[Martin Fowler's Bliki]

Since I'm on a project management kick at the moment, let's pass along this interesting observation from Martin Fowler. It is certainly popular in IS circles to bemoan the inability to hit project targets. But Fowler makes an important point. The usual assumption is that it is a failure of project management, usually on the part of someone peddling project management tools or someone hoping to take IS down a peg or two.

Fowler is closer to the truth. The superficial resemblance between software development and construction in the physical world obscures the fact that often what we are doing in software development is more R&D than it is general contracting. Knowing which parts of the project are routine and which might be pushing the envelope requires a more sophisticated form of estimating and budgeting than vanilla project management techniques.

9:23:15 PM •  • comment  

I haven't had time to watch the Alan Kay video from Etech, and now there's a video of a Fred Brooks keynote:

Programming effort in a start-up (company or project) usually begins with a solo programmer and grows to a small team. Then, with luck, it grows to a large team. And radically changes character! Here lurk all the difficulties of software engineering. Growth is gradual, and change often imperceptible, until suddenly the project is in trouble. Process discipline has become necessary, often well before it was developed. What discipline? When? How, without dampening creativity?

According to Stephen Norrie, who blogged about it, the video covers solo programming, conceptual integrity, pair programming, team size, architect role, code control, change control, documentation, testing, discipline, preserving creativity.

[Tesugen.com]

Brooks is always worth paying attention to. He's currently an emeritus professor of computer science at UNC-Chapel Hill, but his real claim to fame is managing the development of IBM's OS/360 back in the early 1960s. His Mythical Man-Month: Essays on Software Engineering is still a must read for anyone who has to manage complex projects, software or otherwise.

7:42:25 PM •  • comment