Project Status Reports are the cornerstone of project performance reporting, yet are seldom well written, and even less often well understood. Whilst Project Managers may diligently (and painstakingly) produce their status reports on a regular basis, many reports end up sitting idly in someone’s already crowded inbox (when they don’t make their way directly to the trash can). So why should you bother putting a (good) status report together in the first place?

Because you are worth it…

Your status report is to your project what the front page is to a newspaper: it is there to provide the latest headlines and news on what’s going on and tell people what they should care about right now. By extension, it also reflects on its author’s competence at being on top of things; the status report is to the PM what a CV is to a job seeker: write it poorly, laden with inaccuracies and mistruths, not only will it get you nowhere, but it can definitely make you look bad! Bad status reports (or none) can quickly spell lousy (or lazy) project manager. So do yourself a favour and get good status reports out.

Because it’s all about the customer…

Status reports are there to help your stakeholders, your customers, your team, to understand where the project is at and how well it is doing. It’s a direct communication channel for you to connect with people: it’s a way to instill confidence, create visibility and generate support for your project. It’s about telling your customers you care.

Because you need to keep the boss(es) happy…

Yes, status reporting is about management reporting and that’s ok… as long as it is helpful to the project. Reporting for the sake of it just consumes time, but if it leads to securing support and getting decisions made, then it’s actually doing the job it’s meant to. It’s a way to bring things to attention as well as providing confidence that the project is carefully managed.

Because it actually helps you (yes, you!) manage the project…

Producing a status report may take some time, but don’t see it as an administrative burden that you have to do because you have been told to do so (by your boss, PMI, or a blog on project communications…). Do it because it helps you focus on the essentials: going through the regular process of articulating clearly and simply how things are going forces you to focus on what is important, identify priorities and decide where you need help. It doesn’t stop there: your status report can help you execute a whole range of project management activities, from simply informing others to providing a mean to get updates from your team & reinforcing accountabilities, supporting team meetings, engaging a wider audience, and answering ad hoc requests for information about your project. The diagram below illustrates the multi-purpose aspect you can give to a status report:

Of course, if there are masters of clarity and simplicity out there, it’s Apple (save for their obscure iStore terms & conditions updates). You don’t even have to explain it: that’s where their magic operates, it’s so obvious. Innovative concepts, amazing execution, powerful messages conveyed through brilliant yet simple visuals.

The much awaited* book “Insanely Simple: The Obsession That Drives Apple’s Success” by former Apple marketing guru Ken Segall will give us an insight into Apple’s simple secrets. I particularly like the following:

“Words are powerful but wordiness is confusing… the way to make you and your company look smart is to put your ideas simply and clearly“.

Below is the book review, courtesy of last week-end’s Sydney Morning Herald:

* The book (with its insanely simple cover!) will be available worldwide from all good (and bad I guess) bookstores on April 26, 2012. I’m looking forward to it.

Project Managers as decision-makers influencers

Project Managers encounter many situations throughout the project life when choices have to be made and decisions taken. It could be making a decision about a specific way to solve a problem, or having to choose a particular technology to deliver a project, or perhaps selecting an external vendor. Regardless of the scenario, PMs need to analyse a situation, identify and assess options, and make a decision. In theory. Because most of the time (and particularly when it comes to situations that have a significant impact on the project), PMs don’t actually get to make the decision and need to secure it from their stakeholders. Hence, it is critical for a PM to know how to communicate effectively about options so that others can make the right decision.

How to communicate effectively about options:

