Ever-Changing Business Requirements
A typical time-span for projects we deliver here in Wind Mobile is about six months. That’s considered rather as an average size when talking about systems for mobile operators. However that’s definitely enough to see significant changes in this competitive business environment between the beginning and the end of the project.
Usually before we finish deployment we get a list of features which are to be ordered just after final acceptance. These are either new ideas which appeared during implementation or features forgotten during initial negotiations or things which appeared not very useful or usable during tests and need to be improved.
A great environment for agilists you would say.
Well, yes indeed. Except of I’m yet to see mobile operator which would agree on that methodology for a typical business project. Quite often it’s hard enough to break even a little step in implementation procedures, not to mention putting a whole thing upside down.
What option you have then?
• Go for agile. At least you can try. With typical business project it can be hard, but for projects which can be classified as R&D it’s easier. I’m lucky enough to work with that kind of approach with at least one of our customer. And for goals we put on our roadmap it works great. Unfortunately in most cases I can say you won’t be allowed to use agile approach with that kind of customers.
• Manage it. You work with one of old-fashioned ways. You have scope, you have schedule and here you go. Each time when new requirement appears you manage it – add to the list, decide whether to implement it or not. And once decision is made you take whatever it brings. Additional effort, retests, changes in other functionalities or... nothing. As far as you decide consciously you shouldn’t cry about it.
• Scope creep. That’s the previous option but left alone without any control. Sure, they will try to put in as much new features as possible. Sure, being a naysayer is unwise but so is the other end of the scale. If you enter to uncontrolled scope creep you won’t reach the goal in fair condition. It’s a difficult decision to set up the best point when you start to reject but a crucial one.
• Be a naysayer. Talking about naysayers... you can always say: “Hey, there’s an agreement and I can’t see even a word about the feature, so you better forget that until we see a signed purchase order.” You’d be surprised how often this approach is used. I’m not sure which scenario is worse – this one or scope creep. When you have a standard answer for every question, most of the time this answer won’t be any good.
It’s always worth to look for the most reasonable way of working with changing requirements. Agile brings very good answer for that, unfortunately its implementation quite often isn’t feasible (that’s subject for another post by the way). But each process which involves a common sense and a bit of analysis to decide individually what to do with new or changed requirement should work well.
I’m curious what your approach in that area is.
4 comments:
I think I am fond of "Manage it" approach but I would call it "Prioritize and manage". It's funny how well Pareto principle fits in this situation. There are two implications of this principle:
1. 20% of the requirements bring 80% of customer's satisfaction, so focus on them.
2. 20% of the requirements need 80% of your effort, so try to avoid them (e.g. negotiate them with the customer).
Following these rules you can prioritize your requirements. There are "good" ones (cheap and effective) and "bad" ones (expensive and with little importance to the customer). When you focus on the good ones and negotiate with the customer to exclude or postpone the bad ones, your project will be successful.
i agree, however you can if you want pick and mix, you can manage the strictly software side/development using agile principles and manage the client using a structure method..it works i've tried it before.
Mike, I think your approach is the most reasonable one. Unfortunataly you can't always convince a customer to follow the Pareto principle. Sometimes you just have to do whatever client needs even when you believe it doesn't make much sense. They pay and they expect.
Andreas, to some point you can try to hide your nice agile software development methodology under some heavy old-school technique shown to the customer. But you just won't have the customer playing actively in your agile process. It'll be a bit lame.
By the way, can you tell a bit more how the process were organized? How iterations were planned? Did you manage to gain some attetion from the customer before deploying the whole thing?
Post a Comment