Lonnie Pacelli's Blog, page 79

Six Takeaways to be a Better Public Speaker

Recently I was asked by a journalist how I practiced public speaking.  At this point in my life, getting up in front of an audience is pretty much second nature.  However, it wasn't always so.  I had to work hard at the skill and had to fail A LOT before I found my schtick and was able to get pretty OK at it.   

Here are the highlights from the interview along with six take-aways to help you be a better public speaker.
How did you work on your public speaking skills?

I took every opportunity I could to speak at as many venues as possible.  I also observed other speakers that did things I admired and, more importantly, did things I thought were cheesy.  As example, starting off a presentation with “Good Morning”, then when the audience doesn’t respond saying “You can do better than that…Good MORRRR-NINGGGGG!”.  The audience then feigns laughter and parrots “Good MORRRR-NINGGGGG!” with an eye-roll.  Sheesh.

Amazon.com Widgets Did you speak at local rotaries? Libraries? Conferences?

Yes.  I spoke in front of as many audiences with varying sizes as possible.  When first starting out don’t refuse a gig and don’t worry about getting paid.  It’s great on-the-job training. 

What did you learn and what can you teach the rest of us?

There are six take-aways that I think would best help someone wanting to improve his or her public speaking skills:

1)   Videotape yourself.  Watch how you come across and decide if you are being compelling and entertaining or just coming off like a doofus.

2)   Find a coach who is an accomplished speaker that you admire to give you the honest scoop on your speaking abilities.  It’s not about hearing what you want to hear; it’s about hearing how you can improve and digesting the tough messages.

3)   Establish credibility before using humor.  With a new audience they don’t know whether or not you’re worth listening to.  If you lead with humor before you’ve established credibility you’re going to inject doubt in your audience’s mind.  Start off your presentation with an attention-grabbing story which demonstrates your being an authority on the subject matter.  Then use humor later on after the audience has decided you’re worth listening to.

4)   Use slides as a crutch, don’t read them to your audience. 

5)   Pick out several audience members who are giving you “cues” on your effectiveness; then periodically look at those audience members throughout your presentation to gauge interest, boredom, or some other feedback mechanism.

6)   Have fun.  The audience wants you to do well and wants to know that the next hour is going to be entertaining and insightful.  Let the audience root for you and feed off of it. 

Using the Project Guide to define your project in MS Project

A pretty nifty feature in Microsoft Project is the ability to define a project through the use of the project guide.  The project guide is a cool little wizard that walks you through setting up a project, assigning resources to the project, tracking progress, and reporting on progress.  What I like about this wizard is not only the help it gives newbie project managers, but also is a great reminder of the cool MS Project capabilities for more seasoned MS  Project project managers.  

To get started with this cool project management software tool do the following: Turn on the Project Guide:
On the Tools menu, click Options, and then click the Interface tab
In the Project Guide Settings, select the Display Project Guide check box 
You can also turn on and off in the View menu 

Define your project and tasks:
Define the project      
Define general working times
List the tasks in the project
Organize tasks into phases
Schedule tasks
Link to or attach more task information
Add columns of custom information
Set deadlines and constrain tasks
Identify risks to the project
Add documents to the project
Publish project information to the Web (if using project server)

Define your resources:
Specify people and equipment for the project
Specify the booking types for resources
Define working times for resources
Assign people and equipment to tasks
Link to or attach more resource information
Add columns of custom information
Publish project information to the web (if using project server)

Track and manage your project:
Save a baseline plan to compare with later versions
Prepare to track the progress of your project
Incorporate progress information into your project
Check the progress of the project
Make changes to the project
See what is driving the start date of the project
Track risks and issues associated with the project (if using project server)
Request text-based status reports (if using project server)
Publish project information to the web (if using project server)

Report status of your project:
Select a view or report
Change the content or order of information in a view
Change the look or content of the Gantt chart
Print current view as a report
See the status of multiple projects in project center (If using project server)
Compare progress against baseline work
See the project's critical tasks
See project risks and issues (if using project server)
See how resources time is allocated
See project costs
Publish project information to the web (if using project server)

Use this cool little project management software tool in MS Project to help ensure you're getting the most of what project management software has to offer! 

Ten tips to boost your facilitation skills

So let's cut to the chase...

You may be a great consultant, one who effectively applies his or her wisdom and experience to help his or her client solve some tough business problem.   That's all fine and well.  When it comes to facilitation, though, it's a different ballgame and a very different approach to problem solving.  I like to think of the difference as follows:
Great consultants advise clients on how to solve problems.  
Great facilitators help clients solve their own problems. 
So, can a great consultant be a great facilitator?  Absolutely.  I've known some outstanding consultants who were extremely effective facilitators.  But it's wrong to assume that just because you are a great consultant you will automatically be a great facilitator.  Some are self-aware and know not to dip a toe in the facilitation pool.  Many, though, assume that they know how to facilitate solutions and end up in a crash-and-burn situation with their client.

