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 client
2. 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

There are so many classic issues contained in this approach it is hard to know the best place to start! Firstly I will say this, an Agile approach may suit you better because of the way it handles functional requirements and technical debt (bugs and issues) however I personally have no direct experience with that model. I'm sure someone will come along and discuss that as an approach. However, in the meantime, assuming you want to stick with a waterfall model:

• Project Managers gathering functional requirements: This is not a traditional PM task and is more suited to business and systems analysts. BAs are trained in teasing out the exact functional requirements and presenting them in a way that the client can approve and (hopefully) the development team can use in their estimation and development processes.

• Planning: Clearly the PMs are not planning the projects with enough contingency to allow for unforeseen issues, impacts from other projects overrunning and critical bugs and issues. It doesn't sound to me like this is an estimation issue (depends on how wild the developers' estimates actually are and how much they differ from reality). It sounds more like hopelessly optimistic planning and mismanagement of expectations. These are all areas where perhaps the PMs could benefit from additional training.

• Capacity planning: The people that are responsible for planning how the resource pool is allocated and assigned (you don't say whether this is also the PMs) need to get smarter with their understanding of the different output rates of the team- Some will always be faster/more prolific that others and when making up the team for any given project this knowledge has to feed in to the planning- pretending that everyone works as fast as the fastest member of the team is somewhat delusional and will always result in over-optimistic planning. It is also important to take into account the impact on the existing team members of adding new members that need to be trained/mentored or even just assimilated into the team- the effect is never just on the productivity of the new person, it affects the productivity of everyone around that person. The other side of the capacity-planning coin is that in a pure software house/consultancy environment, utilisation is king. No company can afford to have people on the bench, so a sales driven environment will always overload the personnel ("sweating the assets") - This will never go away and it goes with the territory, however by better planning and understanding of the productivity of the people it could be better. Management must also play a part in this and be led to understand that if you push people too hard corners will get cut, quality will fall and more time will be spent fixing the quality issues. Additionally there will usually be relationship or reputational damage. Balancing this against a non-charging "bench" of under-utilised people is always a tricky task. Easy to get very wrong and very very difficult to get right.

• Management blames developers for being unable to prioritise : This has a simple answer- Developers DO NOT prioritise the issues. The PMs, maybe. The BAs, maybe. The client, always (once you get to UAT). Someone somewhere should be discussing and balancing the outstanding issues and informing the development team of the priority order of the bugs. Simple as that- Developers are probably the worst group of people to ask to prioritise the bugs and issues as they (usually) do not have the higher level/business-oriented view of the project. In my personal experience I, as PM, usually facilitate the prioritisation of issues. During the SIT stage we do it using a risk-based approach (to over-simplify it, fix the things that move the product closest to the Acceptance Criteria) and during the UAT stage I work with the client to figure out what is most important to them.

One last thing, you don't mention testing in your waterfall process. Is that because you don't do it or just because it is "so obvious" that it doesn't need mentioning? If you go straight from Developer/Unit Testing to the client/go-live, then you are asking for trouble. The team needs to do System and Integration Testing (SIT) before the client ever sees it and that needs to be properly planned by someone who understands testing; not a PM and definitely NOT a developer. This is where the tasks undertaken by proper BAs come into their own as their specifications are used by testing professionals to construct test cases and then to prove the product works against those test cases. By the time the client gets to see the code it should already pass all the tests the client will ever run against it. UAT should be a simple thing (though somehow it never is!)

Hope that helps. Good luck!

EDIT after re-reading question: Given it's a small company you probably don't have the scope for adding BAs and testing resources. However I would seriously question why two PMs are needed for four developers- For that many people I cannot see how you need more than one PM running multiple projects. If you dropped a PM and replaced then with a BA who has testing experience that would be a much better mix in my opinion.

Answer 2

It surely is a tough ask to manage concurrent projects with limited resources. I have been facing these issues lately and found a way out by implementing agile and some bits of KANBAN.

I ensured that there is a PM + task management tool, that supports me in all processes throughout project life-cycle. I implemented Redmine to manage projects and tasks. Linked all team members on to the portal, defined sprints after conducting scrum of scrum and further holding daily scrums to ensure project/task timelines are met. Unfortunately, me as PM was also responsible to collect and document requirements and later on test them on staging.

To summarize, I would suggest you following quick steps:

1. Implement Agile Scrum
2. Implement project + task management tol (redmine, basecamp, jira, TFS etc)
3. Create a KANBAN Board to monitor
4. Before initiating a project, conduct a scrum of scrum.
5. Conduct daily scrums for active projects.
6. Ensure the team members update task statuses on the PM Tool.

These steps would pretty much control the chaos with managing multiple projects.