Communication skills for project managers – Presentation skills

CAPE CANAVERAL, FL - JULY 03:  NASA's John Cha...

Image by Getty Images via Daylife

 Read Part one    Read Part two

Presentation skills – Part three

 

As part of a series on soft skills for project managers, last week I wrote a section on communication skills. It may seem that it is a little odd not to include presentation skills as a communication skill and I will certainly not argue with this. I have also delivered a section on persuasion skills separately for the simple reason that these are key skills that require individual treatment as opposed to a short paragraph in a single blog about communications, also because it would be impossible to give communication a reasonable coverage in a single instalment  and because in the world of Project management,  lot of people will associate communications with the communication plan as opposed to recognizing it’s importance in an every day sense.

Critical for project managers

Charts used in project management

In my early days as a project manager I survived some very gruelling relationships with programme managers and sponsors as a result issues around presentation and reporting and since then I have seen other project managers and  Business Analysts driven to distraction by bosses demands for reports that they could understand.
Not only do the normal rules of presentation apply, but the project manager also needs to be able pinpoint the concerns that stakeholders need updates on and exactly how they can be reported to in order that they feel satisfied and comfortable. Above and beyond all other aspects of project management, this one is critical to survival of the project manager.

First of all you need to try and reach an agreement on your KPIs at the outset, or as soon as possible. KPIs can vary quite substantially for example, you may be in a situation where budget is critical and the critical factor is that you don’t go over budget. In this case the stakeholder will need very reliable KPIs to warn you as soon as you begin to slip. In this instance EVA might be a useful approach.

It allows you to plan a cost schedule for delivery of the product over time and plot against that costs accrued and value created so that you can easily see when the budget exceeds target or the value creation misses it’s target. Creating a simple graph and explaining it carefully to your stakeholder may be the perfect way to give her a warm and comfortable feeling about the project.

On the other hand you may find that this idea is a good one, but your stakeholder just doesn’t understand graphical reports and you have to grind it out with columns of data and a slow painstaking presentation. See paragraph on styles. The safest way is to prepare your props to be ready for all types of communication and be aware of the reactions of your audience so that you can switch modes if needed and place the emphasis on a different method of delivery when it is required.

One rule is universally applicable to project management. Responsibility for the audience understanding the message correctly lies with the project manager.
Ed Taaffe

If you ever find yourself tempted to blame it on the denseness of your audience, you are very close to the time when you should consider an alternative career path. The buck stops with you.

Progress against schedule.

Gantt chart

The great universal way to represent this key KPI is the ubiquitous Gantt chart. They are the most used tool by project managers and mostly because they are the one thing that allow you to combine data with a graphical view in one place.
The Gantt however, has many weaknesses. Not the least of it’s weaknesses is it’s ability to cram too much information into a small report. Unless you audience have the ability to drill down then most of the information it shows can be as good as useless.  The fact is that very few people have access to a tool that will open and manipulate these files.
The commonest mistake made by PMs is to assume that their audience also have spent years working with Gantt charts and understand them well. In reality very few people are entirely confident with them and some of those have oversized opinions of themselves, the remainder are generally embarrassed to admit it i public and sit quietly nodding. These people will come back to haunt you.

The next common mistake is to assume that your audience are interested in performance over time, they may be worried about risk of slippage against budget, or looking for indicators of inaccuracy in your forecast.

Slack, and accuracy of prediction

A great way to analyse and communicate the accuracy of your predictions and show your progress against these is the PERT chart.

Pert chart

The pert is fundamentally a network diagram that shows your key products being deliver, or milestones being met in the order that is necessary. It demonstrates the difference between products that depend on others and products that can be delivered independently, thus creating a critical path.
The critical path is the longest route you can take from start to finish of the project. This is extremely important to be aware of, because the tasks that make up this critical path can not be delayed without delaying the project. Provided the time needed for each task in the critical path has been sufficiently estimated for in terms of time then the project will hit it’s target.

Estimation of the critical path is done by entering three settings for each task or product. The settings are Optimistic time (OT), Pessimistic time (PT) and most likely time (MT).  By manipulating this chart a little you can very easily display the best and worst case scenarios and keep a close eye on the most likely completion dates.  The commonest calculation used to start out with is:

ETA =(OT +4* MT + PT)/6

It should be clear by now that the message delivered by the PERT chart is very different form the one delivered  by an EVA graph or a Gantt.

Progress against budget

To present a report on your project’s progress against budget, one of the easiest graphical tools is an EVM chart.

EVM chart
EVM or Earned Value Method  is a fairly simple way to compare the  projected use of time and budget with the actual use of time and budget for the work completed. It is very easy to see a project delivering on time and not notice that it has used too much budget in doing so, or to see a project that is within it’s budget profile, but has not delivered sufficient value with the budget already spent. In both of these circumstances, the project will eventually run into trouble.  Without EVM or another tool to keep track, it is almost impossible to reassure stakeholders that ll is well.

EVM start out by defining milestones in terms of work done y date within cost and then records actual time, cost and work completed  to determine whether the project is on target. The tricky bit with this method is estimating the value of work in progress for incomplete products. Even a poor estimate at EVM will still provide a clearer view into the project’s true state than relying on Gantts and guesswork and should help to reassure your stakeholders.

Traffic lights

Traffic light report

RAG for red, amber, green is a very simple yet powerful way to report on a programme or portfolio so that people can quickly get a feel for the state of play. A simple dashboard can contain one clock for each project with just the three settings. A quick glance will then tell the stakeholder whether there are issues and how big they are likely to be.
Red reports will need detailed reporting, while Amber reports require a paragraph of explanation.
RAG reports overlaid on a programme PERT can be a very powerful tool for seeing instantly the likely consequences of a localised issue on the overall programme.

Innovation and customisation.

The key to good communication is to get to know the requirements of your audience and customise the delivery to suit them.  If there is no well trodden method out there then don’t be afraid to ‘innovate. Analogy is the key so create pictures and sounds that help them compare the subject to some concept they are more familiar with. Traffic lights, measuring jugs, barometers and all types of household concepts are regularly called on for help.

Critical to all presenters

There some rules that apply to everybody called on to make a presentation and here are a few of the key issues. The most important bit starts before the presentation. Prepare, Prepare, prepare. It’s that simple. Do your preparation well in advance so you can put it out of your head for a few days and then look at it again with a fresh viewpoint. Never deliver an important presentation for the first time to important people. Get some opinions first from knowledgeable people or a small subsection of your audience.

PowerPoint

PowerPoint and it’s equivalent have become an institution in the business world.  It has it’s fans and it’s haters, but it is still indispensable in many situations.  The key to using PowerPoint well is to use it only as a central roadmap for your argument and only for the visual aspects of your presentation.

NEVER write out your speech and read it out form PowerPoint, especially not with clever little animations on every line.

NEVER substitute PowerPoint for a paper or brochure or for speaking t your audience. Each communication tool has its own job to do.

DO stick to one idea per screen and one image per idea and limit text to one line per screen.

DO use your slides as a roadmap for your presentation

DO write out your presentation and practice it using the slides as your cue cards. Write extra notes in for your own purposes if you wish.

DO provide separate handouts that include your slides AFTER you presented NOT before.

DO use your slides as a backdrop and engage the audience directly, not via reference to the slides. YOU are the presenter  not PowerPoint.

DO agree in advance whether you are inviting questions as you go or you are providing for fixed periods when questions can be floored.

Presentation Structure

There is a very simple set of rules for presentations that work well and are easy to follow, here it is:

Start middle end presentation technique

It’s very simple and proven.  Introduce yourself and the presentation by telling them what your goal is and how you are going to do it then sum up what you have told them.

E.G.  My name is Ed Taaffe, I am an expert in presentation techniques and I intend to make you more confident in presenting to your stakeholders by walking you through some very simple but effective tools for making your presentations more successful.

Then show them the examples and finally close the presentation by saying something like.

