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…

We’ve already talked about the idea of risk management as part of the project. Obviously the first requirement for the rest of the risk management process is actually to have identified the risks!

Identifying risks can be a tricky business. But there are a few things you can do to make it more successful. The first thing we need to do is look at what we are actually trying to find. We are trying to figure out what things could happen that will effect the project in a bad way.

So what would be a bad effect on the project? Well, traditionally we are trying to protect three main areas in a project: time – how long it takes us to complete the project; cost – how much it costs us, in terms of money and resources; and scope – what the final output will actually do. In addition, the quality of the final output can be effected.

By keeping these four areas in mind, we can start to identify what some of the risks could be:

1. What could happen that will affect how much time we have?
   • Could the launch date be moved forward?
   • Could poor weather conditions delay external work?
2. What could happen that will affect how much money we have, or can spend?
   • Could the project budget be cut in a lean time?
   • Could our suppliers put their prices up significantly?
3. What could happen that will affect the scope of the project?
   • Could a competitor put out a product which covers something we don’t, meaning we need to expand scope?
   • Could part of the project be more complicated than expected?
4. What could happen that will affect the quality of the output?
   • Could a component from a supplier not meet our requirements?
   • Could we run out of time for removing bugs from code?

By identifying the things that could happen that will affect us, we can not only identify them as risks, but also identify the drivers behind them – what will cause these risks to occur? In that way, we can start to make sure we head the risks off early, and hopefully make sure they don’t occur.

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.

So, I’ve already talked a little about how to ensure quality in what you are producing. But let’s take a look at it in a little more detail, to get a better understanding.

As we know, we need to make sure we have criteria that describe what the quality of the final output should be. These criteria need to be agreed beforehand between those making the output, and those who will be using the output.

But quality isn’t just something to be tacked on to the end of the project, polishing the final output until it comes up to scratch. Quality needs to play a part throughout the project. Each task that forms a part of the project should have appropriate quality constraints as part of it.

But what is an appropriate quality constraint? Well, the most obvious constraint is that the output of the task should actually be what the task was supposed to produce! It should meet the criteria that have decided before the task started.

Now, these criteria will not have been decided at the very top level. No, they should instead have flowed from the quality criteria that were set at the top, for the output of the project as a whole. But for the individual tasks, criteria should be set either as part of the scheduling meetings, or when the tasks are being divided up among the team.

And, of course, we need to have decided who gets to assess whether the output of the task meets the quality criteria. Usually it is better to have someone who didn’t do the work to assess the quality. This isn’t because the person who did the work is going to deliberately conceal flaws (hopefully…) but simply because they are likely to have been too close to the work for too long to be objective about it. Fresh eyes see more clearly.

Finally, don’t think you can get away form this scrutiny as a project manager. Don’t forget that you have many tasks that need to take place in the project too – monitoring, production of reports, etc. All of these are an output of a task – and so they should also be subject to a check on their quality!

At the beginning of the project, we should have identified a project assurance role, and someone to fill it. This role should be examining the project management outputs, and providing feedback and info to you on improving them, as well as providing the independent eye of the Executive in checking progress of the project.

By checking quality throughout the project, you make sure that by the end, we don’t have to suddenly tack on a few more weeks to get the final output to the quality it needs to be. It should just flow naturally from the high quality of the tasks done to get to the end.

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!

One of the favourite sayings of my father is “Wisdom is not in not making mistakes, but in not making the same mistake twice”. This is an important lesson for all of us as project managers. Learning from our mistakes helps us to become better project managers – experience is always a good teacher.

But what we should all be trying to do is make sure we are not the only ones to learn from our mistakes. Making sure others in our organisation, or even our profession, get the benefit of our experience is an important part of our professional lives.

So how do we go about this? Well, first of all, we need to recognise when we have made mistakes, when we have not taken the best action in a given situation. This needs a certain amount of honesty, and to be done well, it needs time to really consider the project as a whole.

The best way of doing this is to analyse the project when it comes to an end. Hopefully, the project will come to an end successfully, with the end result we wanted delivered. But it may be that the project has been stopped early, for whatever reason. Regardless, at this point we need to evaluate a number of things:

• Exactly how successful was the project really?
• What actions did we take that helped?
• What actions did we take that didn’t?
• What problems occurred?
• How did we deal with them?
• Were there things we could have done better?
• Were there things we didn’t do that could have helped?

As you can see, there is a lot of ground to cover. You will also note that a lot of this involves honestly looking at your own work. Now, this can be tough, especially when looking at places where we messed up. But it is only by examining our mistakes that we can learn from them.

However, to help us out in this area, it is always useful to have help in doing this analysis. Your Executive is a prime example to examine your work, but don’t neglect your project team members. Your team will have a different perspective than your Executive, and as they are closer to the nitty gritty work of the project, may have valuable insights into areas that went wrong.

But I don’t want you to go overboard on only focusing on the mistakes. It is equally important to learn from the successes, so that these can be replicated in the future.

All of this analysis should be formally presented as a report, an evaluation of the project as a whole, a set of lessons to be learned. This report should be the final part of your project, where you look back at the work that was done. It can form a valuable tool for future project managers working on a similar project – your experiences can inform their work.

This means that hopefully not only won’t you make the same mistakes again, nor will anyone else in your organisation!

Oh, and that saying my father likes? I don’t know who said it first, because a similar message is attributed to numerous people. Which kind of demonstrates the benefits of spreading good messages too – lots of people can learn from it!

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!