Earlier I talked about using a ‘Blank Page’ for analysis. This is not my own idea, at least, I cannot imagine that no one else took this for granted. For every project the first idea is set upon an inspiration, a thought. These thoughts, that probably some smart guy or gal had before you came along in the project, need to be streamlined in order to do something good with it.
This is because of the principle I told you earlier: knowledge isn’t power inside a project, or, at least, not always. Thoughts and Inspiration can be the end of a project, of you’re not able to make them concrete, to eliminate the assumptions that lye underneath. This can be done in a lot of way’s. But the six basic questions are the most important ones to ask at the beginning of any project. (I dare to believe that most principles are easily translatable into other than Software project, is this true? Tell me!). Here are the questions I’m talking about:
Who? (and What?) Which people are defined by the project, what are the surroundings, the project scope or system boundaries. The main question, or answer if you like, here is that we need to know what the elements inside our project are. Who are the actors and what are their goals or reasons to be part of this? Who is the problem-holder? Who are the stakeholders? (What is the problem?)
How much? The basic question that lots of us are scared to actually ask. This means that there’s a budget, there’s a price added to the solution you are about to develop. How much means: what is the assumed effort the problem-holder is willing to put into the project, how much (money, time, resources, …) will the problem-holder save with this project?
When? Again: a multi-dimension question. When does the organization need the solution to the problem? When did the problem occur? When does the organization expect pay-off of the solution? When do we start? When do we go into production? What is the time-box we can act in?
Where? Somewhere in the organization the problem occurs, the solution is needed. But where exactly? Is it a department? Just a part? Is it an IT-system? Just a link between them? Is it something an entire business-process deals with, or does it delay parts of it?
How? We can ask this both way’s: how did the problem occur? But also: How do we need to solve it? Sometimes it’s better to know the first one, and then, as a logical reaction, go into the next one. This is the main thing most sponsors know, or think they know. This is the inspiration we where talking about.
And last, but maybe even most important:
Why? Here we, finally, start talking about problems. Or (Surprise!) not actually. What we need to ask here, are the implications of the problem(s) that we are going to solve. Go as deep as you need. This tells us the main reason the project is setup. The reason why we’re there. implications are essential in order to understand what way we need to go, what the solution will be, or needs to be.
I strongly believe that these questions are more often not answered than are. Ask these six small, yet essential, questions in the project you’re currently in. You’ll be surprised how much of these get answered. You even might be surprised by the effect it might raise. One thing in mind: don’t be scared of the outcome.
