“If it worked in Sharknado, why can’t it work for us too?!”

I believe the term “Think outside the box” is an overused cliche.  What is this box?  How big is this box?  Is the box a representation of the limits management believes employees are able to think within?  What if someone sets the box on fire?  When gathering a team to solve a complex issue, do we really want to say we’re in a box?  There has be to a better rally cry!

Enter Sharknado.  As I boarded a flight home over the weekend, a gentleman sat down next to me and pulled out his iPad and notebook, and started watching “Sharknado 3: Oh Hell No!”  Every so often he’d chuckle, pause the movie and jot something down in his notebook.

After we landed, he closed everything up and put them back in his bag.  Since the jet bridge was malfunctioning and we had to wait a few minutes, I asked him if his movie was good.  His response was interesting: “No, it’s awful.  But I started a new job with a company in downtown Minneapolis.  Our mantra is if it worked in Sharknado, why can’t it work for us too.”  He went on to say the ideas characters had in the movie were terrible, but somehow they made them work and didn’t die.  When the team he works with is faced with a problem, and some of them can be quite large, “any idea is feasible until it’s not.”  The team often uses one-liners from the movie, which is what he wrote down.

Instead of using an old cliche, this team has found another mantra to bring everyone together to solve complex problems.  Solving problems may even be kind of fun for these people!  Though I haven’t seen Sharknado, I think I’ll at least view some of the highlights on YouTube.

Yes, I Declined Your Meeting!

Meetings.  In my role, I’m in meetings 70% of my day, most of which I schedule.  These include status updates, decision making, following up on an action, or just planning out a near-term deliverable.  Each meeting has a reason for taking place, a goal to accomplish and points to cover at the time of creating.  I hold myself to a very high standard when it comes to meetings because if not planned well, they’re a huge waste of time and causes frustration.

Because I host and go to so many meetings, I’ve developed a bit of an anger issue for those invites I receive that don’t have a purpose or agenda.  Usually, they don’t tell me anything at all what the focus is.  So, I decline them with the response “Too vague; what are we going to accomplish?”  Below is a discussion I recently had with someone where I declined their meeting request:

  • Person: Why did you decline my meeting?
  • Me: There was no agenda or purpose.
  • Person: Didn’t the meeting title cover it?
  • Me: That’s a pretty broad topic that can go 100 directions, and usually does.  I need more detail so I can come prepared.
  • Person: Aren’t you supposed to be prepared for anything?
  • Me: Yes, but unless everyone knows what we’re going to talk about and what goal we’re trying to accomplish, it’s a waste of time.  We’ll spin our wheels.  Again.  Besides, this was covered weeks ago in the last meeting you called.
  • Person: [snarky] Why don’t you run it then?  Obviously you got a handle on things!
  • Me: Gladly.

Meetings are only as good as the results they produce, so going into them prepared is critical to achieving meaningful output.  Below are the rules I have to running meetings.  Though there are more, these are the more “common sense” items:

  • Have a clear meeting title
  • Have the goal/purpose of the meeting clearly stated
  • An agenda – sounds simple but missed most of the time (can be omitted if there is a clear goal or purpose and there’s not a lot of different topics)
  • Start and end on time
  • Yell bullshit if someone goes on a tangent; parking lot anything not contributing to the meeting’s goal
  • Document decisions/actions and route to everyone
  • If you see the meeting is getting forwarded, remove unwanted guests and confront the person forwarding

Meetings.  You’re going to have them.  You can’t always control the meetings you’re invited to, but you can control the meetings you host.  By doing a little prep work, you can create the best results in the time the group is together.

