You Want IT When?

As a reader of Businessweek, I usually start from the back. That’s where Jack and Suzy Welch answer questions from the readers. In the June 30th publication, there is a quote from the Welch’s that hits upon a recurring theme of mine, and I’d like to share it. They talk about the challenge of balancing future requirements with current requirements. Here’s what they have to say:

… Because, in our opinion, one of the fundamental tenets of management is that you have to eat while you dream, meaning, you have to make money in the short term while you invest for the long. Any dope can do one or the other. To keep the cash flowing, simply squeeze everyone and everything you’ve got. The same goes for strategy. Just tell everyone to buzz off — you’re busy envisioning the future. The challenge of leadership is balancing today’s needs with tomorrow’s opportunities.

Tomorrow’s opportunities need to be balanced with today’s needs. There’s no formula here, and notice where he says that opportunity lies: in the future. Many use the word “enough” to describe this relationship favoring the present over the future, but “balance” is more appropriate as it doesn’t favor either the present or the future. It’s situational as it should be, and overly favoring the present sacrifices opportunity. Who can afford that? Finally, it’s the essence of good leadership. Here’s the article: “While Coporate Europe Fiddles…“

The second quarter was another successful three months for yuwantithwhen.com.  A number of essays were very popular with the site’s visitors.  The most popular essay for the quarter was “Why It Takes So Long.”  Thanks to Steve Johnson over at Pragmatic Marketing for directing his readers to the posting.   There are often very good reasons it takes longer than expected to deliver a software product, but there are things that we often do to make projects take longer than they should.  I’m thinking of writing the sequel to the essay:  “Why it Takes Longer Than it Should.”  I’m not sure when I’ll pen that one, but it’s in the queue.

Read the rest of the article →

For about 10 months I’ve had the world map displayed on the top left sidebar of this web site. It’s a really cool free widget created by amung.us. Whenever a visitor visits the web site, it posts a marker on the world map identifying the location of each visitor.  Recently, the markers on the map have been resetting everyday.   Since I like the cumulative record of visitors on the map, I contacted the company and asked why they made the change, and here is their response:

We experienced some technical difficulties at one of our data centers which resulted in some users missing stats data. We are attempting to recover any lost data, and restore the service to full working capacity.

Thank you for bearing with us during this time.

Christopher C. Shannon

whos.amung.us

Christopher responded quite rapidly, and I appreciated his frank response.  However, I grew impatient waiting for a fix, and I’ve been thinking about upgrading to feedjit.com for a while now. I hesitated because I didn’t want to lose all the data that has accumulated since I’ve been using maps.amung.us.  While I was drawn to feedjit.com’s widget because I like the map better, it wasn’t enough to make me switch even though maps.amung.us hadn’t made a single improvement since I began using the widget ten months ago.  However with this defect, there was nothing to lose by giving feedjit.com’s widget a try, and so I did. 

The web changes everything.  Now that so much software is offered for free, the barrier for switching vendors based on price is gone.  Consequently, high quality is even more important when the barrier to switching vendors is nearly zero.  Quality and useful features on the first delivery are a competitive advantage, and they are often more important to consumers than new/enhanced features delivered frequently.  Incremental, frequent enhancements to satisfied customers is simply not required, but if you get your quality wrong or deliver the wrong features, you will lose customers — even formerly satisfied customers.

If you liked this essay, you may also like the following related posts.

• Agile Content is the Goal
• Does Agile Solve the Right Problem?
• Burnt Toast

It’s suggested that the web has changed everything.  Whatever requirements there were for delivering desktop applications, the requirements for delivering web applications has changed.   For the web, the thinking goes; delivery of new features to customers is paramount to remain competitive.   Maybe it’s true, but what’s the evidence?  My own experience with popular web sites does not support this conclusion.

Read the rest of the article →

Agile doesn’t work in the real world is essentially the conclusion of David Starr, an Agile proponent, in his article “Why Agile Doesn’t Work.”  First, he informs us of what is the primary objective of Agile software development methodologies:

Sure, TDD works, so does continuous integration, and a host of other great development practices. The truth is, though, that the real Agile value proposition was never about code. Better software with higher quality and excellent craftsmanship is a great side effect, but Agile is really about changing how products are created and delivered. Agile intends to fundamentally change the model of your relationships with clients and coworkers.

Read the rest of the article →

While reading a June 12, 2008 Time Magazine article “How He Did It,” an account of how Barack Obama came to win the Democratic nomination, it reminded me of the dynamics of a software project.   Early in the Obama’s campaign near panic set in as Obama was drawing record crowds and record donations, but he still trailed Hillary Clinton by 20 points in the polls.   Many in his campaign feared his approach to politicking would not get the job done.  Obama’s “top moneymen were urging him to rethink his strategy, shake up his staff, go negative.” 

Read the rest of the article →

They said it wouldn’t happen again, but it did.  The American auto industry wouldn’t be caught unprepared again when another energy crisis were to hit the economy. Sure, consumers were all too complicit by indulging in the conspicuous consumption of oversized vehicles: the Sport Utility Vehicle (SUV).  You probably have seen them in the shopping mall parking lot.  They extend about four feet beyond the length of the designated parking space, and their width bulges beyond each side of the yellow lines.

Read the rest of the article →

“I’d rather drive a Pinto that works every day than a Lexus that always breaks down,” said an unsatisfied customer of a company that delivered a product plagued with quality problems.  For him leading edge was less important than quality, or to put in other way, leading edge features that don’t work is like not having the features in the first place.  That’s true for most customers. 

It appears that the software development community believes that customers have a high tolerance for product defects.  How else can you explain the low quality that we often experience in the software products that we purchase?   I’ve often written about my experience with video editing software where it was difficult to find a product that could compile an edited sequence successfully.  Essentially, many of the video editing products at the time could not reliably complete the primary function for which people purchased them: compile sequences to a single AVI file.

Read the rest of the article →

Is formal project management necessary to successfully deliver a software project?  The short answer to that is no.  Many successful software products have been launched without any project plans or schedules, at least not in the traditional sense.  When I first started in this field, project plans were not the norm, but that was when programs fit in a device with less than one megabyte of memory. 

Read the rest of the article →

Why does it take so long to deliver software products? Many stakeholders ask this question during the course of a software development project.  It’s interesting when the developers ask this question because they know what it takes to implement the functionality in software, but in asking that question, some in the organization often fail to appreciate what it takes to deliver a commercial product to market.  From one perspective, they are correct; it shouldn’t take so long, but from a different perspective, the long duration is understandable — even if undesirable.  I’d like to explore the perspectives that explain these differences using a hypothetical delivery.

Read the rest of the article →