The Beauty of Whiteboard Sessions

No offense to Microsoft® Visio, I think the whiteboards and dry-erase markers are boon for the IT industry. One can use them to their advantage before diving into the technical formalization of the processes. The idea is not new; decades ago, I recall senior management folks used to take notes on paper napkins during a business meeting at some fancy restaurant. I am sure they still do.

Consider a situation, where a client or someone from the client’s team acting as a representative of the client approached the development team with a pretty color-coded printout of a Microsoft® Visio diagram representing process flow with multiple swimlanes, along with technical details identified in it. Asking them, “Take a look, and let us know what you think.” And they expect an answer, like, “Wow! What an excellent job you all did! It is all clear. We will get on it right away. Will be done.”

Just to make it clear for some folks who may not have caught the sarcasm, neither was the development team invited, nor the development team was part of those sessions where the customer and other teams cooked up that Microsoft® Visio diagram. Someone somewhere in the cross-matrix corporate food chain decided on behalf of the development team without their presence. On a stretch, one can draw conceptual parallels that might have happened during the “Taxation Without Representation” American Revolution!

In other words, the client has a problem (or business case that needs a solution), which they already identified, defined, solved and came up with a technical solution for, all by themselves. Now, all they need is the development team to make it happen. Simple!

If the development team knowingly does not provide any feedback, and something goes wrong at a later date, for sure, the development team would get in trouble, “Why didn’t you think of it before? After all, you’re the experts!”

If the development team provides feedback that something needs discussion, the response they get in return, like, “Oh! Now, it’s too late. We already presented this [pointing to the Visio diagram] to the board, maybe next time we can make that improvement.”

The result, either the project would fail due to lack of transparency, or the outcome would be different than the expectations, again, due to the lack of proper communication and false assumptions. One can argue, run the daily scrums to discuss and report all the issues, which, of course, is a tool to reduce the risk. However, there is not much one can do if the false assumptions and lack of knowledge are the basis for the framework of the solution under which the development team is operating.

Here are a few steps teams can consider mitigating such failures, including, but not limited to:

Identify key stakeholders. One of the key reasons for project failures is that cross-matrix teams forget to identify and include critical stakeholders at the beginning of the decision-making process. For example, consider keeping the development team as one of the primary stakeholders for the development projects.

Kickstart with whiteboard session(s). It is more straightforward on the whiteboard to move boxes around or erase some flow steps right in the discussion sessions in front of stakeholders. “A picture is worth a thousand words,” whoever said it, was a genius. For example, one can refer a step in the flow as a process box, or a question box, or a diamond box. However, they all are looking at the same drawing on the board that is asking a question in the process, with two subsequent paths, one corresponds to the “Yes” and another to the “No” answer. There is no guarantee that all users in the session would still have the same perception. Nonetheless, such a mode of discussion session reduces the chances of confusion and miscommunication. Until a solution or process flow is ironed out on the whiteboard with the agreement of all concerned parties involved, there is no need to formalize it, i.e., in a Microsoft® Visio. One can take a picture (a blessing of the smartphone devices in today’s age!) for future reference. There would always be one person (or a few people) who may have more knowledge of the process than others. They can undoubtedly lead the conversation, but recognize that no one person knows how the entire end-to-end enterprise-wide process would be feasible in the client’s environment. Hence, consider starting the discussion with an interactive whiteboard session. [Assumption: In most companies, video conference option is available to include participants who would be joining the meetings remotely.]

Communicate. Communicate. Communicate. Communicate. I would always err on the side of over-communication versus less.

Once a project failed or turned red on a project plan, practically, there is no point in getting into the bickering and pointing figures that the client signed off on the requirements and acceptance testing, etc. Like it or not, the development team has to swallow the pride, take the blame, and do the needful in the team spirit to bring the project back on track.

Learn from such experiences, and take steps to mitigate and alleviate such situations in future – starting with going back to the drawing (white) board!