Archive for the 'Project Management' Category

The Benefit Gap (What’s missing)

Thursday, May 25th, 2006

Jürgen has an interesting article: The Benefit Gap

The “benefit gap” is simply “what’s missing” - the difference between “what we need” and “what we use”. I’m still looking for the best English translation of the German term “Nutzendefizit”.

When we have a goal and do something to reach it, then we have to distinguish the following:

1. What we need, i.e. what would completely satisfy our goal.
2. What we want, i.e. what we think we need.
3. What we ask for, i.e. what we say we want.
4. What we get/have, i.e. what we accept under given constraints.
5. What we use, i.e. to what extent we really use what we have.

Ties in neatly with the findings of The Standish Group (mentioned here: Use Case Driven Agile Development), according to which an average of 45 percent of any given product is waste and will never be used.

By the way, Jürgen’s blog deals with the following:

What’s this Blog about?

The central theme of this blog is the lack of incentives for software producers (external or in-house) to reduce the lifecycle costs (i.e. to increase the quality) of software. In fact there are big incentives to lower the initial expenditures by reducing quality and shifting costs into the future, thus increasing the total lifecycle costs for the consumers. This is one of the major reasons for the persistence of the software crisis.
Software is almost unique as a credence good with very high switching costs. The inability of consumers to take quality sufficiently into account when selecting software or software producers coupled with the high cost of switching later on creates a significant competitive advantage for producers of lower-quality software.

Always a good read.


Wednesday, April 26th, 2006

As of last week, I am a Certified ScrumMaster (CMS).

What is Scrum?

Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration.

I can recommend Netobjective’s course:

ScrumMaster Certification (CSM) Agile project management is as radically different from traditional project management as agile processes are different from traditional methodologies. One of the most popular agile methods is called Scrum, and this course is about managing Scrum projects. Rather than plan, instruct and direct, the agile project manager (called the ScrumMaster) facilitates, coaches and leads. In this course, you learn how to make a development team, a project, or an organization agile, and at course completion, you are certified as a ScrumMaster. The course consists of lecture, hands-on discussions and exercises, case studies, and examples used to educate you in the way of the ScrumMaster.

Now waiting for my first Scrum project.


Waterfall 2006

Monday, April 3rd, 2006

Waterfall 2006 - International Conference on Sequential Development

After years of being disparaged by some in the software development community, the waterfall process is back with a vengeance. You’ve always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project. Learn how slow, deliberate handoffs (with signatures!) between groups can slow the rate of change on any project so that development teams have more time to spend on anticipating user needs through big, upfront design.


(via Jürgen)

Software project management: PMI vs. Agile

Thursday, December 15th, 2005

I’ll be at the PMI Silicon Valley Tools and Techniques Forum in January on Balancing the Best of Both Worlds: Traditional and Agile Software Project Management.


Wednesday, September 21st, 2005

Just passed the PMP exam.

Use Case Driven Agile Development

Tuesday, August 23rd, 2005

I had been to Netobjective’s seminar “Transition to Agile” about two years ago, so I knew this month’s talk on “Use Case Driven Agile Development” (August 15, at De Anza College) was likely to be good. It was very good. Dan Rawsthorne is a good coach.

During his two hour talk, Dan gave what he calls a “low precision, sunny day-version of the truth”. Here are some brief notes on the first part, the Essence of Agile.

First, for whom do we (or should we) develop:

  • Ultimate end users
  • Maintainers
  • Whoever pays for it

Agility is about paying attention and reacting. You can’t not make mistakes. What you can do is figure out you made a mistake quickly and react accordingly.

According to studies by The Standish Group, an average of 45 percent of any given product will never be used. It’s complete waste. With agile development you are trying to avoid that kind of waste. The magic of project management then, according to Dan, is to redirect the resources used to build the stuff that’s not needed towards the useful things that we don’t know about (yet).

Here’s what you should aim for in an interative product development cycle:

  • 1. iteration: build the 7 percent that’s always used.
  • 2. iteration: build the 13 percent that are often used.
  • 3. iteration: build the 16 percent that are sometimes used.
  • 4. iteration: build the 19 percent that are rarely used.
  • 5. iteration: no development here, just avoid the 45 percent that are never used!

Of course, one can never fully achieve this, but keep it in mind while you’re trying.

A brief summary view of project management:

  • Goal: provide a suitable solution for users that consists of quailty code and doesn’t cost too much.
  • Ideal: convert effort you would spend unwisely into developing things you don’t know about yet.
  • Common strategy: get your money, then spend it wisely.
  • Implementation: we claim this requires an agile process.

The essence of agility:

  • iteration
  • validation
  • feedback

The important thing about agility is doing everything in small, easily validated chunks. Validate that the chunks are the right ones and that we have accomplished them. So, a process is amenable to agility if it can be decomposed into small chunks, each of which can be validated.

Interesting note about the half life of requirements. We all know requirements go stale after a while. At a rate of 3 percent per month, that means a 100 percent change over a 3 year project period (or maybe one third of the requirements change three times over the course of the project). Why? The universe changes around your product. Even if you knew your requirments perfectly they’d be wrong after a while.

One of the “good” team philosphies leading to agile is validation centricity (validation is any activity that lets you know you’re doing the right thing and you’re doing it right). Activities of validation, verification and test are more important than those of analysis, design, and construction (some agile teams validate as often as twice a day!).

And finally, let the product lead: decisions must be based on the product, not documented plans, anlyses, requirements, or designs.

Download the seminar notes (PDF).

Listen to the customers!

Tuesday, August 16th, 2005

Mark Hurst on Lessons in listening to customers.

As Dan pointed out in his talk on Use Case Driven Agile Development last night, according to The Standish Group (”What are your requirements?”, 2003), a high percentage of the delivered features of a project are never used:

We find that on average only 54%, down from 67% in 2001, of the originally defined features of a project are delivered. Even more troubling is the realization that of those features that are delivered — a full 45% are NEVER used.

Now that’s scary.

Let’s play catch

Thursday, August 11th, 2005

Hal Macomer is inviting people to play catch. Hal was one of the first people I put on my blogroll - excellent stuff on project management and collaboration!

IT project management: fail early, succeed sooner.

Wednesday, July 6th, 2005

No Crystal Ball For I.T., by Rob Austin, Harvard Business School.

PMI Silicon Valley Tools and Techniques Forum

Thursday, June 9th, 2005

Yesterday’s topic at PMI Silicon Valley Tools and Techniques Forum, co-hosted by PMI Silicon Valley and SDForum: Managing Customer Expectations with metric based Software Cost Estimating. Fun!