THE NINE WINS AXIOM AWARDS

PHIL SIMON

Award-winning author, dynamic keynote speaker, trusted advisor, & workplace tech expert 

The Chopping Block: Cutting Features From an IT Project

Consider dropping non-essential features for the good of the project and the organization.
Nov | 13 | 2009

 

Nov | 13 | 2009
}


I am often involved with projects that are running behind schedule and over budget. Such is life of an IT consultant, I suppose. In many instances, projects can recoup valuable time if non-essential features and functionality are removed from the immediate plan and postponed until a later time. This post explores the decision on what can and can’t be cut from IT projects.

Consider the following three questions:

  • What type of project is it?
  • Are executives’ incentives in synch with other employees in the organization?
  • What are the risks and rewards of keeping non-essential functionality to the overall project and the organization itself?

What type of project is it?

Generally speaking there are two types of projects. First, there are those that involve a Waterfall or more sequential methodology. Then there are those that involve Agile methods. Let’s look at each.

Waterfall Projects

Clients are typically reluctant to cut functionality from Waterfall-based projects for one simple reason: there’s typically (and mistakenly) a “now or never” mentality. In other words, key stakeholders believe that if the software isn’t present immediately, they’ll never see it.

Be prepared to drop non-essential features for the overall good of the project.

This may or may not be the case. Delays, budget cuts, internal politics, and key employee turnover often mean that the best intentions regarding future roll-outs are derailed. I’d argue, however, that continuing down a parlous path because you’re afraid that internal obstacles will prevent you later on is a fundamental misstep.

Agile Projects

On Agile projects, internal players tend to understand the concept of phases better. They are more likely to sacrifice “nice to have” functionality if it’s likely to increase organizational risk. Project teams, developers, and senior management know that the next version of the software (or the next phase of the project) can easily incorporate enhancements. There’s no “burning plank” mentality here: there will be a next version, and typically soon.

Determine in advance which features are essential. If necessary, be prepared to drop non-essential features for the overall good of the project.

Are executives’ incentives aligned with those of the organization?

To borrow a phrase from poker, executives sometimes go all in with a particular feature, application, module, or system, refusing to ignore signs of peril. For example, a few years ago I worked on a project in danger of imploding. System testing and data validation were months behind schedule, affecting the entire organization’s financial health, not to mention little things like payroll and financial reporting. Less important, the roll out of a manager self-service application that would minimize paperwork also looked doubtful, although this affected a very small percentage of employees in the organization.

While the overall project suffered, CXOs refused to cut self-service from the project plan. Why? Because their bonuses were tied to the introduction of the tool, whether it was successful or not. This is a classic example of senior managers letting their provincial self-interests override their responsibilities to the organization at large.

From day one, make sure that senior managers’ incentives align with those of the organization.

What are the risks and rewards of keeping non-essential functionality to the overall project and the organization itself?

Consider an ambitious CRM project. Everyone would love to have sexy analytics (now that would be a great title for a book) from day one. However, does that functionality come at the risk of not being able to enter new customer sales? The latter is pretty important, even though it’s not what sold senior management on the CRM app in the first place. Those dashboards aren’t worth a red cent if they don’t contain accurate data. Imagine the chaos if basic sales data cannot be obtained? Will fulfillment become an utter nightmare? Will the data become corrupt and impure, requiring a massive data cleanup effort?

IT projects are never perfect.

Remember that there’s always tomorrow. Absent some really compelling business need, ensure that critical functionality is rock solid before chasing next-generation functionality.

Simon Says

Most people realize that IT projects are never perfect. If behind on a key project, don’t hold out for each and every bell and whistle promised from the beginning. Consider dropping non-essential features for the good of the project and the organization.

Go Deeper

Receive my musings, news, and rants in your inbox as soon as they publish.

 

 Blog E Data E Analytics E The Chopping Block: Cutting Features From an IT Project

