Is Delivery Date the Only Thing

In the September 2007 Issue of the PM Network there is an article titled "The Need to Speed". According to th article a survey of project managers around the globe that indicates that there seems to be a problem with on time delivery of IT projects. When you look at the cold hard reality of things, this should not really come as surprise to anyone. Aside from the fact that the article never mentions how the deadlines were set and by whom, the article concerns me because of it's suggestions on ways to address projects coming in after deadline.

Even though the advice is listed as the opinions of the people who took a survey, the fact that these particular answers are being pointed out in the article, causes the information to take on a little more importance.

The statement in the article that really caught my attention, and confirmed my fears that traditional PM thought and training is focused on the wrong thing is this statement below:

"More than one - third of EMEA-based executives agreed with that assessment, but are particularly frustrated with changed made mid-stream, so they advocated ignoring changes to business requirements as a means of speeding up project delivery."

Huh??? Ignore changes to business requirements to get the project done on time? Ah yes, this is the focus on that magical iron triangle - scope, time, and cost. Here's the problem with that: you can deliver a project on time, under budget and with the agreed upon scope, and still entirely underwhelm your customer. I humbly suggest that we have been measuring project success using the wrong metrics. Scope, time, and cost are important, but the truly meaningful measure is really value produced by the project. It incorporates the sides of the iron triangle and goes a step further by measuring how the project improved the state of the organization be it through added revenue, reduced costs, or protection of existing revenue.

You see change happens. Business requirements will and should change throughout the course of a project. There are at least a couple of reasons for this.

• First off, for any project that lasts any considerable amount of time (even as short as three months) it is very possible that business conditions change during the life of the project. If the environment in which the project is happening changes, the characteristics of the project necessary for it to provide value is likely to change as well.
• Perhaps more frequently the "changes" that people see in requirements is really a result of better understanding of the requirements. This happens frequently when the team suffers from the desire to avoid uncertainty by identifying to the nth degree all requirements at the very beginning of the project. Changes occur because details were established before the team had the appropriate information to properly make those decisions. And often the people making those decisions are not aware of all the relevant details needed to make a decision.

So how do you get around this problem? Don't define requirements in great detail at the beginning of the project. Doing so creates a requirements inventory, and limits the options that are available for design.

And always keep in mind, if deliver something on time that completely misses the mark for what the customer wanted, is it really a success?

Moving to Knowledge Bridge Musings

All of the blog entries posted before now on Sunday September 2 are actually copied over from my old blog on KentMcDonald.com. I decided to switch over to Blogger.com as my blogging mechanism, but I wanted to save my old entries. As I went through the old entries, I noticed a lot of them were announcing a new presentation. I decided not to replicate those, but I am posting all of my presentations on the Knowledge Bridge Partners Publications page.

Everything after this is new stuff. Enjoy.

A Challenge to some Friends

I recently challenged some friends to identify one book on MP3 to which I should listen. Assuming I can actually find the book in a format that I can use, I commited to listening to the book and letting them know my thoughts.

The results so far (I should note that some had trouble keeping their recommendations to one book):

• Innovator’s Dilemma (Clayton Christensen)
• Innovator’s Solution (Clayton Christensen)
• Dealing With Darwin (Geoffrey Moore )
• Inside the Tornado (Geoffrey Moore )
• Living on the Fault Line (Geoffrey Moore )
• Crossing the Chasm (Geoffrey Moore)
• The Tipping Point (Malcolm Gladwell)
• Blink (Malcolm Gladwell)
• Great Boss Dead Boss (Ray Immelman)
• Good to Great (Jim Collins)
• The Seven Day Weekend (Riccardo Semler)
• Orbiting the Giant Hairball (Gordon MacKenzie)
• Wikinomics (Don Tapscott and Anthony D. Williams)
• Freakonomics (Steven D. Levitt and Stephen J. Dubner)
• The World is Flat (Thomas L. Friedman)
• Team of Rivals (Doris Kearns Goodwin)

If you would like to add your thoughts, Contact Us.

Powerpoint waters down great ideas

I will admit that I still utilize PowerPoint, and I will also freely admit that until recently, I have used it in a bad way. We all learn to improve, and I think this example is the best way to show how PowerPoint can actually detract from good ideas.