Perhaps you've had some experiences with facilitation and know the do's and don'ts.  Then again, maybe you're struggling with how to be a good facilitator.  Give these  Ten Tips  a look and see where you can improve your facilitation skills and help your clients solve their own problems:
1.  Do your homework - Take the time to understand the problem to be solved, the key players involved in the meeting, and the "hot buttons" around the problem statement.  Talk to the boss plus one or two of the key players who are on opposite sides of the problem statement.  Resist the temptation of developing your own conclusions prior to the facilitation meeting, though.  If you come across as jaded you'll lose the trust of the meeting attendees.


2.  Articulate the problem statement - Key to any facilitation meeting is a clear, crisp articulation of the problem statement and ensuring that all meeting attendees agree with the problem statement.  Write down the problem statement on a whiteboard or easel in plain sight of the attendees so you can refer back to it throughout the meeting.
Amazon.com Widgets 3.  Encourage inclusion of all attendees - Take particular note of those who aren't speaking up during the meeting.  Look for opportune moments to ask them specific questions about what they think about a particular comment or issue being discussed.  While encouraging inclusion is important, be cautious not to "pick on" any attendees and create an environment of discomfort.

4.  Keep things moving  toward addressing the problem statement - Frequently as a facilitator you'll find that a discussion will drift off course and will not be contributing towards addressing the problem statement.  Your job as facilitator is to keep the discussion moving forward while at the same time not being so rigid that you'll frustrate your meeting attendees.  If the discussion has drifted to addressing a different problem statement or if the discussion has become destructive, bring it back on course.

5.  Establish a "parking lot" - Many times a facilitated meeting will uncover other important issues which should be captured but are not germane to solving the stated problem statement.  Capture those items in a "parking lot" to be addressed in future discussions.  Ensure the parking lot is visible to all attendees and refer back to it as necessary to keep your discussion focused. 

6. Maintain a list of action items - Frequently during facilitated discussions specific actions relative to solving the problem statement will be revealed.  Be diligent about capturing those action items and ensure they are clearly visible to all meeting attendees.  Ensure that the action item addresses what needs to be done, who needs to do it, and when it needs to be done.   Also take the time to summarize the action items at the end of the meeting to ensure everyone agrees as to the importance, assignment, and timing of the action items.

7.  Stay objective - As a facilitator it is super important that you are perceived as completely objective and are not viewed as being in anyone's "camp" during a discussion.   Once a facilitator is viewed as biased then the trust of the meeting attendees (particularly those who are on the opposing side of the facilitator's bias) will quickly be lost.  Once you've lost the trust it's difficult to regain, so stay objective and don't reveal your biases. 

8.  Discover through questioning, not preaching - Facilitating doesn't mean you get on your soapbox and start espousing your vast wisdom on the topic at hand.  Facilitation means you use your wisdom to help others get to a common, agreed-upon resolution to problems.  The best facilitators do so by asking pointed, specific questions which are relevant to the problem statement and designed to bring new facts to light.  Once the facilitator starts pontificating then the meeting becomes more about the facilitator and less about the attendees solving the problem. 

9.  Keep the boss from hijacking the discussion - I've seen many, many facilitated discussions where the highest ranking person in the meeting expresses his or her opinion and subsequently sets the course of the meeting to his or her agenda.  Once the boss states a perspective then those afraid to challenge him or her aren't going to speak up.  Have a discussion with the boss up front to ensure that he or she doesn't jade the meeting.

10.  Be the one in control of the discussion - As the facilitator you need to keep the meeting moving forward and avoid being rat-holed on some off-the-beaten-path discussion.  This may mean wrestling control of the discussion from an outspoken attendee or shifting the discussion topic back to the problem statement.  It's isn't always pleasant and you're likely to tick someone off, but that's your job.  Lose control of the discussion and you'll lose respect of the attendees. 

Great Sponsor + Great PM = Great Success - Ten Truths of an Effective Sponsor/PM Partnership

A sad tale of a how a sponsor/PM relationship killed a project...

Exec identifies a need for a project and nominates self as sponsor.  PM gets assigned to project and assembles project team.  Sponsor is vague about problem to be solved other than "we need a new system".  PM can't communicate problem to be solved to the team because he doesn't understand what the problem is.  Sponsor continues to ask for more and more things to be included in project, PM doesn't have courage to say no.  PM treats sponsor as "that person in the corner office" and doesn't know how to ask for help, so he escalates everything.  Sponsor has to make some tough decisions but is unwilling to do so because of the political fallout.  PM provides bad information about decision alternatives so sponsor ignores him.  Due to changing priorities project no longer makes sense to do, but PM lobbies to keep the project going.  Sponsor loses interest because there are bigger fish to fry.  PM and team are disillusioned because sponsor doesn't care.  Project dies a slow death.  R.I.P.

