When I found out in August that I would be presenting my paper on “The Project Management Mid-life Crisis” at the 2008 APM Conference I was delighted. However this initial delight quickly turned into a stark question: how could I deliver my complex message simply and with maximum impact?

I am no stranger to giving presentations. In fact, at work I have a reputation for being pretty good at them. However on this occasion I wanted to do something a little bit special. In trying to decide how I could do that I came across some fantastic resources on the Internet and a video that would forever change my idea of what constitutes a “great presentation”. I also discovered that the divide between good and truly great presentations can be a hard one to cross.

Everything I have learned since August came from three places:

1. The Excellent Blog of Benjamin Ellis

I had already prepared a set of slides and decided roughly what I was going to say before I found a post by Benjamin entitled Larry Lessig – Copyright and Great Presenting. As soon as I watched the video of Larry Lessig presenting on How Creativity is Being Strangled by the Law I realised that I still had massive room for improvement: I needed to work on exactly what I was going to say and then make the PowerPoint slides back this up visually.

I read many of Benjamin’s other postings on presentations, all of which were well worth the time invested in doing so. I recommend that anyone reads the following:

• A Presentation Lesson From Al Gore
• Preparing to Present – A Check List for Presenting at a Conference or Large Event
• 10 Tips for Better PowerPoint
• 10 Things Not To Do In Business PowerPoint Presentations

2. Alex S. Brown’s Presentations

I listened to a number of Alex S. Brown’s presentations about project management that he makes available on his website. The key lessons that I took away were the importance of humour and of getting the audience involved. That is why my presentation began with two questions which the audience could respond to with a show of hands. It is also why my slides included stills from The Office and Absolutely Fabulous.

3. The Patience of my Girlfriend

Once I had re-drafted my slides and practiced alone many times I unleashed the results on my girlfriend. She works in education and knows a thing or two about how to get a message across clearly (to a sometimes unreceptive audience!). The first time I presented to her we identified numerous areas for improvement and I set about re-drafting the entire presentation again. This process was repeated several times until my long-suffering other half could almost recite the entire presentation better than I could!

Was it worth it?

Without doubt there are pitfalls to the approach I ended up taking. When the organisers of the conference first saw that I had prepared 120 slides for a 20 minute talk they were horrified and promptly suggested I cut down to no more than 20. It took quite some persuasion before they changed their minds.

Another issue is that to be effective you have to know exactly what you are going to say and advance the slides at exactly the correct moment. This takes some practice and also makes you reliant on technology. In fact, I had a small panic when, a week before the conference, I was led to believe that someone else would be advancing the slides on my behalf. Fortunately on the day itself I was given a small remote control so that I could advance them myself. Phew!

Pitfalls aside, I received a lot of very positive feedback from conference delegates. One described my talk as “the most useful so far”. Others said that it had been “entertaining” or that they had “liked the use of visuals”.

More importantly, by trying to do something out of the ordinary, I have learned more about effective presentations over the last few months than ever before. Expect some follow up posts with hints and tips of my own very soon!

Not all that long ago I read David Allen’s excellent book on personal organisation Getting Things Done (which I also reviewed in this post). Ready for Anything is a follow up to this and consists of a collection of 52 short essays, each of which talks philosophically about the techniques he described in his previous book.

It is a relatively short book and I finished it in what felt like no time at all (always a good sign). David Allen’s writing style is enjoyable to read and the book is littered with wonderful quotations.

I don’t think this book would be very meaningful unless you have already read Getting Things Done. In fact, I felt that this book contained very little new information at all. This led me to wonder whether there was really any point to reading it? Was I just participating in some kind of GTD masturbation: good fun but hardly fruitful?

I think the answer is a partial yes. However it did highlight to me some areas of GTD that I have not been applying as well as I need to in order to keep on top of my work and personal commitments. In fact, each essay ends with some questions that are specifically designed to uncover any areas in your life where you might not be living up to your full potential.

