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?

All of your certainties are under attack. You thought you were on safe ground, a stable platform to start from. But now that ground is moving beneath you, an earthquake shaking everything you have built, threatening to bring it all down. The landscape is changing, and you’re the one who has to try and survive.

Oh, alright, I admit it, that’s just a tad melodramatic. But when you have been working hard to deliver a project, having the goalposts moved can feel almost like a natural disaster, an earthquake knocking you down. This is only to be expected – we all like to think we have control of our work, so it can come as a genuine shock when circumstances prove us wrong.

But, as I have written before, project management can be described as being about managing change effectively. Normally, the change is what the project is trying to achieve, bringing about a beneficial change. A consequence of working with change, though, is that a project itself is almost guaranteed to undergo changes.

This doesn’t have to be a bad thing. Nor, of course, is it necessarily a good thing. But it is something that is going to happen, whether you want it to or not. There’s no point in pretending it doesn’t, or resisting it when it comes along. Far better to deal with the requests for change that crop up – you never know, they may actually make your project better.

So how can we handle these requests for change? Well, now that we have accepted they will occur, we need to make sure we capture them. A change request that comes in should be recorded. You must capture these requests, and make sure they are dealt with. But how they are dealt with can vary.

The first thing to check is – is this really a change? Has the person asking for this change misunderstood or misread the project requirements? Are we actually already doing this? Believe me, this happens far more than you’d imagine…

Now, if it really is a change, you need to prioritise the importance of it. This can vary from an absolutely vital change, to something which is a purely cosmetic change. Try to have a set of different levels. I’ve used a system of four levels before, those being:

• Vital – the output of the project will fail if the change isn’t made
• Important – not having it causes problems, but it could be put up with or worked around for a short period
• Desirable – the change would be beneficial, but the output can still be successful without it
• Cosmetic – unimportant, has no effect on the usefulness of the output

So, you’ve worked out the priority. Now you need to figure out what impact making the change would have. Obviously this is going to vary massively depending on the change, the project, the environment, and so on. But the best place to start from is by analysing what would actually have to change. By this, I mean analysing the change to understand which parts of the project work would have to be done differently, or again:

• What has to change?
• How much effort will this require from the project team?
• How much will it cost?
• Will something else in the project, or linked projects, have to be dropped or altered to make the change?
• What effect will it have on your project schedule?
• Will the change introduce new risks, or get rid of old ones?
• And, importantly, what effect does it have on the Business Case?

Now we have a judgement of the priority and impact of the change, we can start to make an educated decision about whether to make the change or not. But remember, you are working on behalf of the Executive – ultimately, any decision about change is their responsibility.

In general, if the priority is Desirable or Cosmetic, and the impact is low (i.e. can be done well within the tolerances you have been set) then I’d probably just go ahead and make the change, though I would make sure it was flagged up to the Executive. If the priority is higher, or if the impact is higher, I’d refer the decision up to the Executive, unless they have already put some other mechanism in place for approving change.

You may have realised that means I would refer up a decision that was of Vital priority, but very low impact. Why? Why would I not just go ahead and do it? Well, two reasons.

Firstly, if I believe a given change is very low impact but Vital priority, that suggests to me I may have missed something – I want to make sure I take advantage of the Executive’s knowledge of the environment and organisation to confirm my thinking before I go ahead with any Vital change.

Secondly, if the project has managed to get approved with what may be a major flaw like that, I want it to get a good looking at. Has the change request come about because of a dramatic change in the external environment? Has this environment change been factored in to the rest of the project? Did we capture this on the risk log? Do we need to re-evaluate the whole Business Case?

Basically, if there is a change request that is Vital, I want to make sure that we haven’t just been struck by an earthquake, that the ground we have been building our project on really is stable enough to carry on. And that’s a decision that needs the expertise and wisdom of the Executive – after all, it is their neck on the line if it all goes wrong!

What about you? How do you deal with changes? What tricks have I missed?

(Image courtesy of videocrab / Kevin Simpson. Some rights reserved.)

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!