9 Comments

  1. Dayce

    A sobering perspective, especially now that Agile methodology is catching in company environments that inject their traditional Waterfall attitudes, creating a doomed mixed-methodology approach.

    Again, something that any manager involved in technology implementation should read.

  2. Jim Harris

    Excellent post Phil,

    I have to ask. How long have you been using “Simon says” to make your points?

    Because, I have to say, that is awesome!

    I wish that I had a cool last name. Harris sounds like “harass,” which isn’t a great word association:

    Harrisment: Read all of Phil Simon’s blog posts!

    But seriously, everyone really should.

    Best Regards,

    Jim

  3. philsimon

    It’s a recent edition, my friend. You’re a fan? Cool

  4. Michiko Diby

    “Clients are typically reluctant to cut functionality from Waterfall-based projects for one simple reason: there’s typically (and mistakenly) a “now or never” mentality” Is that ever a true piece of wisdom. Today, a client I’ve been working with for a year..I’ve taken his project through one major and two minor releases and he says that he can’t do another big release. Why? Becuase his experience in the past is that a project longer than 6 months turns into a 2 year project. Even when facing the evidence that my team is honest to schedules, he’s still burned by past experiences with other contractors. Wow. Thanks for drawing this truth out.

    Michiko

  5. philsimon

    Interesting story, Michiko. I can understand the ‘burnt hand teaches best’ mindset but that’s no excuse for putting an entire project at risk.

  6. michiko.diby

    well…it was a “cmon really?” convo that ended with a tentative agreement to reduce scope to bring in the timeline. DoD environment in this climate also is a bit dicey, everyone’s a bit jumpy. That adds to it. I’m going to buy your book Buddha man.

  7. philsimon

    Buddha man. I like that. I wonder if the URL is taken? Maybe I’ll call my third book that–or my fantasy football team next year.

  8. michiko.diby

    Honorific title for your profound wisdom

  9. Dylan Jones

    37Signals.com embody many of the principles I think modern IT projects should follow.

    When you use their web apps they come across as incredibly sparse (if you compare their Basecamp app against Microsoft Project you’ll know what I mean) but they focus on the bare essentials.

    The result is massive popularity and products that go to market in months, not years.

    Contrast that to so many bloated IT deliveries that p***s sponsors/users/shareholders/customers off and take years to deliver, if at all.

    Getting Real (https://gettingreal.37signals.com/) is their manifesto, well worth a read.

Trackbacks/Pingbacks

  1. Phil Simon: Six Archetypes of Bad Project Managers - […] and realism. Sometimes, it’s necessary to put functionality and even entire modules on the chopping block. However, both consultants and…
Comments close 180 days after post publishes.

 

Blog E Data E Analytics E The Chopping Block: Cutting Features From an IT Project

Next & Previous Posts

9 Comments

  1. Dayce

    A sobering perspective, especially now that Agile methodology is catching in company environments that inject their traditional Waterfall attitudes, creating a doomed mixed-methodology approach.

    Again, something that any manager involved in technology implementation should read.

  2. Jim Harris

    Excellent post Phil,

    I have to ask. How long have you been using “Simon says” to make your points?

    Because, I have to say, that is awesome!

    I wish that I had a cool last name. Harris sounds like “harass,” which isn’t a great word association:

    Harrisment: Read all of Phil Simon’s blog posts!

    But seriously, everyone really should.

    Best Regards,

    Jim

  3. philsimon

    It’s a recent edition, my friend. You’re a fan? Cool

  4. Michiko Diby

    “Clients are typically reluctant to cut functionality from Waterfall-based projects for one simple reason: there’s typically (and mistakenly) a “now or never” mentality” Is that ever a true piece of wisdom. Today, a client I’ve been working with for a year..I’ve taken his project through one major and two minor releases and he says that he can’t do another big release. Why? Becuase his experience in the past is that a project longer than 6 months turns into a 2 year project. Even when facing the evidence that my team is honest to schedules, he’s still burned by past experiences with other contractors. Wow. Thanks for drawing this truth out.

    Michiko

  5. philsimon

    Interesting story, Michiko. I can understand the ‘burnt hand teaches best’ mindset but that’s no excuse for putting an entire project at risk.

  6. michiko.diby

    well…it was a “cmon really?” convo that ended with a tentative agreement to reduce scope to bring in the timeline. DoD environment in this climate also is a bit dicey, everyone’s a bit jumpy. That adds to it. I’m going to buy your book Buddha man.

  7. philsimon

    Buddha man. I like that. I wonder if the URL is taken? Maybe I’ll call my third book that–or my fantasy football team next year.

  8. michiko.diby

    Honorific title for your profound wisdom

  9. Dylan Jones

    37Signals.com embody many of the principles I think modern IT projects should follow.

    When you use their web apps they come across as incredibly sparse (if you compare their Basecamp app against Microsoft Project you’ll know what I mean) but they focus on the bare essentials.

    The result is massive popularity and products that go to market in months, not years.

    Contrast that to so many bloated IT deliveries that p***s sponsors/users/shareholders/customers off and take years to deliver, if at all.

    Getting Real (https://gettingreal.37signals.com/) is their manifesto, well worth a read.

Trackbacks/Pingbacks

  1. Phil Simon: Six Archetypes of Bad Project Managers - […] and realism. Sometimes, it’s necessary to put functionality and even entire modules on the chopping block. However, both consultants and…