While this is a fictional story, you can undoubtedly relate to most of these things happening on one project or another in your career.  The sponsor/PM partnership on a project is one of those "soft skill" factors that gets frequently overlooked when assessing a PM's skills but is a key determinant in the success or failure of a project.  Under a healthy partnership, the sponsor and PM work as a singular unit to ensure the project gets what it needs to be as successful as possible using only as many resources as absolutely necessary to secure success.  Under a less than healthy relationship the project will undoubtedly cost more in time and money assuming it even gets completed at all. 

Throughout my career I've been both a sponsor and a PM and have first-hand experience in how this relationship needs to work from both sides of the desk. Through my experience, I've locked down on ten truths which I feel are crucial to securing a healthy sponsor/PM partnership.  See if these resonate with you:
Truth #1: Great sponsors clearly articulate a root-cause problem to be solved. Great PM’s make sure the team knows (and remembers) what problem is being solved.   No surprise that great projects start with a great problem statement.  Where things go awry is when there's fuzziness about the problem statement between the sponsor and PM and when they aren't completely unified on the problem being addressed.  The sponsor needs to be clear about the problem, the PM needs to keep it at forefront and never allow the team to drift from solving the problem.
Amazon.com Widgets Truth #2: Great sponsors ensure the solution solves the root cause problem. Great PM’s don’t allow solutions to lose focus. It's so easy for a project team to get all lathered up in the coolness of a solution and the incremental value which can be had by just taking on a bit more scope here and there.  I love when project teams can kill two birds with one stone, but at the same time the sponsor and PM need to be very disciplined about keeping the project team focused on solving the root cause problem and not allowing scope to explode due to emotional frenzying. 

Truth #3: Great sponsors enforce a “good enough” mindset. Great PM’s don’t use “good enough” as an excuse to cut scope. Using a "good enough" mindset means being very conscious of not gold-plating a solution and putting incremental work into a feature that doesn't yield incremental benefit.  PM's, project teams, and sponsors alike fall subject to gold-plating to increase coolness or solve out-of-scope problems.  The sponsor needs to continually remind the team to not gold-plate and to do what's required to solve the problem.  At the same time, the PM can't use good enough as license to trim scope to solve a budget or schedule problem.  Certainly budget and schedule problems will happen, but the PM can't hide behind good enough and unilaterally trim scope based on his or her convenient definition of what good enough means.

Truth #4: Great sponsors ensure the project has the right resources to get the work done. Great PM’s articulate clear resource requests and “right size” the ask to the need.  No news flash here; projects need people and money to get things done.  Where things go awry is when project needs are poorly articulated, lack credibility, or are flat-out ignored.  This is one of the most important areas of an effective sponsor/PM partnership.  The PM needs to be crystal clear about what resources are needed to complete the project, thoughtful about alternatives to fulfilling the need, and objective about the consequences of not filling the need.  The sponsor needs to be convinced of the resource need, then needs to either support the PM to secure the resources or understand and accept the consequence of not securing the resources.  This truth is a massive failure point in projects with both the sponsor and PM being culpable.

Truth #5: Great sponsors hold the PM and team accountable for results. Great PM’s embrace the accountability and enforce it with the team.  Any leader worth his or her salt understands the concept of accountability.  Most sponsors joyfully embrace this role and effectively drive accountability across the team and with the PM.  The PM has a specific responsibility to embrace the accountability, demonstrate respect for the sponsor with the project team, and cascade the accountability throughout the project team.  Too often project managers will bad-mouth the sponsor to the project team and undermine his or her credibility as sponsor which creates ill-will between the sponsor and the team.  The sponsor needs to drive objective accountability and the PM needs to demonstrate respect and ensure all team members are held appropriately accountable for results.

Truth #6: Great sponsors are on top of the big issues and stand at the ready to help resolve them. Great PM’s articulate issues clearly and timely and escalate only those they can’t solve.  Too many times in my career I've seen a project sponsor be treated as if they were royalty.  The PM would make the trek up the mountain to report progress to the sponsor in hopes of pleasing him or her and getting a nod of approval from his or her highness.  Here's the reality:  the best sponsor/PM relationships are when both the sponsor and PM recognize the sponsor plays a specific role on the project and fills needs that he or she is best suited to fill.  The sponsor needs to be on top of the big issues which are appropriate for him or her to be addressing and be "at the ready" when the team needs an issue to be addressed.  At the same time, the PM needs to make sure that only those issues which are appropriate for the sponsor to address are being escalated.  Too often the PM will use issue escalation either as a means of "covering your butt" thus putting the sponsor on notice for an issue or will escalate inappropriate issues due to flat-out laziness.  The PM needs to escalate only those which cannot be solved at his or her level and ensure the sponsor is given as much time as reasonable to put the issue to bed.  The sponsor needs to be ready and willing to act. 