Today on Project Management Guide we are going to look at quality. In a project, quality has an important and specific role. So, for those beginning project management, what do we need to know?

As we have learned, a project exists to produce certain outputs, and part of the process of gathering requirements for what those outputs are must include information about what counts as an acceptable level of quality.

It is an understandable desire to only ever produce outputs of the highest quality. However, this level of quality is likely to take a lot of time, money, and effort. We don’t need our outputs to be the best, but late and expensive, we need them to be good enough, and on time and on budget.

So how do we go about making sure what we produce is of an acceptable quality? Well, you’ll remember from our post on project plans that one of the areas we need to cover in the plan is quality criteria.

What this means is that at the time of creating the project plan you will have agreed what criteria the output needs to meet, and how this will be measured. This will have been agreed with, at a minimum, the Executive and a representative of the end user, and hopefully with a representative of the people doing the work too!

Remember, quality criteria can be influenced by many things. Your business, or your customer’s, may have specific quality systems in place. Certain recognised standards of quality, such as ISO standards, may be mandated by contract. And, of course, the final use of the output will dictate what is needed – the quality required of a component in a washing machine is significantly different from an equivalent component in a nuclear submarine!

Now, these criteria, once agreed, tell you what success is, what completion of the project is. They need to be SMART:

• Specific – Clearly defined and precise
• Measurable – e.g. not “new computers”, but “computers with 2Gb of memory”, etc.
• Attainable – Don’t ask for the impossible
• Relevant – Is the criterion actually related to the aim of the project?
• Time-based – Enough time to achieve this. There is no point expecting a year’s worth of work in one week!

You will also need to decide who has the final say over the quality of the outputs. Hopefully your work on defining the quality criteria will mean there are no arguments over the quality (i.e. no qualitative judgements, only quantitative).

But quality isn’t something that you worry about only at the end of the project. The quality of what you are producing should be monitored throughout the project. Intermediate steps on the way to the final output, or separate, discrete pieces of that output should be quality checked as the project is carried out.

That’s a very quick overview of quality in a project. What tips do you have about quality in a project? How do you make sure you’re meeting the customer’s expectations, while also meeting your business needs? Let me know!

Project management does not exist in a vacuum. We have embraced the various new methods of communication to encourage better collaboration and team-work. It is now practically inconceivable for a project not to be using email, tele-conferences, even video-conferencing to maintain contact with the participants.

But are we embracing the new technologies available now? Are we making best use of the tools we now have? With project teams becoming even more spread out over the globe, are we making best use of our new communication methods?

This series will look at the various new social media tools available to us, and how we can start to use them in our projects. Some of you will already be using some of these tools. I’d love to hear your stories about how they have worked for you – many of the uses are only now developing, so I’d love to hear your best practices!

Wikis are websites that allow the people who access it to contribute to it, or to change and update the information that is already there. The most famous example of a wiki has to be, of course, Wikipedia, which has harnessed the efforts of individuals around the world to build a resource with a remarkable breadth, though with sometimes variable quality!

But can a similar system be of use to us as project managers? We’ve already looked at the benefits of FriendFeed, most notably that as all the ‘conversational’ information is being captured, it generates a searchable resource of this information. However, sometimes we need to make things more formal.

While we can use blogs to share formal documents, they are primarily a one to many communication tool, in that the person writing the posts has the most control over putting information out. In other words, while a blog is useful for gathering comments on the information, it is not good at allowing collaboration in the creation of it.

When all of your team are close by, this may not be a problem – you can walk over and talk to them! Unfortunately, this is increasingly often not the case, and this is where a wiki can come into its own.

By putting up a wiki page, you enable the people viewing it to add information, to modify what is there, and to improve the usefulness of it. This means you can gather the knowledge and expertise from all of your team members, who can contribute to the generation of this resource.

This is useful when you are looking not only at the documentation around running the project, such as risk logs, but also when you are looking to create the documentation about the product – in other words, the documentation about using the product, which should be part of the output of the project.

