Demo - A Picture is Worth a Thousand Words
- Amit Starikovsky
- Jan 1, 2006
- 5 min read
"Draw me a sheep," asked the Little Prince of the pilot. The pilot drew a sheep to the best of his ability, but the drawing did not satisfy the Little Prince: once the sheep looked sick, and another time, too old... Only when the pilot drew a box and explained, "The sheep is inside the box," did the Little Prince's face light up, as he could now see it in his fantasy ("The Little Prince"/Antoine de Saint-Exupéry).
When characterizing portals and other knowledge management solutions, we know how they begin but not always how they end. Such projects typically include many participants, including the project management team, content providers, users, IT people, and many others.
Just like the Little Prince, we all just want a sheep. We all imagine exactly how it should look. During the specification process, we often ask interviewees to describe their "fantasy," what and how they would like to see. Fantasies are not easy to fulfill. Indeed, one of the difficulties in projects of this type is that everyone sees the solution differently in their mind's eye. To avoid finding ourselves in the shoes of the pilot from "The Little Prince" and leaving everything as a fantasy, we must initiate expectation alignment.
In this review, we want to suggest a relatively simple way that helps formulate agreement regarding the solution and ensure we all speak the same language: a demonstration- a PowerPoint drawing that allows a first glimpse at how the solution will be implemented. It's clear to everyone that there is no substitute for detailed specification, but using a demo based on the specification allows for an initial "Look & Feel," certainly in a better way than the specification itself, due to the simple fact that a picture is worth a thousand words. The demo doesn't present the solution entirely - it gives direction and even outlines a path, but it doesn't faithfully represent, let alone completely, the future solution. The optimal timing for using it is after the specification writing has been completed or is in progress. We recommend, of course, using both in parallel.
It's important to ensure and reflect the agreed-upon reality in the demo: to adhere to the implementation of the marketing concept, the navigational framework (including the content tree), and the division of portal "real estate." Regarding the demo's content, we recommend demonstrating the portal's homepage and 2-3 additional items from the content tree. It's important to remember that the demo can also serve as a marketing tool, so it's recommended to demonstrate at least one crowd-attracting item (Killer Application), and it's advisable to also present at least one item showing a work process to show how the workflow will be implemented in the portal.
Using a demo can greatly assist in advancing the project: Beyond Look & Feel, the demo also helps focus different interviewees. Often, appetite comes with eating, and only after the user and the content provider see how the portal "looks" does the penny drop, and many additional ideas emerge.
The demo serves as a platform for formulating agreement on the content tree: Usually, discussions regarding the content tree are accompanied by a long and cumbersome Word or Excel table, which almost always gets cut off in the middle, and someone gets lost in it. Building the content tree using PowerPoint capabilities allows for an efficient presentation of the content tree, whereas browsing it is also from the user's perspective. This is why many times, after we've built the content tree and agreed on it with the client, we made changes to it after presenting it within the demo framework.
The demo keeps us in reality When working with IT people. We often discover that what we demand at the specification stage cannot be implemented at the implementation stage despite having agreed on it in joint meetings. The reason for this is that, being human, we are susceptible to misunderstandings, even if we do everything we can to prevent them. Using the demo can illustrate the requested solution and clarify issues that are unclear/controversial, especially when dealing with critical and essential items that we want to ensure are implemented in the way we envision. Presentation using the demo will prevent us from having false expectations, which can occur in a reality of people speaking "two languages..."
The demo also serves as a reality check: Building the demo is performed in light of what we wrote in the specification. As such, the process of building the demo can serve as feedback, as we can see how easy it is to implement the principles we specified, how clearly and comprehensively it is written, etc. Many questions that arose and were answered during the demo construction found their way into clarifications within the specification, saving us valuable time.
Despite all the above, every coin has two sides, and in knowledge management, we should not be satisfied with just one side of the coin.
Using a demo also has several disadvantages: First, an "advanced" presentation of the solution concept may fixate the people involved in the specification - both at the interview and approval stages. Since it's just a drawing, the demo might set expectations that are too high and cannot be fulfilled in development.
Additionally, we must maintain the principle of fidelity to the source. Sometimes, we lack the details to complete the picture, and then we might present a picture that doesn't reflect the full reality and does injustice to the truth.
However, it seems that the significant disadvantage of the demo is the resources it requires: in most cases, preparing the demo takes a long time, on average about 10 hours, and for people who are not skilled in using PowerPoint, it might take even longer. Not every project can accommodate such an amount of hours, so it's recommended to check if time has been allocated for it. If you're in the middle of a project and haven't reserved time for this, as per our usual approach to lessons learned, we recommend reserving time for it in the future.
If you've decided to go for a demo, don't settle for its simplistic form. Try to simulate the solution you would like to see as much as possible, as mentioned, that is aligned with the detailed specification.
From a practical standpoint, we recommend using Painter, which is part of the tools in every Windows computer. More advanced users can also use snag-it. These two applications allow editing of images, more and less complex drawings, color adjustments in navigation frames, and more.
When you build the navigation framework, make sure to build it as a base template so that you won't need to copy it to every additional page you want to demonstrate and to prevent "disruptions" along the way, as it is one of the essential components in the demo.
As we emphasized at the beginning of our words, the best solutions we can find exist in our fantasies. If there's a lesson to be learned from "The Little Prince," we don't want to leave it to fantasies but try to agree on what we all want.
The demo offers a practical and relatively simple way to illustrate and align expectations. Even in light of the disadvantages we detailed here, the advantages seem more numerous; therefore, we highly recommend using it.
Comentarios