There are many reasons that cause a delay for a project, it due to specific situations. But is there a tricky thing to slow down your workflow, that always happen in most of your projects? What is that?
The case study below were shared by other project manager, for perspective exchange purpose.
About the contributor: Terry Woodward has been a Corporate Project Manager, a Director of Data Services and a Development Manager for SOF Inc., with the total 30 years of Tech experiences.
When it looks like a project is going to have trouble meeting it’s deadline, one of the common attempts to compensate is to try to expand the team by adding more resources.
While on the surface, this may seem like a good idea, it often has the effect of slowing progress even more .
To know why, let me tell you my practice.
On an early software project we had for a Fortune 500 customer, I had a team of three core developers working on a new set of image processing technologies.
Each of the developers had a different functional area of the project to work on. The Client had an unmovable deadline due to the re-assignment of existing personnel timed to coincide with the delivery of the software.
At about 70% completion stage it began to look like it would be difficult to meet the deadlines due to some complications with newly released hardware drivers used in project, so we a decision: add another developer to the project.
In the beginning, it looked like this was a good idea because some of the remaining core work could be divided and assigned to the new developer.
What happened in practice is that a whole new layer of communication needed to be added to coordinate the work.
Where previously it was easy for the three developers to meet to coordinate interaction with their specific area of responsibility, the addition of the fourth developer added:
- the need for extra communication to manage the split work
- the historical background to the direction of the project
Meeting time increased, coordination became more difficult, progress slowed even more.
After all, the 2 lessons I have learned from this experience are:
- Carefully factor in increased communication cost when team size expands and;
- Consider subdivision of work in ways that minimize the need for additional communication.
For example, bringing in a Q/A engineer to manage testing instead of adding an additional core development engineer in this project, would have reduced the need for core level communication and would have likely accelerated the progress because of the functional division of responsibilities.
What you guys think about this experience, share your cases to others 