Friday, June 20, 2008

Project management thoughts - 2. The initial team and tasks

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 mostly talk about the initial tasks of the project TP and my thoughts about it.

The initial team

Even though the project now have 20 engineers, it began only with 2 engineers. The primary goals of the initial team were to understand high level requirements of the project and to estimate required resources for the project. The initial team members were:
  1. A senior engineer with around 2 years of experiences, skilled in C#, Java and PHP
  2. Myself
The initial team worked around for 3 weeks to capture high level requirements of the project, business goals of the client, preferred development process of the client, preferred technologies of the client and the time line of the project. The detailed requirements specification was not defined and one of the first goals of the project is to identify and solidify the requirements.

The initial plan

The client wants to identify the detailed requirements with a prototype project. The prototype project will follow agile development method and needs to have a weekly build on which the client would like to try out a few different ideas and solidify detailed requirements as the builds go on. Basically the prototype project will be a brain storming ground for the client and requirements capturing ground for us (ReliSource).

The client wants a separate development project to run in parallel to the prototype project and the solidified requirement sets should be sent to the development project team for real implementation.

The idea is to test different things on the prototype, solidifying them and to build them in the real application. Both of the prototype development and real application development needs to go in parallel and the project, actually the first release, needs to be completed within six months.

Sounds doable? Well, not exactly. I shall post about 1. why not, 2. how we proposed a different strategy which was doable and also made the client happy, in my next post.

2 comments:

we4tech said...

just a bit curious,
as you mentioned you are running two branches of development, where one branch is working on new ideas and second branch is working on real implementation.

if i had to do such thing here in somewhere in... i would do it more in agile way.

here is how i would love to do -
TEAM - A
works with idea, design, concept and so on...
come up with new design delivery and new user stories
this team will have less developers only those who like to experiment (developer + scrum master + product owner + clients)

TEAM - B
this team starts their sprint right after when TEAM-A completes their first sprint (actually they will work on the output which were given by TEAM - A)
someone from TEAM - A will hold the product ownership role.

this team can be bigger (dev team + test team + scrum master + product owner)

thanks for initiating such brave blog.

Kaisar said...

Hi Hasan,

That's the exact scenario one would think about to do the parallel developments using agile (Scrum, in your example) based development.

But there are some practical and real life scenarios that may block the development progress, for both of the teams. I've explained that to my next post. Please check it out.

Thanks.