A few things I've learned.

Some practical advice.

Ingenious Viral Marketing Campaign: Slap Chop

I’m not sure if the strategy for Slap Chop was planned out from the beginning, but if it was, whoever came up with it, while simple, is a genius.

Simply by allowing/paying an artist to remix their infomercial into an entertaining and sharable piece of media, they were able to get a large number of eyes to see their product and create a memorable experience.

The reason I believe it is a pre-conceived strategy is because each step was carefully orchestrated to fit into the campaign.

Here’s the basic formula:

1) Take a fairly typical “As Seen on TV” product:

Slap Chop – Dice, Chop & Mince in Seconds

2) Create a borderline cheezy late-night infomercial:
(Feel free to only view the first 15-30 seconds, the next video is the real kicker)

What’s interesting is the subtle hints in the infomercial that opens it up to be a perfect candidate for a funny remix. Parts of the script–“You’re gonna love my nuts.”–seem to be begging to be made into a parody. Coincidence?

3) Encourage (or even pay?) artists to create an entertaining remix:

As of the writing of this post, the Remix has 5,587,762 page views on YouTube (compared to less than half as many views, 2,467,519, for the original version).

The great part of this remix is that it is well-done, but does not immediately jump out as a typical corporation-backed high-production value video. It keeps you guessing.

4) Let the sharing begin!
Once you see it, you too may find it just funny enough to pass on. And at some point in this chain, someone will actually like the product and make the purchase.

Making a Quick Assessment is Better than No Assessment at All

For a producer, knowing your teams strengths and weaknesses is just as important as those characteristics are to the individuals success. Given that you’re likely to be working with new individuals often, you have to rely on quick ways to gauge your team. To that end, its good to find quick ways to feel out different aspects of your teams work.

For example, one of the most important qualities to understand when working with someone is whether they work best on their own, or if they need constant guidance to move forward.

Here’s a quick way to know…

First, assign or ask an individual to accomplish a fairly simple task and give them a long-term deadline or no deadline at all. For example, ask them to send you an email containing a simple piece of information you know is easily and readily available to them (maybe their AIM or some other relevant, but easily available piece of information).

Second, based on how long the individual takes to fulfill your request, you can determine how to interact with this individual and to manage expectations going forward. If the individual completes the task immediately, you can assume that they are self-sufficient and will not require frequent check-ins for monitoring progress once a task is assigned. On the other hand, if the individual waits until the very last moment of the deadlineto fulfill the simple task–or doesn’t fulfill the task at all–you can identify the individual as needing more frequent direction to make progress.

Of course, this is not an end-all-be-all solution; it can be wrong based on a number of variables, but its better than nothing at all. You can always continue to reshape your expectations over time. You can easily vary also by the medium. For instance, are they more responsible to email rather than remembering a verbal request, etc.

Great is Good Enough, a.k.a. not everyone needs a Porsche SUV.

Most projects start with two basic scope limitation: Time & Cost. That is to say, an agency is required to tailor a solution’s Scope to a predetermined cost-requirement as well as time-limitation. In these instance, I find a lot of teams struggle to produce within a presented set of time and cost boundaries. It’s understandable that everyone wants to do their best work, and wants every piece of work to be portfolio-worthy, but the reality of the business world is that the client can’t afford (and doesn’t always need) extraordinary work, but simply needs a great product within their budget and time limitations that will move their business forward. That is to say, in my implied analogy of car-buying, not every driver can afford the Porsche, and not every driver necessarily needs an SUV, and even fewer drivers really require the Porsche SUV. Right-scoping helps the client meet their goals without the headaches of delayed projects (not to mention dealing with change orders, etc.), and it helps the agencies by keeping projects within budget and more importantly, keeping the client happy.

To that end, its critical for all team members, including User Experience Designers, Visual Design, and Developers to adhere to the time and budget set before them. Rather than simply thinking of the OMFG-the-absolute-best-two-million-dollar-idea-that-can-take-four-years-with-all-the-bells-and-whistles, truly great creatives from these disciplines take these limitations into consideration when defining ideas and executing them; ultimately outputting a solid product whose end result is great for the client, but also for the agency.

How to: Easily Dial Into Conference Calls From Your iPhone

The short version is this:

Dial-in: 1-888-555-0000
Passcode: 1234567#
Leadercode: *9898#

