Finding Your Way



We all need a map (yes fellas, even you).  Maps are tools to navigate in areas that are unfamiliar.  They hold immense amounts of information in very simple forms.  Maps help us to remember where we have been and how to get to where we are going. 

We navigate in unfamiliar media every day.   The trick is to know how to make a map when there isn’t one around.  Below are some basic ideas on how to make a map of a project, a development plan, or a strategy.  Let me know your thoughts.

  1. Start with an idea.  Vague is okay when starting the process.  You may not know where you will end up, but have an idea of the outcome.
  2. Lay down the rough lines.  Outlining is useful and so is creating nested topics.  If working a project, think about significant milestones that have to happen to reach the end.
  3. Start to fill in the detail.  This step is progressive and iterative.  Once you start filling in details you will have to refine other parts of your map and revise.  This leads to more detail.
  4. Think of different ways to deliver information.  Maps use symbols, lines, numbers, legends, etc.  Think of how you might incorporate the same into your map.  Using different colors or thicker lines to demonstrate impact or size is a simple way to add information (large cities have a different symbol and are usually in bold type on a map).
  5. Proofread.  Have someone else try to navigate using your map.  That is the ultimate test.  Can he get from here to there?  This is useful for strategies, procedures, presentations.
  6. Make it easy to read.  You don’t want people to have to stare at your map for days before they know how to use it.  But don’t forget that people need to be trained on how to read maps.  You didn’t know how to use a map before you were taught and you probably haven’t seen a map like the picture above unless you are a pilot.

Maps can be graphical, linear, or simply post-it notes on a wall with string.  It’s about organizing the information and making it available to others.  These are skills any leader or project manager must have to be successful.

How have you used maps in your life?


Why to Say “No” to a Customer


image from:

It can be tempting to do what your client asks of you even when you know it will be wrong or it will not work.  After all, “she is the customer and the customer is always right.”  Below are a few reasons why you should be willing to tell your client no and even to be willing to walk away from the job.

You Have Professional Integrity

You are partnering with a client because they need your expertise.  They should be hiring you because they are not in the position to do the job themselves.  This should put you in a position of knowing the pros and cons of the job.  Take the time to walk through it with your client (after all you may have missed something) and be willing to explain yourself several times.  If it gets to a point that you are being pushed into something you don’t like, for whatever reason, be willing to walk away.

They Will Respect You

No one respects a pushover.  No one respects pushy people either.  You have to be ready to temper your customer service with professional resolve and vice versa.  A soft approach is the best way to take a hard line.

You Have Their Best Interests In Mind

If you are willing to do whatever they ask, they don’t need you.  You become a second pair of hands and that it not fun.  What you want to be is a trusted partner, and that means you contribute knowledge and expertise.  Letting the client know that you want them to be successful is how you can make sure you never put yourself in a position to be blamed for your project failing.

If you are tactful and professional you can make sure that you only work on the projects that will make a difference for your clients.  This is what will make you stand out and give you a great reputation.  If you are in a position where you have a direct boss within an organization there will be times that you have to do what you may not think is best.  But don’t be afraid to speak your mind and get your ideas on the table.

How can you say “no” to clients and customers?

Take Care of the Little Things


As Project Leaders we are usually have skills regarding our attention to detail.  But we are also usually very neglectful of the “soft” side of project management (which is why I prefer to use the term “Project Leader” as a reminder that projects involve the personal component just as much as the technical).  So when I want to write something regarding the little things, I am not just talking about the technical, task-related items that are part of a project.  Below are 5 little things to take care of while you are managing the tasks of a project.

It is easy to mismanage our tone when we are working on a project.  We can become so focused on accomplishing tasks and getting updates that we forget that there is a person that is working on this for us.  Often times we are doing these updates via phone (a conference call is typical) and we want to be efficient and not waste other’s time.  However, forgetting to be appreciative and approachable can cost us in the long run.