Culture of Success & Virtual Teams (Post #10)

I have been managing virtual teams for over 10 years and have been a full-time home-worker for more than three years.  I’ve seen a number of definitions of virtual teams, but the best is “A group of individuals, brought together for a common purpose, who are from different geographic locations & rely on communication technology to collaborate.”  This concept started with NASA back in 1972 and continues to grow today.

So when it comes to Creating a Culture of Success with your team, what’s the difference between a co-located team and virtual team?  Well, in theory not a lot.  But in practice, take every communication concept I’ve discussed and amplify it by 10x.

  • Over-communicate project status and issues with stakeholders to they’re never surprised by something that may be going on
  • Make your project goal front & center in every meeting you attend with stakeholders and team members
  • Establish a team communication strategy (scheduled meetings, ad hoc meetings, meeting formats, facilitation, email protocols, instant messaging, etc)
  • Being present and touching base with those you can’t see frequently
  • Trying to budget travel for face-to-face when you can
  • Conflict resolution needs immediate attention and resolution
  • Guard your team from distractions, because you cannot physically see the distractions coming
  • Beware of jargon when interacting with global team members

Managing a project is hard, but managing a virtual team can be truly taxing at times.

I started this series of blog posts two months ago and during that time, have presented Culture of Success twice at PMI events.  I’d like to thanks everyone who’s read these, commented, and liked them.  I hope you’ve found them informative.  To the person who first asked “If you project managers are so damn good, why do projects keep failing?”, thanks for challenging me.

Culture of Success: People vs. Process Paradigm (Post #9)

This is one of my favorite topics; the People vs. Process paradigm. This is a debate I see carried out in LinkedIn groups and PMI meetings on a frequent basis.

When companies are small with few employees, processes are thin and it relies on people to get the job done.  As it grows, the dependency needs to shift and have more processes in place.  Let’s define each:

People Dependence

  • Organization depends on its people to effectively execute work
  • Cons: can be mistakes, lack of accountability & not repeatable

Process Dependence

  • Organization depends on processes to ensure proper execution of tasks
  • Cons: Can be too bureaucratic, paperwork heavy, someone (hopefully not YOU) needs to manage

The question is, is one better than the other? Or, what is the right blend of people dependence and process dependence?

There is no “One Size Fits All” Solution.  If you’re creating a process or enhancing an existing, there is no magic bullet for success.  Every company, culture, project and team will be different.  No matter what you hear, read or are told, there’s no one size fits all.  Though PMI offers a good framework, each company should tailor their methodology.

I’ve started a couple of project management offices (PMO) in my career.  The first was for a small company that had little process and wanted more structure.  We assessed their needs and slowly implemented processes based on the biggest challenges.  It took a couple years, but eventually the PMO was viewed as a trusted department in the company.  It was a tailored approach that worked well and is still in place today.

The second was for a slightly larger company that again had very few processes.  A PMO was stood up right away and a director from a Big 3 consulting firm was hired to run it.  He had a playbook with lots of processes and artifacts.  He was smart and driven to implement the playbook, but the step we missed was assessing what change the organization could handle.  Six months after starting the director was let go and PMO disassembled.  A couple of processes remained, but for the most part, groups resorted back to what they knew.

When working with companies on either new or existing processes, there are a few artifacts I require; project charter, schedule (see next section for the level of detail), risks/issues log, and populating status reports.  These standard artifacts define done, highlight problems that can pop up, and keep stakeholders informed on progress. I also require regular meetings with teams and stakeholders. Above those, all other processes are open for discussion.


Define Rules vs. Guidelines.  When creating processes, I don’t want them to be too rigid or bureaucratic.  This can decrease buy-in by project managers and they’ll work to skirt around the system.  Instead, I have created rules and guidelines.

An example is a project schedule.  I require every project have a schedule, which is a rule.  The guideline comes from the level of detail the PM will track to.  If it’s a complex project, there may be more detail.  If it’s less complex, there may be just key dates.  The PM is allowed the flexibility to get as detailed as they see fit.

What Came First; the Process or the Tool?  Let me start by saying a tool will NOT help you unless it supports and/or enhances and existing process.  I see questions on LinkedIn asking what tool people like the best.  My response is “it depends!”  Look at tool selection as a project in itself, with a sponsor, requirements, vendor RFP’s and deployment plan.  Understand if the tool can start small and be scaled up as employees grow accustomed to using it.

In the final installment of Culture of Success, I’ll touch on virtual team management.