Truth #7: Great sponsors are an advocate, coach and battering ram for the project. Great PM’s know how to leverage a sponsor and listen to the sponsor’s counsel.  Some of the best sponsors I've worked with provide an open door to coach and counsel the PM.  The sponsor shows an active interest in the PM's success and deliberately works to help the PM grow as a professional.  They also serve as an ambassador for the project to other areas of the organization to ensure other stakeholders and constituents are supportive of the project.  Their interest is much more holistic and strategic; they want to help the organization be better and help the PM be better at his or her job.  At the same time, the best PM's see this relationship as an opportunity to grow personally and professionally and actively seek out and listen to a sponsor's coaching.

Truth #8: Great sponsors willingly make tough decisions even if unpopular or politically charged. Great PM’s provide clear and unbiased alternatives, information and consequences to support decision making.  On virtually every project there will be at least one decision which the sponsor has to make which will be unpopular with some organizational faction.  The PM has a clear responsibility to provide the sponsor with an objective point of view on decision alternatives, allow the sponsor as much time as reasonable to make the decision, and, while being politically aware of consequences, not be politically driven by consequences.  The sponsor needs to ensure alternatives are appropriately vetted, the facts and consequences are understood, and then make the decision as timely as reasonable.  The PM needs to be believable and objective, the sponsor needs to be courageous and timely.

Truth #9: Great sponsors don’t opportunistically increase scope if the project is going well. Great PM’s keep the team focused on delivery and don’t claim victory too soon.  In the 2006 Olympics, snowboarder Lindsey Jacobellis had the gold medal all but won. On the last jump of her race Lindsey does a hot dog move and trips at the finish line only to walk away with the silver medal.  Victory was in sight, cockiness crept in, then something bad happened to blow it.  Projects are no different.  The sponsor and PM need to jointly ensure that victory doesn't get claimed too soon, that scope control doesn't get sloppy, and that the team stays focused on driving the project to conclusion.  The sponsor needs to resist the desire to add "just a little feature" at the end and the PM needs to not allow the team to relax. 

Truth #10: Great sponsors continually evaluate priorities and are willing to pull the plug on a project if it no longer makes sense to do. Great PM’s don’t get emotionally tied to a project and don’t lobby to keep it alive if it should stop.  Sometimes a project no longer makes sense to do.  Whether it be about changing priorities, overly aggressive benefit statements, or under-estimated costs, both the sponsor and PM need to keep an ear to the railroad tracks and ensure the project still makes sense to continue.  If the sponsor has bigger fish to fry he or she needs to either continue to commit to the project or kill it.  The worst thing a sponsor can do is allow a project to die a slow death due to disinterest.  It not only wastes time and money but also creates disillusionment with the team because management isn't demonstrating support.  The PM needs to keep a "business first" attitude and recognize that sometimes a well-intentioned project no longer makes good business sense to continue.  Lobbying to keep a low-priority project going will just delay the inevitable.

Carbonite - a great solution for online backups

I've been using Carbonite for online backups for a number of years and am a very happy customer.  I
originally signed up with a competitor online backup product but was having so many problems with it that I cancelled the subscription in favor of Carbonite.  It installed without incident and immediately after install started an online backup up my designated folders.  The initial online backup took a number of days to complete but because it happens in background it didn't interfere with my daily routine.  Restoring files from the online backup is a snap and I am able to restore previous versions of a file from my online backup dataset.  I've had a number of situations when I wanted to go back to a previous version of a file and was easily able to do so from my Carbonite online backup. 

There are a few things I recommend you do to ensure a comprehensive online backup strategy:

I like to use an external hard drive as a backup source in addition to doing online backups.  While Carbonite is a great online backup solution, an external hard drive is faster than restoring from your online backup.  Doing both external hard drive and online backup balances speed with security in the event that both your PC
and external hard drive are lost. 

Back up your c:\users\%username% directory to ensure you online backup not only documents but also your favorites, your desktop, and other information about you as a user.

Go with the recommended online backup schedule option.  It's best not to second-guess Carbonite's online
backup algorithm. 

I highly recommend Carbonite for safe and secure online backups.  Go here for a free trial.

Making sense of calendars in MS Project

Since Microsoft Project's initial release in 1984 it has evolved  into an incredibly powerful and sophisticated project management tool.  One of those sophisticated features is calendars.  As one of my heroes  Spiderman says, "with great power comes great responsibility".  As a project manager, you can exploit some of the cool capabilities with Microsoft Project calendars, but beware, you could really tie your shorts up in a knot if you start getting too fancy with project calendars.  In addressing this topic, I want to start off by telling you what Microsoft Project help says about calendars then give you a few tips to help you avoid Project Manager hell when trying to develop a meaningful and realistic project schedule.      

There are four types of calendars in Microsoft Office Project 2007: base calendars, project calendars, resource calendars, and task calendars. They are used to determine resource availability, how resources that are assigned to tasks are scheduled, and how tasks are scheduled. Project calendars and task calendars are used to schedule tasks, and if resources are assigned to tasks, resource calendars are used as well.  You can modify these calendars to define the working days and hours for the whole project, for groups of resources, for individual resources, and for tasks. These calendars are distinct from the Calendar view, which shows the project schedule in a calendar format.

A base calendar is used as a template that the project calendar, resource calendars, or task calendars are based on. It defines the standard working and nonworking times for the project. It specifies the work hours for each work day, the work days for each week, and any exceptions, such as holidays. You can select a base calendar to use as the project calendar or as the basis for a resource calendar. You can also apply a base calendar to specific tasks. Project has three default base calendars: 

Standard -  The Standard base calendar reflects a traditional work schedule: Monday through Friday, 8:00 A.M. to 5:00 P.M., with an hour off for break.
24 Hours - The 24 Hours base calendar reflects a schedule with no nonworking time. The 24 Hours calendar can be used to schedule resources and tasks for different shifts around the clock, or to schedule equipment resources continuously.
Night Shift - The Night Shift base calendar reflects a graveyard shift schedule of Monday night through Saturday morning, 11:00 P.M. to 8:00 A.M., with an hour off for break. 
 
You can use the project calendar to reflect the general working days and hours of your project, as well as regular nonworking times (such as weekends and evenings) and special days off (such as holidays).
   
The project calendar defines the working and nonworking days and times for tasks. This calendar usually represents your organization's traditional working hours. Project uses this calendar to schedule tasks that do not have resources assigned or that have a task type of fixed duration. By default, the Standard base calendar is used as the project calendar, but you can reflect alternative schedules by using other base calendars.

Resource calendars make sure that work resources (people and equipment) are scheduled only when they're available for work. They affect a specific resource or category of resources. By default, the working time settings in the resource calendar match the project calendar. However, you can customize the resource   calendar to show individual schedule information, such as vacations, leaves of absence, or equipment maintenance time. By clicking Change Working Time on the General tab of the Resource Information dialog box, you can edit resource calendars to indicate nonworking time. You can also create or assign different 
base calendars for individual resources, or groups of resources, to indicate specific working hours. For example, you can assign a resource to a calendar that you created for carpenters who may be working during a time that is different from other workers.

Task calendars make it possible to schedule tasks during nonworking time, as defined by the project calendar or resource calendar. For example, you can set up a task calendar if you have a task that needs to be worked on overnight or through the weekend. You create a task calendar in the Change Working Time dialog box as a new base calendar. You then apply the base calendar to a task by using the Advanced tab in the Task Information dialog box. If you have applied a task calendar to a task that already has assigned resources, by default, the task is scheduled for the working times that the task calendar and resource calendars have in common. If you want to schedule the task by using only the task calendar, select the Scheduling ignores resource calendars check box on the Advanced tab in the Task Information dialog box. 

Some tips when establishing your calendars...
Avoid modifying the standard calendars - Keep the default settings for the standard, 24-hour, and night-shift calendars.  If you need to change any of the calendars from their default settings copy the calendar of choice to a new calendar which you can use as the basis for your project
Think "good enough" when determining working times precision - Unless you have a specific need to say a
task finishes at a particular hour within a particular day, try to keep to an hours-per-day setting for your project calendar.
Do make sure you record non-working times for resources - Record things like vacation time and times out
of office.  Don't chew up project slack because you haven't recorded resource non-working times.
Be careful with creating too many task exceptions - If you truly have some task-level exception where you need to use a customized calendar then by all means do so, but beware that too many exceptions could make
maintenance of your project a real pain in the neck.  

Microsoft Project calendars can give you tremendous flexibility in how you define your project.  Just make sure you balance precision with simplicity and avoid making managing your Microsoft Project plan a project in
and of itself.

Project Management Screw-Up 4 - We Didn't Do A Good Project Schedule

Excerpted from The Project Management Advisor - 18 Major Project Screw-Ups And How To Cut Them Off At The Pass (Prentice Hall, 2004)
I can remember vividly my very first project schedule.  My manager gave me the mission statement and an overall timeframe he thought it should take for me to complete the project.  I diligently broke the schedule down to lower levels of detail.  I continued to divide the overall timeframe among the tasks and assigned people to the tasks.  I worked for days on end with my face buried in a computer screen developing the schedule. 
 What I ended up with was a horrendously detailed project plan that had no logical dependencies identified, people being asked to complete 40-hour tasks in 15 minutes, and some people being asked to work 200 hours per week to get their work done.  But by golly, the schedule met my manager’s timeframe request.
Sadly enough (for me), this is a very true story but one that I don’t think is too terribly uncommon.  It’s pretty easy to ignore reality at times when you’re developing a schedule and to skip some fundamental steps in completing your schedule.  You may get everything to look good on paper, but the result may deviate significantly from reality. 
Amazon.com Widgets How it happens:

The project schedule was either too detailed or not detailed enough – A project schedule is only effective when it is able to help you know that everything is on track and that you’re going to be able to complete the work on time.  When your activities are at too high a level, you risk losing accountability, missing out on key dependencies or expose yourself to “90% complete syndrome” when the team reports progress that is not real. When your activities are at too low a level, you can frustrate your team members by unduly micro-managing them, creating a greater administrative headache for yourself, and confusing the team with an excessive number of activities to manage.  Either of these can spell schedule slippage and can severely impact successful project completion. 