Don’t forget that you are serving the needs of those that are working on the project just as much as they are serving yours.  It is necessary that you be timely with responses and due dates as well.  There is a lot to manage when running a project, but providing information to those that are managing tasks is one of the most important things you can do as a project leader.  Give realistic commitments and keep them.  This is one of the easiest ways to lead by example.

Keeping up is necessary.  90% of what a project manager does is communicate.  Make sure that you are getting the latest information to everyone and keep yourself current on the progress of all of the parts of your project.  You may not know the details, but that is okay.  Just know where the project is and how it may affect the other pieces.  Keep others up-to-date as best as you can.

Take a Break
We all need to recharge.  Make sure you are taking the time to recharge yourself and your team.  If you don’t take a break you may find yourself completing subpar work and settling for mediocrity.

Take Turns
Whenever possible find a backup that can help with some of the duties required of you so that you can be there to support the team.  Let someone else lead a meeting so that you can take some one-on-one time with a member that needs that extra support.  This also provides development tools for other members of the team that may need to work on some of these skills.

These little things can add up to big things in the long-run.  Don’t discount the power that these small tasks have on your project and your team.

What are little things you have done to make a big difference?

How have leaders impacted you by taking care of the little things?

Scale and Perspective


A blimp in the distance.

Understanding Scale is what Engineers and Project Managers do.  Understanding Perspective is what Leaders do.  Combining the two, marrying scale and perspective, is what Project Leaders do.


Building to scale is when you construct something to be proportionally equivalent to the final product.  Scale models are used to understand spatial relationships; scale systems are used to test loads and outputs.  Scale also is a measure of degree.  A small-scale project versus a large-scale project.  Scaling a project refers to pilot testing and then upsizing a system to its final size or load.


Perspective is a point-of-view and understanding the relationship of things from a specific place; knowing how to represent items in terms of the things around it.  Artistic perspective often discusses the ability to translate 3-dimensional into 2-dimensional in such a way that it is understandable and realistic to the viewer.  Abstract perspective involves the position and observation from the individual on the topic or object.  Perspective is tied to emotion and experience.

When working on a project, it is important to remember both Scale and Perspective throughout the process.  Using the DMAIC model from 6-sigma, we can apply both Scale and Perspective throughout the method.

Define – Understanding the scale of the project is part of the define phase.  One must determine the size and scope that will be included and excluded as part of the project.  The Project Leader must also understand the perspective of the sponsor and the end-user.  Too many times we omit the perspective of the people that know the process best and can add significant value to the scope.

Measure – This is often thought of as strictly a scientific item.  However, this phase of the project requires a thorough understanding of the perspectives of the customer, sponsor, user, and team.  Each of these perspectives will have different metrics that are important to them and they need to at least be considered.  Some will be eliminated due to time constraints, feasibility, or other reasons, but consideration is key when involving people in your project.  The scale of this phase can be daunting unless a good method of vetting the essential from the ancillary is found.  Scaling this section back can be detrimental unless all of the perspectives that affect the project are understood.

Analyze – Be careful of “paralysis by analysis”.  There are hundreds of statistical tools to use and different ways to slice and dice the data.  Scale your analysis so that it is representative of the perspectives you choose to include in your project.  Understand the key improvement areas of each and perform an initial-phase test to see if the data warrants further investigation.

Improve – This is where scale and perspective can sometimes collide.  By including multiple perspectives you will undoubtedly increase the scale of the project.  Understand where improvement will yield the best results and start there, adding scale as long as the project justifies the improvement.  Implementation may need to be scaled as well, working your way to the final product once you have proven the method.

Control – This is where gaining perspective at the beginning of the project will pay the most dividends.  By understanding the perspective of the end-user you will be able to sustain and control the process.  Remember, the end-user will be the one to decide whether or not your project will work, not the boss, not the sponsor, not you.  If the end-user decides that the project does not satisfy the need from their perspective, no matter how much you scale, it won’t work…period.