• Be clear about who makes the decisions: it may sound obvious but sometimes it isn’t so. Many projects have (over)complicated governance models with demands for consensus across a large group of people. Whether you have one decision-maker (lucky you) or 10 (sigh), identify upfront who will need to validate a particular decision. Keep other people informed but only seek approval from those who should (and can) give it.
• Adapt to your stakeholders’ decision-making style (always think about your audience first): find out how your stakeholders actually make decisions and adapt your communications accordingly. Not all decision-makers have the same approach, so look at how your stakeholders like to operate: Do they need lots of details or are happy to rely on the big picture? Do they want to get involved early in evaluating options or expect to validate recommendations? Do they need review/buy-in from others or can they make the decision independently?
• Give people choice…: avoid going with only one option or a Hobson’s choice as this removes people’s ability to decide, and will likely antagonise them. Always propose several options: even in situations where there doesn’t seem to be a lot, it’s actually ok to propose things that you know no-one wants (such as the widely unpopular “do nothing”). Although you shoudn’t overdo it and present unrealistic choices, putting in a “bad” option can actually help you influence your stakeholders in selecting the right one. This may sound a little counter-intuitive, but research shows that we don’t always know our own preferences, and are better at picking something from a list if it includes things we don’t like. Check out Dan Arieli’s talk on TED on this subject; he has some great factual examples showing how our behaviours and decision-making ability can change depending on how things are presented to us.  
• … but not too much: don’t come up with too many options though: this can be overwhelming, and it will actually reflect badly on you: as the PM, you should show you have done the groundwork and sieved through the un-SMART choices to actually enable your stakeholders to make a good, informed decision.
• Influence (aka help people make the right decision): you may not be the one making the decision, but you should always be ready with a recommendation and have enough to back it up. If your decision-maker pushes for an alternative, be clear about the impact of going his/her way. Try to remain open and objective though: they aren’t there just to say yes or no; they can also provide insight and input into problem-solving. And they are also the customers, so you need to be ready to support them.
• Make your message clear and simple: 
  • don’t drown people with details: people don’t need to see all the detailed work that’s gone into analysing, comparing and drawing out conclusions, so keep things meaningful but “exec-summary” style. State the situation you are addressing, and provide a brief, clear description of each option, focusing on why it solves the problem. If people want details, they’ll ask.
  • make your recommended option stand out: when discussing options, the position of your preferred option counts: either put it first (this gives you the benchmark to compare other options against) or leave it for last (this works well when you want to introduce an alternative that hasn’t been considered before and when none of the other options are really satisfactory; saving the preferred option for the end allows you to showcase it as “the” solution). Just don’t drown it in the middle.
  • make your message visually clear: in addition to keeping words succinct and to-the-point, use good visual presentation to support your message. A simple table showing the options with their key comparison points will be more effective than a long, detailed narrative. Clearly point out pros and cons, and if you use a scoring method to show how options are evaluated, keep it simple and make sure it does not leave room for interpretation (include a guideline or legend to help your readers understand it).
• Follow-up: once a decision is made, communicate it to the rest of the team and the project stakeholders. Be clear about the impact on the project and update your plan and activities accordingly.

And here’s one I made earlier…

The example below shows a situation where a project is impacted by a vendor’s poor performance. Analysis work has gone into the process, and findings are presented to the project sponsor for validation: options are summarised with pros and cons concisely presented, and the recommendation is clearly highlighted.

Yesterday, I downloaded a couple of apps for my beloved iPad, and got the now familiar message about updated Apple iStore terms and conditions, which I was required to review and agree to before I could proceed with my purchase.

The new terms and conditions were laid out for me in plain black and white text…all 44 pages of them! Beside the fact that I wasn’t willing to spend time reading all of it, even if I had, there was no easy way for me to tell what had actually changed. Short of getting hold of the previous version and comparing it word for word, it just wasn’t feasible for me to spot the difference. So I clicked “Agree” and who knows (well some lawyer somewhere does I guess!) what I have signed up to…

This is a good example of bad communication about change. It’s the same on projects: Project Managers constantly have to communicate changes (what it is, why it’s happening and what impact it’s going to have), and it’s always a challenge to get the message across to project stakeholders, particularly when the change needs approval. Failure to communicate effectively about project changes leads to two possible situations:

1) Your stakeholders don’t approve the change until they understand what it is, and you end up spending a huge amount of time going back and forth with them to explain it all;

2) Your stakeholders sign off even though they don’t understand it (sometimes finding themselves in a “no real choice” situation very much akin to my iStore terms & conditions scenario above). Now you might get away with it (hey, after all, it is their responsibility!), but this can lead to dire consequences, and honestly the last thing you want is a pass-the-blame game between you and your stakeholders about “who approved what without understanding it” and “who didn’t make it clear in the first place”.

Because change is often difficult to accept, it’s really important to make it clear to your stakeholders what’s changed and what it means to the project (and to them). When you are communicating a change, whether it is a revision to the project schedule or an updated baseline scope, don’t just issue a new project plan or a new version of the scope statement: make it clear to your audience what’s new and make it simple for them to understand what it means.

