I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

Last week, I suggested a first project management concept, that the primary aim of every project is to benefit the business. I also said that projects are about change – bringing change into a business.

And this leads us to a second project management concept: Project management is about making the project environment as stable as possible. What is possible varies.

Let’s explore what I mean by this. We’ve already seen that a business needs to embrace some change to make sure it continues to compete in its market, to stay relevant to its customers. But businesses in general try to be stable – to provide certainty to shareholders and staff.

These two competing demands come to a head in projects. Projects bring change into the business, which means they could be seen as threats to the business stability. Uncontrolled change has a name – chaos. So change can only be brought into a business in a controlled manner.

And this is what project management is about. Projects are about change, so the management of that change is an attempt to control it. It is an attempt to provide a stable environment within which change can happen. That stable environment protects the business from uncontrolled change, while providing a space for change to occur.

But, of course, how stable the environment can be depends on the specifics of the project. For example, a project to build a new office building needs a very stable environment indeed – an attempt to change the design after work has begun on construction is likely to be impossible, or exceedingly costly.

Alternatively, software projects can cope with a much less stable environment – yes, work may need to be done to ensure earlier completed sections are adapted to the new design, but this is much more possible, and cheaper, than with a physical product.

We can see, then that “as stable as possible” can vary widely. This is a natural consequence of the particular change being brought about through a project.

This gives us, then, our second project management concept: Project management is about making the project environment as stable as possible. What is possible varies.

What do you think? Do your project environments push for more stability, or more change? Let me know!

Sometimes things like this happen. I had planned to spend some time writing a post that has been simmering in the back of my mind for a while now. But wouldn’t you just know it, an unexpected meeting has come up, and suddenly I’m only got 15 minutes. But I need to get a blog post done today, now.

Which means I need a new idea to write about, something I can get done quickly. But I was severely lacking in inspiration, or so I thought. Turns out, when the deadline looms, words start to flow.

And haven’t we all experienced that in project management? How many times have you been ambushed by senior management with surprise meetings, attendance compulsory, which knock out your personal schedule of work? How many times have you had a deadline suddenly imposed from outside, and suddenly you have to produce something that hadn’t been asked for, with practically no notice?

I don’t know about you, but I’ve been in that position before. I’m almost convinced there is a type of manager who delights in springing deadlines on his staff, like a teacher handing out pop quizzes to a class.

Hopefully, most of the time these deadlines will just be demands for information on the project, which you should be able to meet fairly easily thanks to the monitoring you are doing. But sometimes you get a real doozy of a question, something that means you have to produce something new.

And this is when all our techniques for managing work, and tasks, and time, are blown out of the water by someone above us. So what do you do?

Well, I tend to embrace the power of the deadline. Like I was saying about this post, inspiration didn’t seem to be coming, but the deadline looming kick-started my brain. And this can happen with your work as well – knowing you have to deliver, and fast, can reduce the mental delays that we all inflict on ourselves in some way.

Not that this is an ideal situation – much as I’d like to kid myself, this post is unlikely to be of a quality I’m happy with. But sometimes, we need to make sure we deliver something with some value quickly, rather than massive value late. So embrace the adrenaline surge the deadline provides, and get working!

And, after the fuss and the commotion of an imminent deadline has died down, take your manager aside and point out to him that, really, you need more notice of these sort of requests! It’s all very well responding in an emergency, but your time is part of the project resources too, and that means you need to guard it as jealously as you do the time of your project team.

I hope this has delivered some value, because I really have to go now – don’t worry, I’ll have a word with myself to make sure this sort of deadline doesn’t crop up again…

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

Today I am going to get back to the very basics. Why do we do projects? What are they for?

I think this one is simple, but far too often forgotten: The primary aim of every project is to benefit the business.

To begin with, let’s look at the traditional view of business as usual. A company has a particular process it goes through to create its product, to produce as many of it as the company can.

