Logistics - Deciding a common location for all document sharing

Some of these posts can seem very logical and obvious, but in reality, many of these items have come up based on experience learned from various projects, shortcomings and feedback provided by the teams with whom I have been working. And they can be very important, even though they may not seem much.
When you have a number of different teams working on the same set of tasks, there are a number of documents, instructions, examples, demos, and other artifacts that need to be shared between these different teams, shared real time and with the required access available to all these different teams and their team members.
And it was one such case that caused a delay of around a week in the actual schedule of one such task that was being coordinated between different teams. A delay of any kind has a ripple effect on the entire schedule, and when schedules are less than a year, a delay of a week in any such related task can cause significant problems to the schedule and lead to some fire-fighting in the team management. In this current case, we eventually ran into an issue where a rights / security caused a blockage, and the person tasked to ensure the coordination did not even know about this security problem.
During the course of a project, the project / program manager cannot take on each and every area, and in one particular case, the coordination between a team located in the main geography, another team located in a different geography and a vendor team located in another geography. The vendor team was new to the product and had to be brought up to speed on the processes and technical knowledge of the product. In the light of some of this coordination effort, a team lead with experience of some of the relevant functional area of the product was put in charge of the coordination effort, reporting every week to the overall manager of the product about the status.
The lead started out well, using previous experiences to set out some of the required documentation. However, when an outsider vendor is needed for the product work, they need to be granted permission for the documentation area, And this permission cannot be granted by the team, but by a central IT unit which is responsible for all server access.
The problem turned out in this case was that part of the documentation was placed in a server that was off-limits to any outside vendor (there were some specific security protocols for some of the more important servers, especially those where code is resident on the server); but this information was not known to the project lead responsible for the coordination. The project manager knew this information, but the multiple tasks being done by the manager and the leads ensured that a proper discussion did not happen for the next 4-5 days, at the end of which a meeting resulted in the lead learning this security information, It took another 2 days to make changes to the documentation location, and then get the required permission. This entire stand-off did need to some changes being made on some parts of the schedule, not something that the project manager welcomes.
What the learning from this was that we did not do the required leg-work before starting this part of the phase, especially about a common location for sharing of documents and the permissions for these.

Working with vendors: Asking for a weekly status report

When the team works with vendors, there is always the element of doubt regarding the capabilities of the team with the vendor. In many cases, this may not be because the capabilities of the team with the vendor is any less, but because every product or project is different from the others, and it takes time for the team with the vendor to achieve the same level as the core team. However, this may not always happen; there may not be enough time for the vendor team to come anywhere close to the same level, and this time may not be available during the course of the project. This is one case, but there may be other cases where the coordinator from the vendor side may not be so competent, or there may be other reasons which is causing some sort of problems in terms of the client team feeling that there is some problem with the way that the vendor team is executing the project.
A number of these problems arise because of coordination and communication issues, and it is important that such matters be resolved; there should be a communication protocol setup to ensure that such matters don't cause conflict between the teams. There are several methods to have a regular communication process between these teams:
- Senior leads from both teams should setup a regular meeting for discussing issues (in my experience, this was a once in a week meeting that could be cancelled if there were no issues - this meeting was a big help to quickly reach conclusion on some meetings)
- A regular status meeting between the managers of both teams (such a meeting ensured that issues that were getting escalated were discussed and action items decided on how to resolve such meetings; in my experience, this meeting was also a weekly meeting that could be cancelled if required)
- The simplest way that we devised to highlight current status, ongoing items and ongoing issues was through a weekly status report. We discussed this with the managers and leads of the vendor teams, and then figured out a format which covered all these status items. For example, if there was an issue that was needed to be highlighted from the vendor team, they would put this in the report along with the other items, and this report was circulated to the entire team. This ensured that there was knowledge of what the vendor team was doing, what were the next items on their schedule and what were some of the major issues that they were facing. It also caused team members to flag issues where they had a different understanding from what the vendor had communicated, and quickly led to a resolution of issues.
We had asked the vendor team to ensure that this report was available every Monday afternoon, which also covered the entire items from the previous week, and on the odd occasion where team members were working over the weekend, these items were also incorporated in the report. A side benefit was that these reports conveyed an impression of the amount of work being done by the vendor teams, which was a subjective cross-check during the billing process.

Sharing of test data with vendors along with test cases ..

