The traditional definition of a ‘project’ is an initiative that achieves an agreed objective and is temporary, with an identifiable beginning and end. The term ‘project’ also conjures up for many people the dreaded ‘waterfall’ with gates, milestones, dependencies, Gantt charts, resource allocations, work breakdown schedules, and the rest. But ‘projects’ don’t have to work this way, and there are many different types. For example, in my current team we have defined three types of projects that we work on, which each operate quite differently:
- Technical builds
- Transition projects
- Continuous improvement
The first kind we usually run using scrum, as absolutely agile as we can manage (which, for sure, is not completely agile). In fact, my team doesn’t actually ‘run’ these, as much as we track them.
The second kind refers to business transitions that involve multiple components and may include hard deadlines imposed externally. For example, I work in financial services, so the kind of thing that might impel this kind of project would be transition to a new system, onboarding or offboarding a large asset base, meeting a new regulatory requirement, etc. These projects often have to be run more traditionally, because milestones and dependencies and hard dates are very real in these cases. We still aim to be as ‘lean’ as possible, aiming for minimal documentation, minimum ‘hard dates’ and simple status reporting, as far as we possibly can.
The third kind can be a mix of small short initiatives and longer-term changes, and may not even always have a defined end, although we try to impose that whenever we can.
In all cases, the important thing is that we are trying to create or improve something
In all cases, the important thing is that we are trying to create or improve something, whether it is being run as a project (has an end date) or is being built as a product (initial build may have an end date if everything planned gets delivered in the original timeboxes, but delivery is ongoing and iterative and maintenance and support continue forever).
I’m not sure it is really possible to run an organisation on a ‘sometimes project, sometimes product’ framework. Maybe it is? but you probably have to choose (or split your organisation in two). Many corporate organisations cannot truly commit to product/agile – even if they are building products.
‘Product’ should definitely be the organising principle when building a customer application. Not least because after you build and deploy it, you have to maintain and support it, but also because, to develop a good product and continuously improve it requires a completely different mindset.
But not every ‘technical build’ is about building a product. Sometimes you’re building something small or temporary, or augmenting something that already exists.
‘Project’ might not be a well-loved concept these days, but really it just indicates at least a semi-organised way of delivering something. ‘Project’ does not need to mean PMP or PMBOK or Prince2, or any other methodology – just as ‘agile’ does not need to mean scrum.
In my workplace three teams are actively working together – project/Change team, Technology team and Product team – and figuring this out as we go. It’s challenging, fun, interesting, frustrating at times but always evolving. It can be hard not having a defined, mutually agreed framework in all cases, but our guiding principle is: let’s work together, agree on the leanest framework possible for the requirements, and get the thing done.
the non-project project 