To summarise, this book was:

• Enjoyable to read
• A little bit useful
• Not worth reading unless you have already read (and at least partially implemented) Getting Things Done

Photos from the 2008 APM conference have been uploaded here. The APM have also setup a conference blog which seems to include quickly written summaries of each presentation together with links so that you can download the slides. My contribution is described here (although most of my slides are missing).

As you can see, I managed to put on a cheesy grin for both of the occasions that the official photographer caught me with his camera:

I also liked this photo very much because it gives a good feel for the excellent venue and fantastic organisation that made the conference such a success:

In the paper that I recently presented at the Association for Project Management (APM) conference I included a section that listed useful and interesting websites related to project management. I don’t often publish lists like this on my blog but today I’m going to make an exception! These are all sites that I visit regularly and I feel they offer useful and/or interesting viewpoints. I thoroughly recommend that you take a look and consider adding some or all of them to your RSS reader of choice.

10x Software Development

Advice and opinions from legendary expert on managing software development Steve McConnell.

A Girl’s Guide to Project Management

Informative thoughts on project management from Elizabeth Harrin.

Agile Project Planning

Information and insights about agile project planning and software development by Dave Churchville.

Alex S Brown

Alex S Brown publishes a wealth of project management related information on his website. You can read my interview with Alex here.

Aligning Technology, Strategy, People & Projects

Thoughts from Eric D Brown on aligning technology, strategy, people and projects.

Bruce’s Brain

Blog of Bruce P Henry (Director of Rocket Science at LiquidPlanner) in which he talks about a wide range of topics that are related to the management of software projects (and some that aren’t!). You can read my interview with Bruce here.

Construx

The homepage for Construx Software, Steve McConnell’s software consultancy, this site has many useful resources including white papers, estimation tools and recommended reading lists.

IT Leadership

Information about IT leadership from TechRepublic (which also has many other useful IT related resources).

Johanna Rothman

Johanna Rothman is a well known expert and author on the management of technical projects. On her website she maintains two blogs: Managing Product Development and Hiring Technical People. Additionally Johanna makes available many of her interesting articles. You can read my interview with Johanna here.

PickTheBrain

A website dedicated to self improvement with a focus on personal productivity, motivation, positive psychology and self education.

Pawel Brodzinski on Software Project Management

Pawel Brodzinski’s blog about all things releated to the management of software projects. You can also read my interview with Pawel here.

PM Hut

A large collection of categorized articles on project management.

Practicing Earl

Thoughts from Earl Beede on product development (especially software).

Project Management 2.0

Views and analysis of how Enterprise 2.0 technologies affect contemporary project management and what impact they have on an organisation as a whole.

Project Shrink

Blog by Bas de Baar that focuses on the importance of people in software projects.

Undocumented Features

Stacey Douglas presents her ideas about software project management, business analysis and improving the software development lifecycle.

Raven’s Brain

Blog by Raven Young on all aspects of project management and leadership with a particular focus on the “softer skills” that are so critical to effective leadership. You can read my interview with Raven here.

The McCarthy Show

The website of Jim and Michelle McCarthy where they host a podcast and publish a wealth of other useful information about building high performing teams. You can read my interview with Jim McCarthy here.

The Practice of Leadership

Articles by George Ambler on leadership skills.

Tyner Blain

Scott Sehlhorst’s thoughts on the most effective ways to develop software.

Back in June when I interviewed Jim McCarthy he was keen to tell me about The Core. So keen, in fact, that I posted a follow-up to that interview devoted purely to Jim’s story of what The Core is and how it evolved.

The Core is an intriguing idea. It is a document that attempts to define an optimal way for members of a team to interact. The document is similar in style to documents that describe technical protocols like TCP/IP and HTTP. However this isn’t a document focussed on technology but rather on how people should behave and interact in order to achieve the best results possible.

