Problem Statements – What are you trying to solve? June 20, 2007Posted by Darth Sidious in Project Management.
Often in meetings, whether it’s a brainstorming/vision meeting, product management, or for the proposal of a particular project – the support for an initiative is based on what someone wants, i.e. the target is based on the feature itself.
This is incorrect thinking, and I use the dark side of the force to punish anyone who continually thinks so narrow minded. You have to focus on the problem – all project kick off meetings should start by stating the problem (that needs to be solved), or task #1 is to identify it.
The Problem Statement should be on the header of all project documentation as it is your guide to solving it. It’s too easy to get excited about features and capabilities; for example say you bring the proposal of “we want to build a laser cannon.” You can spec it out, and it can be built – but what if the problem was merely for security forces inside the ship to take down Jedi’s who have penetrated the outer defense and are already inside? One, not only would a laser cannon blast a hole through the ship, but secondly Storm Troopers wouldn’t be able to feasibly lug something that big around.
See, unskilled managers will ask the weapons development team to build such a thing – but it doesn’t solve the problem. Don’t ask for the tool; ask for the solution. And the solution is a combination of processes, tools, and policy.
For example, say the software that controls the doors to the docking bays asks the user to ask the pilot a number of questions to ensure everything checks out – and you have an issue where there’s been too many unauthorized landings (usually the resistance trying to get inside); so the management team thinks well let’s just highlight things in red, and do popup warnings on the screen to add extra emphasis.
But if the docking bay operators are being scored on how fast they can get ships docked, there’s no incentive for them to follow the warnings.
So the true solution involves process; by making sure docking bay operators are adequately and periodically trained on docking bay policies, that managers coach supervisors on how to coach those operators, and that managers have exception reports to highlight those users that are not within the tolerances of ‘normal’. You would also augment the staff’s performance appraisals to include adherence to the policy as a performance metric – otherwise if bonuses/raises aren’t in sync or supportive, you’re inadvertently MOTIVATING people NOT to follow the policy.
Now your solution is end to end complete by having software guide the user, but having management enforce the policies. All of which has been defined by the Problem Statement.