What are the required documents should I prepare In order to start my Project

Question

I am preparing to start my new project which is Developing open source ERP System What really I am confusing about:

1. How to start : what is the first step should I begin with. ( Preparing the environment or preparing the documents first )
2. what are the documents that should I prepare? ( I read about PID Project Initiation Document, FSD, BRD and User Guide etc...)
3. Its a good idea to create a blog and website before starting or its time consuming ( or it can be done later).
4. some software that may help

Some clarifications:

1. My Project is about developing Web Based Open Source ERP System
2. I have no real client currently ( so I have no specific requirement for a customer, but of course I defined my project requirements )
3. Since its Open Source is there any extra steps should I consider ? ( community, licencing ? )
4. I have an idea about Project Life Cycles, but in reality how can I implement it.

Thank you for your time, and really I am sorry if my question is not straight to the point, but consider that this is the first time that I manage a project :).

So the image isn't clear for me.

Answer 1

This is a very broad question, from a general "where to start" to very specific about Open Source. I'll focus on the "where to start"…

Regarding the size of this project (ERP) I would start with figuring out if you have a market for it. You say you have no real client as yet, but do you know what you need to convince potential customers to implementing your solution? Can they start with a single module or do you need multiple modules available before you can actually publish something? A project needs a clear goal, otherwise it will start drifting even before you have started .

Next, do you have a team available? Even though it will be open source, will it be build by a commercial team or by volunteers around the globe? Maybe the project should start with some marketing to get volunteers enthousiastic. This kind of project should not be initiated by a single person alone.

Regarding a project Lifecycle depends a lot upon the approach you have chosen or will choose to develop this thing. For now, start with three phases: Preparation (or initiation, what you're doing now), execution and closing. The execution phase can later be subdivided into technical phases (e.g. by release).

Now to the organisation of the project itself (sounds more like a program to me), the first thing to do is to decide upon the scope of your project and communicating this to all your stakeholders. A Project Initiation Document helps in this respect, but personally I start with building a deliverable-based Work Breakdown Structure (WBS) to discuss and decide upon the scope and supporting processes (QA, training, marketing, …).

The WBS will be the basis for that, as well as for creating the PID, some kind of schedule, etc. Since you have your "Project requirements" available, creating a first draft of the WBS will be relatively easy. Furthermore, some kind of 'budget' is necessary, either in money or in number of hours if you're working exclusively with volunteers, to set expectations straight.

Note that 'documents' are also deliverables on your project, so if you want to create a user guide, then it should be visible on the WBS as well. Make a decision about any documentation you think is necessary.

If your team will only meet 'online', than it is a good idea to start with a collaboration environment. However, I would start with a shared dropbox folder or whatever (just keep it simple) untill you really have the project started.

Some final points to complete the PID: - Use your WBS as input for an initial risk analysis. - Finally, determine how to track and communicate progress. Again, the WBS can help here.

When this is clear and agreed to, you can start.

Answer 2

That's a very perceptive question. The first document you should develop is your Project Initiation Document (or project charter as it is more commonly known).

BUT the value of the project charter is not the document, it is the process of creating the document. The point is not to spread ink on dead trees, but to identify the key stakeholders in the project, the fundamental reason for executing the project, and determine at a high level how you'll tell when you're done. The charter is just a way of recording the negotiations and discussions that lead to those decisions.

User guides are for much later in the process. A blog is an optional tool; if it helps you to execute the project, great. But it may not be the best investment of your time at this point.

I suggest that you broaden your research to the project initiation phase, rather than to the documents. (A quick google search will find you a cluster of other sites about the initiation phase). You'll need to tailor the initiation phase to your project; try to understand the purpose of each of the artifacts and then determine whether that artifact will increase the probability of success of your project. The Initiation Phase should allow you to make an informed decision about whether or not to proceed; will the results be worth the effort?

Once you complete the initiation phase, then you move to actually planning the project. That is the earliest place that I would touch the FRD & BRD etc.

If you're doing an open source project, you may wish to look at some of the incubators; they adapt the project management process to facilitate contributions from dispersed participants.

Answer 3

I'm going to assume that you are in the project initiation/start-up phase.

Your very first step should be to have at least an outline of your project's business case. Remember that the best measure of success of a project isn't if it came in on time or on budget, but if it delivered value (in terms of benefits realized post-project) compared to money spent.

In tandem with the business case you should have a description of the end product(s) of your project and a project approach. What are the products meant to do, what are their major subcomponents, are you going to buy off-the-shelf or develop internally? These will help you start to quantify likely costs and benefits necessary to make a business decision on the value of the project.

Note that early on both business case and product descriptions will be rough and approximate only. They will require progressive elaboration as you get more information but should provide ongoing justification for moving your project forward throughout it's lifecycle.

Once your business case and product description and approach are documented the next thing you need is a plan for your planning. Figure out the whos/whens/hows to get your WBS, schedule, stakeholder analysis, risk analysis, communications, governance structures etc etc planned out. The key first step here is figuring out which pieces are necessary and to what level of detail you need them. This is going to be entirely project dependent and largely a judgement call on the part of yourself and your key stakeholders.