To easily dial into the above number from your iPhone, just add an entry in your calendar invite or your address book as follows:

1(888)555-0000,,,1234567#,,,*9898#

The below example uses the “Wait” function, but I’ve found it to be useless and have had a much easier dial-in experience using just the “Pause” function.

The long version is this:

If you’re like me, the first few minute of many of your phone calls are identical. While i don’t have a solve for people joining the call late, I do have a way to make it easier to dial-in from you mobile phine. You Dial into the same conference number, you dial the same conference code, and then you dial the same leader code to get started. While a relatively easy task when the phone number is seen on a screen other than the phone itself, this can be a very painful experience if you try using your mobile phone to dial what seems like 40 characters. If you don’t want to take up extra space in your brain to memorize, a little setup up front will save you a lot of headache when the need to dial-in to these calls arises.

There’s a rather easy way to do this with most mobile phones that have PAUSE (typically using the comma – ‘,’ ) and WAIT (typically using the semicolon – ‘;’) as part of adding a phone number to the address book.

  • PAUSE – pauses for 2-3 seconds then dials the remaining numbers in the string.
  • WAIT – ‘waits’ for the user to take an action before the numbers that follow are dialed. When using the WAIT feature on the iPhone, where the END button typically appears is split into two buttons: END and DIAL… at the bottom-right. The phone will dial the remaining numbers once you hit the “DIAL…” button.

As an example, let’s say you need to frequently connect to the following conference call:

Dial-in: 1-888-555-0000
Passcode: 1234567#
Leadercode: *9898#

To easily dial into the above number from your iPhone, just add an entry in your address book as follows:

1(888)555-0000,1234567#;*9898#

Here’s what it would look like (the last few characters can’t be seen, but you get the idea):

The above will do the following:

  1. Dial 1-888-555-0000
  2. Pause 2-3 Seconds
  3. Dial 1234567
  4. Wait for your input and continue only upon you pressing DIAL (this automatically becomes available when you use the WAIT feature). See below screenshot and you’ll notice the button on the bottom-right.
  5. Dial *9898#
Reference for step #4 above:

Pro-tip: When sending out invites for these types of meetings, use the above format for sending out dial-in information and people who will be dialing in from their mobile phones will appreciate you that much more.

For more information on PAUSE and WAIT, especially for Android and Blackberry devices, click here

A Practical Guide to Project Post-Mortems

Few would disagree that post-mortems, in theory, are extremely important in business, especially as part of the project management processes. The problem, however, is that in most companies, in practice, a lot of teams use Post-Mortems as therapy sessions. That is, a lot of problems are discussed, even documented, but rarely are the lessons-learned communicated to others.

The Problem

The main issue with the standard approach to Post-Mortems is that the output of these sessions is frequently not translated into a usable and easily digestible format. Unfortunately, while they are documented, the information is often too overwhelming for someone to desire to delve into them. I, personally, don’t really enjoy going through lengthy word documents. And if someone does in fact muster enough time and patience to actually review the Post-Mortem documents, they’ll most likely leave with little they can leverage to improve their next project. Often, the information is too specific to a project for it to translate.

The standard post-mortem practices leave little evidense behind of their occurrence. Commonly, organizations will make the mistake of having detailed discussions of a projects successes and its downfalls, documenting them, and filing them away. This practice seldom provides a great ROI for the time spent in the discussion and documentation of a project’s post-mortem. Specifically,  the only time that a post-mortem of this nature is useful is if the same exact team happens to do a near-identical project in the future. This is one of few scenarios in which the information of the post-mortem will be beneficial to the organization. And even-so, the chance that the team will review the outcome of the post-mortem is slim to none.

The Standard Post-Mortems

The main objective of Post-Mortems is essentially to discuss hind sight, which is always…well, you know the rest.

It’s critical that Post-Mortems aren’t purely associated with negative connotations. That is, it’s just as important to recognize the achievements and give the accomplishments their due credit, as it is to discuss what didn’t go well, and how it could have been done better.

It’s also important that the focus of the Post-Mortem improvements are limited to 3-5 topics at most in order for the sessions to be useful.

A simple survey prior to the meeting can gauge the groups overall areas of concern. The conductor of the meeting should use these as agenda items. An anonymous survey will especially empower even those team members who may not voice their concerns publicly to participate. The results of the survey should be used to extract topics for discussion in the meeting.