I’ve learned to use two rules of thumb when defining the appropriate level of detail for a project plan: 

Can the activity be assigned to a single person to complete the activity? Can the activity be completed in less than 40 hours? Let me explain my question rationale. In the first question, I have found that explicit, clear lines of ownership are vital to ensuring that activities are completed.  Whenever there is an activity assigned to “the team” or some other group of people there is no single point of accountability thus no one truly owns the task.  Therefore each and every task should have a named person that takes the heat if the task isn’t completed on time. 

In the second question, the more time an activity is given to complete the greater the likelihood that you will be surprised at the last minute that the activity was not completed on time.  I’ve gotten burned way too many times on an activity getting to 90% very quickly then taking twice the amount of time to finish the last 10%.  Now, it’s not that I’m a distrustful person or that I think that people are overtly trying to deceive me.  No one wants to miss a deadline and thus will continue to report that they are on target and hope that everything falls into place if things start going awry.  Sometimes it works; sometimes it doesn’t.  I prefer to leave as little to chance as possible.  So, I’ve zeroed in on a 40-hour rule of thumb because it allows you to divert train wrecks on time but also doesn’t micromanage the team member.  Depending on your environment, you may want to use something other than 40 hours, just be definitive and consistent in what you use. 

The project schedule didn’t correctly address dependencies between tasks - When designing your project schedule, you need to keep in mind how those activities relate to other activities and define them accordingly.  Establishing clear dependencies between tasks and having a true understanding of the critical path (the string of tasks that are the longest point between the start and finish of the project) is in my view one of the most important components of your project schedule.  As you’re designing your schedule activities it’s helpful to keep dependencies clean by defining clear finish-to-start relationships.  There are ways to accommodate this using most common project management software packages, but I recommend keeping your dependencies simple to understand and manage. 

The project duration was too long – When designing your schedule, keep specific focus on the length of time that you go between celebrating successes.  I’ve become a strong advocate of keeping project phases to no longer than three months in duration.  This is not to say that, if you are implementing an Enterprise Resource Planning system that you should try to do the entire implementation from software selection to implemented system in that three-month timeframe.  What I am saying is that you should phase the project in such a way that there is a defined beginning and end to the phase within three months.  Why would I say such a thing?  Simple; people (particularly management) live in a short attention span theater world and over time will become discouraged and lose interest if a project drags on too long.  So ok, you’ve figured me out, I’m just breaking a $10 bill into two $5 bills, but I’ve seen teams perform better when they are able to have mini celebrations at the successful end of each phase because at any point in time the end of the phase of work is no more than three months away.  This also gives the team and management logical review points to look at the project’s mission and ensure that it is in sync with management’s current priorities. 

Some of the tasks didn’t produce useful deliverables – When you’re defining your project schedule, make sure you’re continually asking yourself these questions:
What is the deliverable that will be produced out of this activity?  What will it look like?  What happens if we don’t do it? If you don’t have satisfactory answers to each of these questions, then seriously consider whether or not the activity is necessary.  Remember, every activity that you do should be getting you one step closer to successful completion.   If you can’t articulate what the activity is supposed to produce then chances are you don’t need to do it. 

The team didn’t understand the plan – Your project team needs to have complete buy-in on the tasks, the durations, the team assignments, the dependencies, and the deliverables.  What I’ve seen work well is doing shorter, more frequent informal reviews with team members while you’re developing the schedule.  I’ve seen project managers hold themselves up in an office or conference room for days on end, emerge from their cave with the schedule to end all schedules, and then have the other team members storm the Bastille because they don’t see how they’re possibly going to be able to accomplish what the project manager expects (recall my opening store about my unrealistic schedule).  It’s days like those that the project manager wonders why he or she didn’t take over the family delicatessen instead of doing this stupid project manager job.  Get the buy-in along the way; it helps you avoid rework, allows the team members to feel more included in the process, and will produce a better quality plan that the team will believe they can achieve. 

Warning Signs:

Tasks aren’t getting done on time – Chronically missed deadlines on tasks can be due to unrealistic task durations, poorly defined dependencies, poorly defined work assignments, or project distractions.  Diagnose the reasons for the missed deadlines immediately before the snowball rolling down the hill turns into an avalanche. 

Tasks assigned to “the team” or some other group of people aren’t getting done – Any time that a specific name is not attached to a task, it is easy for team members to assume that someone else will do the task because no one is specifically held accountable for task completion.  If you want things to get done, make sure that there are specific names beside each of your task and that each team member feels personal accountability for getting their work done.

Team members aren’t aware that they were supposed to be working on a task - It’s an ugly situation when you’re getting status updates from team members and a task that was supposed to be completed last week wasn’t even started because the team member didn’t even know they were supposed to be working on the task.  Make sure that work assignments are crystal clear and that team members know what tasks they are supposed to have completed by when.