Here are a few examples from the field. To set the scene, imagine you are the project manager responsible for the delivery of a website supporting the launch of a new product range, and you want to address some key aspects of the project with your project sponsor, the Sales & Marketing Director.

◊ About the methodology used to manage the project:

Don’t say: Project methodology used will involve iterative waterfall integrating Agile principles, allowing streamlined iterative software cycles through collaboration between self-organizing, cross-functional teams.

Say: Website functionality will be released faster and in smaller chunks, and will involve extensive interaction and feedback from Sales & Marketing subject matter experts.

What’s different: The project methodology you choose is not relevant per se to your stakeholder and would mean likely mean nothing to him. Here it’s about making it meaningful and saying that his team will be heavily involved in the project , and that the new website site will go public soon, and in phased increments.

◊ About testing the new website:

Don’t say: Testing plan and execution will be composed of several test cycles of UT, SIT and UAT with bug tracking and fixing prior to code freeze for technical deployment.

Say: The website will be validated first by the technical team, then by Sales & Marketing users before launching to the public.

What’s different: Avoid specialist acronyms (here Unit Testing, System Integration Testing and User Acceptance Testing) and focus on what makes this relevant to your stakeholder: here it’s about providing confidence that things will be thoroughly checked before going public, and that his team will have a responsibility in doing that.

◊ About managing project progress:

Don’t say: We will use the PMO’s centralized PPM tool to monitor project plan and milestones achievements, and identify and track risks and issues.

Say: We will report project progress to you on a weekly basis and proactively engage you to resolve problems when required.

What’s different: You don’t need to talk about the tools you use because frankly your stakeholder won’t care if you are using a sophisticated software or the back of a packet of mints to monitor the project: it’s your job to track the project, whichever way you see fit. What matters here is to tell your sponsor that he should expect weekly reporting, as well as being called in to make decisions when needed. Oh, and of course you can kill the acronyms on this one (Project Management Office and Project Portfolio Management).

◊ About project budget status:

Don’t say: CPI is 0.8.

Say: We are currently running over budget due to the need to add functionality to comply with legal requirements. Approval on additional budget or scope revision will be required.

What’s different: another case of staying away from specialised acronyms (CPI = Cost Performance Index, an efficiency indicator showing the ratio of planned cost of completing work on actual cost of completing work). Actually, here CPI is more likely to mean “Consumer Price Index” to your Sales & Marketing guy! Although I am an advocate of “less is more”, here this short piece of data doesn’t really inform the non-initiated. The number in itself doesn’t matter so much: what matters is to say what it means (we don’t have enough money to finish!) and what to do about it (we need a decision from you!). See also post on talking about risks and issues.

Is a picture worth a thousand words?

Although I am a lover of the written word and can devour books, when it comes to professional communications, I think a good picture can be worth a thousand words.

In today’s world, images are becoming more and more important, and good visuals and message presentation can make a huge difference when it comes to making your message stand amongst hundreds (think of your stakeholders’ inbox..). Research shows that we retain far more through visual aids than simple verbal form.  From the simplest (like underlying the important words) to more sophisticated diagrams (like process flows or smart graphics), good visuals help make abstract and complex concepts visible and concrete, leading to better understanding and response from the audience. In fact, not only do they help you engage and persuade your audience, they help your very own thought process by forcing you to organize information logically, and represent and articulate clearly what you want to say.

With the vast amount and complexity of information that need to be shared, Project Managers can dramatically increase their audience’s response by using good visual presentation to convey information. As a PM, you constantly sell your project to stakeholders, and a lot of project information can be enhanced through visuals, whether it is a well formatted, easy-to-read project status or a clear overview of your project timeline.

 Why making it look good matters…

No matter how we would like to be fair and not judge a book by its cover, first impressions do count. That’s how we are; it goes with the first time we meet someone, the split second it takes us to decide to switch TV channels, the quick glance we give a CV before binning it, the 90 seconds we need to decide a home is perfect for us.  The same principle applies to our daily work communications, and using good visuals can tip the balance in the favour of your message getting read rather than ignored or glazed over. Where poor presentation and lengthy documents can bore readers to death, good visuals can make your stakeholders pay attention to your communications.

Quality of message presentation (whether it is an email or a set of slides) is not only a direct reflection of the author, it also tells the audience what we think about them.  If we want people to take the time and effort to read or listen to us, we have to make the time and effort to render our communications accessible.

