Business Case » Bob Lambert

Agile development: rugby analogy considered harmful

App Dev, IT, Project Management 1 Response »

Dec 132010

Recently my friend Mark Hudson posted about the inappropriateness of the term “sprint” for an agile project phase, preferring the cycling term “interval.” That post really struck a chord with me.

As a rugby union fan and former wing/fullback I’ve always thought the whole rugby analogy was wrong. Agile development is continuous and fluid, yet the agile originators chose the word “scrum” for its daily standup meetings. In rugby union a scrum is a set play resulting from a minor penalty, like offside in American football or a foot fault in tennis. If you like the rugby analogy the right term would have been “ruck,” which is kind of like a scrum but part of the continuous run of play (in the other kind of rugby, called rugby league, the scrum has devolved into an almost meaningless stylized ritual – which I guess happens on some agile projects). Continue reading »

Business requirements up front

IT 3 Responses »

Mar 312010

“Our goals can only be reached through a vehicle of a plan, in which we must fervently believe, and upon which we must vigorously act. There is no other route to success.” – Pablo Picasso

It is an old story: about 30% of IT application projects succeed, 45% are “challenged,” and the other quarter fail altogether. That’s the consistent result over the years of the Standish Group Study of Project Outcomes. Jorge Dominguez, here, displays a chart of the remarkably similar results since 1994. Not a pretty picture, right? Some question the validity of the Standish studies, but Scott Ambler parallels the Standish story in a recent Dr Dobbs column called “Lies, Great Lies, and Software Development Project Plans,” which itemizes the strategies commonly used by IT project managers to “stay out of trouble” when schedule/budget results don’t match initial estimates. For example, “18% change the original schedule to reflect the actual results”. Continue reading »

BI Business Case Basics: Three Things to Remember

Data Management, IT, Project Management No Responses »

Jul 282009

Here are three things to remember when putting together a BI business case:

Excerpt from "Show Me the Money: A DM/BI Business Value Primer", Bob Lambert and Tri Truong, Information Management Special Reports, March 24, 2009

Intangible benefits don’t count.
BI has no inherent value.
Senior managers often make decisions about future outcomes with insufficient data. Continue reading »

DQ, he isn’t so dumb he just needs glasses

Data Management, IT, Project Management 1 Response »

May 032009

In a recent very thoughtful post on data quality, Paul Erb plays out an analogy comparing data users with Don Quixote and data quality professionals with Sancho Panza, then reverses the analogy to cleverly coin the “Sancho Panza” test of data quality professionals. He encourages data quality professionals promoting the critical role of data quality to apply a what would Sancho say test to ensure that they are aligned with the needs and interests of data consumers. Continue reading »

Do your homework before presenting a BI business case

IT, Project Management No Responses »

Mar 252009

Excerpt from "Show Me the Money: A DM/BI Business Value Primer", Bob Lambert and Tri Truong, Information Management Special Reports, March 24, 2009

Before starting the Business Intelligence business case, the BI advocate should do the homework required to ensure its success, including these essential steps:

1. Know the organization’s goals and objectives.
2. Identify a BI champion.
3. Identify and work with BI stakeholders.
4. Identify an application with tangible business value.
5. Define and quantify a quick win prototype project. Continue reading »

Big project coming up? Learn to two-step.

IT, Project Management No Responses »

Mar 062009

History is littered with IT application projects that end late, go way over budget, or abandoned altogether. I was fortunate enough to see one work out really well (almost – please read on). It was no mistake. It came down to a simple method advocated by a gentleman named named John Carpenter.

The project was an HR management software conversion from one commercial off-the-shelf software (COTS) package to another. The company concerned was conservative about spending money. A previous business case had proposed a similar project. The problem with that business case was that the benefits were really tough to conceptualize, so the cost/benefit analysis relied on soft benefits like “improved access to information” and “more consistent reporting data”. The folklore was that the CFO had physically thrown that business case out of his office. Continue reading »

Suffusion theme by Sayontan Sinha