Overall I think it is fantastic and I thoroughly recommend reading it to anyone. It is highly concise and will probably take less than 20 minutes of your time but covers a lot of very useful ideas. Having said that I do think it has some limitations and I’m going to start by talking about those.

In order to apply The Core exactly as it is described then everyone on a team would need to understand it and believe in it. I suspect that Jim and Michelle have the ability to get a whole team on board in this way during one of their BootCamp training courses. However I must modestly admit that I don’t think I could personally achieve this with everyone on my team. The good news is that you can apply a lot of what is contained within The Core without everyone having to buy into it.

The style in which the document is written will not appeal to everyone. As it happens myself and other technically minded colleagues found it quite easy to read. It is very concise and concentrates purely on what you have to do rather than why you have to do it. However other people I know who aren’t from a technical background found the style strange and confusing.

The document is very dry and, if I imagine a workplace where all interaction followed this exact protocol, then I am imagining a workplace that I would not like. I see certain non-work related communication (such as asking about someone’s kids, finding out what they got up to at the weekend, sharing the odd joke, etc.) as essential to building an effective team. These things are not ruled out by The Core but neither are the expressly ruled in.

So, negative points aside, what did I find really appealing about The Core? In a word what I like is its simplicity: this is a short document that contains the bare minimum of information you need. Specific aspects that I feel are particularly useful are as follows:

Checking Out

The Core states that if you are physically present then you must be fully engaged with the task at hand. There is no requirement to always be engaged. However if you aren’t engaged then it is your responsibility to get out of the way of other people who are. You are required to Check Out with a minimum of fuss and others are required to not judge or in any other way hassle you for doing so.

Asking for Help

Asking for help is often an area where I have seen significant tension within teams. The types of phrase I have heard used are “How am I supposed to get my work done if I always have to help other people” or “I don’t like to ask someone for help if they look busy”. The Core has a nice description of how help should be requested and given (or declined). I especially liked the following guidance:

“Asking for help is a low-cost undertaking. The worst possible outcome is a “No,” which leaves you no further ahead or behind than when you asked. In the best possible outcome, you reduce the amount of time required to achieve a task and/or learn. Asking in time of trouble means you waited too long to ask for help. Ask for help when you are doing well.”

Reaching Group Decisions

I have made no secret of the fact that I think the best meetings are short. But a common reason that meetings go on longer than they should is that it can take a long time for a group to reach a consensus decision. The Core describes a quick process for reaching group decisions which is based on the premise that if you vote “no” to something then you must be able to clearly state what would need to be changed for your vote to be turned into a “yes”. This makes it impossible for people to hold up progress by pointing out what is wrong with a particular approach. Rather they have to be prepared to move things forwards by suggesting something better.

The Perfection Game

The Core describes the perfection game as a way of improving any product (code, a document, a presentation, etc.). The way it works is that you present the product and then people tell you what they liked and give it a mark out of 10. Crucially they must then state what you would need to change about it to score 10. This means that no matter how much they dislike something they must give it 10 if they cannot suggest any changes that would make it better.

Investigation

Often you have to improve your understanding of something in order to be able to work with it or improve it. The Core provides excellent advice for how to do this without causing offence. Everybody hates it when someone questions their approach to something with a phrase like “That seems an odd way to do that. Why don’t you do it like this?” and even though Harry Enfield based a whole infuriating character on this strategy it still seems remarkably prevalent. The Core gives sound advice for avoiding this style:

Ask only questions that will increase your understanding.

Ask questions only if the subject is engaged and appears ready to answer more.

Refrain from offering opinions.

Do not ask leading questions where you think you know how he or she will answer.

Avoid theorizing about the subject or providing any sort of diagnosis.

Consider using the following forms for your questions:

• What about X makes you Y Z?
• Would you explain a specific example?
• How does X go when it happens?
• What is the one thing you want most from solving X?
• What is the biggest problem you see regarding X now?
• What is the most important thing you could do right now to help you with X?