Team members are confused as to what they are supposed to produce for a task – So you assign a task to a team member and the day that the task is due the team member produces a deliverable that looks exactly nothing like you were expecting it to look like.  The deliverable now needs to be reworked which means other tasks are going to slip as a result.  Be clear about what deliverable needs to be produced and ensure that you and the team member have a common understanding of what it needs to look like.

Turning it around:

Get real with the schedule, and fast – Don’t delay; get the schedule in shape quickly making sure that you’ve defined all the right tasks, durations, dependencies, and resources to get it done.   More importantly, don’t go into a cave for days on end to do; make sure you are getting input on the schedule frequently to avoid an unrealistic schedule.

Do focused reviews with team members – On some projects, I have developed supplemental documentation which explains key tasks that might be confusing and even gone so far as to produce a template of what the deliverable out of the task needed to look like.  I prefer to do mini reviews as the plan is being developed to ensure that the team is putting their thumbprint on the plan and that any confusion points can be addressed early.

Keep dependencies simple – While it’s great to clearly understand dependencies between tasks, I’ve also seen plans that are overly complicated because the project manager built in serial dependencies between tasks that could actually be performed in parallel.  This could be due to an assumed dependency between the tasks or because the project manager is anticipating that one person will be doing both tasks.  Before defining a dependency, put rigor into making sure that the tasks are truly reliant on being performed serially.

Highlight tasks which are due in the next 1-2 weeks – I’ve learned through experience that solely relying on the project schedule as the communication vehicle for a project team is not always the most effective way of ensuring tasks get done on time.  Depending on the experience of your team, they may not understand how to read the schedule and may miss some key tasks that need to get done.  I’ve learned to use either status reports or e-mail reminders to individual team members reminding them of what they need to do and when it needs to be done.  It puts a bit more work on the project manager, but it better ensures the team member knows what needs to be done by when.

Take Aways: Make sure all your lowest level activities have a sole owner and are no longer than 40 hours in duration Break your project into phases that don’t exceed three schedule months Know the critical path of tasks through the project and keep clean finish-to-start dependencies between activities Make sure that your activities have associated deliverables that are relevant Ensure the team buys into the plan along the way; don’t do a grand reveal when the plan is complete. Remind and highlight team members of tasks needing to be completed within 1-2 weeks

The Expert

A colleague of mine forwarded me this video.  Experienced PMs have at some point in their career experienced unicorn and rainbow requests, sales guys that promise the world, and herculean deadlines.   Hope you enjoy it!

I'll Be Done Friday, Honest! Six Techniques to Ensure Solid Project Management Execution