So today we have seen three key techniques used by pros all over the world ton make their presentations more effective.

  • 1. Understand your audience and their needs and use analogies that will appeal to them to explain the concepts that concern them.
  • 2. Use a good mix of visual and oral delivery and encourage questions in a controlled way
  • 3. Use reports for written presentation, use PowerPoint for visual delivery and use your own presentation skills for oral delivery. The right tool at the right time in the right way.
  • 4. Prepare well in advance and seek and pay attention to feedback at every opportunity.
  • 5. Project management throws up it’s own unique communication challenges, be aware of these challenges and don’t be afraid to innovate to get your point across.

If you are not registered, Regisrer Now to download a free paper [download#1]

Reblog this post [with Zemanta]

TOGAF – well I finally did it ( here’s the summary)

TOGAF
I couldn’t find a readable short summary anywhere so I decided to bear the pain, skim read the dull text and write a summary for any unfortunate person trying to get a quick overview of a new framework in an industry he/she already knows well.
My conclusion after a few hours of wading through the treacle is that it is well put together, if horrendously poor in it’s presentation.
A slight contradiction is that parts are already a bit outdated in that it pays too much attention to things like portability in a world where interoperability is the buzz word and the “cloud” and “tower of babel” are the modern metaphors, nevertheless any slight shortcomings can easily be overcome by intelligent people using it.
A sharp warning though is that; even more so than the ubiquitous Prince2 for project management, TOGAF won’t make an architect of you, you have to bring all the skills to the table and then it helps you get things in the right order, but even that is up for interpretation, so you really must know your stuff and have integrity
It is not therefore a reliable hiring tool in it’s own right and I see it as definitely a team game.
TOGAF calls itself a Framework, but the main body of it is ADM which is in fact a process for doing architecture.
It follows the usual pattern of breaking up enterprise architecture into four logical steps (steps because it is a process)
The technical architecture uses a method closely allied to the idea of inheritance in OOD whereby the patterns and principals are inherited from more generic ones and you then build something more specialised on top of all that.
E.G.
Organisation specific ( This is the innovative bit)
Industry specific ( This is common to all organisations in a specific industry and saves a lot of time)
Common Architecture ( This varies little from one organisation to another therefore requires a little more effort than foundation, but saves much effort)
Foundation architecture ( This doesn’t vary much from one organisation to another therefore requires little, or no effort)
They call this idea the “Enterprise continuum”
Questionable ideas
Things I would question:
1.The Foundation architecture specifies knowledge bases that you need to develop such as a set of standards and a Technical reference Model. This part is potentially futile in that:
a.constant change often makes last years standards out of date, but nobody ever updates these things
b.notwithstanding the previous comment, experience suggests that few people ever refer to them even in some big name software houses.
2.Developing business processes and storing them away gets mixed reactions.
a.Many processes are defined by and governed by the existing productivity systems and in any case may even have no scope for change, so what will you gain from low level process views?
b.The speed of change is such that keeping recorded process up to date will be more of a chore than a benefit in many businesses.
c.If you can set this at a high enough level such as business goals and strategy it is very useful, but then the benefit depends on the audience who will access it, or ignore it. The jury is out.
d.The right place in my view for business process analysis is Opportunities and solutions phase and the key to this is JIT (as per the Agile principal) if you want relevance and accuracy. In my opinion,  nobody in their right mind would invest a large sum on a solution based on old archived process diagrams at least not any experienced business analyst.
e.Finally new systems generally herald a new process, or new approach to the goal and therefore brand new processes. As-Is modelling is only an exercise to extract the business rules in order to build a better process against them, otherwise, who needs a history level in a manic business world?
3.I don’t see a Zachman like illustration that lets a business stakeholder engage with it on a business level without struggling with the gibberish. If I am right about this, then it could be a downfall, because it will end up just a techie thing behind the doors of IT and the business stakeholders look skywards at the mention of it. This is very common and would negate most of the effort.
You only have to attempt to get some sense out of the Open Group website to see what I mean. If reluctantly, at least I was able to suffer it and get a glimpse of the big picture, I can’t see anybody form a business background touching it with a bargepole. I think the implementation needs to be aware of this and cover up for the shortfalls.
4.It’s a techie invention and although pretty good once you uncover it, it was “not invented here”.
5.The Migration Planning function is a potential route to serious friction. Modern business won’t stand for an IT function that wants to “wag the dog”. When they want it in three months because it is important, no amount of processes will stop them and I have seen many big rows break out over this. I recently saw a head of projects and a director resign within two weeks of each other over rows based on this function.
ADM
The process looks something like this:
The colour coding is a suggested classification based on my interpretation and my own experiences, but I fully expect to be contradicted as I did spend a only a few hours on this and concluded the following:
Pale Blue box – CTO/CIO/Technical architect and/or Enterprise architect.  Plenty of sign-off seems to be the order of the day.
Black box Technical architect’s role but very much in collaboration with the IT function, who will have to implement it and keep it running. Often the ITIL process sits between the black boxes and the rest of the process.
Red box  – Business focused business analyst and I would say a lot of verification needed to make sure the techies don’t build a toy when nobody is looking.
Green box  – Data analyst and systems analyst
Purple box –  Business analyst role working with the business to identify opportunities, develop business cases and priorities shortlists
Blue box –Test, or QA manager and UAT signed off by  Business Analyst and UX manager.
As a rough guide the phases look something like this:
Framework and principals
1.define the scope of the project,
2.adapt the ADM process to your situation
3.identify constraints, document the business requirements, and
4.establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.
Business architecture
1.business modelling,
2.highly detailed business analysis, and
3.technical-requirements documentation.
Information systems architecture
1.develop baseline data-architecture description
2.review and validate principles, reference models, viewpoints, and tools
3.create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations
4.select data-architecture building blocks
5.conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders
6.review qualitative criteria (for example, performance, reliability, security, integrity)
7.complete data architecture
8.conduct checkpoint/impact analysis
9.perform gap analysis
Technical architecture
The infrastructure necessary to support the proposed new architecture.
Opportunities and solutions
Evaluates the various potential solutions and prioritise the ones that deliver most.
This is about business cases and stage gates and good financial analysis, but it is also about good business instinct and gut feel and requires business people to make the decisions in possession of the best possible information.
Migration planning
This is mostly programme management in that it involves acting on the outputs of the previous step to plan the flow of project through system taking into account opportunity and dependencies.
Implementation governance
This is most closely aligned to QA functions in project and programme management
It sets the acceptance criteria
Architectural change management
This is about updating the change management documents with details of new additions. For me, this is better handled by ITIL and as a PM this normally means an agreed handover to IT as part of the implementation and rollout plans.
Once in place
After the first implementation, I interpret it that the business will engage with the Opportunities and Solution function which triggers a quick iteration of the previous steps of ADM to make any required adjustments and the new solution progresses through the remaining stages.

TOGAF

I couldn’t find a readable short summary anywhere so I decided to bear the pain, skim read it and write a summary for any unfortunate person trying to get a quick overview.

My conclusion after a few hours of wading through the treacle is that it is well put together, if horrendously poor in it’s presentation.

A slight contradiction is that parts are already a bit outdated in that it pays too much attention to things like portability in a world where interoperability is the buzz word and the “cloud” is the modern metaphor, nevertheless any slight shortcomings can easily be overcome by intelligent people using it.

A sharp warning though is that; even more so than the ubiquitous Prince2 for project management, TOGAF won’t make an architect of you, you have to bring all the skills to the table and then it helps you get things in the right order, but even that is up for interpretation, so you really must know your stuff and have integrity. It is not therefore a reliable hiring tool in it’s own right.

TOGAF calls itself a Framework, but the main body of it is ADM which is in fact a process for doing architecture.

It follows the usual pattern of breaking up enterprise architecture into four logical steps (steps because it is a process)

The technical architecture uses a method closely allied to the idea of inheritance in OOD whereby the patterns and principals are inherited from more generic ones and you then build something more specialised on top of all that.

E.G.

Organisation specific ( This is the innovative bit)

Industry specific ( This is common to all organisations in a specific industry and saves a lot of time)

Common Architecture ( This varies little from one organisation to another therefore requires a little more effort than foundation, but saves much effort)

Foundation architecture ( This doesn’t vary much from one organisation to another therefore requires little, or no effort)

They call this idea the “Enterprise continuum

Questionable ideas

Things I would question:

1.The Foundation architecture specifies knowledge bases that you need to develop such as a set of standards and a Technical reference Model. This part is potentially futile in that:

a.constant change often makes last years standards out of date, but nobody ever updates these things

b.notwithstanding the previous comment, experience suggests that few people ever refer to them even in some big name software houses, so only do it if you can enforce it.

2.Developing business processes and storing them away gets mixed reactions, I suspect that this should be built up over time as and when you have occasion to look at particular areas of process.

3.I don’t see a Zachman like illustration that lets a business stakeholder engage with it on a business level without struggling with the gibberish. If I am right about this, then it could be a downfall, because it will end up just a “techie” thing behind the doors of IT and the business stakeholders look skywards at the mention of it. This is very common and would negate most of the effort.

You only have to attempt to get some sense out of the Open Group website to see what I mean. If reluctantly, at least I was able to suffer it and get a glimpse of the big picture, I can’t see anybody from a business background touching it with a bargepole. I think the implementation needs to be aware of this and cover up for the shortfalls.

4.It’s a techie invention and although pretty good once you uncover it, it was “not invented here”.

5.The Migration Planning function is a potential route to serious friction. Modern business won’t stand for an IT function that wants to “wag the dog”. When they want it in three months because it is important, no amount of processes will stop them and I have seen many big rows break out over this.

ADM

The process looks something like this:

ADM process
ADM process

The colour coding is a suggested classification based on my interpretation and my own experiences, but I fully expect to be contradicted as I did spend a only a few hours on this and concluded the following:

Pale Blue box – CTO/CIO/Technical architect and/or Enterprise architect.  Plenty of sign-off seems to be the order of the day.

Black box Technical architect’s role but very much in collaboration with the IT function, who will have to implement it and keep it running. Often the ITIL process sits between the black boxes and the rest of the process.

Red box – Business focused business analyst and I would say a lot of verification needed to make sure the techies don’t build a toy when nobody is looking.

Green box – Data analyst and systems analyst

Purple box –  Business analyst role working with the business to identify opportunities, develop business cases and priorities shortlists

Blue box –Test, or QA manager and UAT signed off by  Business Analyst and UX manager.

As a rough guide the phases look something like this:

Framework and principals

1.define the scope of the project,

2.adapt the ADM process to your situation

3.identify constraints, document the business requirements, and

4.establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.

Business architecture

1.business modelling,

2.highly detailed business analysis, and

3.technical-requirements documentation.

Information systems architecture

1.develop baseline data-architecture description

2.review and validate principles, reference models, viewpoints, and tools

3.create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations

4.select data-architecture building blocks

5.conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders

6.review qualitative criteria (for example, performance, reliability, security, integrity)

7.complete data architecture

8.conduct checkpoint/impact analysis

9.perform gap analysis

Technical architecture

The infrastructure necessary to support the proposed new architecture.

Opportunities and solutions

Evaluates the various potential solutions and prioritise the ones that deliver most.

This is about business cases and stage gates and good financial analysis, but it is also about good business instinct and gut feel and requires business people to make the decisions in possession of the best possible information.

Migration planning

This is mostly programme management in that it involves acting on the outputs of the previous step to plan the flow of project through system taking into account opportunity and dependencies.

Implementation governance

This is most closely aligned to QA functions in project and programme management

It sets the acceptance criteria

Architectural change management

This is about updating the change management documents with details of new additions. For me, this is better handled by ITIL and as a PM this normally means an agreed handover to IT as part of the implementation and rollout plans.

Once in place

After the first implementation, I interpret it that the business will engage with the Opportunities and Solution function which triggers a quick iteration of the previous steps of ADM to make any required adjustments and the new solution progresses through the remaining stages.

I remember having very similar thoughts about Pricne 2 when I first tackled it, so I wont be put off.

Perhaps I am one of the stronger proponents of Enterprise Architecture as a means to avoiding meltdown, avoiding waste and keeping the IT funciton focused on value added activities. For this reason I have decided to suffer the pain and see this through.
Maybe I will then get the courage to write a consumable version of this to win back the many talendted and desperately needed people who surely must have been alienated form the profession by the manner in which this is presented.