Effective Program and Knowledge management in a release

The stage: In IT services, projects are usually operationalized. Consider a bank that offers retail banking services like savings and transactions account, mortgages, personal loans, debit cards and credit cards. Usually, such banks’ IT department will be engaged in projects associated with performance/process improvement, development of small to medium sized features, adding security features to banks’ offerings and production support. As there is very little to no impact of technological advancements to these projects, they are managed in the form of releases of various durations. The teams involved in these releases tend to remain same. In such projects, complexity lies in:

1.       The number of teams involved and

2.       Different demographic locations of these teams

For example, refer to a release that has three different teams: Development teams in India, Infrastructure team from Hong Kong and business and management teams from Florida.

The difficulty arises while orchestrating the release when these teams have to interact with each other on a regular basis. The teams have to understand and follow a single plan to deliver the features for any release with constraints like time and budget. Moreover, there are many development teams in India: 5 teams working on the back-end system, 2 teams working on front-end system and 2 testing teams. Likewise, in Florida, there are 2 teams of business analysts and a management team.

Each function has a project manager: 1 PM for back-end, 1 PM for front-end, 1 PM for testing etc. To manage the release, there is a program manager, who acts as a release manager. He or she prepares the plan by taking inputs from various key stakeholders including the project managers, architects and subject matter experts.

The problem: To evaluate the progress of the release, the program manager conducts a periodic (usually weekly) meeting with all the PMs to get a good visibility of the progress in each team. This helps the program manager to understand the overall progress of the release. If any of the PMs are not present in the meeting due to some reason, he or she assigns a backup person to provide the update. Usually, this person has worked in only a subset of the development and may not have the overall view of the project. In such cases, it becomes necessary to identify the key people from each team that can provide help during system testing and user testing phase when their PM is absent.

To address this issue, we can conduct an SCA on the teams involved and identify the important resources from each team that can act as backup for their respective PMs and are most knowledgeable resources for all complex features.

How:

Create a smart survey for all the team to participate and identify the following:

1.       The person who acts as a focal for other team members in identifying the right person from his or her team to solve other their queries.

2.       The person who is the most knowledgeable member for a feature.

For example, the testing team talks to person “P1” from team A to identify the right person to address their queries.

Here, P1 and P2 acts as shadow PMs for team A. P1 routes all the queries from testers to the right person in team A. Likewise, P2 routes all the queries from front-end team to the right person in team A. Both of them can act as backup to their PM in the weekly meeting with the program manager.

Using SCA, we can also identify the most knowledgeable person for each complex feature in the release. For example, P1 from team A is identified as the most knowledgeable person for a complex feature F1.

Such focal points will be involved in fixing the defects and preparing knowledge artifacts for the complex features that they are good at. Remember that for a complex feature we may get one person from more than one team. This is because, a particular feature was developed by back-end and front-end teams. So, the changes associated with that feature will be known by more than one person.

Implementing this process based on the outcome of SCA can help the release run more effectively and reduce the unwanted communication needed to fix a defect during the testing phase.