One of the things we can say about this situation is that it is steady-state – the company can continue going through the same process to build ever more of its product. But, of course, the environment that the business operates in is going to change. And that means the company needs to adapt.

This is where projects come in. A project is about change. An individual project in this case could be about improving manufacturing methods, developing a new product to make, finding new markets, and so on. While the details of the project may change, all of them are change, about bringing change into the business.

But why would we want to do this? Why bring change into the business? Well, as I have already suggested, a business cannot stay the same while the environment it is in changes. New competitors may arise, economic conditions may alter, suppliers may go out of business.

A company that doesn’t react to these changing conditions, that doesn’t bring change into itself, will fall behind. It will suffer because other companies *are* reacting to the changing environment. These companies will take their market share, and eventually drive the first company out of business.

This means that we need to find a way to help the business. We need to deliver a project that benefits the business.

Now, of course, that benefit can make different forms. In general, the output of the project will directly either make, or save, the company some money. For example, the project may develop a new product to be sold, or improve manufacturing processes to reduce costs.

But this is only a generalisation – it may be the project itself only touches on the financial side indirectly. For example, a project may improve brand awareness in the marketplace. While this improved awareness will lead to increased sales, the project itself doesn’t deliver them.

So that’s why we do projects – we bring change into the business, and by doing that, or at least doing it successfully, we benefit the business. And that is my first project management concept: The primary aim of every project is to benefit the business.

What do you think? Do your projects have a different primary aim? Let me know!

Jurgen Appelo wrote a post a couple of days ago, Your Software Project Has No Goal. His argument was summed up in the first sentence:

Human beings, organizations and software projects share one important thing: they have no intrinsic goals.

Um… no. That’s wrong. And the reason why it’s wrong is in the very next sentence:

The goal of something that emerges from interacting parts is not determined by the goals of those parts.

The key point here is Jurgen is talking about something that emerges from interacting parts, an emergent phenomenon. But an organisation or a project isn’t an emergent phenomenon – they are created, and created with a purpose, a goal.

There are plenty of emergent phenomena all around – the flocking of birds, the building of termite mounds, convection cells in heated fluids, and so on. What all these examples have in common is that they display behaviour at the macro level – that of the flock, colony, or convection cell – which emerges from much simpler behaviour at the micro level – the individual birds, termites, or convection particle.

So, for example, in flocking a bird may only be obeying three simple rules – keep in touch with the flock, travel in the same average direction, but don’t get too close to any individuals. From these three simple rules, we start to get the typical complex flocking behaviour we all recognise, despite none of the individuals trying to behave in that manner.

In other words, the flock doesn’t have an intrinsic goal – it only happens because of interactions between participants having an emergent effect, not because they decide to form and behave as a flock.

Perhaps the strangest example of an emergent phenomenon is intelligence. Billions of neurons are connecting to each other, each individual cell following simple chemical prompts. But out of all of this, we get thought, memory – consciousness.

But the important thing to remember about all of these phenomena is that they emerged not because they were what the individual participants were aiming for, but as an unexpected outcome of it. You can readily see, however, where this breaks down for organisations and for projects.

You see, organisations, at least business organisations, don’t typically start because there happened to be a few people hanging around. They don’t emerge because separate individuals are trying to have a job.

No, organisations start because some individual, or group of individuals, decide to begin an organisation. And this is the crucial difference – an organisation is the intended outcome. To this end, a group of people are employed to be part of that organisation. An organisation is not an emergent phenomenon, it is an intended one.

And because there is a conscious effort to make an organisation, because it is an intended outcome, there is a purpose behind it. The decision to start an organisation is made because it is thought to be the best way to achieve what the creator is after. An organisation starts with a goal, otherwise it wouldn’t start at all.

Sure, once the organisation exists the interactions of the people in it may lead to an unexpected culture. There may indeed be emergent phenomena within the organisation caused by the interactions of the individuals inside it. But that doesn’t mean the organisation has no goal, only that the individuals in it have many goals, some helpful to the organisation, some not.

