When your team is on to executing a project, there is always a task-breakdown (Milestones->Features->Tasks etc.,) exercise done. The way you do the task decomposition is, most of the times, influenced by how you/your team had done it in the previous projects. But, as your project goes on, there might be some feedback - be it internal or external - that helps you revisit the effectiveness of your task-breakdown. This might enable you identify the opportunities to execute the project better and faster, yet respecting the sustained development.
This is some lesson which our teams learnt by practice when the things forced us to do so. Here is an example of how we learnt this hard lesson:
Quick background of the project...
- The project was about migrating a System-level application, from one hardware architecture and OS to another hardware architecture and multiple other OS platforms.
- This was the project which had the potential to change the fortune of our company (in fact, it did) and could help us move to a “Next” level in the business. Thus it carried a greater business importance.
We were thinking, we were doing just right...
- The major portion of the “Task Breakdown” in our project plan was done based on the “Functional” features of the product. “Task Distribution” among the team was done based on this.
- We were doing incremental code deliveries every 2 weeks or so. We were almost 30% into the project timeline (excluding the time we spent for the initial Inception and Elaboration activities in the first few weeks). The line items on the MS project planner were looking GREEN. :)
The customer’s feedback that made us rethink our approach...
Things were looking very bright and we were thinking that we were on the right track, until we got this message from the customer side on a fine day.
"The customer, in his feedback, politely screamed that they were not so happy with the project progress per the validation metrics they were using".
- The customer stated that, as per the Automated testsuite that they were using for measuring the project progress, hardly 8-10% of the testcases were working whereas we were almost 30% into the project's timeline.
- The customer’s concern, in this case, was not about the Quality but the question raised was whether our team would be able to complete the project on time.
- It was HIGH time that we had to win the customer back in the game. Definitely, and without choice, we had to do something about it.
Then, how did we react...
An immediate jerk reaction would have been that the project manager asking the team - ‘Let us slog it out, and bridge the gap, come what may and I promise you late-night dinners:)’. This would have made everyone run around the clock. But our team, guided well by our project manager, did something different. What we analyzed was the fact that we could do the work breakdown and distribution in a different way.
- There was considerable overlapping(duplication) of efforts with individuals owning the tasks based on “Functional” Features. This meant that more than one engineer were working on migrating the same source code files at the same time.
- The corrective step taken was to break and own the tasks based on the 'Sourcecode files' to enable us perform bulk modifications in an iteration. We had enough technical details for doing this and I am not mentioning them here.
- Now, our iterations became slightly longer because we needed to have enough room to test the bulk code modifications before delivering the code drops. We explained this to the customer and got their acceptance as well. Of course, “All conditions Applied” works neither for the customer nor for the service provider. There needs to be reasonable trade-offs made.
With this approach, we bridged the gap that we had with respect to the project progress and also continued the same approach for the rest of the project duration.
What is meant to be conveyed through this example?
- Breakdown-into-Tasks doesn’t have any standard formula. As long as your approach to this is logical and your team knows how to validate, it is right-for-the-project and right-for-the-context.
- Practically, you cannot get all your practices defined to the perfection when a project starts. You just cannot get started with too many variables in hand. Also, the demands of the project are always different at different times.
- It is about your continuous attention to the details and how do you constantly tune your approach to what-is-more-apt. Probably this is what “Responding to Change” was meant for this specific instance explained.
- On top of all, if you are a project manager, involve your team in making important decisions that would have impact on both “Customer Satisfaction” and “Team Satisfaction”. In this case, if the project manager had a made a decision to “slog it out”, he could have still won the customer but at the cost of the team satisfaction.
Is your team's task-breakdown the best during all phases of your project? Is there anything that can be done better?
(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)