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 :)

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

// Geoff

Thanks for all your help guys, especially geoff, the three step approach is exactly what I needed.