As areas of improvements are discussed, confirm if the issue exists, and direct the conversation towards how you can realistically and practically improve it. Sticking to reality is important here, so make sure solutions are actionable and a very clear way to address it is discussed.

Extracting Solutions from Post-Mortems

Here’s an example of what you can extract from discussing a Post-Mortem improvement area. Let’s assume the result of a Post-Mortem indicates that several team members were frustrated with the amount of changes that were needed through a project’s life. A logical next step would commonly be to understand that it’s impossible to limit changes that can come last minute from the client or due to a necessary improvement.

However, even without needing to control the unknown (last minute changes from the client or internal lead), this area can still be improved by applying process. Digging further into this issue, one might discover that changes were happening too rapidly and priorities were uncertain. To address this issue, a solution–and outcome of this Post-Mortem topic–could be to a apply a process by which changes were controlled: Change Management. An actionable solution could therefore be simply to log changes in sprints and then review and prioritize them in intervals as opposed to working on the solution on a first-come-first-serve basis.

Post-Mortems in Large Organizations

It’s actually simpler than you’d think, and coincidently, can be modeled after website analytics. That is, a more useful method of capturing and leveraging the benefits of post-mortems is to set metrics (quantitative as well as qualitative). The data that should be captured should be general enough to be applicable to a large array of project types within the organization, but specific enough to yield actionable metrics.

Post-Mortems in Practice

If you’ve made it this far, you’re either truly onboard, just curious, or both. Either way, let’s look at a practical way of implementing Metrics-Based After Action Reports.

First, set the performance metrics that are applicable across all projects in the organization.

Then, start tracking the hours as they would be mapped in the post-mortem. For example, comparing 1) number of hours spent on a deliverable from time tracking [Wireframes], 2) the overall team satisfaction of the deliverable from post-mortem analysis [Quality], and 3) the size of the deliverable [Pages], could yield a pattern showing the relationship between the number of hours spent, the overall satisfaction, and the amount of work. Therefore, a direction relationship of hours to pages can be made for future project projections. Over time, this data can be used to predict more accurate time estimates for delivering similar products.

Other Business Metrics to Track

  • Internal to Internal Communication
  • Client to Client Communication
  • Internal to Client Communication
  • How did the actual amount of work compare to your assumptions?
  • Hours Estimated to Actual Hours
  • Billable Cost to Actual Cost
  • Time Estimated to Actual Time
  • How well would you rate the final Wireframe deliverable?
  • How well would you rate the final Functional Specifications deliverable?

This level of tracking can  be overkill for certain organizations or even specific projects. However, for larger organizations, it can provide the necessary gauges with which large-scale adjustment decisions can be made.

Finding the Right Software with the Right Features, A Directory

I’m always interested in the latest software, especially for Project Management. Basecamp being one of a number of such applications that I already knew, when I came across Wrike today, I thought to myself “wouldn’t it be great if I could go to a single site and be able to see and compare a number of available software that would help me make a decision?”

Then I thought: “maybe I need to make one!” and of course, followed by: “It probably already exists.”

And it does; introducing Capterra, a directory of software that has most of the information you’d want to compare for the software you’re looking for. There’s a nice directory to help you find whatever type of software you’re looking for, including Project Management Software.

I think the name could’ve been a little more informative, but the again, look at Google. Dub Dub Dub SoftwareDirectory Dot Com is already taken anyway.

Great Synthesis of the Internet/Browser Relationship

Keeping Your Email Inbox Organized

My basic approach is to make sure my inbox contains only the things I need to address. In essence, my inbox functions much more like a checklist.

When I get an email, I first determine if I am responsible for any actions. If yes, I keep it in my inbox until I’ve completed the task, if not, I file it to my archive folder so I can search them later if necessary. I frequently create a folder for a specific project that contains all communications for that project in case I need to reference them.

If you have the ability to tag/categorize your emails (with MS Outlook or GMAIL), you can also make use of these. They help both for your immediate inbox as well as later for reference.

For instance, I’ve made it such that emails that are only addressed to me (which makes them higher priority) are highlighted differently than those I am cc’d on. I also have emails from different clients or projects highlighted with different colors.

