Posted by: ahmedashfaque | October 14, 2014

What is a project division? Excerpts from my book


In instances when it is felt that the requirements are not clear enough to proceed with the later stages of the project, it makes a lot of sense to divide the project into two parts. The first part will deal with developing the requirements to the point where they can be taken for designing the application, and the second part will deal with the development of the software application. This is a good way to remove all uncertainties from the project. The requirement development part of the project may not have a fixed deadline denoting completion (as there is no previous knowledge as to how many requirements are there in the first place), but when the requirements are crystal clear, the other part of the project to develop the software application will have a lot of clarity, and thus, timelines and cost can be predicted with some good accuracy.
One alternative to project division is also available. It can be done this way. First, the customer can ask for open bids from service providers with just the preliminary information which is available about the project. At this stage, price or any monetary information for the project is not included. Once a suitable service provider is chosen, he can be asked to make detailed requirement specifications. These specifications are then handed over to a third party expert who provides project size information based on the requirement specifications. He hands over the project size information to the customer and the service provider. The customer in turn can calculate the required budget for the project given the prevailing market rates for software development costs. The service provider calculates the schedule and the number of people required to do the software development on the project based on its productivity level. So at this stage, project budget, project duration, and the number of people on the project is fixed. Later, if the requirements are modified, then the impact of the change on project schedule, project budget, and project team size can be calculated, and the project information can be adjusted accordingly.

On paper, this arrangement looks good. But what are the weaknesses of this model? Well, one point of contention is how good the bidding process will be. After all, without detailed information being provided for the bid, how can service providers make good bids? Then, how is the customer going to know which bid is good and which one is not in the absence of vital information on bid responses like project cost, project schedule etc. So the bid selection will be mostly arbitrary. This is the weak point in this model.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: