Powerpoint vs Presentation: The Art of Communicating Effectively

A lot of people would say that the word "powerpoint" is the same as the word "presentation" and, sadly,  a lot more would define "presentation" with the word "powerpoint" embedded somewhere in that definition.

The truth of the matter is that a presentation can exist without a powerpoint and a powerpoint, unfortunately, can also exist without the presentation. Most companies can fill up rooms of powerpoint documents that failed in getting the message and the decisions across but don't blame the powerpoint for it - in most instances, it was a failure in the presentation and not the powerpoint.

I have learned (and I continue to learn now) that there is a process to a successful presentation that does not start with opening up powerpoint (gasp!). Here are some key tips I have learned so far:

1) Key Message - The thought process should start with the key message - what is the one primary objective of the presentation. It can be a sales pitch or a decision driver, for example.

2) Outline - Breakdown the key message into an outline. The art of the presentation starts with an objective and then goes first into a high level story telling approach - what are the key points that would support the objective.

3) Simplify - When you have the outline ready - review it and ask yourself the following questions - is the story build up good?Does it have direction? Does that direction logically lead the audience to the objective? Is there information that you can consider extraneous? Does it fit the time allotted for the presentation?

4) Approach - When you have the high level outline done and you understand what you want the presentation to do - decide next what is the best approach for the presentation. It is not always through a powerpoint document that a presentation becomes effective. It may be best to just stand in front of the crowd and talk them over it or maybe start with a video for that emotional build up or a series of photos to set the stage.

5) Effective Powerpoints - If you do decide on a powerpoint, keep in mind the following tips that I have learned over the years:

• Keep it simple - each slide must have one message and one message only
• Word it right - imagine that each slide is a billboard on an interstate and your audience is driving a car on that interstate at speed limit and think about how many words they can read on your billboard as they speed by - that is the number of KEY words that you should have on your powerpoint. Studies vary - from 8 to 10 words.
• Keep it tight - the message of your slide should be heard and understood within 5-8 seconds. Imagine that you are presenting your slide while inside an elevator - borrowing from the proverbial elevator speech - each slide should only take as much time presenting as a 2 floor ride in that elevator.
• Images help but don't overdo it - studies have shown that learning is enhanced if senses are involved in the process at the same time. The saying that "a picture speaks a thousand words" still hold.
• Bottom line - each element in your slide, from that picture to that movie to the words used, must have a distinct value and purpose to be on that slide. If you can't figure that out in 3 seconds - remove it.

The Leader vs The Visionary - 6 Steps on How to Connect the Dots between the Vision and the Product

A lot of people associate leadership with being a visionary as if one quality naturally begets the other.

Unfortunately, this is not so and there are people who are great at visioning an idea but truly cannot lead it to execution. There are also people great at executing but cannot envision a strategy.Vision is important but vision without execution is futile. Execution is important but executing without a vision is folly.

The people we remember the most as having changed history are those that can envision a strategy AND can also see it to fruition.

How do you connect the dots between a vision and its execution? Here are the steps I have observed of the people who I believe were able to not only envision ideas but also saw them through fulfillment.

1. They OBSERVE their current environment and look at opportunities or gaps. It can be a simple product that takes half the time of doing a task or it can be a grand plan of remodeling a city to make it more sustainable.

2. They create possible solutions and define the BENEFITS vs COST for each one(quantitatively and qualitatively)

3. They PRIORITIZE the possible solutions and define risks vs opportunities for each one and decide which solution will make the most sense to do.

4. They further scrutinize their ideas and define what RESOURCES they need to make their visions into reality and start the process of connecting the dots between the idea and the final product.

5. They MARKET their ideas to the relevant stakeholders and get buy in and support.

6. They see their ideas through with such persistence that they don't rest until their ideas either become reality or they realize that the actual cost is costing prohibitively more than the foreseen benefits.

At the end of the day - a visionary who just envisions but cannot fathom how to execute is just a dreamer and a person who just executes without the guidance of a strategy is a lost soul.

How to Estimate Project Cost High Level