This way, I can just scan my inbox and get a general sense of which of my clients have more pending needs, which I’m solely responsible for, etc.

Of course, the best way to do this is to setup several “Rules” that run automatically so your mail client automatically categorizes your emails.

Here are some examples of different approaches to categorizing and prioritizing emails automatically.

  • Highlight emails in which I am the only recipient in RED: At a glance of my inbox, I can quickly pickout the highest priority emails.
  • Highlight emails from [Project] in [Color]: As noted above, being able to see which project has a larger number of open issues can help determine priority.
  • Forward emails from [Email Address] to [Recipient(s)]: This is a tricky one because it can quickly turn to spam. I generally tend to use it with clients who have Basecamp in situation where I’m the only official Basecamp member in my team. This ensures that any feedback that is shared for a project will quickly get disseminated to the rest of the project team. Used specifically when I’m out of the office.
  • Delay sending emails by 2 minutes: If you’ve ever sent an email only realizing after a split second that it’s missing your intended attachment, you’ll appreciate getting a 2-minute delay to add and/or change the attachment you’re sending. Sometimes, you will want or need to bypass the delay in order to send an email immediately. Thankfully, most email clients allow for exceptions to be added. For mine, I have an exeption to my rule such that if I type the combination of /k/ in my email, it will bypass the 2-minute delay. This of course can be set in a variety of combinations.

Bonus:

Adding tags, especially colored ones to emails has a unique side-effect in which most mail clients will also process the rules you set above on Calendar Invitations.  In case of color coding by client or project, or direct email versus being cc’d, seeing these at a glance on the calendar are pleasantly helpful.

Budgets Part III: Reconciling the Budget

Reconciling the Budget

Let’s assume that being over budget is not an option, and so it’s necessary to reduce scope in order to lower cost. Reducing scope is a process on its own and will be discussed later. For now, let’s assume that the scope is reduced, and that the reduced scope translates into lower overall expenditures estimated at $4,000.

For example, it can be determined that the project can now expend $1,000 less for the remaining 4 months (though it could mean that a single month is reduced by $4,000 or other deviation, depending on the nature of the scope change). And so, it needs to be reflected in the Plan as follows:

A reconciled budget.

Note that the Plan Estimates have been adjusted to reflect this, now being reduced to $19,000.

Now, assuming that updated plan accurately reflects the updated scope in terms of expenditures, the project should be in good shape.

The only way to ensure that the project is within budget is to continuously track and adjust the budget.

Risk and Risk Mitigation