But because the organisation is a conscious creation, the creators of it harness these interactions, or stop them. For a business as a form of organisation, the simplest generalisation of a goal is to make money for the creators, or the owners. So those efforts of the individuals that help this goal are rewarded – by decree of those on high. Those efforts which damage this goal are punished – by decree of those on high.

And this goal, to make money, is an intrinsic one – it is the very reason the business exists. The reason an organisation can have this intrinsic goal is because it is created – it is not the product of interacting elements.

The same argument follows for projects. Projects don’t (or at the very least, really shouldn’t) start because there are some developers sitting around twiddling their thumbs, time on their hands, nothing to do. No, a project starts because some conscious agency, a creator, decrees that there is a problem to be solved, an aim to be met, a goal to be achieved.

That act of creation means the project starts with an intrinsic goal – again, because a project does not emerge out of the interactions of those within it. It is created, and then people are brought into it.

Of course, the intrinsic goal may be a bad one, but that doesn’t mean it doesn’t have an intrinsic goal. As a starting point, it is probably fair to assume the intrinsic goal of all projects in a business is to make, or save, the business some money. Why? Because then the intrinsic goals of the project and the organisation are aligned – meaning the project is far more likely to have been given the go ahead to begin.

It is the fact that an organisation and a project both have a conscious act of creation, an act with a defined purpose, that means they both have intrinsic goals. Religious arguments aside, there was no conscious decision made to create a race of hairless apes who run around asking questions, which is why humans don’t have intrinsic goals.

Human beings: no intrinsic goals. Organisations: intrinsic goals. And, sorry Jurgen, but yes, your software project does have an intrinsic goal.

Recently, I’ve been tweeting about trying to put together a ‘crash course’ on project management. I’m seeing and hearing about a lot of people who are being asked to take over project management tasks and roles to try and cut costs. Not surprisingly, I think this is a false economy by any business (I would say that, I’m a project manager…) but figured if you’ve been put in that position, you just want to try and do your best to make it work. You want to get hold of the tools and techniques that can help you deliver the project successfully. Hence the crash course.

But this post isn’t about that course – I’m still trying to polish that, and decide what to do with it when it is finished! (And I’ll make sure to let you all know too.)

No, this is about what else I started thinking about while putting that course together. You see, the crash course is focused on the tools and techniques we use as project managers, what we use to get our job done. But it occurred to me that by just showing these, I was giving people a false understanding of what project management is, and how to do it well.

I’ve been guilty of this on this blog as well. I’ve been writing it to try and help new project managers, and to help myself refresh and retain the project management knowledge I have. But again, I have only been displaying the tools, not the whole picture.

Of course, it’s easy to understand why I have been doing this – the tools are pretty simple to teach. Oh sure, they may be complicated to use, it may take a lot of information to show how, but it’s a simple process – you are just moving information from one brain to another.

But that’s missing the most important part of what project managers need to have – they need to have an understanding of the concepts behind these tools.

Put it this way – it is easy to describe a hammer. You can talk about the handle, the head, the materials it is made of. You can describe the process of using it, how you place a nail, strike it to drive it into a material. All of this you can do in great detail, with great precision and accuracy.

But if you don’t explain the reason you’d want to hammer a nail, the person you are teaching knows how to use a tool, but not why. They are capable of doing a task (putting a nail into a wall) but not of understanding why it is useful (to hang a picture). Knowing why you are doing the tasks allows you to make better judgements – suddenly you know to position the nail so the picture gets good light, and so on. The concept informs the task.

And that’s what I want to get to. By only teaching the tools, I run the risk of creating project management automata – able to carry out the tasks, but with no understanding of why they are carried out. In other words, the very paint by numbers type of project manager I talked about the other week.

I suspect that gaining an understanding of the concepts behind project management goes hand in hand with the changing perception over time of what a project manager is, as set out by Cinda Voegtli at Project Connections in Evolution of a Project Manager (hat tip at Raven Young).

