Lack of Scope - a project killer for sure..projects with no finite definition of 'are we there yet?' and clients with little patience for being 'pinned down' to a set of deliverables. You WILL have these clients from time to time, and they are most certainly manageable - in fact they can be quite profitable clients in many cases, they just take a different style of management. In my years of managing technology projects, I've discovered that there are some fairly classifiable reactions to lack of scope.
The responses to lack of scope run a wild arc from doing surprising little for the money to packing so much into a project it becomes unusable. Many experienced firms will see lack of scope as a great money-maker as they will promise little and give even less. The client doesn't know what they need, so they never know if they received any value. If they dare complain to the development firm, they will be met with 'We gave you what we promised'. Note this is a far toss from 'We gave you what you needed'. Inexperienced architects tend to 'overgive' - they feel that if they 'just do more' the client will love the end result. The problem with this thinking is that it's usually NEVER enough of the right stuff and WAY too much of the wrong stuff. The client wants a shopping cart with 'all the bells and whistles' so the provider creates a shopping cart with 30 different kinds of discounting methods, but no wishlist or forward-to-friend functionality, so in the end it's discovered that the client really meant that he wanted more 'social' functionality and less 'pricing' functionality and the client is disappointed. Here it's a case of 'we did our very best' - but we all know that this is a slipperly benchmark at best. The client creates these situations as it's sort of a 'I'll tell you when you guess it' approach to project management, and it can be tricky. These clients aren't evil and they aren't stupid, the're just busy. The good news is that I've discovered something..if you know what you're doing you can usually strike a really nice balance for the client with very little input.
The reason an experienced (and introspective) manager can find the sweet spot so easily is because they have done so damn many of these types of projects (whatever type it is) and they 'just know' what needs to be in there. Also, you learn to read a client, their culture, and past projects they have commissioned and you get a feel for what rings their bell. With the understanding of 'what just works', some knowledge of the clients psyche, and a little patience, you can give the client something that is in their budget, satifies their wish to get some value out of their investment, and most importantly, actually creates a positive result for the client.
Subscribe to:
Post Comments (Atom)
3 comments:
Well said, Bill. But I'd note that your perspective is an "earned" one... you have the background and the intelligence to sort through shifting or non-specific requests and deliver what's really needed. That only comes from long-term, in-the-trenches, experience.
That experience creates value for clients even when they don't realize it.
It's also about the relationship. Trust... an overused word, but an unfamiliar concept for most...
Keep up the great work!
Mike
I've become so numb to lack of scope projects that I actually enjoy them and I kind of dislike the tightly scoped projects. One of the differences I see between the two is that the lack of scope projects are generally from the "money" people and they just want a project to help the "little people" below them. They tend to get as little information from the actual end users and then even less to the developer.
I agree that the relationship makes all the difference. I've been successful in a majority of my projects just because of knowing what the client wants without them even asking for it. The problems come when you have a tightly scoped project where the end users have set a very detailed scope and you've perfectly matched it with your design and you purposely leave out the nice little touches that you'd normally include because of the scope. Then, the end users start testing and they get ANGRY that some undefined process or report isn't included. Your only defense is that "It's not in the scope document". Not a win-win.
Whenever I start a lack of scope project, I try to communicate that this will be a process. Each iteration will need to be tested and notes taken and suggestions communicated to me for development. It definitely adds to the cost of the project, but the overall satisfaction level is much higher. This is the heart of "extreme programming". The more feedback loops you get, the better the outcome.
I guess the relationship is most of it - I hadn't looked at it quite that way, but yes, you eventually get to the point with these clients where they give you short orders and a long leash..ultimately you begin communicating in grunts and nods - like an old married couple :)
Post a Comment