I entitle this note “The Fictitious Difference Between AMS and ADS“. (AMS = Application Maintenance Services : ADS = Application Development Services or something similar). Now, from an organizational perspective there may indeed be a difference when it comes to how the changes get funded. One may be capital funded and the other operational. Or it may be that there is a cutoff in terms of the effort: less than x days of effort it is maintenance but over that it is a development effort.
My real concern is over how people seem to treat AMS and ADS as different things. One is managed in a certain way while the other is managed differently. One follows different steps than the other. One uses different processes/procedures than the other. One may even use the tools differently. But why?
For instance, let’s take a maintenance effort to add a couple of new pages to a website. Seems simple. But before the project gets started they add one more page to the request and suddenly the project changes from being maintenance to development (because of effort or funding, it doesn’t really matter). My question to you is this: should the project be run differently. if the answer is “yes” then there is a problem. A serious problem. A problem that is so large that I’m not sure that I have enough time to discuss the problems over the course of the next five years.
Ah, more Jessop hyperbole.
Nope, darn well serious. Whether a project is AMS or ADS should not impact whether or not you produce a weekly status report for your effort. It should not determine whether or not you create a new set of servers or re-use existing servers. It should not determine whether you take a copy of the entire code base and create a new TFS repository or just create a branch off the current trunk. It should not determine whether you use Agile, Scrum or Waterfall. It should not determine whether or not you do performance testing.
There are a billion and one things that should not be determined by whether or not a project is AMS or ADS.
And yet it does.
There is a growing voice in the development world crying out that we shouldn’t be having projects to develop new applications. Instead we should be developing products and managing the product lifecycle. You may be developing a major change, or a minor change, but it is to the same product. You may be funded by capital dollars or operating dollars, but those merely provide the funding, they do not make changes as to how a product is enhanced. Where you get your funding may change who receives the status report, but the status report is still created. It may change who gets involved in the steering committee meetings, but it doesn’t change the fact that you have one.
Changing how you develop based on where you get your funding, is an admission that what you are building is deemed an expense and not an asset. Oh, sure, if done with capital dollars it shows up as an asset on a balance sheet, but it is still thought of as an expense. We don’t build systems of engagement, we build products. We don’t build applications, we build user experiences. We build products that provide a user experience and in the long run, it doesn’t matter to the user whether that was a capital funded project or an operational project, all that matters is that the product and the experience was created.