We, as Project Leaders, are people that work with processes, projects, and people.  We have to understand the process we are affecting, design and manage the projects that will improve that process, and serve the people that will benefit from and use the final product.

What is your perspective of this post?

How have you seen different perspectives affect the outcome of a project?

Providing Choices


When you look at a group of tomatoes at the store from a distance, they all look the same.  That doesn’t make for excitement.  It doesn’t make me feel like I have options.  If I want a tomato, I get that type of a tomato.  It’s kind of like getting a Model T in fire-engine red…not going to happen.

People like choices, and as Project Leaders, we need to understand that desire.  Sales people have been using this tactic for decades. 

Don’t give people the option to say “no”, give them options on how to say “yes”.

As a Project Leader, you are a salesman, whether you want to be or not.  You have to sell your solution, your method, your team choice, your timeline, your budget, and your abilities.  These are all points of sale, and if you provide options, you will sell more.

The Solution & Budget

Selling the solution seems like it should be the last step, but it is the first.  Most times a project is “identified” already and you are the one to get it done.  The thing is, there are multiple solutions for most situations:  Automation vs. Manual, New vs. Used, Higher Investment/Lower Operation Cost vs. Lower Investment/Higher Operation Cost.

These are all choices.  Scope your project on all of these fronts for feasibility and impact.  Present the options to the stakeholder and help him choose the solution that is right for him.  Remember that the solution and the budget are closely related.  Provide valuable options that are at different investment levels, however, make sure they all satisfy the objective of the project.

The Method & Timeline

Method is the HOW for executing the project.  You already have the WHAT sewn up with the choices you provided for the solution.  Now, with the different solutions, you can have different methods.  These choices can range from installation methods, equipment options, operation needs, interviews, surveys, process flow maps, value-stream mapping, and many other buzzwords, catch-phrases, and tools that proliferate in the Project Management arena.  Pick different options that, again, provide value to the stakeholder.  Method and timeline are directly related and usually the longer the time investment the more thoroughly the solution will be implemented and sustained after the project is completed without your intervention.

Be careful here.  It can be easy to find yourself providing a method option that is going to tie you to the project for a long time.  Understand your time commitment and budget and provide options that fit within your requirements.  Also, be cautious about being pulled back into the project after it is completed because it drifts backwards.  This is usually because you provided an option that was too short on time and the project was not adopted readily, requiring your intervention later.  Make sure the stakeholder knows when you are parting ways with the project and understand that support will be limited afterwards.  People will not own something if they can rely on the Project Leader as a crutch.

The Team & Your Abilities

These options start with a clear assessment of what you bring to the table.  Understand your time availability, your technical capabilities, and the level of intimacy you have with the project topic.  Create options around how you will support your weaknesses (and it is okay to have weaknesses on a project and still be the Project Manager) with other people and create potential teams with suggestions.  Make sure that all of these teams satisfy your requirements for time and talent, but still give options on who is on the team and the time they will need to invest to the project.

How Many?

Three is always a good number.  I think that is why the Baby Bear in Goldilocks didn’t have any siblings.  You will find that with a number like three, the process of elimination takes over and you will have an option that is too hot, too cold and another that is just right.  Sometimes you can’t make it to three, that is okay, work with what you have.  Other times, you may need to present more options.  Understand your audience and the project complexity.

Don’t provide too many choices.  People get bogged down when they have too many options to consider.  Use yourself as a guide.  If you would be willing to sit and read all of the options and weigh them against one another, chances are that your stakeholder will as well.

At a Snail’s Pace: 3 things to learn from the Gastropod



We are in a rushed world.  We want instant gratification and we expect timely service from our suppliers and our customers expect it from us.  When we manage projects we are looking at the critical path and trying to crunch the schedule as much as possible without any slip.  As project managers, our job is to complete the project with the right quality, cost and in time.