Ineffective queries include the following:

• Questions that lead or reflect an agenda.
• Questions that attempt to hide an answer you believe is true.
• Questions that invite stories.
• Questions that begin with “Why.”

Stick to your intention of gathering more information.

If you feel that you will explode if you can’t say what’s on your mind, you shouldn’t speak at all.

I attended the second day of the APM conference on Thursday 30^th October. It was another full on day with an awful lot of interesting speakers providing a great deal of food for thought.

Nigel Smith, Chief Executive of the Office of Government Commerce (OGC), presented an opening keynote speech in which he talked about the purpose of the OGC and the areas that they are looking to improve.

After a break for coffee I attended a session on sustainability. This was kicked off by Penny Pullan of Making Projects Work. Penny gave some really insightful tips for how to decide when to use conference calls instead of face to face meetings. Penny then went on to talk about the skills and techniques that are required to make conference calls effective. I couldn’t help but feel that a lot of these tips applied equally well to in-person meetings. I must also add that when Penny (and members of the audience) described day-long meetings I was reminded of my personal view that the best meetings are short. Following Penny’s talk Adrian Pyne talked about sustainability from a programme management perspective.

After another short break it was time for two keynote speeches from Sir David Normington (Permanent Secretary, Home Office) and Jonathan Simcock (Executive Director, OGC). Sir David Normington shared a list of six “non-negotiables” for successful projects which I think are worth repeating here:

1. Clarity at the outset about the objective(s) of the project
2. A clear focus on delivering measurable benefits
3. Clear roles and responsibilities for those working on the project
4. Clear roles and responsibilities for all suppliers and other stakeholders
5. A simple plan with clear milestones
6. Good risk management and appropriate escalation of issues

After a question from the audience, Sir David added an additional item which was “Ensuring sufficient resources are in place”.

Then Jonathan Simcock took to the stage. My favourite part of his speech was when he highlighted that knowing how to do something is very different from actually doing it. The analogy he used was a football game and he suggested that most people in the audience probably understood the rules of soccer but that didn’t mean we could form a premiership team.

The last session I attended was titled “How do you find that something extra?”. The presentation from Ian Anderson (Department for Work and Pensions) and Tony Teague (Human Systems) looked at what characteristics are important in project managers. They suggested that soft skills (which they actually called “tough skills”) are more important than understanding any particular process or methodology. This was a sentiment that the audience overwhelmingly agreed with. They also described certification as “necessary but far from sufficient”. The second presentation in this session was from Neil Mooney (Provek) and Jane Hodgen (Tata Consultancy Services) and this looked at how Tata Consultancy Services had selected 8 programme managers from a pool of 192 project managers.

The conference ended with an excellent summary of all the sessions provided by subject champions Adrian Dooley, Peter Simon, David Bright, Mary McKinlay and Tom Taylor. Overall I very much enjoyed this year’s APM conference. It was a real pleasure to present my paper and attending the other talks was a brilliant learning experience. I would thoroughly recommend the conference to any professional who is interested in deepening and broadening their understanding of this thing we call “project management”.

Today I presented my paper entitled “The Project Management Mid-life Crisis” (download it here) at the Association for Project Management (APM) conference. It was a fantastic experience and the organisation and venue proved to be superb. I was introduced by Adrian Dooley at just after 11:15 and spoke for just under 20 minutes.

After my talk Geoff Whittaker took to the stage and put forwards an interesting point of view on how objectives should be set to incentivise project managers.

After Geoff Whittaker and I had presented the audience was able to vote on a number of questions using rather snazzy interactive keypads. 100% of the audience agreed with me that project management most focus more on people and 92% agreed with me that it is essential for PMs to concentrate on delivering value. However only 62% felt that companies should resist mandating a single project management process and only 61% agreed with my central thesis that project management has reached a mid-life crisis.