Sooner or later, we will alll need to estimate costs and though there is an entire science on this subject and it can fill many books - sometimes you just need a "high level" number or a "ballpark figure" just to assess whether a project will be cost prohibitive or not to do.

I just want to share with you what my "rule of thumb" process when estimating technology project costs and I hope it helps you now and in the future. I found that the numbers I get from this process are within 10-18% of where the science will take me - enough to drive a decision on whether to proceed with the project or not.

My Definitions:

• Base Estimate - Ideal Estimate assuming all things go right
• Base Budget - the internal budget we use to actually move the project forward
• Planning Budget - the budget we use for planning and budget requests 

Calculations:

1. Base Estimate = summation of all the resource costs you need for the project (eg Labor, Hardware, Software Licenses, Conference and Travel, Support and Sustain costs, Implementation and Training Costs)

2.Base Budget = Base Estimate + Impact of Known Risks (see below how to estimate)

3.Planning Budget = Base Budget * Unknown Risks/Contingency Factor (see below for rule of thumb)

How to estimate the Known Risks

1.Analyze the risks you identified and determine which are related or dependent to each other (if one risk happens - the other will happen too) and classify them into risk groups

2. For each risk group identified - estimate the dollars it would take to recover the proejct or the business if the risk happens * probability of it happening (there is a more accurate way that includes impact - talk to me if interested) . Note - if the probability is > 50% - then it is an issue, not a risk.

Sum the resulting dollars

  

How to estimate the Unknown Risk Factors/Contingency Factor - this is more a gut feeling based on experience or parametric analysis of historical projects

If your gut or experience is telling you that

1.There is a low probability of unknowns - add 5-10%

2.There is a medium probability of unknown - add 10-15%

3. There is a major probability of unknown - add 15-20%

 Sum your numbers.

Four Critical Components in Successful Project Implementations

As most project managers know, having solely a project plan does not guarantee project success. We can fill entire buildings with project plans that are associated with failed projects.

I have found in my experience that there are generally Four Critical Components that a project manager must consider when implementing programs or projects to assess the probability of success for his project.

1. Senior Management Support - this is a key ingredient to success. The project must have full senior management support and this does not mean just financially, but that helps of course, but senior management must believe in the output and must advocate for it to the general business community. This is where excellent stakeholder management skills come into play. A project manager must understand what BUSINESS KPIs are important to senior management, how the project supports those and what is the ONE PROJECT KPI that senior management will protect in times of crisis - cost, schedule, quality, scope?

2. A Solid Strategy - Thee project must tie up to an overall business strategy that can span multiple years and it must be an important part of that strategy. The strategy must be concrete (not just a vague vision), comprehensive, sustainable and drives significant incremental value to the company or client. If the project feels more like an off activity then it probably is a rogue project and we all know that at crunch time - nice to have projects are no match to critical to do projects.

3. An Enabled Talent Pool - we all know this - even the best project plans out there will not bring any benefit to the company and the project if the people leading and executing the plans are not properly enabled and/or not the caliber required by the project. Don't be deceived by some people saying that project managers are generalists - the best project managers I have seen are actually specialists. Not to say that they can't run general projects but they excel in their chosen fields. The project team members must also complement one another, know their roles and must be properly resourced to execute their jobs. The most mature team are those that understand that individual superheroes do more damage than good to a team and at the end of the day - it is the entire project team - working as one - that can deliver successful projects.

4. A Consistent and Appropriate Set of Tools and Processes - from process definition, handovers and even documentation requirements - all of these must be consistent and appropriate for the project being undertaken. A good PM will know the different process and tools (like those from the PMBOK) - a great PM will know which processes and tools will be most effective in the project. Discuss early on in the project what processes will the team follow, who will do what at every task (RACI), what documents will be required at what phase and what tools will be used to create and share project assets across team members. Regularly assess as well how the tools and processes are helping the project and be open to changing them if need be.

Finding the Balance between the High Level and the Devil

It is amazing that a lot of projects get derailed because new details are found late in the project and some of these projects even become un-recoverable but sponsors still avoid discussing details during the initial phases of the project.

Understandably, at the early stages of the project, not much is known about the deliverables but sponsors and project managers must consciously allocate time early on to talk about potential risks and not put those discussions on the parking lot with the hope that eventually people lower than the managers will think about it.

