Projects don't come about through some law of nature. They're a mental construct we've created to help ourselves manage our work.
I spend most of my time on projects.I've worked on projects to build e-commerce systems, projects to build and update websites, projects to create new products, even projects to define the way we do projects within an organisation.
The idea of a project as the fundamental unit of work is pretty pervasive within our industry. Many organisations structure themselves almost entirely around the portfolio of projects that they are undertaking.
And a large industry, think of PRINCE2 and the PMI and various other project management bodies, has emerged solely to service the interests of projects and project managers.
But how real are these projects?
Somewhere along the line we've reasoned that dividing the stuff we have to do into discrete, tightly-bounded chunks called projects will make it easier for us to coordinate related activities, communicate with people affected by our actions, and so on.
In other words, a project is a model. It's a mental abstraction we use to help ourselves make sense of the world. And, as the saying goes, "All models are wrong, but some are useful".
So the concept of a project is a simplification,life sometimes doesn't split cleanly into projects. Thus I often see problems such as the following:
Projects create artificial boundaries between activities.
For example, they create a split between building and operating websites and other systems.
One day we're building out elements of the site as part of a project; the next day we're making similar changes as part of day-to-day operations. And the mechanisms we use to prioritise work, allocate resources, etc, all change completely overnight.
This creates conflict, confusion and overheads: arguments about what constitutes a "bug" versus an "enhancement"; change management boards to classify work between the two; dispute resolution mechanisms, and so on.
Some activities don't fit neatly into projects.
People have to do a lot of stuff that doesn't have anything to do with a specific project, product and customer administration, system maintenance, staff training, etc.
Because this work isn't part of a project, we don't allocate time for it, don't set up mechanisms to resolve conflicting priorities, and otherwise fail to manage it.
This then flows over into our projects. How often have you seen a project fail to make the expected progress because people's time is being frittered away on other activities?
Or conversely, how often has necessary work been overlooked because people were too busy on their project tasks?
We set up projects that are ragbags of loosely related activities.
To avoid the above problem, we try to put everything into a project, so we end up with projects that aggregate an incoherent suite of activities into one bundle purely for the convenience of our mental model.
And again this creates overheads, people spend time listening to status reports on activities that have absolutely no bearing on their own work, for example.
These are all signs that our model is breaking down.
It's interesting to look at some of the trends going on in software development in this light. For example, agile development teams are going into progressively tighter iterations.
30 day sprints were the norm when Scrum first came into vogue, but seven days is much more common now. And kanban teams are moving completely away from the idea of defined projects and iterations in order to try to deliver a continuous flow of new features into production.
This aligns with the pressure on most organisations to deliver change more rapidly, and at the same time creates big questions for the idea of a project as the defining model for organising our work.
I think this "flow" model is going to get a lot more mileage in the coming year.
That doesn't mean that the idea of a project is irrelevant. Some work does fall neatly into projects. And the idea of a project has served many organisations well.
I can certainly think of several organisations where lack of a well-defined project portfolio and project management structures has created an unholy mess. Interdependent activities are run independently, with consequent problems at the interfaces.
People with common goals act at cross-purposes with each other. And no-one has any clear idea of what is going on overall, nor of how people's time and attention are being prioritised.
But projects are no longer the only game in town. Be prepared to adjust the model to fit the realities of your situation, rather than vice versa.
Graham Oakes helps people untangle complex technology, processes, relationships and governance. He is a guest blogger on Econsultancy.
No hay comentarios:
Publicar un comentario