Following this “voting session” the audience asked a series of questions during which a number of people indicated to me that the themes I had covered resonated with them personally.

Later in the day it was a real pleasure for me to meet Elizabeth Harrin (of Project Management for Girls) and hear her talk about the necessity for PMs to find ways of working that fit in with the teams they are leading. Hopefully she will make the slides available for download from her website.

Following this Martin Price focussed on the importance of people to project success and he used a great quote of Doug DeCarlo which was “People are not the heart of the matter…they are the matter”.

Later in the afternoon I had the pleasure of listening to Dr Peter Merrick and David Tuffs talking about the benefits of agile project management and how best to introduce agile practices to an organisation that is currently using more traditional approaches.

If you were at the conference and would like to give me some feedback on my paper/presentation then I’d really love to hear from you. Feel free to drop me a line at david@day.net or leave a comment below. For those who couldn’t make it today you can download the paper here (this version also includes all the original interviews) and again I would be very interested in hearing your views and opinions.

As a final note I would like to extend my extreme gratitude to Pawel Brodzinski, Bruce P Henry, Alex S Brown, Johanna Rothman, Raven Young and Jim McCarthy for taking part in the series of interviews on which my presentation and paper were based. None of this would have been possible without them.

How can I get the best out of everyone working on my team? This is surely a question that managers at all levels, from team leaders to chief executives, must regularly ask themselves. In First, Break All the Rules Marcus Buckingham and Curt Coffman attempt to answer this question. The book is based on research that involved surveys of over a million employees and interviews with over eighty thousand managers. Surprisingly the conclusion from this extensive study was that most conventionally held wisdom about how to manage people effectively is wrong: from encouraging people to work on their weaknesses to the idea that you should reward the best performance with promotion.

One of the most valuable things this book provides is a simple tool for measuring how well members of a team are being managed. It consists of a list of 12 questions which include things like “Do I know what is expected of me at work?” and “In the last seven days, have I received recognition and praise for good work?”. Using these questions you can build up an accurate picture of the quality of leadership that your team is experiencing. I am a community governor for a local infant’s school and we are already using these questions to assess how well we are managing all the staff at the school.

After introducing and explaining the power of these 12 questions the book goes on to cover four distinct areas:

Selecting for Talent

This book has a very careful definition of talent:

“A recurring pattern of thought, feeling or behaviour that can be productively applied”

Once you understand this properly it offers a very important insight into how you select people to work on specific tasks. Traditionally, to take an example from software development, if you wanted someone to develop a prototype with a customer in C#.NET then you would look for a developer with C#.NET skills. Similarly if you are developing a risky new web application in PHP you might look for a PHP expert.

However in both cases you would be missing the point in terms of talent. In the first example you need someone who has some C#.NET knowledge (or who could pick it up in a day or so) but, far more importantly, you would need someone with an investigative mindset. Someone creative. Someone with empathy.

And with a risky web development project you need a developer who is comfortable with unknowns. Someone who is willing to try out new techniques and approaches. Ideally they will know some (or even a lot) about coding PHP. But an expert in PHP who is risk averse and only wants to work in areas he or she already understands will add little value to the development effort.

Defining the Right Outcomes

In order to get the best out of people you have to make it very clear what your expectations are in terms of definable outcomes. This book makes the point that you should spend very little time telling people what to do (i.e. use the standard requirements gathering template, follow this coding standard, write a test plan) but instead focus on the outcomes you are looking for (i.e. requirements from which we can create a high quality specification, code that is readable, code that works).

Focussing on Strengths

I have seen plenty of performance reviews which concentrate on someone’s strengths and weaknesses. Usually the next step is then to come up with some kind of plan for addressing the weaknesses. This book challenges this directly and argues that it is a waste of time. Instead you should “Let them become more of who they already are”. Don’t ask someone who is brilliantly creative but highly disorganised to become more organised. Instead develop their creativity even further! Don’t ask someone who loves detail but struggles with “big picture thinking” to change: work out how they can deliver even more value by working at a low level of detail.

