Every time Facebook makes changes, the interwebs alight with sharp criticism. Without fail. Are people really that adverse to change? Are the changes that disruptive? Or is there some other reason for the predictable uproar? There has to be a lesson here.
Category Archives: Project Management
What Would You Like?
Discovery phases are often started by asking stakeholders, “What would you like [application X] to do for you?” Once they get over blank slate syndrome, a laundry list of wants, needs, brainstorms and brain-farts pours forth. Someone hands off that list with the title REQUIREMENTS on it. A project scope is born.The document is handed to the business analyst who is told “This is what our users and stakeholders told us they need.” The BA validates the requirements asking “How important is this feature?” “We must have it.” say the stakeholders. Everyone puts forth their best efforts and designs a smashingly feature rich design. The stakeholders look at it and give their stamp of approval.
Then the development estimates roll in. Reality steps in and suddenly you have to revamp the design to something that costs 40% less. We’ve all been there.
It’s at this point that the team starts asking questions that let you determine what’s in or out.
- How often will this feature be used? By Whom?
- What value does it bring to the user? the business?
- What is the impact if it’s not included?
- How great is the cost of human error?
- How much money is currently being lost because this feature is not there?
These questions should be asked before and during design. Talk to users. Find out what they do, what issues they are trying to solve. Find meaningful criteria by which functionality is scoped so that you don’t end up including every idea that the team has. If a feature saves someone 1 hour once a year, is it worth developing? Everything added increases the cost of complexity.
Without meaningful prioritization criteria, scope is a playground for political bravado and never-ending debate.
Save your sanity. Do some user research. Build some metrics.
Of course, if you’re agile, you shouldn’t have this problem.