Chess and Project Management (Part 1)

Chess-Move.jpg I found a box of old chess books that I hadn’t touched in 15 years.  After flipping thru some dog-eared pages of classic games, I realized I missed playing and decided to get back into it.  I started by downloading a chess “tactics” application on my phone to use during my train ride to and from the office.  Chess tactics are move sequences in which your opponent is not able to respond to all threats – thereby giving you the advantage.  These move sequences reinforce core chess fundamentals such as “discovered attack”, “pins”, “skewers” and “forks” to name just a few.  The tactics app starts by presenting a board position and asks for the next “best move.”  The better you are at recognizing and applying core fundamentals, the more successful you will be in determining the next best move. 

In chess, (and most anything these days) there are helpful guidelines to start you off on the right foot.  For example, “play to control the center of the board”, “don’t sacrifice without a clear and adequate reason”, “develop your knights and bishops first & don’t bring your queen out too early” are just a few to keep in mind. 

“These young guys are playing checkers. I'm out there playing chess.” - Kobe Bryant As I started to improve at chess tactics, I started to identify tactics for other “games” I play on a regular basis; one of which is managing a team developing software applications in the healthcare industry.  So what about the guidelines for Project Management, and do they share any similarities with those in chess?  The more I focused, the more similarities I saw, so I decided to create blog posts to delve deeper.  While there are some big differences between chess and project management, there are strong relationships.  The first similarity has to do with experience….

Experience Matters

The total number of possible moves during a chess game has been estimated at 10120 (referred to as the Shannon number).  As a comparison, the number of atoms in the observable universe, is estimated to be around 4×1080.   When presented with this many move options, experience and pattern recognition play a significant role in choosing the “best” move.  Any chess player who wants to improve does a thorough post-game analysis to learn what they did well and where they blundered.  With the advancement of today’s computer chess engine technology, it’s easier than ever to get brutally honest feedback by plugging in your game and having the computer tell you the “best move” you should have considered vs the one you made.  My post game analysis not only helps me figure out where I blundered, but more importantly – should I recognize a similar pattern / scenario in the future, I am now the wiser for it and enlist proactive moves to prevent disaster or to grab an edge.

There are many different “moves” or approaches a project management can make throughout the project life-cycle.  Even though it’s nowhere near the number of possible chess moves, it’s still important they consider all their options in terms of approach and direction; weed out the “bad” moves and focus on the remaining set to determine what’s best.  Hopefully, the more projects you manage, the better you’ll be at managing projects, but again, that’s only if you take the time to review your project from a variety of angles after it’s been completed and learn from it.  I’m not aware of any Project Management computer engines that can assist you like they do in chess (yet), but often times your team members (client included) will provide you with feedback that will help you.  Remember – mistakes are not necessarily bad, but not learning from your mistakes is always bad.  Take the time, be objective, learn, and adjust.

Looking at the projects I’ve managed throughout my career and considering all of the post project lessons learned, here are some of important areas of focus along with project management tactics that shift the odds in favor of successful project outcomes.  You’ll want to ensure they are all considered / monitored throughout the project lifecycle: 

Project goals / Business Case:  These addresses “why are we here?” and “why are we doing this?” 

We’re looking for consistency, and alignment among stakeholders as to the purpose of the effort.  Your project will encounter issues almost immediately if you don’t manage any inconsistencies.  Some of what I look for:

  • Are there compelling reasons as to why this project is necessary?
  • Are there established criteria for measuring the before and after differences the project introduces? Do all stakeholders understand these metrics the same way?
  • Do you receive consistent responses from stakeholders as to why the project is necessary?
  • Are expected deliverables are understood consistently across stakeholders?