Sponsors and Project Managers always say that "the devil is in the details" but let the devil remain uncontrolled. Control the devil - or at least identify the worst case scenarios - early on and the probability of project success increases.

The key is finding balance between defining deliverables and identifying critical risks that might derail the project.

Projects Must Align with Corporate Priorities

In the everyday hustle and bustle of user communications and the desire to serve by managing the low hanging fruits as fast as possible, project management teams are most likely to miss out on a critical aspect of a project - is it really needed by the corporation?

Most of the projects I have seen are more responses to the short term pains of a few groups of people rather than an answer to an over-arching need of the company. Most of these pains are mere symptoms of the root problem rather than the problem itself and thus there are several project teams that deliver what we call "band-aid" solutions rather than long-term pain relief.

There are some questions that help determine where the project request is truly rooted on and what need does it truly answer and some of them appear below. In several cases, just asking the project sponsor a few of these questions can get people collaborating more across peers or having them re-think their original requests.

1. Priority -> How does this project tie-up to the corporate priorities(sometimes call the CEO agenda, the company mission,etc)?

2. Cost/Benefit - > What will the company gain if we do this project? Don't forget to ask as well what will the company lose if we don't do the project? The more specific the answer - the better. It is, for example, better if the sponsor can tie it to profit growth or profit loss or if the user can tie-it to a specific business process problem that the project will address.

3. Project interactions -> Does this project tie-up with any existing or planned projects that the company is already undertaking?

4. Resources -> To what extent will the company support the resource requirements of the project?

It would be an eye-opener if our executives realize how many projects failed (and costed the company money) because the questions above were not asked(or answered) early on.

Gray Areas are Wonderful Places

As people rise up the ranks in management, there comes a time that they learn a very important lesson - management exists to live in the gray and to provide direction for the rest of the team to follow.

Managing gray is really a very dangerous activity -> if you lean toward one end more often than is perceived as required will bring you negative reviews. An example of a gray area is "the desire to service your customers" vs "the capacity to realistically deliver everything they ask for" or the gray area on " I believe in this employee and will give him a second chance" vs "I am sacrificing my company's interest by keeping him" or a simpler gray area that matches speed vs thoroughness. Work too fast on a project and you can be called reckless, work too thorough and you can be labeled as slow.

The key to successfully managing the gray is developing the ability to develop the sense to know, case by case, where you would lean into - to truly understand where the benefit will really lie and be wise in deciding and communicating the basis for the decision and what it means tactically to your team. There is no "one size fits all" nor a "silver bullet"

Few people understand the gray areas and fewer still write about it but there is a book that writes about it that I found enlightening in this discussion - >Managing the Gray Areas.

The thing is - we also quickly realize that the higher we go up the ranks, the bigger the gray areas become - eg "should I keep the model of this company being its new CEO and be reviewed as risk-averse" or "I should change the model of this company as its new CEO so I will be reviewed as revolutionary and out-of-the-box" thinker.

Bottom line - if you can't swim in the gray area and if you can't grow it - it will quickly show - not only through your output but also in the belief your team has for you...manage it will and it will be the only place you want to be.

Career Advice for Project Managers

I have a team of people right now that all have sparks in them and on one-on-one discussions with them - most of them want to be project managers. I just know that all of them will become great project managers someday and I see myself as one of the few people who can help them get there faster...by telling them what mistakes I had and how I learned from them and hopefully they learn the lessons faster than I ever did...I figured that my own success is driven by them becoming great project managers in their own right so I always see this as a win-win move.

My team gets juicier projects and our sponsors know that even amidst of several high profile, complex projects - my team delivers.

One of the basic discussion points though that I think most people miss that is critical to their careers is knowing what they want to be when they grow up and I am not talking about people wanting to be VPs or even CEOs at some point in their lives but truly describing in detail how they see themselves becoming that person and what exactly are they doing by then and most importantly knowing what would it take for them to get from where they are now to where they truly truly want to be.

I always tell them that it is like using a GPS - their own career GPS so to speak.