Some time back I was responsible for a portfolio of projects being done within the finance organization of my company.  One of the projects was outsourced to a large consulting firm who supplied the project management, analysis, and development resources to the project.  I would hold weekly meetings with the project manager who consistently gave me a "thumbs up" on the project up to the first key milestone being hit.  When the week of the first milestone approached, he announced that the milestone was going to have to slip by a week to ensure successful delivery.  The next week came along and again the project slipped a week.  This went on for two more weeks with the promise of "we'll for sure nail it next week."  I decided to do some crawling around the project to assess where the project was really at.  Turns out we were at least a month away from delivering to the milestone which was already a month late.
Needless to say I was less than thrilled with the consulting firm running the project.   They sent out one of their heavyweight project managers to assess the situation.  After two hours of reviewing the project he reported back to me that the project had slipped, not due to anything his organization had or hadn't done, but because of things we as the client did to cause the problems.  Needless to say I pretty much lost it with him.  I then went through the project plan with him and went through each task and peppered him with questions about why his project manager hadn't managed the execution of the project and why we were continuing to get a 'thumbs up" when in fact the project had slipped horribly.  After my inquisition he said he'd follow up and get back to me.  I'm still waiting.
Amazon.com Widgets Ah, the best laid plans of mice and men often go awry.  Despite how pretty a project schedule looks, how clear the organization chart is, or how well articulated the risks and issues are, the most successful projects execute great to a great plan.  Solid project management execution means driving the plan, making adjustments as necessary to address unforeseen issues (if you are able to run projects that never have issues email me at lonnie@leadingonedge.com; I'd like to spend a day in your world), and removing roadblocks which can inhibit successful completion.  The project manager has to stay steady at the helm making sure these things happen; they won't just happen by themselves. To articulate this a bit more here are three formulas for you to keep in mind:
Planning + Execution = Project Success

Execution - Planning =  Randomized Flailing

Planning - Execution =  Well-Dressed Inertia
Through my experience I've come up with six techniques that can help you as a project manager better ensure project success.  While this isn't an exhaustive list of everything you can do, it does highlight some specific areas which can help keep a project from derailing: 

Snuff out and squash "shiny objects" - First, let's put shiny objects in context; to me a shiny object isn’t important to the task at hand and isn’t time-sensitive.  If something comes across your desk that can be done later without impact to your work, yet interrupts what you’re doing, then this in my view constitutes a shiny object.  It’s also important to distinguish between shiny objects and the garden-variety fire-drill.  The primary difference to me is a fire drill needs to be done immediately, otherwise there is some material and tangible business consequence; whereas with a shiny object there is no material and tangible business consequence if it doesn’t get done.  This is an important distinguishing factor because many shiny object violators I know view their shiny objects as fire drills and take comfort in responding to fire drills because of the sense of accomplishment they feel in putting out the fire.   Be on the lookout for shiny objects and squash them before your team gets derailed.  

Watch the "off-workplan" tasks - Recently I worked with a project team that had a pretty decent project plan with dependencies, resources, and timeframes all laid out.  The problem, though, was that the project plan assumed 100% resource focus but only about 60% of the resource focus was dedicated to the project plan.  The other 40% was consumed via to-do lists which the project manager kept in addition to the project plan.  Thus, the project was doomed to a 40% schedule slip right from the get-go because of the to-do list tasks.  As the project manager, you have the responsibility of ensuring that all project-related activity is reflected in your project plan and that you specifically articulate the percentage of time resources are dedicated to tasks. 

Think realistically aggressive when developing estimates - I've worked with three distinct personality types when it comes to estimating levels of effort.  The first personality type is Ms. Reality.  She looks at a given set of tasks and develops a realistic yet aggressive expectation of what will be required of her to complete the task.  More importantly, she hits her dates with a high degree of reliability.  The second personality type is Mr. Op T. Mystic.  Mr. Op consistently under-estimates tasks and provides a "if all of the stars align" projection on completing tasks.  Tasks quickly get to 90% done then stay there forever.  The third personality type is Mr. Gloom N. Doom.   Mr. Gloom typically provides worst-case estimates and will slather on contingency like barbecue sauce on ribs.   The secret sauce (can you tell I really like ribs?) here is to recognize the personality type you work with and try to snuff out reality with each personality type.  Sure, you'll get some push-back particularly from Mr. Gloom, but unless you apply some aggressive reality to your estimates you're going to have a hard time getting sponsors and higher-ups to view you as a credible project manager.

Hold weekly status meetings -  I am a big fan of weekly status meetings and weekly status reports, particularly on high-visibility  projects.  In fact, I have become a strong proponent of creating my project status report (see my status report template at the bottom of this article) right in my status meeting.   Key to this is focusing on project plan tasks, milestones, risks and issues during the status meeting.  I've been through way too many status meetings where the focus was on each team member talking about accomplishments and effort versus results.  Now, it's nice that all of the team members are working so hard, but when everyone starts patting themselves on the back for how many hours are being worked at the expense of managing to schedule, you've got a sick project on your hands.   Keep the status meetings focused on schedule, risks and issues and keep them very regular.  Don't let weeks go by without doing them unless you're willing to play Russian Roulette with your schedule.

Expose the violators - So okay, before I have every HR manager ready to shoot me let me explain what I mean.  In status meetings, I think it is completely within bounds for a project manager to expect project team members who don't deliver on their commitments to explain to the project team why they aren't pulling their weight.  Too many times I've seen project managers shield slacker project team members or not force them to explain their actions (or inaction as the case may be).  What each member of the project team needs to recognize is when he or she doesn't perform it isn't just the project manager that is being let down; it is the entire team.  When each project team member feels accountable to the rest of the team for delivery and directly feels as if he or she is letting the rest of the team down he or she is more likely to perform and meet dates.  This can be very effective in getting teams to perform, just make sure it is done with respect.  It's about getting teams to perform, not about skewering someone's dignity.
Use the 1/1/1 rule when planning tasks - Great execution starts with great planning.  Sure, we've all seen acts of heroism where a project team worked 90 hours a week to get a poorly conceived and planned project done on time.  However, no one likes to work in that mode.  Projects that are well planned are more likely to be delivered on time, per customer expectation, and within budget, period.  A key component of good planning is using what I call the "1/1/1" rule in work breakdown structure decomposition which stands for "one deliverable, one person, one week."  Driving to this level of detail in a project plan ensures  there is no ambiguity on who is responsible for the task and what the deliverable associated with the task needs to be.  Also, by using a one week duration you better ensure the task will be completed within one weekly status reporting cycle.  Most importantly, you'll minimize surprises of a "90% complete" taking forever for the last 10% to be complete. 
Excellent planning coupled with strong execution is crucial to ensuring the success of any project.  Subtract planning or execution from a project, and you either get the randomized flailing of a project out of control, or the well-dressed inertia of a good-looking project going nowhere.

Cloud Computing Growth Stats

In case you're thinking that Cloud Computing might be some passing fad, give the below stats a look.  If you're not a believer, beware of being left in the dust with the other typewriter repairmen. 
Cloud Computing Infographic | by Awesome Cloud Services