In several previous posts, I have been outlining some details with respect to interaction with vendors, for example - (Outlining focus areas of testing, Process for answering queries from vendors, Extracting relevant test cases); all of these outline some areas of interaction with the vendors. Working with vendors cannot be just one single area, there is a lot related to information regarding processes, tools to be used, focus areas to be decided, and so on. Yet another area of interaction between the vendors and the core testing team is the data to be used for the various areas of testing.
Having testing data is very important. You may have all the required test cases for doing a complete feature testing of the application, but without the test data, all this does not mean anything. For example, if you are testing a video application, then you need to be able to test for the different video formats that the application would support, and there are a large number of such video formats that are needed to be tested (unless you are in the video domain, you would not really believe the number of formats that exist because of the large number of companies that do something for video). For each such different type of video format, you would need to have the required data in this regard - multiple number of video files in each format (as another example, you could have a video file that is just a collection of images, another without audio, and yet another that has a combination of video and audio - there could be a defect that is only found if the video file does not have any audio - we once found a defect like this and it was a big pain to figure out what the problem was; after this, we had to add files with and without audio to our testing matrix).
And video files are large. The total size of the video test data that we used for complete testing was more than 50 GB in size, and it was guarded with great care. Because of the sheer size of the test data, we had decided not to put this test data in the source safe we used (because the data backup of the source safe meant that the guys running the source safe were not happy over backing up so much data that was binary rather than being coding text files) and hence had made multiple disk copies of the this test data, and there was some amount of effort required to ensure that there was a master copy of the data and all copies were synchronized to this copy.
Are you getting an idea of the problem we faced when we added a vendor testing team to this matrix. We had to tell them the focus area of testing, we had to prepare the extraction of the required test cases and make sure that these made sense for somebody wanting to do the testing who did not have the same amount of experience as the core team, and then we had to also pass on the large test data to the vendor while linking this test data to the test cases. Even though we had a fast connection to the vendor, there were some permission requests that also had to be processed since some of the test data that we had was from the vendors with no permissions to pass on, and hence every time we needed to pass them onto a vendor, we needed permission (no monetary problem, just the paperwork and time required), and since the test data was changing with new video cameras entering into the market, there were synchronization problems. And in an unusual case, we found that a particular set of high end video files required a very high end machine and this information was not captured properly. So when the vendor tries to use those files, things were not working.
The challenges may differ depending of the type of test data, but there is a need to ensure that there is a strategy to prepare for the passing on the required test data to the vendor.

Working with vendors: Telling them the points of focus for the particular version ..

In some of the previous posts, I have been talking about the issues and processes involved in ensuring that the interaction with the vendors (especially when they are involved in testing) is fine. In the last post (Working with vendors to ensure that tools are synchronized), I talked about how the team should be spending time on defining a process for transferring knowledge about the tools used by the team during testing. Now, this is easy for tools that are in generic usage, such as tools for Defect Management, Source Safe, or for capturing the details of Test Plans and Test cases. However, this is more complicated when the tools are specialized such as Fiddler, and other such tools that take time for vendors to learn more.
In this line of thought, there are several other processes that the team needs to transfer to the vendor team and do this in a systematic way to increase the level of efficiency. Some of the processes that the team might need to convey to the vendor team are:
- Certain specific processes such as the dealing with defects that have existed for some time. Consider the case of a defect that has been present in the product for more than one version, and the team has decided that they do not want to make the fix. Similarly, there may be cases where there is a difference of opinion with respect to the functionality, but anybody who needs to do this testing will be able to log a defect. In such cases, the team members know about these defects and do not try to file them, but somebody who is new to that area such as a vendor team member will not know, and will file defects in such areas. It is for the product team to ensure that they have transferred instructions regarding how to handle these defects to the vendor. If this does not happen, there will be wastage of time when the vendors actually do these testing. I saw such a case whereby there were some new members to the vendor team and there was a delay in passing on such information, and suddenly there was a buzz in the team about the vendor finding a number of defects that the team members had not found. There was some pressure on the testing team, but then it was found that most of these defects were of the types that the team already knew about, and there was a sigh of relief in the testing team (they would have come under a lot of pressure if the vendors found a number of defects that the core testing team was not able to find).
- Similarly, there are certain points of focus for every release. Or it could be the case where this is a patch or dot release that is focusing on a certain area, and it is incumbent on the product team to pass on the application focus onto the vendor team. This is needed to ensure that the testing done by the vendor team focuses on the relevant area instead of spending time on other areas which are not relevant. The team needs to decide on the best way to do this, one way to do this is to take the application where test plans and test cases are captured and create a plan that shows the vendor the focus areas where testing needs to be done. However, this pre-supposes that the test cases are written in a way that a subset can be used by the vendors and would make sense.