Problem statements are not easy to develop. I know this, which is why I try to instill in engineering students the importance of writing an effective and meaningful problem statement. And yet, there I was yesterday, in an initial project meeting, buying into a “client’s” list of wants, not needs. I walked out of the meeting convincing myself that we had to retrofit an existing workflow and series of business processes – and migrate 11 web sites to a new platform – to accommodate the client.
As TCers know, it’s needs on which we build our functional requirements; it’s needs that we vet, organize and rank to determine how we’re going to solve a client’s problem with an information product. It’s needs from which we create alignment (stasis) throughout the product.
By this morning I’d diffused the wants (and other extraneous commentary) down to a single, actual need. It’s a need that does not warrant anything close to what the client imagined, proposed, or expects. In fact, it’s a need – a real life business requirement – that is being met with existing workflows and information products. It’s just that the client is too clueless to understand this.
I’ll likely spend more time than I should documenting the actual problem and detailing the existing solution to politely convince the client he's missing the point. But that’s part of what we do, right?
No comments:
Post a Comment