Working with external teams to ensure that they fit your requirements into their schedule

I work in an organization that is fairly large, being a $500 million organization, having a number of products being worked upon by different product teams. As a part of this process, there are also many common components that are made by a few central teams, which provide functionality common to most of the products. For example, when you consider that functionality such as reading and writing to optical media, being able to open and write to video files, etc are common functionality, it makes a lot of logical sense to ensure that these functionality are done by a common team and then other teams pick it up. It is not such a open and dried system though, there are elements of complexity in these systems though:
- The various product teams that pick up these common components or code have different schedules, while the common component teams follow a set schedule (in most cases, this schedule is set primarily by the most important product team - for example, if you take the case of Microsoft, the MS Office or the Windows team will have a much higher priority than somebody working on Skype, and the schedule for a common component will be more geared towards the schedule of Office rather than that of Skype)
- The features needed for each product could be different, even if these are tweaks. The common components may provide a core technology, but even in these, there could be significant differences. A product that is geared towards an expert in the field of video would demand support for a more comprehensive set of video formats, while a more entry level product would just want support for a few widely used video formats. The makers of the common component have to work towards balancing the needs for such different requests for requirements, using the priority of the products that are requesting such features as a variable in making decisions.

As a result, if you are not part of the most important team, you have to keep in mind that your requests, even though important to your team, and critical, may not make it to the final list of items that the component team is working on. We have been in that position, and it can be pretty painful, but you are reminded that it is a decision meant for the good of the organization. What can you do about such a situation ? Well, there are a number of items that you can do:
- When you know that such a prioritization problem can happen, you need to ensure that for requirements which require a modification in the common component, you start working a bit early on those requirements and have the relevant discussions with the component team early. The later you present your requirements to the external team, the more problematic will be the conflicts that the external team will have to factor in, and the higher the probability that your requirements will not make it.
- Strike up a discussion with the product team that drives the requirements of the component team and learn about what are some of the new features that they are looking for. Evaluate those to see which of those fit into your requirements, which will give you a higher chance of ensuring that your features do make it.
- Even if the requirements differ like the point made earlier about different products requiring different levels of video format support, getting into discussions early and having more discussions geared towards such kind of support can ensure that the component team is able to provide alternative functionality, such as the same component providing different levels of functionality depending on variables that are passed to the component.

Product Development - Getting requirements and prioritization - Part 2

The previous post talked about how the Product Management team generated requirements for the new version of the product. When this happens, the next most important task is to get an idea about how much effort getting all these requirements into the product will take. This is easier said than done. Doing effort estimation when the requirement is a stated 2 line statement can be really difficult, and requires some amount of refinement.
What would next happen in most cycles that I have seen is that the requirements are next discussed between the Product Management team and the engineering team (typically senior engineers along with the engineering manager); this process also envisages that the requirements are discussed to some extent in terms of what the workflow would be (keep in mind that this is not the right time of the cycle to start designing screens or dialogs or detailing the workflow other than a top level attempt - doing such an effort for most requirements would take too long and is difficult to attempt).
What really helps for this effort is to use some sort of documentation (I know people who use Word or use an internal Twiki implementation, or some other tool to capture such requirements in a medium level of detail (this is somewhat tricky, you need to have enough detail that you can take a rough guess at the effort estimate), and where you can break down the top level requirements into one step lower of requirements (example, if you need to add a new editing capability to a tool, the intermediate level requirements could be about having different file formats supported, or about different levels of editing such as having 3 quick buttons, or a slider to allow the user to have more control)).
Another element of this cycle is to press for prioritizing the requirements. It is incredibly important to make sure that prioritization is done, and there is a possibility that the product management team may have some hesitation in terms of doing the prioritization of these requirements. However, given my earlier statement about resourcing not being infinite for the product development cycle, setting a priority means that the team can focus on those requirements that are most critical, and then on the ones that are deemed less critical. The other advantage of forcing the priority is that this process forces the product management team to take a deep look at the features (including sub-features) in terms of whether this is something that will really benefit the product. This also ensures that resources are spent wisely.