A wiki isn’t the perfect answer, of course. While, hopefully, the documentation produced on the wiki will be good, it still needs to go through a quality process before release, and this may uncover problems. And, of course, actually getting your team to contribute needs discipline on both your and their parts. There may be a temptation to set up a wiki and leave it alone, assuming that the documentation will magically now get written. This works about as well as you would expect.

But while a wiki brings some challenges, the benefits of using one can be great. Having the accumulated knowledge and expertise of the project team around this project put down in an organised manner is incredibly valuable. And if it is done throughout the life of the project, it is likely to be much more successful than when tacked on the end.

Have you used a wiki in project management? Was it useful? Or did it just mean another thing that had to be monitored? What do you think? Let me know!

Part of The Social Media Project Manager Series.

I’ve been writing recently on my thoughts about what project managers need to do now to grasp the opportunity (yes, opportunity) that the current economic climate gives them, and move from being a good project manager to being a great one.

And I really do think this climate is an opportunity for project managers, one we should grab hold of. For one thing, we get to shine by delivering for our businesses. For another, governments around the world have been announcing huge stimulus packages that will involve many new projects that need managing.

Something else, though, has got me thinking about this being an opportunity. And that is a book, Outliers: The Story of Success.

This is by Malcolm Gladwell, he of Tipping Point (The Tipping Point: How Little Things Can Make a Big Difference) and Blink (Blink: The Power of Thinking Without Thinking) fame.

Outliers is a fascinating book. Malcolm Gladwell looks at successful people, and how they got there, in an interesting way. Some of the conclusions are perhaps what we have suspected, but he has done the legwork to find the data that backs it up. I really do recommend you take a look at it.

Now, some of you may have seen some of the buzz around the book, most of which focused on the assertion that someone successful needs to have practiced something for about 10,000 hours before they get really good at it.

Yes, 10,000 hours. 10,000 hours of work and practice. 10,000 hours, day after day, month after month, year after year, of sheer effort on whatever it is they are now successful in. The figures seem to hold for everything from music, to law, to ice hockey. People start to get good, really good, when they have spent 10,000 hours doing what they do.

Now, this isn’t really that surprising an answer. It may be a little disappointing, but it’s not surprising. It’s disappointing because all of us secretly would like to think that the people who are successful are somehow gifted – that their success has literally been given to them. But it turns out that successful people really aren’t that different than the rest of us.

But what I think we need to pay attention to now, with the economy as it is, is the other aspect of what makes successful people successful. And that is the environment they are in.

Outliers has a compelling section where Gladwell talks about the rise of Jewish lawyers, and law firms, in New York. And the reason they rose was, at least in part, because they were lucky enough to face a harsh environment.

It was precisely the difficulties they faced getting into one of the supposedly prestigious New York law firms in the 60s and 70s that placed these lawyers into a position where they could take advantage of the changing legal scene in the 80s and beyond.

Reading this book made me think about what we really mean by an opportunity. Often, opportunities come to us disguised as a challenge, a problem, maybe even a disaster. I’ve been writing elsewhere about the pros and cons of being a contractor, precisely because for some, the disaster of losing their job may really be an opportunity for more success.

It is all about being in the right place, at the right time. And, crucially, about grasping the opportunity, recognising it for what it is.

Right now, right here, I believe that project managers, good and great project managers, have the opportunity to make the best of this economic challenge. To make the best of it, to be successful not despite it, but because of it.

But then, I’m a born optimist.

What do you think? Am I just fooling myself? Let me know!

Today in the Project Management Guide we are looking at our day to day work, the real meat of what it means to be a project manager. This is where we really earn our keep. Not surprisingly, there is a lot to this, far more than be covered in one blog post!

However, as part of helping brand new project managers, I want to give you a very rough overview of what I try and make sure I do on a regular basis. These things help me make sure I have a grip on what is actually happening with the project.

The most important thing to do is make sure you have a clear idea of progress. The best way to do this is face to face. Now, many project managers, particularly in software development, like to have a very short stand-up meeting at the start of every day. It is done standing up as this helps to naturally speed the meeting up!

