IT Consultant at KTK
10 February 2003 19:58pm
Hi Everyone, I'm trying to write a problem statement for this IT project I am doing, but I can't get my head around what I should include. Actually I don't know how to even go about writing a problem statement.
Can someone please suggest a few pointers or suggest a source of information on the Internet? Your help will be much appreciated. Thanks.
P.s. I really like this site, it's got everything I could possibly need. Well I hop :)
Director at Nukta Ltd
17 February 2003 16:07pm
Hi there Adam,
A good way to look at these things is to work out why you are trying to write a problem statement, who the audience is etc. There must be a reason that you need to do one and once you get your head round that, the rest falls into place,
If you would like further help, then by all means drop me a line and we can talk it through
Project Manager at Invisible Site
27 February 2003 07:15am
A problem statement can be simply defined as the definition of the problem to be solved by your project. If you break this up, you have two things you have to do:
a. Define the problem
b. Do it in such a way that you have enough information to solve the problem
If you accept that most projects that initiated to solve a problem (or fill a need), then you have to start off by defining the problem. We're not talking about objectives or goals yet. Objectives are what you want to do or achieve. Before we can think of that, we have to know the context in which we have to operate.
Problem statements typically define the domain of the problem. This implies that your problem have to give who will work on the project a clear and concise description of the various entities and actors and how they interact with one another.
Let's say that you boss has decided to create a sales force automation (SFA) product. Now, before you start thinking about what you have to build, you have to define the problem domain. This will help you better define the scope of your project (i.e. what's included in your project and what's not)
The first thing NOT to do in writing a problem statement is to stare at a sheet of white paper, rack your brains and hope that the words will come out. Here's a more systematic 3-step process for coming up with a problem statement.
1. Define the problem. Define the overall reason why you need this project in the first place . We need the SFA product because the current sales process is not generating enough sales.
2. Mapping out the problem. Break down the overall problem definition into its component parts. This means indentifying the entities, actors, processes and relationsships between each. I find it handy to use the who, what, when, how test. In the SFA example, actors would be buyers and sellers. Entities would be purchase orders, product evaulation, sales offers, sales invoices and so on.
For example, ask who does the selling, what does he or she sell, when do they sell it, and how do they sell it. Repeat for the persons buying the stuff. Then think about how these two parties interact. Do they meet online, at your companies place, a conference, or at the buyer's location? What process do your sellers use to sell goods? Then think about all the other entities and actors that may be related to the seller and buyer, like your company's order fufillment department and so on.
It'll be easier if you make a map or flow chart of all the entities, actors and relationships. Start with the most obvious objects first, then brainstorm for other players that have to interact with you main players. Only put down the actors and entities that have a direct bearing on your problem. What's most important is that you put down the things that you team needs to know to get the job done. If they need to know how the buyer decides on a sale, then you have to try to map that out (you might need to add functionality in your software to help youe seller's close the sale)
3. Describe the problem. If you have been diligent with the two steps above, this part should be easy. It would just be a matter of describing your problem map above in more detail, like defining the attributes of each actor and entitity and pehaps some simple business rules. This wil give you a head start in the job of writing down the specifications of then project
Hope this helps
Tech Lead at Teletext
04 March 2003 16:59pm
Rather than thinking in terms of problem statements, I would suggest thinking about your project in terms of a.) the business case for doing the work and b.) risk.
If you're unclear about the business case then I'd recommend more strategic analysis before you even commit to proceding with the project. If you're clear about the business case then a "problem" is essentially anything that's a risk to you delivering on time and budget/realising the business case.
I find that thinking in those terms clarifies any discussion of what constitutes a "problem", and also has the major benefit of keeping everyone focused on why you're doing the work in the first place!
On 19:58:07 10 February 2003 Fox wrote:
>Hi Everyone, I'm trying to write a problem statement for
>this IT project I am doing, but I can't get my head around
>what I should include. Actually I don't know how to even
>go about writing a problem statement.
>Can someone please suggest a few pointers or suggest a
>source of information on the Internet? Your help will be
>much appreciated. Thanks.
>P.s. I really like this site, it's got everything I could
>possibly need. Well I hop :)
05 March 2003 07:13am
Thanks for all your help guys, especially geoff, the three step approach is exactly what I needed.
Free market research on digital marketing
Daily Pulse: award winning newsletter
It takes 30 seconds to register