I was watching this particular snail move across the sidewalk.  It was slow and deliberate.  When it ran across an obstacle it took its time to evaluate the best way around it and then continued on its journey. In this relatively short amount of time I felt myself relax and become amazed with the simple movements and methodical pace of this creature.

When we are running projects we tend to rush through them in order to get the results.  What we neglect is the setup.  This is where a methodical pace will get us somewhere faster than the crazed frenzy we typically use.


Take the time to investigate.
We often leave out the most important part of the project: evaluating its validity in the first place.  Many projects are “handed” to project managers with the assumption that it will get done; that it has already been vetted.  But usually the project has only had a cursory glance and it “felt” to be a good opportunity.

Work with the end-user to begin the project.
“A stich in time saves nine,” right?  Slowing down at the beginning and getting a solid working definition of the project objectives through the eyes of the user is the best way to make sure that the project stays done (in other words you don’t have to keep revisiting and revising the project after it is “closed”).

Incorporate time to get around obstacles.
Just like our shelled mascot, give yourself time to properly evaluate obstacles as they arise throughout your project.  Conduct a solid risk assessment (sometimes this can be as simple as on the back of a napkin for smaller projects) and think of how to mitigate those risks.  When they show up, you will have the beginning of a workaround that you can refine when the risk arrives.


 What other benefits come from slowing down a project?

Learning from the Past


Today is my 11th wedding anniversary.  These milestones often make me look back and reflect on the past.  Reflection is defined as a “consideration of some subject matter, idea or purpose” by Merriam-Webster.

So why is reflection important?  Well,

“Those that cannot remember the past are condemned to repeat it.”

George Santayana

That is why, in Project Management, there is a lessons learned portion of the project.  This is meant to be a time of reflection.  It is a time to consider the project and learn from its successes and failures.  A time to document and to share what we have learned not just from the results of the project, but also from the processes we underwent to accomplish those goals.

Often, at the end of a project we are already working on the beginning of the next one.  We want to end the last project quickly and then move on so that we can focus on our next endeavor.  However, by shortcutting the lessons learned process we actually cause suboptimal work in the future.

I think that every project should have two summaries.  One that documents the project results and another that summarizes the lessons learned from the project.  These documents can have drastically different audiences.

Management generally will want to see the results summary.  After all, this is the typical document we create.  However, our peers and the upcoming project managers can learn more from a lessons learned summary than they will from a results summary.  The lessons learned summary should be distributed to the project management office and also to other departments that could benefit from the information collected in this investigation.

There are several sources on how to conduct a lessons learned analysis.  But there is not much on how to summarize and distribute these documents so that they are useful.  A 20 page summary will not be read by colleagues as much as they will be deleted or recycled.  Here are some tips on how to make the information useful.

  1.  Keep it Short and Sweet.  A one or two page document should be more than enough.  If you get longer than that, people will become disinterested.
  2. Use bullet points as much as possible.  These are lessons, so they should be only a couple of sentences long each.
  3. Talk about the What, Why and How.  Leave out the Who, When, and Where.  These are going to change for every project, but the What, Why and How will be the most likely things that will apply universally.
  4. Use accents to get the message across.  Using bold, italics, underlining or colors will help to get the message across about the major ideas.
  5. Keep it functional and factual.  Don’t put in your assumptions or guesses unless they are called out as such in a separate section of the document.
  6. Know your audience.  Tailor the document for those whom you are writing it.  There is no point in putting the budgetary information as a lessoned learned when you are sending it to people that are not affected by or do not affect the budget.

If this is done right, the report should be short and to the point.  It should be functional and something that can summarized even further on an index card.  The investigation needs to be thorough, but the report should be distilled.

Take the time to reflect on your projects.  Learn from them.  Then pass the knowledge on to others so that they won’t be condemned to repeat your past.

What are some of the things you have seen that work?

What lessons have you learned from others that helped you succeed?