…. and why it’s not enough:

Of course having pretty slides and professional-looking sleek documents is not quite enough – they may impress at first and audiences might wow at your graphics skills and Powerpoint/KeyNotes mastery, but you do have to show (and know) content. If good content can be destroyed by poor presentation, a pretty package cannot hide an ugly gift (for long). Good presentation is there to carry the message, never to replace it. Unnecessary, complicated, overworked graphics and animations, don’t only take too much time to produce, they will actually distract your audience from the main subject. Using good visual presentation does not mean turning into a graphic designer: it’s about conveying in a clear and simple way a message, and help the audience read and understand that message.

Remember to get the balancing act right…

Content and format go hand-in-hand and complement each other in a ying-yang kind of way, and you need to weigh the time you spend on format against the objectives and the importance of your communications. For example, it is worth spending time doing a really good presentation of your project (which will be used time and time again and seen by a large audience), but don’t labour over making fancy resource utilisation graphs if you’re the only one using them.

 … and keep things clear and simple:

• Use what’s available to you: there is no need to go on a graphic design course to produce powerful visuals. There are many visual aids available to us and today’s standard office softwares offer a vast choice of ready-made graphics, templates and colour schemes.
• Don’t ditch text: words are still important and there is no point in trying to replace all text with visuals. Pay attention to the language you use and choose meaningful and focused words rather than obscure symbols.
• Give your documents breathing space: whether you produce a project status report or a project presentation, think of your audience’s ability to read and understand what you’re trying to say. Don’t overcrowd your documents with lots of graphics and text and make sure there is plenty of white space to rest the eye on.

Listening is recognized as a key part of effective communications, yet we seem to slowly but surely forget that essential skill. We are surrounded by multiple sounds on a daily basis, yet we hardly pay attention. We sit in meetings, half-listening to what other people say, because we’re busy checking emails on our laptops. We talk to people on the phone whilst typing out notes for a report. We set up important face-to-face meetings, yet keep our ears tuned to the ring of our cell phone, just in case. We brand ourselves as multi-taskers and think we are more productive.  In the end we end up getting everything half-done.

So stop and listen*. Re-tune. Listen again.

* If you have forgotten how to listen, here is a 5-minutes reminder from Julian Treasure: view below or click here 

Someone asked me why communications are so challenging when it comes to projects, arguing that there aren’t a lot of jobs out there, particularly in the broad management arena, that don’t require good communications to be successful. The truth is, all managerial jobs do demand great communication skills (is there a manager’s job advert that doesn’t mention it as a must-have?). But it got me thinking: what is actually sooo special about Project Management that makes it so hard, and important, to communicate well?

So here are my top 3 challenges:

Challenge 1: Audience

PMI defines a project as “a temporary endeavor undertaken to create a unique product, service, or result” (PMBOK®). It’s that uniqueness that makes it tough: because each project is unique, everything that goes with it, including its audience, is too. So for every new project, you get a new group of people, with different needs, expectations, styles, abilities and interests. Communications-wise, it means every project requires you to adopt a strategy that adapts to and fits this new and unique audience.

Extra challenge: within the audience itself, PMs have to deal with a wide range of people on all kind of levels: from junior team members to powerful senior executives, from technical experts to strategic business thinkers, from detailed-hungry specialists to big picture decision-makers. PMs have to find the right styles and techniques when communicating with such a diverse array of people.

Challenge 2: Time

Of course, one of the great constraints of project management (whatever methodology you choose to apply) is time. Not only do PMs need to spend time wisely on communications, they also don’t get much of it to get to know people, build relationships and establish good communications. There is little room for trial and error, and few opportunities to re-engage lost stakeholders and fix failed messages: project communications need to be effective from day one.

Extra challenge: PMs also need to consider their stakeholders’ own time constraints. The reality is that projects involve many people who also have other things to work on, and as a PM you will compete for their time. Communicating well is essential to optimize interaction with others (especially with those busy, senior, hard-to-get-hold-of decision-makers) and messages must be purpose-driven, timely, and straight to the point.

 Challenge 3: Information.

PMs need to be able to communicate about a wide range of topics (such as financial information, technical matters, status update, contractual issues, etc.). They must find the balance between sharing too much (information overload) and too little (information retention). Not only projects hold huge amounts of information at different levels of complexity, the fact is that information is never static: it’s ever-changing, and by the time you share it with others, it’s often already superseded by updates and changes.

