A Project is a temporary collaborative endeavor undertaken to create a unique product, service or result (through a series of Releases)
This definition of “Project” is close to the PMBOK standard and points out some key features of a project:
- It is temporary, once its aim has been met it finishes
- It is collaborative, it uses people and resources
- It has a specific goal, normally one primary goal
Strictly by this definition most work to create a product can be considered a “project”. In HSD we often talk about “product development” and “projects” fairly interchangeably because of this. However, the word “project” also invokes ideas around traditional “project management” that can be counter to modern ways of working with embedded bias towards waterfall methods. As a result, we see a lot of focus on “teams”, “cells”, “delivery units” etc. The software industry needs to move past this discomfort. When we use the word “project” in HSD, we mean a temporary collaborate effort to meet a specific goal or create a product through a series of Releases
Project != Project Management
A Project in Holistic Software Development
In Holistic Software Development we consider a software project, whether in explicit form, or an implicit collection of activities and people one of three ways:
1. The Small Picture of HSD
The Small Picture of HSD is essentially a map of a single project.
2. A stand-alone Project
When Projects aren’t part of a programme, they are simply stand-alone projects as part of the Portfolio. This means that their requirements will derive directly from a Business Case (or Portfolio Request) although they won’t need intermediate levels of requirements elaboration or Solution Architecture as the only architectural context is Enterprise Architecture.
The Project boundary is further expanded as a stand-alone project is responsible for raising its product to the highest required level of done and will also normally have product adoption and business change as part of its scope.
3. As part of a Programme
When Projects are part of a Programme they get a lot of context from the programme in the form of requirements (a programme backlog), planning (some form of coordinating roadmap) and architecture (Solution Architecture).
A Programme will normally be responsible for sourcing development and test environments for the Programme as a whole rather than each child project diverging, but sometimes a Project will have to source its own environments if it is unique.
A Project that is part of a Programme will deliver its product to the Programme iteratively and incrementally, if not continuously, for integration with output of other Projects to form a Product Family.
During development we recommend seperation by interface between Project teams, not source sharing dependencies.
The Programme is normally responsible for adoption and business change of the entire solution, delivered incrementally rather than individual Projects.
Due to this structural relationship, Programmes can feel like the customer to Project/Delivery teams. Programmes, may actually be a Business Customer (in that they are coordinating funding) but they are not the Product Customer, which should be a real end-user Customer wherever possible.
If conflict is likely between Programme Business Customers, Product Customers and delivery teams the Product Forum practice is ideally suited to de-conflict the situation.
Projects with Internal Structure
Within a project (in either shape) projects may have internal structure as teams are organized to deliver the primary aim of the project. Teams are often organized into function teams and component teams, delineated by architecture, work streams/packages or other patterns. All have their advantages and disadvantages, the key thing to bear in mind, is that pull is established across each team to the project. Teams must be formed effectively and understand their value proposition to the project and in turn the business. When considering internal project structure be mindful of Conway’s Law.
Critically, the definition of done must be understood between teams without losing focus on the teams’ collective responsibility to deliver the product as a team of teams. More information on cross-team interactions is in the Team-Forming practice.
Projects may encompass a mix of agile/iterative teams, continuous flow teams and other delivery models as part of Product Delivery.
As mentioned earlier, the “project” construct isn’t necessary for product delivery. Various delivery methods ranging from Incubators, Accelerators, Hackathons, organic cells etc. exist to deliver projects. Sometimes it’s useful to treat all of these things as “projects” as it makes sentences shorter when talking about portfolio management, which is why we often use “project” with a lower case “p” to cover these pieces of work.
The hybrid dynamic model, and HSD in general, embrace multiple methods. We recommend that leaders enable multiple processes to be used in parallel for different types of work. There is little to be gained from standardization of creative knowledge work and a lot to lose.
Project/Product Managers act as leaders for teams performing critical communication roles, dealing with stakeholders, coordinating with other teams, mitigating local risks, driving continuous improvement etc. Not all teams need Product/Project Managers as some teams perform these functions as a group.