The Value of Projects – Do we always need them?

Img_1915 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?

Comments

re: The Value of Projects – Do we always need them?

Good question, David! When I started in IT it was punch cards and Assembler or Fortran ... but that was at college. Yes, I did learn MVS systems programming on green screen on an IBM 3158. Projects were a few people then and they all sat in one room.I just visited on of our customers on the day of the first successful end-to-end test and the complete project team was located in one room. That is really the way to go. Most spread out projects - in scope and people - fail!The other way to avoid failing projects is to stop coding, but start to use environments such as our Papyrus Platform where a project consist of mostly definition and a little scripting. The project assets are tightly life-cycle managed in a repository with automatic deployment into production on Windows, Linux, Unix or z/OS. That approach also enables to start small and grow in an adaptive manner towards what the users want. That makes your applications - you guessed it - AGILE! I really hate the word by now ...

re: The Value of Projects – Do we always need them?

Hi Dave,The solution is to remove all the programming and use what is in effect agile generative model -driven development. Novel and important. See wood despite the trees. But how do we tell you this cut off as you are by the impenetrable Forrest growing in the your Scottish Glen!?Graham .graham.clmsuk@gmail.com