Extra challenge: PMs also have the hard task to broach difficult subjects and convey sensitive messages (like project problems, delays, issues, risks, requests for additional time or money, etc.). So communicating clearly and in a positive, constructive manner is crucial.

So what?

Being aware of what your challenges are as a PM will help you understand how to go about establishing effective communications and devise the appropriate strategies. When you start on a new project, evaluate your audiences, your time constraints as well as the kind of project information you will need to share with people, and integrate this into your communications plan and priorities.

Last but not least: don’t look at communications as a project management problem. Though they can be challenging to put in place and demand time and effort, effective communications are actually part of the solution, and will help you and your project move forward.

The other day I watched an episode of CSI in which the DA rejects a prosecution case put forward by Grissom’s team because of the complexity of the scientific evidence. The evidence is linked to the time of death of the victim, which is calculated by evaluating the maturation age of insects found on the cadaver and applying linear regression techniques, whilst taking into account environmental factors like heat, humidity, soil composition, etc. Whilst Grissom is of course more than comfortable with the technical explanation, Captain Brass sheepishly admits he scarcely understands it. The DA concludes: ”how can a jury understand it when your arresting officer barely gets it?“, and promptly sends the CSIs back to the lab.

Eventually the CSI team finds (as they do) other evidence whilst running tests on bullets. Then it’s back to the DA, who this time is more than happy to take the case on, as, undoubtedly: “people understand bullets better than bugs…“.

It caught my attention because, beside telling me once more that really there is nothing that can’t be solved using a magnifying glass and a pair of tweezers, it was a clear case of the need to communicate in a clear and simple manner that fits your audience. It’s the same on projects; whether you have a great idea for a new project or need to go to your project sponsor for a major decision, you have to find the right angle to get your stakeholders’ attention, understanding and buy-in. Something that may be obvious to you to understand is not necessarily so for people outside your field of work or your technical specialty. So find what will talk to them, relate what you want to say to them, say it in their language, and you will win your case (or at least move it forward).

Effective communications start with using simple and clear words, and establishing a common understanding of those.

On projects, we constantly refer to success. Now that is a word that is very much used and misused, and the source of many misunderstandings. The Oxford dictionary defines success as “the accomplishment of an aim or purpose“, a broad and vague enough statement that pretty much allows any interpretation. Ask your project team and your stakeholders what project success means, and you will get many different answers. Whilst success is (or should be) at the forefront of everyone involved in a project, hardly any time is actually spent on defining what success is. Odd, isn’t it? We all work towards one goal, and yet most of the time we don’t even know what it looks like…

As a PM, how many projects have you completed successfully? Chances are: most of them, because you probably/hopefully delivered your part. Was your project successful? Now that’s a totally different question…

So what is project success?

A project can only be successful if the success criteria were defined upfront (and I have seen many cases of projects that skip that part..). When starting on a project, it’s essential to work actively with the organization that owns the project to define success across three tiers:

• Tier 1: Project completion success: this is about defining the criteria by which the process of delivering the project is successful. Essentially this addresses the classic “are we on time, budget, on scope, quality?” (adapted to whichever PM method you might be using). It is limited to the duration of the project and success can be measured as soon as the project is officially completed (with intermediary measures being taken of course as part of project control processes). The PM should be accountable for this tier.
• Tier 2: Product/service success: this is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, etc.). These criteria need to be measured once the product/service is implemented and over a defined period of time. The product/service owner should be accountable for this tier.
• Tier 3: Business success: this is about defining the criteria by which the product/service delivered brings value to the overall organisation, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (eg. x points marketshare won), etc. The project sponsor should be accountable for this tier.

=> Overall success: Each tier supports the next, yet you can be successful in completing the project whilst the resulting product or service delivers no value… So it’s important to bear the big picture in mind: ultimately tier 1 matters little if tiers 2 & 3 are not met, and the overall success needs to be defined and agreed as part of this exercise.

What about communications?

This is where communications are important: tackle the definition of success for your project early on and get agreement and buy-in on what it means. Get people together and work as a team to define how success applies to your project across each tier. This process also involves the definition of measurements criteria, and this is what will make the definition tangible.

Each project is unique, therefore each success is too, so share the definition of success with your team and remind people of it when problems arise. Communicate your progress towards it and of course, celebrate it!