This frequency of meetings may not be appropriate for your project, though. While it may be possible in a software project to break all of the tasks being done into bite-sized chunks which can sensibly be reported on every day, it may not be possible in other industries. For example, while it would be possible to get a daily update on the number of bricks laid on a construction site, is this information worth getting?

If you gather progress information too frequently, there is a danger that you will get an exaggerated view of progress – no-one wants to come to a meeting and report only tiny progress, but if a task is large, that is all that can be reported on a daily basis!

The key message to take away is that the progress updates you get need to be timely, useful, and accurate.

• Timely – so you can take any action needed at the right point.
• Useful – so you can do something with the information, rather than just get swamped by it.
• Accurate – so that you are actually getting the truth about your project.

Now, the frequency that will hit these criteria will vary for you, both on the industry you are in, and on the individual project. It may also vary depending where in the project you are, so don’t be shy about changing the frequency when it makes sense.

I’ve worked on one project that had daily updates when we were negotiating contracts with three possible suppliers, because we needed to make sure everyone knew where we were, and to share information about issues raised by the suppliers. The same project dropped to a weekly schedule once we got into the rollout of a very large network infrastructure, because that was the most sensible way of sharing that information.

And, of course, think about whether these meetings actually need to include the whole team – I’ve already written about my dislike for meetings, so only have everyone there if it makes sense!

Now, one reason for having getting this information is to give you a clear idea of progress. Another is to find out about the issues team members are having. Getting this information is vital – you want to know about all issues as soon as possible, because, in general, it is easier, better, and cheaper to deal with the issues early.

Whenever a new issue is raised, you must make sure you log it. We’re going to need to figure out how we deal with this issue later, so make sure we capture it.

The next thing I do, now I have all this info, is to assess progress. This means taking a look at what we have actually achieved, against what we had planned to achieve. Are we miles away from where we should be? Have we made some error in our estimation of the work?

Now, I need to examine the issues.

• What sort of issue is it? A change in requirements, a problem we didn’t foresee, an unavoidable risk occurring, a new risk spotted, a change in the external environment?
• What impact is it going to have? Will it effect quality, timescales, budget?
• What can I do about it? Are there actions I can take as project manager to solve this? Or do I need to refer it up to the Executive?
• What impact would there be in taking action to deal with this? What cost? What timescales? What quality impact?

We’ll go into more detail on risks and issues in a later guide.

On a regular basis, I want to make sure the Executive, and anyone else selected by the Executive, gets an update on the project. I do this by condensing the information on progress and issues I have already gathered. I should put in to this report information about issues we have come across, both to keep the Executive informed, and to flag up issues that may require action later.

And lastly, I need to receive any completed sections of work, and assign new ones. Obvious as it may sound, it bears repeating: No work should be going on that the project manager a) isn’t aware of, and b) hasn’t approved. The point of having a project manager is to make sure that the effort in the project is guided sensibly to achieve the aims. That becomes an awful lot harder when people are doing things on an ad hoc basis!

That’s a brief (a very brief) overview of what you need to be doing. I’ll be going into more detail on these in later guides. For now, it is over to you – what else do you try to do on a frequent basis? What are the must do things I have missed out? Let me know!

A quick update today, looking at an example of a business using Twitter and FriendFeed in the same way I suggested in earlier posts. The company in question is Humana.

Chris Hall has a blog post up, Meeting of the Minds, where he talks about how this came about. He was in a meeting, essentially a project kick-off meeting, about the social media strategy for Humana, when someone suggested that they record the event on Twitter – in the public domain.

You already know I think this is a good idea. The meeting agreed to use a hashtag (#hcoc) to make the tweets easier to find, and an interesting thing is that co-workers not in the meeting were able to follow along, and even suggest ideas. This kind of wide-ranging collaboration is a great benefit of this openness.

In addition, Chris created a FriendFeed room to enable everyone to find the information easily – providing a more stable and helpful resource.

I really encourage you all to go along to the blog post Meeting of the Minds and read more about it.

Do you know of any other examples of organisations using social media in an innovative way? Let me know!

Part of The Social Media Project Manager Series.