One of the most useful models we have here at Seilevel, at least in my opinion, is the Feature Tree. It allows you to show a high-level view of all the features in a project (ideally on one page) so that stakeholders, analysts and developers alike can ensure a complete set of features and see the link between the business objectives of the project and the requirements (see the Feature Tree example below). However, one thing that I’ve found through my projects is that you can add dimensions to your Feature Trees, showing stakeholders more information at a glance than just a list of features using color coding.
I’ve personally done this several ways. The first and perhaps most obvious is to color code for releases of a project. Say you’re working a multi-year/release project and want to focus the stakeholders’ attention on the requirements for a specific release. This information would of course live in the requirements tables, but it can also live in the Feature Trees by coloring the Release 1 or whatever release you’re looking at in a different color from the rest (I prefer green, given the usual connotation of green meaning “go”). See the Feature Tree below as an example.
You could, however, color code as many releases as you wanted with distinct colors. I’ve also used two other mechanisms for color coding Feature Trees that both revolved around comparisons; specifically capability gap analysis. For this, if you are comparing one company to another or one product to another, you can use a simple 3 color scheme to denote which features belong distinctly to one company/product, which to the other and which overlap (I use green, blue and red, where red are capability gaps, blue are overlapping features and green belong to the first company/product being investigated). See the Feature Tree below as an example.
Finally, if you are comparing multiple companies/products, you can color code with what I liked to call “skittles,” small colored dots on features where each one denotes that a specific company or product utilizes that feature. These work great if you want to prioritize the features that are utilized by the most companies/products or to just get an idea of the features that each company/product has. See the Feature Tree below as an example.
Of course, with all of these mechanisms, you have to clearly explain the color scheme to your stakeholders and include a key on every page. Additionally, you do have to think about people printing in black and white and/or who are color-blind. To work around this, if you are using the skittles, you can make sure that each company/product has its own place on the feature branch so that people can look at the same spot every time to find the dot. If you are color coding the text itself, you could make sure that the features in a certain release are grouped together and put a box around them or something to indicate they belong together or do some sort of bolding, italicizing, etc. to show capability gaps/overlaps.
All in all, I’ve seen great success with using color coding to enhance my Feature Trees. Try it out and let us know about your experiences!