Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Dividing a project into multiple milestones for tracking purposes

Our team was used to working on short projects, doing projects that had a total duration of between 2 /3 months. For such short projects, we would meet regularly (twice a week or more, depending on how close we were to the release), and would review status at each such meeting. In these meetings, based on status, we would take decisions about where we were, whether we were ahead (rarely) or behind the expected point in the project, and what were the next steps (whether to ask for more resources, ask people to put in additional hours, or re-define the feature set). These types of meetings worked well for us, and we were able to track our projects well enough from such a tracking timeframe.
And then everything changed for the team. Due to a re-organization inside the company, and after merger with another smaller company, the team was made part of a different group and handed over a product that was released once every 20 months (approximately). As a result, using past processes became impossible and we had to figure out new ways of doing things. Talking to previous people was difficult, since many of them had been let go, and in such a atmosphere, it was not possible to contact them for getting this sort of knowledge transfer. It was an extraordinary situation, and we spoke to multiple groups within the company to try to get some answers for this issue. Further, we also consulted a lot of literature on the ideal process to follow.
We evaluated Scrum as well, but after evaluation, Scrum was not recommended.
The final recommendation we got, and which we ended up following was to break up the long schedule into many review milestones. We decided on a review schedule where we set up review milestones of 5 weeks each, with the following further details:
– Before every milestone, we set out desired list of features that we wanted to accomplish for the next milestone
– We set up review meetings along with demo meetings for every milestone
– We set up post mortem meetings for every milestone so that we could figure out what was going on right and wrong
– Since we depended on a number of 3rd party components, we collaborated with these teams and put in a number of items for tracking of deliveries from these 3rd party milestones
– We setup once in 2 week status meetings (could call weekly if the situation so demanded) where we would review progress and make changes accordingly
These steps worked out perfect for us, and I am happy to state that the product release was in time, with good quality, and many a people in the company were surprised at this.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>