Posted by Dave West on December 2, 2008
When I started in software development writing Cobol, sitting in an office with my humming green monitor. I was part of an IT department that was linked to a business department. The work I did was in direct response to my customers requests for new features or changes to existing features. We planned work at the start of the month and worked through that list during the month. Yes, there were cross department projects, but that was handled by everyone involved sitting in a room and saying ‘if you do this, we can do that’. It was a simpler time, a time when you could leave your screen unlocked and you had a real lunch hour.
Ok – I am not just getting nostalgic for the sake of it, I honestly believe there is a need to re-evaluate the way in which we use projects as a mechanism for structuring and managing work and remind ourselves that there are different organizational approaches to developing software. This realization came to me as I talked to a number of clients about the use of Agile approaches and Lean thinking in their development of software. Many clients have run into problems when trying to implement one product backlog, stating that they need many project backlogs and then some mechanism to bring them together. They need a backlog of backlogs (or a scrum of scrums J), and then numerous processes to manage the impact of change across those backlogs. The process starts getting more and more complex and harder and harder to manage. Can the application of project structures on work delivery be artificial?
I consider four things when deciding if work should be grouped up and considered a project.
- Size of development team – When a team is large and work needs to be planned in a large amount of detail to take advantage of these resources then it is important to introduce a project structure and appropriate management and reporting to ensure this is working.
- Location of development team – When a team is spread over many locations it is important to put in place organization constructs to better enable these individuals to work together.
- Large amounts of cross organizational dependencies – When a set of requirements require a large amount of change outside of the domain that is driving the requirements it is important to put in place a project organization that includes all those different groups.
- Maturity of the team – Detailed planning and management is often only required when the team is staffed by practitioners who do not have a large amount of experience either in the organization or the problem domain. The project organization provides the support necessary to enable them to be effective.
Does anyone have any experience on when not to use the structures of project to organize and manage work? Or do we need different types of projects to better manage the work, with some being lighter than others?