Unchallenged assumption #3 Projects are the means of doing work
Unchallenged assumption #3 Projects are the means of doing work
The desire for consistency may lead to trying to apply Project Management approaches to all manner of work, whether appropriate or not. Let's examine.
In the introductory post for this series, I introduced the idea of unchallenged assumptions in organisations that had become so accepted as the way work is done that they become very difficult to challenge, even when doing so would be very impactful:
Seven unchallenged assumptions stunting your company's growth
The unchallenged assumptions I had identified were:
Projects are the means of doing work.
There are others, and I encourage you to share your examples in the comments, but these were the most prevalent ones I’ve experienced.
Projects are the means of doing work
Most people are familiar with identifying tasks, adding them to their task list and completing them. When there is a need to do something with multiple people, the first port of call is usually a project. In some companies, establishing a project is informal; That is, someone is made responsible, tasks are allocated, and a due date is set.
A formal project methodology such as Prince 2 or PMBOK is in place in other organisations. Most organisations sit somewhere between these two points on the spectrum (I will come to other approaches, such as lean or agile, separately later).
These organisations claim a formal methodology but have a fairly light and simplistic implementation. For many, a Project is simply a group of tasks that, when completed, achieve something useful, usually within constraints such as a timeframe and a budget. In many cases, this is more than adequate!
A project structure is often a perfect way to approach getting something done. We know what needs to be done, and the main risk is coordination. Did each person involved do what they needed to do when needed to? It is best suited to deterministic work where the problem, the solution, and the steps to realise the solution are well known.
Problems with projects as the default organising mechanism for work
As I will cover in a future post, there are reasons why Projects are a natural go-to for organising work, but the most significant one is the prevalence of working this way that it has become a default.
Defaults are useful. They help us avoid reinventing processes and thinking, which is to be repeated many times over. They are often logical options or extensions of what is familiar to us.
In the case of projects, it is seen by many as the natural extension of how they manage their personal task list—focused on completing an activity within a timeframe with progress made in completing tasks. Projects are treated as a container of tasks, a collection of activities completed within a timeframe.
According to PMBOK definitions, a project is a temporary endeavour undertaken to create a unique product, service, or result.
PRINCE2 defines a project as “a temporary organisation that is created for the purpose of delivering one or more business products according to a specified business case”. Projects have an end and aren't designed to last very long.
If you find the content in this publication valuable, there is an upcoming event that you may find worthwhile.
Register to hear Daniel Walters and Noah Cantor discuss 'Managing Individual and Team Performance'
The assumptions
Formal project management approaches (sometimes described as ‘traditional project management’) define projects far more flexibly and richly, but that is not how they are most often treated within organisations. Even organisations that supposedly comply with one of these standardised approaches to managing projects tend to use only the most basic concepts - a project start date, an end date and possibly some milestones.
This is because it is easy to apply the assumptions from how one manages their task list and scale them up into how projects are managed, even though some key aspects are different. For instance, there tend to be more people involved, and the interrelation of tasks within a project matters.
For this reason, there is a need to establish approaches to managing dependencies, coordination, constraints on who works on what and when work on tasks can commence, and many other mechanics that become critical aspects of managing projects. And these may be concerns that have less than adequate attention invested.
This framing has a primary focus on work through the lens of activity. Progress is, therefore, understood primarily through the completion of activities. A second but equally challenging aspect comes from what tasks are aggregated together as a project.
It can feel like the obvious way to handle any work beyond an individual. As it becomes the default at the organisation, there’s more effort to try to handle the work differently.
The challenge this presents is twofold:
Projects are used when other approaches to completing work would be better suited.
Projects collect together activities in ways that can increase dependencies and add delays between activities.
Projects are used when other approaches to completing work would be better suited.
An example is work that could be a standard process within a permanent operational team being progressed via projects. Another is when software development is being managed through projects when it might be better served by a longer-term commitment of a development team owning and improving service over the long term. The commonality between those two examples is to use the temporary project capacity - the people gathered together for the duration of the project - to do the work rather than leverage a fixed role or team to deliver the work and realise the value.
One driver for organising work into projects, even when it’s not the optimum method for completing the work, is the desire for consistency. A certain amount of control is felt when ALL the work is captured in the list of projects and programmes.
The cost of this consistency is underestimated as the effects are indirect. The effects can be that users of systems wait longer for trivial services to be delivered instead of being delivered as a consistent service through dedicated competencies and processes.
Systems take a long time to be in a state that addresses the user needs in a way that’s positive for the business because activities that must combine to deliver value are artificially separated, which brings us to the next issue.
Projects collect together activities in ways that can increase dependencies and add delays between activities.
This can happen when certain combined activities can add value separated in different Projects. One of these Projects may be in flight, and the other is on the waiting list. It can happen when certain activities are categorised as being of a certain scope that is outside the agreed project scope.
Scope management is a sensible practice, but the choices of scope boundaries can often be quite arbitrary. For instance, when functional separation is used to define scope.
This way of working has become so normalised in organisations that you can observe in many organisations people making statements such as “We will deliver these features, but security is out of scope” when using the features safely would require effort to apply security measures).
No one will say this is good project management, and the formal methodologies offer plenty of guidance to avoid such scenarios. It happens because comfort is drawn from negotiating scope to increase the likely success of the people in a project. The likelihood that there is some optimising for the convenience of the project team is high.
Where functional separation intersects
Within projects and even across projects, as we will explore later in this post, it's common to see tasks organised functionally. This appears logical for much the same reasons we covered in the earlier post:
It may be convenient for the tasks relevant to specific roles to be gathered together, or it may be helpful to understand how smaller activities come together to complete larger activities. For instance, a project where one step is making a cloud environment available may require many smaller tasks, such as setting up instances, setting up users, granting access, etc.
The plan or schedule, the main mechanism for coordinating work by different people with different skill sets, can be an issue. Of course, hybrid approaches are increasingly common, where more frequent meetings and discussions of progress enable opportunities to unblock tasks with dependencies or obstacles.
More levels of aggregation: The Programme
Just as tasks may be aggregated into Projects (or Projects are broken down into milestones and tasks), Projects may be aggregated into Programmes. The issues of functional separation can occur at multiple levels.
Not only will there be legitimate needs unaddressed being explained away because elements to deliver on the need are in different projects, but you may experience the same across Programmes. Unfortunately, this will not be met until all the projects in another programme are delivered. This can even seem like a reasonable expectation in such organisations. After all, this is how everything works!
A project can also be made dependent on the completion of another project or programme. It’s not unusual to see something that should be addressed sooner because it is in the organisation’s best interest to be delayed because of these dependencies. When projects and programmes can run for months or years, the unnecessary delays can be huge. This may happen many times over within a single organisation!
The alternatives
As I cover extensively in this publication, an alternative or complement to understanding progress as completed activities is to understand progress through evidence of progress towards an outcome.
Manage a project to outcomes
Move work from projects to service delivery
Consider fixed capacity talent for software delivery
Be deliberate about choosing the right approach to work
Manage a project to outcomes
Formal project management approaches include realising benefits and defining milestones and progress in meeting non-functional requirements or other criteria.
The use of these practices across many organisations I’ve observed is fairly infrequent and often is secondary to understanding progress through completion of activities.
Even when applied, the realisation of benefits is often later in the project’s life, and opportunities to help correct the coursework to maximise positive impact are missed.
More recently, a positive trend has been observed in organisations using measurement in the form of OKRs and KPIs as the primary measure of progress for a project. It’s still the case that this work might have been better approached not as a project but by an established team, but its progress nonetheless.
Move work from projects to service delivery
Another alternative to using projects is identifying work better handled by a service delivery or operational team. The work that might suit being handled like this is high-value needs that have consistent demand and for which the value of the service benefits from predictable delivery.
If relevant service delivery teams don’t exist, you may need to consider investing or reallocating talent from the project pool - that people are available to be allocated to project work.
Consider fixed capacity talent for software delivery
The agile and lean movements of the past few decades have been the most visible challenge to the default approaches to project management. This has been wildly successful in some places and extremely fraught in others.
Where it has been successful tends to be in areas that are competitive, there are rich and evolving needs to address, and there is strong value in learning about the customer needs over time to best meet them.
When it goes wrong, common reasons are:
Applying assumptions from Project Management experiences to more adaptive approaches to work—for instance, task allocation, planning someone’s time usage to 100% utilisation, functional separation instead of organising around value etc.
Failure to adjust other aspects of the system to allow for the learning and adaption elements of these approaches. For example, locking down systems such that frequent small changes regularly are impaired by a gate or queue to address access or authorisation issues.
Applying agile or lean approaches where a formal project management approach may have suited better. For example, there is a large component of managing third parties, largely deterministic work, etc.
The first two issues are challenges to overcome if moving to an agile or lean approach whether as a project or as a fixed capacity team.
The last issue leads us to another alternative to having projects as the default vehicle for work.
Be deliberate about choosing the right approach to work
In the same way that projects being an unchallenged default leads to work that is inappropriately delivered by a project, you also can over-correct and start moving work that is best delivered as a project by other means.
This doesn’t need to be an elaborate process. It might be adequate to ensure leaders at the relevant levels are familiar with the different means of approaching work and applying judgment.
For more complicated environments, it may help to have guidelines or heuristics or to use an approach such as Wardley mapping to consider the most appropriate approach to delivering on different components and needs.
Once work is established with fixed capacity teams, whether service, operational or development, it should be ensured that the relevant demand for these services comes directly to these teams or is routed directly to the relevant team when the need reaches a customer service or service desk team.
Do you observe the same patterns within your organisation? Is all the work being managed as projects best served by this approach? Share your experiences in the comments.
Good article. In my experience organisations will mostly start projects in order to incubate change and to try and develop a new way of working. We can argue over the effectiveness of each specific approach (and I know plenty that have failed) but the execs who sponsor these projects tend to come to the project decision because they have been ineffective through operational methods or regular service delivery.
Now I fully agree with your critique of "lazy thinking", which applies to both operational methods and projects equally.
As a C-level exec, across most organisations from startups to large enterprises, there is often a challenge to get more done with less. At the startup end of the spectrum you often dont have the people or skills needed to make a specific change, so you initiate a project with people augmentation. Or at the enterprise level you need the current business to keep on running but explore a new thing or way of doing work that requires a specific project. It so happens that many projects in these circumstances fail. There is extensive literature published on this, both within software and outside it.
However I dont think the choice of a project versus another method of delivery is the source of these failures/overruns/problems/issues/etc. What I think lies as the root cause is a reductionist and deteministic mindset. The reductionist mindset tells us that if I break a thing down into component pieces, make the pieces and then assemble them that will create the end result that I need. This is a separate discussion and, in short, prompts the need for systemic thinking.
The deterministic mindset tells me that if I do a thing (in this case a project), I will get the desired outcome without considering the possibility of variation. If something unexpected happens and the project will be delayed then the question is usually "how long?" This is the typical challenge of determinism, not the question "how likely is it that we get another delay?"
The assumptions to challenge are reductionism and determinism, not projects.