What Is a Project?

How can an organization get its hands around all of what is needed to deliver value to customers?

Ask a selection of your colleagues or LinkedIn connections what they think a project is, and the answers you get may vary quite a bit. For example, just over a week ago, I had a great discussion with Steve Tendon, the creator of Tameflow, and Ian Heptinstall, a Lecturer in Project Management at the University of Birmingham, UK. 

The discussion started with Ian sharing thoughts and experiences of his first contact with Agile about two decades ago.  Ian’s thoughts – most of what agile was bringing to the world is just good project management. 

The discussion touched on what a project is. Whether an agile way of working or serial/predictive way of working, in my experience, most projects are focused on a subset of the value-add activities needed to provide value to a customer. 

I ask you to picture the flow of work, all the significant high-level activities that take place in your organization to fulfill a request from a customer or sales team member, or an idea from a Stakeholder to provide something of value to a customer. For an IT-enabled organization, if you are on an agile team, your project typically would start with an approved business case or some other high-level vision/requirements.  Is the work, the agile team would do what you think a project is?

What about the other value-adding activities that may also need to take place?  Was there an earlier project to determine what the value to the customer would be and then approval to move forward?  What about any supporting areas of the organization that had work to do, such as the Marketing area creating a campaign? Was that also a project?  How about operational support (not just support to maintain the IT systems) but changes to business process, maybe training field workers or new activity in a manual part of the process when interacting with a customer.  Is that a project? 

Ian led us into this part of the discussion by calling all of the work to get value delivered to the customer a “Work Package.”  In Discipline Agile, we now have the Minimum Business Increment (MBI), and in Tameflow, there is the Minimal Outcome – Value Effort (MOVE).  Ian, Steve, and I shared our perspective on all three of these, and I feel we arrived at a very similar point. They are containers to describe everything, at a high level, that needs to be done for that value to be delivered.

In my opinion and experience, the MBI is one of the most critical additions to Disciplined Agile.  As a container of information, it bridges communication  through the value stream. We identify all of the value-adding activities from the development value stream (IT), supporting value stream (marketing, legal, etc.), enabling value stream (infrastructure, procurement, etc.), and operational value stream.  This approach replaces the often-disjointed nature of each area in the organization having its project with little coordination or alignment.

Disciplined Agile MBI, Tameflow MOVE, or Ian’s Work Package – there is a growing awareness of how organizations can shift from siloed projects to a strategy that enables value to flow quickly to customers.

If you would like to learn more, please watch the Live Stream Event that I did with Steve Tendon and Ian Heptinstall here: Un-Common Sense No. 9: Two Constituent Parts that Agile Project Management Has.