This section of the book includes two other counterintuitive ideas. One is that you shouldn’t treat people how you would like to be treated but rather how they would like to be treated. You might love to be presented with an award in front of all of your colleagues but for others that might actually be their idea of hell. The other idea is that you should spend most of your time with your best people. It is very easy to fall into the trap of only spending time with people who are underperforming or struggling. In practice this time is often poorly spent and it can end up making little real difference to concrete results. Far better to invest your time in getting even more value out of your best.

Finding the Right Fit

This section of the book focuses on how you reward success and, specifically, the dangers of promoting people to their level of incompetence (as first described by Laurence Peter in The Peter Principle). This book describes the problem well:

“We still think that the most creative way to reward excellence in a role is to promote the person out of it.”

Fortunately the book provides some practical solutions in this area that can be applied by anyone, regardless of their position within an organisation.

So, what did I think?

As you have probably gathered by now I think this is an excellent book. Nearly all of it provided practical insights that have changed the way I work with members of my team. The only part I struggled with were the appendices that explained the statistical detail of the research that this book is based on. Overall I would say that, if you work with people (and who doesn’t?), then this book will make for useful and interesting reading.

The Association for Project Management (APM) conference will be taking place in London on the 29^th and 30^th October and I am very excited to be attending and speaking at this event. I will be presenting a paper on the first day entitled “The Project Management Mid-life Crisis” which is based primarily on the series of interviews with leading project management professionals, authors and gurus that I posted earlier this year.

There are a number of speakers that I am really looking forward to seeing including Elizabeth Harrin (who blogs at A Girl’s Guide to Project Management) and Penny Pullan (from Making Projects Work).

If you haven’t already booked your place then it’s not too late to do so via the APM website.  For those of you who aren’t able to make it I will be posting about my experiences afterwards and making my paper available for download.

I’m really lucky with where I work because it just so happens to be very close to an amazing sandwich shop from where I fetch my lunch on most days. Every time I visit I am served by one of two people, both of whom now know my personal preferences (as far as sandwiches go at least). All the sandwiches are freshly made and most of the ingredients (like the fabulous chicken tika strips) are also prepared on the premises. Most important of all: everything always tastes delicious.

Now the other day I caught a train in to London and, as it was around midday, I purchased a pre-packaged sandwich from the on-board buffet bar. Technically speaking this sandwich was fine. I couldn’t say there was anything wrong with it. But somehow it could not compare to my normal lunchtime feast.

This got me thinking about the different approaches used to prepare and sell each product:

• Personal vs faceless
• Tailored vs standard
• Fresh vs pre-prepared

There can be no doubt that, by being prepared in a factory to a pre-defined recipe by someone I will never meet, the pre-packaged sandwich provides an impressive example of modern industrialisation. I bet I could go back and buy the same product again on a different day and, even though it would have been prepared and served to me by different people, it would taste exactly the same: very average.

There can also be no doubt that the personalised sandwich prepared in front of me by the same person each day is not always exactly the same. Sometimes their chicken tastes different. Sometimes they’re out of ham. Sometimes there are no bagels. But you know what, despite all of that, it always tastes really good.

All this led me to the following question: is using a standardised approach to developing software just a great way of consistently delivering something that doesn’t taste so great?

In my first post on this blog I suggested that the promise of repeatable processes is a hollow dream. And yet all around me I see a continuing trend to the industrialisation of software development. A trend to a world where a factory consumes requirements and defecates software that meets them. Except the requirements turn out to be wrong. And the software is unusable. And in the mean time the business it was meant to support has changed.

Repeatability might sound great but by itself it is worthless. Being able to do a bad thing over and over doesn’t somehow make it good.

I say: get to know your customers. Tailor your software to their needs. And keep it fresh.