The iron triangle in project management tells us that a product is the result of…
In three earlier blog posts I talked about multi-functional teams, matrix management and maintenance. In my maintenance article I argued that maintenance work on an application should be done by the developers who were responsible for building it. However, I also pointed out that this introduces some additional resource planning problems…
When software developers are responsible for multiple projects, you always end up with complications in resource planning. This is not just the case when you let developers perform maintenance on previous projects. Similar problems arise when they are required to do some other activities, like spending time on consultancy or estimations for projects that haven't yet been signed into contracts. Likewise, believe it or not, many developers actually need regular training, or they like to do some quality/infrastructure stuff for the organisation itself.
Therefore, maintenance work on old projects is a challenge, but it's just one of many types of work that can take people's attention away from their current projects. This requires a professional approach to resource planning…
I think there are 3 principles for resource planning:
This is how we have implemented these principles in our company:
Resource planning is not difficult. It just requires some discipline to do it right.
People should be able to trust that their resource manager has thought long and hard on how they must distribute their valuable time over multiple activities. And they should always know which other managers they must turn to for the details of the work in those allocated timeslots. And when the resource managers make sure that there's only a minor level of task-switching, then it's entirely possible to have a small number of people working on a large number of different projects and activities.
Subscribe to this blog with a reader or by email!
Latest, greatest and favoritest posts:
How to Do Many Projects (Part 3): Maintenance
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)