Small firm with 4 developers and 2 project managers in need of some guidance for project workflow?

Question

I work as a developer in a small IT firm with 4 developers and 2 project managers.We currently implement some sort of traditional project management, in which the workflow for a given project is as follows:1. Project manager gathers functional requirements with client2. Lead developer analyses the requirements and puts estimated execution times on these requirements.3. Project manager calculates project price based on estimated execution time + management overhead + some margin for error.4. The client agrees to the project price and is promised a deadline.5. The project gets developed and delivered.6. The client notifies us in case of bugs / need for additional features/ ...7. Eventually, the bug notifications/feature requests fade out.Every project we make is tailor made to the specific needs of our client. This means that task estimates are sometimes off (it's hard to estimate a task you've never done before) or that certain technical issues only arise when we are in the middle of development. This frustrates our project managers greatly, as this usually means we overshoot our estimated cost of development and our profit margin for the project slinks.However, the greatest frustration originates from missing deadlines which were promised to clients. This is because we have, at any given time, always 3 or more projects in active development. Next to that, the developers are often called directly by clients for questions/technical issues/emergencies. There's also the extra overhead when tasks are shifted from one developer to another, which then have to be explained to the developer that receives the task.Every week, one of the project managers assigns tasks to the developers that need to be finished that week to meet the deadlines. Of the 38 assignable work hours per developers, 4 hours are left unassigned to account for unforeseen events. There's also a new developer that just joined us three weeks ago, and he needs some technical help from time to time which also, on average, takes about 2 to 3 hours of my time every week.In conclusion, these 4 hours have so far never been sufficient. Communication with management, high priority bugs, ... takes longer than 4 hours every week. Management blames the developers for being unable to prioritize and says we should put more effort in making accurate estimates and actually meeting our deadlines.My question is this: what is the right approach here? How can we better estimate the scope and duration of a project and effectively set and meet its deadlines? What needs to change?Thank you in advance.

Answer 1

For unforeseen events, you should be using risk based contingencies as specified in the PMI handbook So, 4 hours is not the right answer in most cases.. You should do one estimate at the end of requirements, which is plus or minus 25%. After design, you should know more, and be able to estimate it at plus or minus 10%. You should still have risk based contingency with an estimate of impact for each risk added into the estimate. This is based on what that risk would do to the project. The contingency also applies to schedule. You should consider having an estimating database for all of the work that you do. This could help you even if all projects are different. You can count complexity, modules, and more to have a formula to at least guide you based on past estimates and actuals. You should also use change control very strictly to avoid inflated scope without doing a re-estimate.. I hope that this helps. I managed projects from tiny to ten million and found success with these guidelines.