Stakeholders: Stakeholder management and commitment are key components of a healthy project, so I monitor involvement, availability as well as their focus on communication, change management and training.  Here’s some of what I look for:

  • Do you know who ALL the stakeholders are? Are all stakeholder groups represented appropriately and are they engaged at the appropriate level?
  • Does leadership truly have the funding for what they’re trying to achieve?
  • When dealing with steering committees etc., are decisions and actions being made in a timely fashion and are they effective?
  • What kind of stakeholder resistance is out there and how can it be addressed / managed?
  • Does each stakeholder area understand roles, responsibilities, expectations?
  • Is there consistent alignment of staff/management incentives to project results?


Scope:  Scope documents, agreements, etc. are important because they describe the expectations of the project.  Key here is a truly consistent understanding by all stakeholders.  Here’s some of what I look for:

  • Review the scope document and look for evidence of healthy negotiation and involvement among stakeholders. This will provide insight as to how much level-setting may be required to get everyone on the same page.  
  • Can stakeholders respond consistently to the question, “What are we trying to accomplish here?”
  • Is the scope document under constant revision? (bad)   Is the scope document versioned and readily available? (good).  It’s tough to hit a target that keeps changing…
  • How is the word “Issue” received by stakeholders? Is it good or bad?  Often times a “lengthy” issues log is considered a problem, but I’ve found it’s actually a sign of a healthy project and a project management who is on top of their game
  • Do all stakeholders understand the change management process that will be used should project scope need change / update?
  • Once proposed scope changes are agreed, are they appropriately reflected in terms of cost, schedule and responsibilities?


Risk: As I’ve stated, risk management is key to a successful project / or chess game.  I look for these:

  • Are risk and issue follow-up’s taken seriously and addressed in a timely manner by all stakeholders?  
  • Is there an expected approach by which “all-or-nothing” tactics are employed (usually bad) Vs. piloting and testing on a smaller scale? In my experience, if you can pilot to a smaller group and iron out the wrinkles before launching to the world, you stand a better chance at success.
  • Are risks proactively sought and discussed in meetings? Are they logged, owned and tracked?
  • Are meeting minutes published that provide outcomes, action items / follow-ups, next steps along with who is on point for each?


Schedule: My focus here is on milestones, deliverable acceptance criteria and roles.  Some of what I look for:

  • Have all the resources the project requires been obtained / scheduled? Do you know the vacation schedules and how to manage around them?  Don’t forget about holidays too!
  • How are the project milestones tracking? (expected vs actual)
  • How are dependencies tracking? (expected vs actual)
  • Is there confidence in the status report I send out in terms of accuracy and estimates to completion? Does it contain the appropriate amount of information the stakeholders need?
  • If project scope changes, does schedule require updates as well?


Project Team: While the project team is included in “stakeholders” there are some key things to pay attention:

  • Are breadth, depth and caliber of project management and team skills appropriate for all phases of the project?
  • How is team morale, and motivation? Is there evidence of synergies?  How well do teams collaborate?
  • Is there a clear and consistent understanding of roles & responsibilities?
  • Understand there will likely be some “storming-norming-performing”.


In addition to the above (which I’m sure isn’t new to many of you), I also like to add one of my own.  If you can swing this one, it will pay-off down the road:

  • Provide each project team member the opportunity to communicate their own goals and interests and the opportunities they’d like to engage (should the opportunity present itself) during the engagement. Not only are we trying to achieve a successful project roll-out, we are also nurturing and mentoring the team so they can grow in experience and responsibility.  Sharing this information with the entire team also allows everyone to be aware of these goals – not just the project management.  More about this later…

In summary, “Experience Matters” whether it be a chess game or a project.  To improve you must learn from your mistakes.  Review what went well, what didn’t and what could have been better are key to improving your game.  It’s sometimes a very humbling experience but if you take it to heart and focus, you will be much stronger for it.   


Topics: Requirements Management, Executive Insights, Project Management Strategy

Written by Ken Lubert

Ken is a Principal at NVISIA. He has over twenty years of consulting experience covering business strategy, process optimization, requirements and rules management, customer experience, and relationship management associated with full life-cycle implementations of medium to large-scale projects.

Leave a Comment