I was recently reading an article, Ten Things You Didn’t Know About Apollo 11 Moon Landing, and one of the ten things reminded me of Risk Mitigation in Project Management. In my ever-consuming pursuit of expressing Project Management tools in simpler terms, I’ve broken down how Risk Mitigation works using this real-life example.
Real-life Example of Risk Mitigation
The part of the article that caught my eye was this:
“The Apollo’s Saturn rockets were packed with enough fuel to throw 100-pound shrapnel three miles, and NASA couldn’t rule out the possibility that they might explode on takeoff. NASA seated its VIP spectators three and a half miles from the launch-pad.”
The above statement can be broken down into the following three variables: 1) Risk, 2) Tolerance, and 3) Mitigation.
1) Risk: The Apollo’s Saturn rockets were packed with enough fuel to throw 100-pound shrapnel three miles.
To put this in perspective, a standard 5.3g 9mm bullet can travel about 1.5 miles.  Which essentially meant that the explosion from the rocket could be more dangerous than a handgun to say the least. NASA was willing to entertain certain risks to the ship and occupants, after all, they were planning a launch to the moon! And so decided to continue with the launch.
2) Tolerance: NASA couldn’t rule out the possibility that they might explode.
Every risk has to be measured against the individual or organization’s tolerance.  In this case, NASA had no tolerance  for the potential harm to the spectators and therefore chose to move everyone outside of the presumed blast radius:
3) Mitigation: NASA seated its VIP spectators three and a half miles from the launch-pad.
To completely avoid harm to viewers, NASA went as far as adding an additional 1/2 mile to their assumptions to further mitigate the results of a catastrophic event.
The Every Day Project
In terms of the every day project, mitigating risk starts first at identifying the risk, then attempting to quantify or qualify your tolerance to the risk, and finally to decide what to do to eliminate or minimize the impact.
Here’s what to ask yourself when addressing risk:
What could potentially go wrong?
What is the likelihood of this happening?
What can I do to reduce the likelihood of the risk, or at least to reduce the potential negative impact on the project?I was recently reading an article, Ten Things You Didn’t Know About Apollo 11 Moon Landing, and one of the ten things reminded me of Risk Mitigation in Project Management. In my ever-consuming pursuit of expressing Project Management tools in simpler terms, I’ve broken down how Risk Mitigation works using this real-life example.
Real-life Example of Risk Mitigation
The part of the article that caught my eye was this:
“The Apollo’s Saturn rockets were packed with enough fuel to throw 100-pound shrapnel three miles, and NASA couldn’t rule out the possibility that they might explode on takeoff. NASA seated its VIP spectators three and a half miles from the launch-pad.”
The above statement can be broken down into the following three variables: 1) Risk, 2) Tolerance, and 3) Mitigation.
1) Risk: The Apollo’s Saturn rockets were packed with enough fuel to throw 100-pound shrapnel three miles.
To put this in perspective, a standard 5.3g 9mm bullet can travel about 1.5 miles.  Which essentially meant that the explosion from the rocket could be more dangerous than a handgun to say the least. NASA was willing to entertain certain risks to the ship and occupants, after all, they were planning a launch to the moon! And so decided to continue with the launch.
2) Tolerance: NASA couldn’t rule out the possibility that they might explode.
Every risk has to be measured against the individual or organization’s tolerance.  In this case, NASA had no tolerance  for the potential harm to the spectators and therefore chose to move everyone outside of the presumed blast radius:
3) Mitigation: NASA seated its VIP spectators three and a half miles from the launch-pad.
To completely avoid harm to viewers, NASA went as far as adding an additional 1/2 mile to their assumptions to further mitigate the results of a catastrophic event.
The Every Day Project
In terms of the every day project, mitigating risk starts first at identifying the risk, then attempting to quantify or qualify your tolerance to the risk, and finally to decide what to do to eliminate or minimize the impact.
Here’s what to ask yourself when addressing risk:
What could potentially go wrong?
What is the likelihood of this happening?
What can I do to reduce the likelihood of the risk, or at least to reduce the potential negative impact on the project?

I was recently reading an article, Ten Things You Didn’t Know About Apollo 11 Moon Landing, and one of the ten things reminded me of Risk Mitigation in Project Management. In my ever-consuming pursuit of expressing Project Management tools in simpler terms, I’ve broken down how Risk Mitigation works using this real-life example.

Real-life Example of Risk Mitigation

The part of the article that caught my eye was this:

“The Apollo’s Saturn rockets were packed with enough fuel to throw 100-pound shrapnel three miles, and NASA couldn’t rule out the possibility that they might explode on takeoff. NASA seated its VIP spectators three and a half miles from the launch-pad.”

The above statement can be broken down into the following three variables: 1) Risk, 2) Tolerance, and 3) Mitigation.

1) Risk: The Apollo’s Saturn rockets were packed with enough fuel to throw 100-pound shrapnel three miles.

To put this in perspective, a standard 5.3g 9mm bullet can travel about 1.5 miles.  Which essentially meant that the explosion from the rocket could be more dangerous than a handgun to say the least. NASA was willing to entertain certain risks to the ship and occupants, after all, they were planning a launch to the moon! And so decided to continue with the launch.

2) Tolerance: NASA couldn’t rule out the possibility that they might explode.

Every risk has to be measured against the individual or organization’s tolerance.  In this case, NASA had no tolerance  for the potential harm to the spectators and therefore chose to move everyone outside of the presumed blast radius:

3) Mitigation: NASA seated its VIP spectators three and a half miles from the launch-pad.

To completely avoid harm to viewers, NASA went as far as adding an additional 1/2 mile to their assumptions to further mitigate the results of a catastrophic event.

The Every Day Project

In terms of the every day project, mitigating risk starts first at identifying the risk, then attempting to quantify or qualify your tolerance to the risk, and finally to decide what to do to eliminate or minimize the impact.

Here’s what to ask yourself when addressing risk:

  • What could potentially go wrong?
  • What is the likelihood of this happening?
  • What can I do to reduce the likelihood of the risk, or at least to reduce the potential negative impact on the project?
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: