 |
This is the second blog post pertaining to my observations related to Project Management, and similarities with the game of chess. Blog 1 discussed the concept of experience and some lessons I’ve learned over the years through post-project analysis. This post will cover the importance of knowing your team and putting them in positions for growth as well as advancement of the project….
|
Key Concept: Know your Team
In chess, each player goes to battle with six different pieces: pawn, rook, knight, bishop, queen, and king. The goal of chess is to protect your king, while trying to ‘checkmate’ your opponent’s king. How you orchestrate your pieces throughout the game will have a major impact on whether you are the check-mater or the check-matee…..
Each chess piece is unique in terms of its abilities, and it’s up to the player to understand and exploit them strategically. Knowing the basics is one thing but mastering the ability to “fork” pieces with a knight, or countering an opponents’ attack with “Zwischenzug “ for example, makes you a much stronger opponent. Experienced players also understand how to exploit synergy among different pieces working together. (e.g., It is usually much easier to checkmate your opponent with a bishop and rook than with a rook alone).
Project Managers need to “know their team” as well. This involves both the ability to be a liaison between various aspects of the project and team members and the ability to learn how each team member works and which kind of guidance (or opinion) is either useful or disruptive. Understanding the team members you have available, how to leverage & focus strengths, support the weaknesses and developing strategies for development are all important. As the project progresses, these strengths and weaknesses may apply differently by the “stage of the game” you’re in. In addition, synergies emerge when team members support, strengthen and enable each other, making the overall mission of successful project outcomes a higher likelihood.
While there are no knights, bishops, or rooks on my team, we do have a contingent of Business Analysts, Developers and Architects. Some are quite experienced, while others are just starting out. By leveraging the experience of more seasoned veterans, we were able to identify important foundational tasks for the less experienced Developers to work on to help ease them into the effort, build confidence, and get insight on strengths / weaknesses. These preliminary tasks involved working closely with our Requirements Architect as they liaised with the Business to understand the focus of the engagement and identify business and functional requirements. In addition, we encouraged everyone to gain insight on other applications and services that required integration with our application. By deploying resources in a coordinated effort to encourage core understanding and focus, as well as establish relationships with folks in key integration areas we were much better positioned as the project progressed. In addition, synergies started to emerge…
In the case of our project, we were creating an application to address care management and maintenance of diseases, or conditions such as needing to lose weight, quit smoking etc. The application required user interface design and as mentioned, integration with a variety of systems and services to allow for the sharing of information. While our Requirements Architect was very experienced in driving detail, we found that pairing him with Developers improved the quality of the requirements and eliminated “grey-areas” that often lead to issues later on in the project. Everyone quickly gained an appreciation for the level of detail we needed vs. what the Business thought we needed. The different perspectives each person brought with them allowed us to produce solid requirements and wireframe layouts. Developers started to “own” pieces of the application since they were intimately aware of what the Business needed – (which often times was NOT what they asked for, but that’s a different story). We also found that we were in a much better position to offer options the Business hadn’t considered (that ended up making the application much more effective in addressing their needs). All of this because of the way we focused the team in a coordinated “attack” to establish ownership, focus, and control. Best of all, requirements for future releases came much faster (but with the same quality) as the team learned how to play off each other.
- Max Euwe |
When I play chess, I strive to place pieces such as bishops & knights in an anchor position that supports introduction of other pieces in to further the attack. The same goes for managing projects. This could mean letting more experienced team members to take point and lead a charge of the less experienced while keeping an eye on them to ensure focus and quality. Allowing the anchors on my team to own a segment of the application established a sense of trust and responsibility vs. me being a task-master type PM. I believe this approach improves team morale, personal development and exposes members to areas they might not normally participate – giving them a more well-rounded skill set. Many of you know what a good Developer or Business Analyst brings to technology engagements but in today’s environment, it’s also about what else they can bring to the table that differentiates them from the rest. Identifying these people, positioning them as anchors, and guiding them when they need help is key to developing these “other” areas that are often the difference between a good project outcome and a great one. |