Software Project Lifecycle

I never realised  criticality involved with Software Project Lifecycle until I became part of –

-Undefined Requirements

– Vicious cycle of Rework and Rework

– Never Ending Projects

– Bugs

– Late Deliveries

– Bad Cash flow

Above mentioned points are pain points of any Software Development Startup. At every step of project lifecycle there is good chance of miscommunication/gaps which could ultimate effect the deliveries and company economy or I better say a startup economy. There has to be a full proof process which can take care of all transitions smoothly. Before devising that process I am sure that the process has to serve following –

1. The Requirement Specs should be as clear as possible.

2. Considering requirements will vary there has to be a team which is in touch with client and knows the project right from start.

3. Task distribution is easy, but their status also need to be monitored.

4. Feedback with client are important at every milestone.

5. Quality Check before delivery

6. Most Important – Delivery on time.

Keeping above points in minds I believe there have to be following teams –

Team A – First Communication point. Client gives  a brief requirement and asks for a quote.

A does few meetings with clients and prepares a  requirement doc[R-Doc]. Now A should feed this input to another team-B and gets the effort estimate on top of which A can generate the cost estimate and negotiate with client.

Team B goes through the requirement doc, discusses with Team A, do some magical analysis and outputs an effort and feature doc [F-Doc] and send back to Team A. This team also takes care of Specs.

Now this F-Doc comes to Team C which takes care of implementing it.

Once things are done Team B does a Quality Check (Team B knows the project best).

There is Team D which takes care of timings and make sure deliveries are done on time by poking Team C to do some work actually :).

Well that seems simple. Now lets make this process more clear by discussing these teams.

Team A is Business Team, People in this team should have good sales skills to even sell Used Newspapers at millions  and Business analytic skills to better understand the client Business requirement and prepare our R-Doc( There can be multiple revisions.) Now problem is our Team A is not smart enough to tell  the effort estimate. Well they always think that tough job is done so things should be done by FRIDAY 🙂

Team B is Product development Team. It understands that magical R-Doc and generates F-Doc 🙂 and also tells how much effort will it take. This team should sure have good technology skills to estimate the work correctly, good analytic skills to quality check the implemented work.

Team C is Engineering/Technology team. It is a Black Box , It converts F-Doc into a nice software application. It definetely should have good development, coding skills and debugging skills. After developing this team is supposed to test the application and submit to Team D . Team D asks for Team B for quality check and approval and give a go ahead for final deployment.

Team D is Delivery Team, it  takes care of time and makes sure things get done on time. It also takes care of demos and feedback.

P Team(Project Teams) – They are sub teams of our Engineering Team.There must be multiple projects going around. So there should be a dedicated team for every project. This dedicated team will have Techno-Manager/Project Manager + Project Lead + Developer(s). Team B should involve P teams  at-least the techno-manager and tech lead while preparing F-Doc.

Feedback/Requirement Change – Change in requirements are certain to come. Team D takes care of it.The Client Feedback and Change in Requirements are sent to Team B for approval and modification  in F-Doc, things come back to  Engineering team. Project Manger and Project Lead decides in which release the newly requested features will go in and they are rolled out accordingly.

The above process is explained below.

+Nishant