So, that means I need to try to teach the concepts behind project management too. That’s a bit scary. Concepts are hard to teach. Learning them, really learning them, takes effort, experience, reflection, and a whole load of coaching. And even that isn’t guaranteed to work – concepts require understanding, and understanding can’t be given, it can only be gained.

Not that that is any reason not to try, of course. So over the next week or so I’m going to be knocking around a few ideas about what the key concepts are over on Twitter (you can follow along too), then I’m actually going to try to explain them.

Wish me luck…

Recently I’ve been looking through a few TED talks, thanks to the iPhone TED app. I came across this great talk by Barry Schwartz, and wanted to share it with you. What I think is very interesting for us as project managers is the recognition that sometimes rules don’t work, and incentives can skew behaviour – not always in the way you want.

It is quite long, but believe me, it is more than worth it. Let me know what you think!

1. The Social Media Project Manager – Blogs
2. The Social Media Project Manager – Twitter
3. The Social Media Project Manager – FriendFeed
4. The Social Media Project Manager – More Twittering
5. The Social Media Project Manager – Social networking
6. The Social Media Project Manager – An Example
7. The Social Media Project Manager – Wikis
8. The Social Media Project Manager – Blogging Community
9. Edit: I have also put together a slideshow for this series, The Social Media Project Manager – The Movie! Hope you like it!

Over the past few weeks, I have been highlighting some of the tools that can loosely be described as social media. The tools can be of use to a project manager in a variety of ways. Some of them can be directly used to help manage your projects, some of them to help you learn and develop, and some of them can be used for both.

As the series has gone on, my use of some of these technologies has also increased, as I have started to find them more and more useful. Of particular note to me are Twitter and FriendFeed, both of which I have found exceptionally useful. These two tools have helped me become more involved in the online project management community, both by seeing what others are doing, and by trying to contribute!

My resolutions moving forward are to continue to play a part in the project management community, most especially through Twitter and the Project Management Guide FriendFeed Room. I will also continue to search for new ways and new tools of social media to use in project management.

What about you? Which of the tools have you found most useful, or most interesting? What are you going to do to use social media in project management? Or are you going to steer well clear? Let me know your views!

I had a very strange conversation with a friend the other day. It started off simply enough: he has recently started working in a project management role in a public body, and was wondering what the preferred format for risk logs was. He knew I have worked in that area before, so asked me what it was.

But what came out from the conversation was that he was only asking now as someone from the head office was coming to take a look at the project. Previously, my friend had been getting along without knowing the preferred format by simply not having a risk log!

I imagine you’re as surprised as I was. But it got worse – apparently my friend wasn’t using a risk log because his new boss didn’t believe they were necessary. So as there was no call for a risk log from above, my friend just didn’t bother with one.

By this point, I was horrified. It was bad enough that he was running his project without a risk log. But his reasoning for this, that his boss hadn’t asked for one, betrayed something even more worrying. It suggested to me that he would only normally have a risk log because someone else expected it, because it was another box he needed to tick.

Now that’s worrying. I could forgive him not having a risk log if he had thought about it and decided the project wasn’t complex enough to need one, though I’m having trouble imagining I could come to that decision myself. Unfortunately, it sounds like he hadn’t thought about what was needed for this particular project, and was only now putting in place a risk log as a paper exercise.

That betrays a lack of understanding about project management. The techniques and tools that we learn as project managers aren’t there so we can tick the boxes. The techniques and tools are there because they help us to run projects well!

But they can only help. To get value out of them, we have to understand the principles behind them. We have to know why we are doing the things we do, not just how.

What my friend appeared to be doing was painting by numbers – project management by numbers, if you will. He knew the things that had to be done, and when, so he just got on and did them. But he didn’t seem to be showing any understanding of why he was doing these things.

All this got me thinking – how many more of these “project management by numbers” project managers are there? Has the popularity of some project management courses led to us churning out project managers who know what to do, but not why? Is this why we see so much bad project management?

What do you think?

