During customer interaction and product development we usually face two big issues:

• requirements are not structured
• expectations are not properly managed

Let’s dig deeper into the easiest way of how to eliminate stress and minimize their impact.

Manage expectations

It’s quite common case when requirements themselves are not well-considered and appear on the level of general idea and a set of high-level application features. So, this kind of text need to be structured and think out to a level when amount of pitfalls like “oh, we haven’t taken into account that we need to implement low-level features which were not included in initial requirements document” are minimized.

Also during a phase of requirements coordination it’s necessary to carefully and critically track all changes towards initial document.
Because:

• it can imperceptibly grow into missed functionality, which will be expected by a customer but developers missed requirements changes
• features appear to be unimplemented or implemented in unexpected way

In general, proper and recurrent expectation management is a key aspect of working with customer. It allows you to eliminate all misunderstandings and mismatches between your client and developers team.

For instance, each call or chat with a customer should end up with a proper summary. It must be reviewed and accepted by all the parties. It’s great when these “sum-ups” are centralized and it’s pretty easy to find any point afterwards. But if such a practice is irregular or non-structured, it could lead to a pretty big headache in case of miscommunication.

ColorScope approach

That’s why, at Railsware, we invented a tool named “ColorScope” for our projects.
The essence of this approach is quite simple: during requirements analysis we use “painting out” of already worked out areas within one of five colors.

• green — requirements are already implemented in application
• blue — requirements are accepted for implementation (in our case, there is a user story for this and it is moved to pivotal tracker)
• yellow — this point is not clear enough and needs discussion
• red — this iteration won’t include implementation of this feature
• grey — this part is not valuable from the product perspective (used not so often)

Product description may be presented in any text form, whether plain text or bullet point list with any nesting level. Working on requirements could be done in any number of iterations. At least, all yellow areas should be eliminated (all questionable points should be made clear).

Thereby, PRD (product requirements document) at any moment appears as a clear profile of current state of requirements which eliminate any discrepancies. And final state of “ColorScope” is a specific layer between customer requests (source) and what was taken into development and implemented (target). Even more, this approach allows to change the “source” and backward change the “target”.

The most convenient tool to use in this case is Google Docs. It allows us to collaborate in real-time, seeing all the changes right away.
It has revision history to track all the changes made earlier, it’s always available for anyone who has access to it. In addition, there are few nice features like chat straight in the doc and internal comments (which highlight commented text in yellow, by the way).

Finally, Google Docs allows you to store and share all documents in one single place using folders, My Drive and sharing.

Here is an example

Let’s say we have customer needs for a new ruby on rails development in form of plain text. As I said before, any text form will fit.

After initial phase of “colorscoping”, it gets the shape of colored text with comments on the right.
All colors are from the legend we described above.

There might be one or more iterations of “colorscoping” until all requirements are discussed and mutual agreement is made.
So after that, the document includes all the stuff needed to manage expectations of what should and what will be implemented.

Another cool example could be given just to show that IT is not the only area where ColorScope could be used. The next picture shows the ColorScope approach in pizza making.

As you can see, the process of pizza making can be colorscoped as well and there are certain benefits from that: like if pizza is made for public event or for someone who wants to be in charge of cooking process. Check “4 Steps To Scope Your Product Right” to get a view on Benefit Driven Approach and ColorScope usage from designer standpoint.

So, if you need to have an accurate and strict method for outlining requirements to keep all the expectations managed and team and customer synced, ColorScope would be a great tool to help you with that.