Project management thoughts - 3. Parallel development issues

This is a continuation of the "Project management thoughts" series. Please read the previous posts if you haven't already.

In this post, I shall talk about why the parallel development of prototype and real application is not a good idea in a case like ours.

Why prototype and real development should not be in parallel

The purpose of the prototype is to try out different brainstorming results of the client and solidifying requirements from it. Now, the scope of the new requirements and 'change requests' to already solidified requirements have no limits, officially.

Let's take a break and do some basic maths of project management. A project has three main key factors: Time (T), Material (M) and Resources (R). Time is proportional to material and inversely proportional to resources. This can be represented in the following way.

T = M / R
or T x R = M

Meaning: 1. If your time is fixed and if you increase your material, you also need to increase your resources, 2. If your resources are fixed and if you increase your material, you also need to increase your time, 3. If you material is fixed and if you change your resources, your time will get changed, and so on.

I'm sure most of us know this in one form or another and I only described in details for the newbies.

Now back to the prototype, if the prototype continuously gives us new requirements through out the whole project time line, we need to have time open ended, according to the simple math that we done above, but that not an option in the first place. This is fixed time project.

Besides new requirements, the prototype will also yield a list of small and large changes (large, in terms of task volume). These changes need to get reflected in the already built features of the real application. The changes, of course, are materials (M) which requires more time (T).

The changes imposed from the prototype will virtually have no limits. If we have already implemented, for example, 20 features in the real application that were previously solidified, those may require complete or partial reworks in a very short time. Adjusting major changes in the requirements makes a solid codebase messy, making it more vulnerable to major bugs. Re-structuring, re-designing (the software design) and re-implementing are probably the last things a development team wants to do. If requirements get changed every now and then, which we cannot guarantee, may end up with unexpectedly weak software design and codebase.

There are also other factors of why it doesn't seem to be a good idea to run prototype and real application development in parallel. One of them is the time it takes to solidify requirements from the prototype. If we assume that we shall get requirements solidified from the prototype at a constant rate (or at a good rate) then it would be very wrong in real life. In practical scenarios we may get some or many of requirements solidified from the prototype and we may also need to wait a significant amount of time to get something solidified as it is very much dependent on client's decisions. 'Waiting' on a dependency for uncertain period of time for a 'fixed time and resources' project like ours (or in any project), is just one of the failure factors.

The better solution

Our proposed solution was to complete the prototype application first, with the effort of the full development team, solidifying requirements from it, and then working on the real application, again with the effort of the full development team.

This solves a lot of problems, the ones that I mentioned above. The only concern with this way is, can we really complete the prototype with all ideas of the client in time and then can we finalize requirements from the prototype in time? Well, it requires effort from both of the side, the team and the client. Both parties need to work aggressively towards one goal, which is to identify requirements within a given time frame.

To be continued.

Coming up soon: The team formation, the technologies, the tools used, the prototype phase, the software design phase..

[I shall continue to talk about my project management experiences and thoughts about this project in regular posts. I hope you shall find them interesting or useful].