Oh, and in my friend’s defence, this is his first project management role! He quickly saw the value of risk logs, and I have no doubt he’ll use them well. All he needs is more experience. Do other “by the numbers” project managers have that excuse?

Throughout this series, we’ve been looking at ways you can turn the tools of social media into tools of project management. But there is a much simpler way that social media can help us as project managers. Already there are project managers out there who are sharing their expertise through blogging, and that means there are many places we can go to develop ourselves as project managers.

Today, I would like to share with you some of the best project management blogs and resources that are out there. Now, this list isn’t designed to be comprehensive, but it will point you at some of the places I go.

First up, we have PM Hut. This site is a large collection of categorized project management articles, gathered from all over the web. There are many different project managers appearing here as authors, and a wide range of different views from them.

Next, we have PM Student. This site is primarily the work of Josh Nankivel, who you may recall I recommend you follow way back when we covered Twitter. As well as Josh, there are a few guest authors, and a lively group of commenters to keep you entertained!

Project Shrink is a blog by Bas de Baar, a software project manager. the blog has the tagline “Projects Are About Humans. We Help You Deal With That.” The site has a variety of posts that can help you be a more flexible and people-focused project manager. Take a look!

PM Tips is a collaborative blog that covers not only project management, but also “collaboration, knowledge management and all other work 2.0 concepts present in today’s web 2.0 world”! It offers practical tips and advice to help you be a better project manager.

Finally, do take a look at Pawel Brodinski on Software Project Management. This blog is more personal than the others I have mentioned here, and covers a lot of ground.

There are many more high quality blogs out there as well – I haven’t mentioned Jurgen Appelo’s Noop, Elizabeth Harrin’s PM4Girls, or John Reiling’s PM Crunch, all of which deserve a look.

Don’t forget, however, that if you join the Project Management Guide FriendFeed room the feeds from these blogs, and more, are pulled together into one handy place. Join in, and get commenting!

As I say, these are just a few of the blogs I go to. What blogs do you recommend? Which ones have you found to be most useful? And why? Let me know!

Part of The Social Media Project Manager Series.

As project managers, we’ve all had times when our attention is being pulled from many different directions at once. As well as our day to day tasks, sometimes problems pop up that mean we need to firefight, stakeholders can demand new reports, and team members can seek new direction. All of this can happen despite our best efforts to keep the project on an even keel.

Now, the ability to jump from task to task like this and still be effective is important for a project manager, but I don’t want to talk about that today. No, today I want to talk about the benefit of behaving in the opposite manner, about the benefits of focus.

All of us have had times where we have had to jump from task to task. And I imagine a lot of us have been left feeling that at least some of those tasks were short-changed by us – the pressure we put ourselves under to swap to the next job meant we didn’t spend enough time on the task in hand.

We all know that we should recognise the difference between things that are urgent, and things that are important. But while we all know it, I’m sure many of us still fall into the trap of chasing the urgent, without looking at how important it is.

Sometimes, the best thing we can do is to resist the demands to switch from task to task. By focusing on one task, you gain the ability to really get to grips with it. You will be able to look deeper into the cause of any problems, and come up with more considered solutions.

So, let’s put these two ideas together: deciding on what is urgent and what is important; and the benefits of focus. So how do we merge them?

Well, when you have a lot of issues clamouring for your attention, take the time to focus on one task first – the task of deciding which of those issues are important, and which are urgent.

Once you’ve done that, you are in a better position to focus on those issues that are important and urgent. Those that are important but not urgent can wait until these are done. Those which are not important, but urgent, can be delegated or renegotiated. Those which are neither important or urgent, well, they can just wait!

One of the ways to think about this is to remember that your time is precious. You are being paid (hopefully well…) to use your time for the benefit of the project. So take just a little of that time to make sure the rest of it is spent in the most effective manner, in the best way to benefit the project.

Of course, this is easy in theory, not so easy in practice. How do you deal with these sort of whirlwind days? Do you end up running around firefighting, or do you manage to find the time to focus on what is important? Let me know!