pmStudent

I absolutely love this TED talk by Simon Sinek and had to share it with you.  I want to draw out some of these ideas and apply them to project leadership and project management.

And by the way, he gave the 'I have a dream' speech, not the 'I have a plan' speech. ~Sinek

A great example of this principle in action for projects are implementations of particular methodologies driven by calls for efficiency or because all of the hip kids are doing it.  Countless organizational change iniatives fall prey to this same failure of trying to sell what and how, not why.

How many of us have had process change around us because someone thought it would be a good idea, but we have no idea why the change is happening or why we should care?

"...we follow those who lead not because we have to, but because we want to." ~Sinek

If you adopt agile or kanban or whatever whiz-bang method of working, are your teams and organization following because they have to, or because they want to?  Have you sold them first on the why? 

I think this is an area I can improve on, as I'm sure almost all of us can.  I have implemented agile methods of working with teams without any more justification then "trust me, I think this will really help us work better."  I was luck in that my teams have usually had some knowledge of agile and were positive on the general approach.  So I was relying on their own internal reasons for why in those cases.

Below is my own representation of Sinek's "Golden Circle".  The normal method of selling stakeholders and project teams on a project vision is to start with the what, figure out the how, and probably barely touch on the why.  For many project team members, the best answer they have to "why?" is "because it's my job."

On the other hand, the inspiring arrow shows a project leader who sells their stakeholders and teams on the core "why?" question first, by answering it in a compelling way.  From then on, the details of what, how, when, etc. get worked out in light of the primary answer to "why?" - The Goal.

Please check out his TED talk below. I think you'll enjoy it.

People don't buy what you do. They buy why you do it. ~Sinek

 

Like this? Share it!

We've all been there.

We have all been in terrible meetings or run terrible meetings.   I know I have.  I catch myself even now doing a poor job at planning and managing a discussion well.

It's so simple to do it well.  Why don't we do it more often?  Why do I forget the basics sometimes?

Here's a reminder for me, myself, I, and you too.

What's the Goal?

Have a clear goal going into the discussion.  Is it a decision or set of decisions you want to come out with?  Is it to communicate status?  

Make sure the goal is clear to everyone, and that the goal is stated in such a way that you know when you've acheived it.

This is why an agenda is so important, even if it's just a few lines of text in the calendar item or in an email.  It doesn't have to be formal, but it does have to clearly communicate the goal(s) clearly.

Respect People's Time

Schedule meetings to be 15 or 30 minutes by default.  Most scheduling software automatically defaults to an hour.  Change the defaults.

Limiting yourself to shorter meetings will keep them more focused and productive.  I would rather have 2 30-minute meetings than a single 1-hour meetings if it makes sense.  Sometimes that can be a good strategy, especially when it's a decision-making discussion.  Expect actions and follow-up activity to come out of the first discussion, and get finalized in the second.

Shorter meetings also makes it easier for you to keep the group on track.  If someone gets off topic, you can steer them back by interjecting "we only have a few minutes left for this discussion, so let's table that topic for now and deal with it individually or in a new meeting."

If you are scheduled for 30 minutes and you acheive the goal in 10 minutes, declare victory and get the heck out of there.  Get everyone back to moving your project forward.

Additionally, start the meeting on time.  Waiting around for 5 minutes for other people to arrive is pretty painful for everyone.  In some cases you have to wait...if so, try to get some cheerful banter going at least...otherwise it's just boring silence.

Follow Up

If there are actions from the meeting, follow up on them.  Make sure other people are as well.  

Sending out meeting minutes is a great way to 1) ensure people know their responsibilities, 2) you remember who you are expecting updates from, and 3) help ensure understanding by re-stating the decisions in your own summary.

What ineffective behaviors do you catch yourself or others doing that give you a headache?

Share this with your network

Sometimes we can get a bit project management tools crazy.

This can be a really big problem if we fall back on our spreadsheets, gantt charts, and staffing calculations in an attempt to solve our problems.  These are tools, and can be very useful in helping to model a plan that we can then go execute on.

But putting it into a tool doesn't make it happen, and trying to communicate via entries in a tool is not an effective way to solve problems.

I hear you mumbling..."of course Josh.  Duh!  Why would you even write about this?"

Unfortunately, I write about it because I see it happening every day.

When a problem arises, what's your first step? 

Do you go talk to your team and stakeholders, or do you first go to a schedule?

Calculators don't solve problems....people do.

Share this with your network

I work in a project environment that consists of many project teams working on various systems that need to interface with each other. The interfaces between the systems can be the most difficult parts of the systems to manage.

Although we have interface specification documents (ISDs) and interface control documents (ICDs) some details of the interfaces still have problems.

So how do you make sure that project teams working together don't end up stepping on each others toes?
 

User stories

User stories by their very nature lend themselves to describe who needs what and why and this can apply to interfaces between systems very well. The format I use for user stories is the following:

"As (role), I (condition - need, do not need, expect, do not expect) (something), because (benefit). "

We also capture acceptance criteria to define how we know what 'done' looks like and a change log for reference when needs change.  We just started doing this in my current project environment, and based on my previous experience with implementing user stories I am very confident these will help us be on the same page with groups and individuals outside our project team.

User stories are mostly useful as a foundation for discussion with the various stakeholders that you have, and make sure that you fully discuss the scenario and have documented what the decision was.  On a project like mine, there are many situations where several ways to implement something exist, and it doesn't really matter which route we choose so long as everyone is on the same page.

Unfortunately, I have seen a lot of times in the past where one group thought that something was being implemented as A, and the group who was actually implementing it thought it was supposed to be B.  User stories can help with these situations because doing them forces you to think through these situations and really clarify what A or B really mean and which solution we are going to implement.

They take a lot of the assumptions out of the process.

Open Communication Channels

It's also very important that your team members are empowered to go have the necessary discussions with groups outside your team, at any time their spider-sense is tingling telling them there may be confusion or different assumptions across groups.  Everything does not have to go through the project manager.  Many of these discussions will result in minor changes to the implementation that will not be a change in scope, schedule, cost, or quality.

I still ask my team to keep me in the loop, and they do a great job of this in our daily tag-up meetings when I ask the question, "What did you work on yesterday."  In this way, we keep the whole team informed.

When changes do have potential impacts to the project's PMB (Performance Measurement Baseline) I am always involved.  For each of these changes we need to do an impact analysis and weigh the cost-benefit to see if we really want to make this change through our CCB (Configuration Control Board).

Continuous integration

One of the best things about an agile style process is that you end up doing a build and run through of your entire system from end to end every sprint. Although my teams are no longer doing strict time-boxed scrum, we are doing kanban in a modified way where we are still doing a build of the system every two weeks and running in from end to end.

In addition to running our own system we try as much as possible to get the most recent build from the other systems we interface with and build them as well. This is what I like to call continuous integration, and so far it's really helped us to identify the miscommunications that still occur even with good requirements, user stories, interface documentation, and all the other things that we try to do to make sure we don't step on each others toes.

Hey, if we're getting in each others' way I'd rather find out about it sooner than later.

On large projects, how do you keep your project teams from colliding?

Share this with your network

I just responded to a great question about whether an online MBA would be worth it for someone.

If I had the choice between an in-class degree versus an online degree, I might prefer the in-class option.  I like to badger the professors too much, and you don't get to see their faces get red too often when you are doing it virtually.  :-)

Seriously though, many people find themselves in a situation where an in-class program just isn't going to be a possibility, or at least not something they would be willing to make happen by moving or re-arranging their lives.

Personally, I wouldn’t shy away from an online degree if it were the best fit for my situation. The primary goal will be to study hard and learn tons of new information you can apply.

The better question is to ask if you have the right mindset in the first place, for any form of learning.

As long as you have the right mindset (you are doing this to learn and make yourself more capable) then you can get as much if not more than other students who are doing an MBA program at an Ivy league school.

I am fairly certain that over half of my classmates when I went to college didn't have the mindset I'm talking about.  Having 'the mindset' can be inferred by behaviors like:

• Doing independent research on your own that is not assigned, for nothing more than wanting to learn more about a specific topic.
• Finding ways to incorporate what you are learning in class into your working day.
• Asking lots of questions in class and of professors and aides between classes.  Real questions, trying to delve more deeply into concepts so you can master them.

Just remember, the piece of paper is not what matters. Building your competency is what matters, so more opportunities will become available to you as you network professionally. Networking and getting referrals from people who know you do good work is a much more effective way of getting your foot in the door.

If you’ve built your competency then you can knock their socks off after you’ve created the initial opportunity for yourself.

Share this with your network