1. Know in detail where you want to be (eg you typing the exact address in your GPS and not just the city)
2. Know exactly where you are right now (even the GPS does this first time you turn it on)
3. Know the milestones or critical turns that you need to remember along the way
4. Check every now and then if you are still on the right path
5. Expect surprises along the way and when they happen, be ready to take action and change direction if need be

Situational Leadership and the One Minute Manager

In the book by Ken Blanchard, One Minute Manager, he talks about Situational Leadership. I could say that so far, this is the best theory I heard about management and leadership.

It does not come to us naturally as managers since we always think and say that to be effective, we have to have a management style that define us. This book would tell us that to be truly effective managers and leaderships, we should be able to flex to multiple styles to fit the development needs of our direct reports.

Does the direct report require direction or support or a mixture of both? This book tells us that our direct reports go through different development needs(D1 to D4) and that as managers, we are responsible for ensuring that our direct reports can be as productive as possible by providing them appropriate leadership styles (S1 to S4).

The book also tells us that the development needs varies by task and we should not label a person a D1 or a D4 without attaching the label to specific tasks.

At the end of the day - the book tells us that there is the golden rule (do unto others what you want done unto you) but there is the platinum rule - do unto others what they want done to them and the latter is the true measure of a true leader.

Be Interested to be Interesting - Listening Your Way to Success

One of the things that I value about my current company is that it values people so much so that it has a training program for managers geared towards developing them to become better people managers. What resonated with me the most today is the phrase "be interested to be interesting".

I have always found myself to be in the mood to solve problems so much so that when people come to me about a certain concern - my brain starts thinking about giving this person some advice on how to solve the problem as soon as possible thinking that it is after all what he came to me for - right? I realized today that may not be the best approach after all.

I learned that the best first approach is really to listen - and not just listen by saying "aha", "ok" or simply not talking. Listening is being fully engaged at that moment in hearing and understanding the other person fully. The first goal is to be truly able to paraphrase or summarize what the other person is saying as a statement without your own judgment or thoughts mixed into it.

Some tips I learned:

a. Have the word "you" in the first few words to indicate that what you are saying is not your thought but your speaker's thoughts and you are simply reflecting on what he said to ensure your speaker got his message to you right. Examples can be "From what I understand, YOU..." or "You are saying..."

b.Paraphrase - don't parrot. Don't simply repeat what the other person is saying but say it in your own words

c.Acknowledge the feelings, not just the content. An example would be "From what I understand, you are upset with your situation". You are not saying it is right or wrong to be upset but simply acknowledging what the other person feels.

d. Don't use it all the time. Assess whether reflective listening is the right approach for what you are trying to achieve, which may be providing the other person some room to process his own situation more clearly or allowing the other person to think himself through a solution. There are moments when a more direct approach might be required. Use your own judgment and sense of intent and appropriateness when practicing.

The Project Management Circus: The Final Act - The Escape Artist

The show has reserved its best act for the last and entering the stage right now is the escape artist - who also goes by the name project manager on his non-circus performing days.

The escape artist thrills everyone and brings out that gasp in the audience as he always puts himself in situations that will kill a regular human being..but he is no ordinary person - he is the escape artist.

So what does the escape artist have in common with the project managers of the world? It is his ability to know his environment, use his knowledge and training to get out of tangled up situations and still come out victorious, alive ..and the to roaring applause of his audiences.

A project manager must always know his tools, his equipment to be able to manage his projects. A project manager must also train himself constantly on not only knowing the tools but also on how to use them and when. He must practice. Constantly.

If a project manager does not know his tools well enough and does not have experience in managing complex projects - he might just be one of the casualties waiting to happen in this great art of being an - escape artist.

Red Pill or Blue Pill? (Living in the Matrix)

Most of us, unfortunately, were not given the choice that Neo was given in the movie The Matrix and we typically either land in a matrix environment or not.

I lived in both worlds and I can attest to the fact that whichever organization structure you are in - they all have their pros and cons. I can say, though, that it is the matrix environment that required me, as a project manager, to develop some specific skills that allowed me to navigate it.

Why is it tricky to navigate? For one, aside from your immediate project team, most of the people you need to be successful do not directly report to you. That means that, chances are, their priorities are different from yours and they can derail your project with less of a concern in terms of performance reviews - as long as their real boss agrees with them. There is also this need to have more communication channels which open your team up to a lot of possible miscommunications.

So what skills did I need to succeed in this environment?

1. Influence - John Maxwell, in his book, Developing The Leader Within You actually said that "Leadership is Influence" and never is it more apparent than in a matrix environment. Unlike a direct report, you need to influence more a person or team that does not report to you to buy into your plan and work with you to succeed

2. Communication - Communication takes on a deeper meaning in a matrix environment since it is the glue that keeps everyone pasted onto your objective as you try to move everyone to the goal and as I mentioned, I realized that in a matrix environment,  there is a need to have more communication channels laterally since one characteristic of a matrix environment is that the org chart is a lot flatter but broader.

3. "Ball Handling" - The matrix was created for several good reasons and one of them is to allow expertise to develop in a group while allowing these experts to work in your projects - sounds good but this requires that, as a project manager, you should know when to pass the ball and to whom. This message got imprinted on me in a workshop when excepts of the movie Goal! - The Dream Begins was shown to us.

4. The ability to see the bigger picture - There were times that I needed to admit that truly my project was less of a priority than a project my matrix team was working on and I had to give way and replan my project because at the end of the day - the question is "which project stands to give the company the best possible benefit vs cost". Some days - that project is not yours.

So why does the matrix still exist amidst the complexities it has? It is only the matrix environment that allows a company to have the expertise and flexibility to execute projects through different resources. For it to be as productive as possible though - the matrix must move as one as a project manager - you are one of those people that steer it.

The Beauty of the RACI

The RACI chart is a standard document in most projects and I would say that it should be a standard in ALL projects ..but what is a RACI chart anyway?

RACI is an acronym and different organizations have different takes on what each letter means and that is why as a project manager, you should be aware of the standards of your client's company with regards to a RACI chart - take the time to ensure you have the right definitions because it can cause confusion later on. It is usually created when a project has just been conceptualized.

Typically RACI stands for Responsible, Accountable, Consulted, Informed. In other organizations, it can mean Responsible, Approver, Consulted, Informed or even Responsible, Approver, Coordinator, Informed. Whatever it can mean, it always answers the need to know who are the people responsible in defining and delivering the project and what is their role in EVERY task in a project. Most RACI chart requires there is only one R for each task or only one A for each task if the A means accountable - a good practive to have.

I recommend having a template of all the possible task that a project can take vs lumping them into generic work that may cause issues later on. The template can then be "customized" based on what a project requires. Remember - a task that says "complete the design document required for all data interfaces" is much more trackable and thus controllable that a task that says "complete design documents".

What is the importance of a RACI when you have a solid, trustworthy team? Each project is unique and in my experience, there is always room for assumptions and one assumption that team members usually make is that if the task is unfamiliar to them - then it might not be theirs and will taken cared of by another team member. Another situation is when the task can be performed by more than one person in a team - you can either have a case of two people doing the same work or noone doing the work.

By having a RACI chart from the start, you ensure that each person knows their role, the extent of their role, what they are expected to do in each task, if any, and how they relate to other people and their roles - a perfect recipe to prevent roles and responsibilities issues later on.

The "3 Whys" and its Power in Scope Control and Management

One of the most successful tools in your PM toolbox should be your "3 Whys".

It is a conscious process of not advocating your thoughts or countering an idea until you have been able to at ask your client aat least 3 Why questions.

An example scenario is when your client would ask you to add something in scope.

A series of Why questions can be the following set and all of them will help you to a)understand your client's motivations in making the request, b)determine the perceived value of the request from the client's perspective and c)give you sufficient knowledge to start a negotiation discussion if need be.

1. Why do you want to add that to the project's scope?
2. Why do you think that by adding it it will add value to the project's outcome?
3. Why do you think that by not doing it we will jeopardize the success of the project?

There are several PMs who rush to a decision or conclusion when a change in scope is requested without fully evaluating the true nature of the request and if it can truly benefit or not a project and its outcome.

By asking at least 3 Why questions (and more if need be), you will not only place yourself in a better position to assess the request but it will also give your client that reassurance that you are interested in more than simply execution.

It is a well known fact that one of the common questions in the PMP exam is the question of what should a PM do when a scope change is being requested. Remember - the most no-no answer is to simply say no.

A good PM should always assess the impact first of the request and the "3 Whys" gives you that good start.

The Lion, The Witch and the Project Manager (How to Manage Scope Creep)

The Lion - the stakeholders who roar the most and try to add scope without willing to add resources or bend to new schedules. They hope that since they are the supposed Kings of the Jungle - the only thing they need to do is roar loud enough and whatever wish they have will come true. They sometimes also go by the names of sponsors or key stakeholders.

The Witch - the stakeholders who brew several potions or stories to get you to support the scope addition and with her magical spellcasting, she tries to have you understand that what she wants is truly as natural as breathing and that to not support it is foolishness. She also uses her craft to convince you that the natural addition should not result in any schedule or cost changes. They sometimes go by the names end-users or business partners.

The Project Manager - the lone knight who has to protect the project and the team from the Lion and the Witch and what is the secret weapon you say? The Sword of Truth.

As a project manager, we all know that adding scope cannot have a zero effect on the other constraints, you can minimize them but zero impact is rare, most notably impact to schedule and costs. By stating the truth, the Lions can be silenced and the Witches can be bound.

Question the benefit vs costs of adding the request to scope. Ensure all stakeholders are aware of the impact of the addition and ensure that if the addition is agreed upon - that the decision was not made because the Lion roared nor because the Witch spellcasted but with full clarity powered by the Project Manager's truth.

I did everything the PMBOK says and yet my project was still a failure. What went wrong?

First and foremost, it is a major - MAJOR - mistake if you think that the PMBOK is THE one and only project management bible that will solve every problem in every situation. Even PMI has a section in its book that says “Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances”.

Second, if you did everything the PMBOK says - chances are you don’t really know what you are doing. The PMBOK is very helpful in providing the industry with tools and best practices that you may and can use to help you in managing your project BUT you have to use your experience, knowledge of the project and sensibility to know which tools would be the most appropriate to use for a particular job. Imagine that you are a carpenter and you have a truckload of tools - would you use all or even most of them - say to put up a drywall? Of course not. Same with the PMBOK.

What can help make your project a success then?

1. Know as much as possible about what you and your team need to deliver.
2. Be extremely familiar with the environment you will be working in and what assets and resources are available to do the project
3. KNOW who should be on your team and we are not talking here about simply knowing their names and roles. You should know them sufficiently enough to know how to lead and manage them to success
4. KNOW yourself, your capacity, your experience and what is required of you as a leader and manager to deliver your objectives with your team
5 Understand the tools and know which tools you need and how to use them properly to help in executing the project.


Ultimately, it is not the PMBOK that determines the success of a project but the project manager.




“PMI”, the PMI logo, “PMP”, “PMBOK” are registered marks of Project Management Institute, Inc. Excerpt from PMBOK above copyrighted 2008, Project Management Institute, Inc.

The Great Differentiator

I was asked today by one of my team members the following question - "what makes a great project manager?" Is it his ability to consistently deliver projects on time, on budget, in scope, with quality and with full user satisfaction?

I said "All those qualities make a project manager but not a great one".

A lot of project managers can claim all those in all his projects and I would argue that if the KPIs for a project manager are simply doing all these, he has but achieved the basic expectation of a project manager.  Every project manager, or those who claim to be one, must strive to AT LEAST do all these.

The great differentiator in my opinion between the good project manager and the great project manager lies in HOW he executes his projects to achieve his objectives - his leadership and people skills.

A project manager can deliver a project on time, on budget but he did so through intimidation, fear or extreme politics. A project manager manager can deliver his projects on time and on budget but he failed to nurture and sustain productive relationships within and outside of his team in the process. He could consistenly deliver his projects on time, on budget and yet at the same time - consistently breed distrust and disloyalty by claiming all the glory to the dismay of his team.

At the end of the day - what makes a great project manager? It is the one who can consistently deliver his hard deliverables through excellent leadership and people management skills.