Beyond Projects, Beyond #NoProjects

My recent “#NoProjects - why projects don’t make sense” post stirred up a fair bit of discussion, both on the blog and especially on Twitter - check the #NoProjects hashtag. But, while that post railed against “projects” it didn’t say much about what we should do instead. Indeed as was pointed out it might be better to advocate and rally behind a positive alternative rather than negative idea.

So let me try and put in place the outline of how I see a #NoProjects world working.

(Strictly speaking it might be better to use the hashtag #BeyondProjects but a) #NoProjects has already built up momentum, b) #NoProjects actually describes what we are talking about quite well and c) #NoProjects has 4 fewer letters than #BeyondProjects.)

Stable teams: first off the teams that do the work need to be stable and they need to be kept together over the long run. Of course teams will sometimes loose people and they will sometimes expand. But over the long run we want team members who will live with their creation and grow with their creation.

Teams rooted in business: These stable teams needs to be based with their business users and customers. There should no divide between “the business” and “IT”. IT shouldn’t be hired guns who get called up when there is a problem.

Increasingly, as more and more everyday business depends on technology “the business” is a technology business. IT departments as we know them may cease to exist in time.

(Naturally there are some differences between Beyond Projects in a corporate IT environment and in a software vendor environment. I won’t go into the details here. But, on the whole it is corporate IT departments who have a project obsession and practice corporate psychopathy. Continuity, if not stability, is usual the norm for software vendors.)

Business as usual (BAU) is the source and destination: Everyday business, business as usual, is the source of requests for technology changes and the destination for such changes. Many of these changes will be small - incremental - but others will be big. The people who do the work will be involved with uncovering the need for change and in working with the change when it occurs.

The need for change management will decrease considerably because IT will no longer be inflicting change on unsuspecting users. Instead technologists will be bringing requested improvements to willing customers.

If you need change management then it too will be based in the business lines of work. So too will be testers and business analysts. In fact the role of business analyst will become far more important because they will be charged with work with real stakeholders and helping them find ways to improve the business processes, products and delivery. BAs will look more like internal consultants than the order takers they are sometime used as.

Continuous stream of value: the result of this model will be a continuous stream of value. Technologists will be delivering improvements to the systems regularly, every few weeks if not every day. The batch size for work request and delivery will be one.

Again, as more and more businesses become IT businesses - business which can only exist and compete through the use of IT and IS systems - the value delivered will be bottom line value allowing the business to compete and stay ahead of competitors.

Portfolio management: this is not to say that all lines of business - and technology teams - will exist for ever. Some lines will need be to closed. Some teams will need to survive with less technology. Conversely, work streams which are seeing growth and performing stronger than the wider company will benefit from more resources.

The activity of reviewing work streams, increasing capacity, reducing capacity, starting new initiatives and terminating existing ones needs to be pursued more rigorously than before.

True portfolio management needs to be practices on a regular basis - at least every three months. And it needs to look at value delivered, potential future value and costs. Portfolio management which looks at progress against plan, or measures success as “on time, budget and scope” has no place is the Beyond Projects world.

Like trains: trains run on schedules and so should software projects. When trains leave the station late and arrive late they are poor performers. Just the same goes for software work. We want work which begins on schedule and arrives on schedule.

When this happens co-ordination becomes simpler. The train schedules are known weeks and months in advance. Yes they change sometimes but not often. When you know the train you are going to get you arrange your journey around that.

When you have to take connecting trains you know how much time you need. You might allow a buffer or you might take a risk and run between platforms. How many of you readers have missed a train or a plane recently? Humans are very good at working to deadlines and very poor at estimate how long activities will take.

Co-ordinating multiple pieces of work between different teams becomes a process of putting the features/functionality you need from another team on their train. You inject work into the other team. And the receiving team will be able to tell you their schedule and whether the train you want to put a feature on is overloaded. They might even offer you a discount for going off-peak!

Project managers: obviously without projects there are no projects to manage. But does that mean the end for the people we call project managers?

I think not, there is still work to manage. I disagree with many in the Agile community - and particularly the Scrum community - because I don’t think all management work goes away. There might be less but I think those who argue “you don’t need managers” don’t really understand management work. (In truth most managers don’t either. Go and read Managing by Mintzberg then we can talk about what managers actually do.)

Many of the skills good project managers have will still be needed. They may take on another co-ordination role or they may become business-as-usual managers. Rather than having “Project Manager Call Centre Renewal Project” on their business card we might see “Call Centre Development Manager”.

Management roles will still exist but they will manage real work.

Goodbye matrix management: with projects gone and technologists based in the business much matrix management should disappear. Matrix management has never looked like a great idea, at best it is confusing at worst it is dysfunctional.

There will be more line management and there will be more need for business line managers to understand technology. Some of those surplus project managers will be well positioned to take up the new roles.

(Indeed I suspect that the proliferation of project managers in the last 20 years has much to do with the reduction of middle and junior managers that occurred in the 10 years before hand. First corporations cleared out their management ranks, then reinvented them under the cover of “projects.”)

There then are the basics of #NoProjects, Beyond Projects. I’m sure there is much more I could say and much more I will say in time.

If you have any opinions on this please add them below, I’d really like to hear what people think. And especially why you think I’m wrong, what have I missed? Go on, tell me!