If you are working for a small self-contained team, then this is not a problem that you will probably run into. However, if you are working for a product which is large and complex (consider some of the products made by large companies such as Intuit, Adobe, Microsoft, or Apple), then a typical product will have a lot of complexity. There will be components made by other teams that are critical (for example, if you consider MS Word, the Online Help system would have been prepared by another team, and the team working on Word would have integrated this system rather than try to make it themselves). Another example would be that of the multiple products made by Microsoft and Adobe. The part of the application dealing with serial number, anti-piracy and similar functionality would be common to a company, and individual applications would be just integrating these components. There can be different levels of complexity, and in some cases, this complexity can be pretty high and critical.
As a result of all this, there needs to be regular discussions between a team and the various components on which it is dependent in order to ensure that there is agreement on the inter-dependencies such as features, requirements, and schedule. When all this is going on smoothly, then the project manager can rest easy and not have to worry too much.
However, life is not so simple. There will be often enough times when there is some dependency that is proving to be a problem (the schedule is not working out right, or there are some new requirements that need to be communicated and agreement obtained on getting those implemented, or about the level of quality required, or about who will do the detailed testing, and so on). For all these items, sometimes discussions over email can work, but it can be difficult sometimes, and email can turn out to be more problematic, and it is probably easier to just do a meeting with all the stakeholders.
But, and this is the part that can get tricky, a meeting with multiple stakeholders can get tricky unless it has been planned. In one case, we had people calling into the meeting from 4 different geographical locations, and it was difficult to get the meeting rolling and on course. The discussion was chaotic, with multiple people jumping in, a topic being discussed multiple times, and so on. At the end of the meeting, we got maybe 10% of the required work done, and a lot of feedback about how the meeting really did not work all that well. Due to this kind of situation, not only was progress not made, but it got more difficult to call such a meeting the next time (with people using different reasons for dropping out, and one of them confiding that they felt that this kind of meeting was a waste of time, and could avoid the meeting, so that he can provide the required information later).
We did do the meeting later, but it took a different approach to ensure that the meeting was a success and got everything required from such a meeting done. Also, unfortunately, we had to do a bit of escalation to ensure that everybody did attend the second meeting, but escalation is not something that you can do every time, and if you are not getting things right, it will be very difficult the next time.
I will write more about what we did to change the planning for the next meeting in the next post (Ensuring that agenda and main meeting points are clear before the meeting - Part 2)
As a result of all this, there needs to be regular discussions between a team and the various components on which it is dependent in order to ensure that there is agreement on the inter-dependencies such as features, requirements, and schedule. When all this is going on smoothly, then the project manager can rest easy and not have to worry too much.
However, life is not so simple. There will be often enough times when there is some dependency that is proving to be a problem (the schedule is not working out right, or there are some new requirements that need to be communicated and agreement obtained on getting those implemented, or about the level of quality required, or about who will do the detailed testing, and so on). For all these items, sometimes discussions over email can work, but it can be difficult sometimes, and email can turn out to be more problematic, and it is probably easier to just do a meeting with all the stakeholders.
But, and this is the part that can get tricky, a meeting with multiple stakeholders can get tricky unless it has been planned. In one case, we had people calling into the meeting from 4 different geographical locations, and it was difficult to get the meeting rolling and on course. The discussion was chaotic, with multiple people jumping in, a topic being discussed multiple times, and so on. At the end of the meeting, we got maybe 10% of the required work done, and a lot of feedback about how the meeting really did not work all that well. Due to this kind of situation, not only was progress not made, but it got more difficult to call such a meeting the next time (with people using different reasons for dropping out, and one of them confiding that they felt that this kind of meeting was a waste of time, and could avoid the meeting, so that he can provide the required information later).
We did do the meeting later, but it took a different approach to ensure that the meeting was a success and got everything required from such a meeting done. Also, unfortunately, we had to do a bit of escalation to ensure that everybody did attend the second meeting, but escalation is not something that you can do every time, and if you are not getting things right, it will be very difficult the next time.
I will write more about what we did to change the planning for the next meeting in the next post (Ensuring that agenda and main meeting points are clear before the meeting - Part 2)
No comments:
Post a Comment