On November 19, 1863 Abraham Lincoln gave perhaps one of the most famous speeches in American history. Legend has it that he wrote it on a napkin on the train to the location for the speech. Regardless of how it was written, this short speech has become memorable for some of the ideas wrapped up in it's rather short length. It is of course the Gettysburg Address. I have included the actual text below.

So what does this have to do with PowerPoint being dangerous? Here is an example of what the Gettysburg Address would look like if Lincoln had access to Powerpoint compliments of Peter Norvig.

Here is the actual text of the Gettysburg Address:

Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal.

Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this.

But, in a larger sense, we can not dedicate -- we can not consecrate -- we can not hallow -- this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us -- that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion -- that we here highly resolve that these dead shall not have died in vain -- that this nation, under God, shall have a new birth of freedom -- and that government of the people, by the people, for the people, shall not perish from the earth.

Agile Stories

Mike Cohn has done it again. In a new article on gantthead.com entitled Agile Stories Mike describes in his usual clear, concise style how User Stories can be expanded to provide more details about the requirements with getting into documentation overload. He introduces the use of conditions of satisfaction along with user stories to provide a nice level of requirements information.

A Few Good Managers

For those of you out there who are big fans of agile software development, Tom Cruise, and/or Jack Nicholson, check this blog posting from Robert Holler.

Community Ship

Many thanks to Alistair Cockburn for alerting me to the presence of this article by Henry Mintzberg that suggests perhaps we should be thinking about Communityship more so than leadership.

Brainwriting

A recent post to the Agile Experience Group tipped me off to a good approach to gathering information from a group called Brainwriting. This approach takes away some of the difficulties with brainstorming.

That's what dreams are made of

Chris Matts and Andy Pols are working on a prototype for the Dream Factory which is a little bit
of a lot of things, including a tool for coordinating communities, managing IT investment portfolios and projects, and managing the requirements for a development project.

Chris explained the concept of the Dream Factory to me at Agile 2006. The idea is based partly on the the concept of the Wisdom of Crowds, where the votes of multiple users/stakeholders is used as a mechanism to determine which features are realized. This seems to me to be a good way of prioritizing requirements for projects where there are several customers. It also provides a nice example of how a wiki or blog can be used to gather and document requirements.

If you like the idea, Chris and Andy request that you join the Dream Factory to help them develop it together. The registration process is real easy, and Chris and Andy welcome any input.

Are Featutres the right things on which to focus?

A series of four Blog posts over the past few days have put forth the idea that projects should focus on outcome more so than features.

• Franks Sommer's Blog entry
  Valuing Outcomes Over Features on November 3 summarizes the other blog discussions.
  In that discussion he mentions the others.
• Dan North's entry Outcomes over Features - the fifth agile value
• Ditch the feature shopping list. Think customer journeys
  introduces the concept of customer journeys
• Martin Fowler's Feature Devotion

This concept is also apparently contained in the book What Customers Want. Definitely an area I will want to investigate further.

Try this one at home to test document usage

As I try to get caught up on my Yahoo Group reading, I came across this great test in the Agile Modeling Yahoo Group to determine who,if anyone, is actually reading project documentation.

This story is from Huet Landry on the Agile Modeling Yahoo Group:

One of the folks at my site did a version of this. He password-
protected his "deliverable" files and included a statement to contact
him for the password. Out of 50 recipients over five releases guess
how many requests he had for the password ? ZERO !

That little test is very tempting...

Behavior Driven Development

I learned about Behavior Driven Development from Chris Matts. It is basically a way to utilize some of the principles of Test Driven Development for analysis. All in all it is really quite elegant in its simplicity.

Dan North describes Behavior Driven Development in this article. Basically it suggests the use of the following pattern for recording requirements:

AS A [person or role]
I WANT [some feature]
SO THAT [business value of the feature]


To provide further detail, and prepare for testing, acceptance tests for the feature can be written in terms of expected behavior:

GIVEN [some initial context]
WHEN [an event occurs]
THEN [ensure some outcome]

Powerful stuff when you understand the why behind it.