Home > Blogs > Beyond an Exercise

Beyond an Exercise

It happens more often than we would like to admit. We understand that capturing some form of information should provide some benefit, we follow the prescribed guidance and a decent template to provide structure, and apparently get the job done. Unfortunately, at the end of the day, we never realize that deep value we were looking to achieve. Chances are we have completed the exercise to the letter only.

In our school days, many of us successfully completed assignments that would never pass muster in the real world. Unfortunately, this issue occurs in the real world as well. A software program might successfully compile and show the expected results of a bubble sort for a prescribed set of numbers, but would instantly choke when presented with a random set of characters. A project schedule may generate a wonderful Gantt chart that shows completion well within the prescribed constraints, but that project can fall off the rails in a matter of days or weeks. A team agreement can be crafted by the team that gives the appearance of being able to support the team, but infighting and efficiencies still abound. All we have done in these instances is complete an empty exercise.

We see this syndrome in all stages of a project. We complete the fields of a template (it may be a charter, a specification, or anything else), we drop a standard WBS into our planning tool and throw in numbers that will satisfy our constraints, we write code that satisfies strictly the successful path through this part of the application. We can usually declare completion at this point, as most reviews of the work product are superficial at best. Unfortunately, it is our customer that often takes the brunt of the results.

Saving and closing a document or compiling an application is a long way from closure of the task. If there is a reason for doing the work (and if there isn't, why the heck were you wasting your time in the first place), that reason usually manifests itself downstream. A schedule supports later tracking, a team agreement provides behavioral norms that enable the team to collaborate more effectively. This is where the rubber hits the road, this is where we discover if we really accomplished our goals.

People use products in unanticipated ways, projects certainly never go according to plan, and there are times when team members disagree: life is not always rosy. The better we can simulate these conditions of actual use of our products, the better we can asses whether we've done a good job in building them. There are a couple of ways that we can get better at anticipating these conditions, and building better products.

One way is to walk yourself through the anticipated use of the product. Tell yourself a convincing story. You should be able to easily discover several challenging situations where your work product should help bail you out (if you can't think of any, you probably haven't participated on a project before). Try to go through the steps of designing or testing your application from your specification (better yet, ask a designer or tester to try it for you). Run some what-if scenarios for your project plan - you lose a key resource, a major supplier screws up, a critical task takes exceptionally long. Do your products server their intended purpose through these simulations?

Another way is for the clients of these work products to interrupt themselves as they begin to use them. Are they even using it as a tool to begin with? Many intermediate work products lay idle after they are done. If they are using it, is it a help or a hindrance? If it fails either of these tests, take the time to step back and repair the problem. Often, discovery at this point provides far more rich and relevant information about how to adjust things than the thought experiments you conceived earlier (although this information comes later in the lifecycle here, remember that these can be valuable cases for next time around).

As an example, we ran through an exercise recently where a team was putting together a team agreement. We ran it through scenarios we could anticipate, and tried to ensure it was substantial enough to do the job. The next day, though, the team was struggling in a meeting, and we called for an in-process review. We asked about how satisfied people thought about the progress, and what they would do differently. Lo and behold, the feedback gathered was precisely the information needed to refine the team agreement so that, if used, it would eliminate the struggles in the future.

Try to reduce the surprises your external customers have to deal with. And a great way to do this is to recognize and eliminate the steps along the way where you are simply going through the motions. Treat everything you build throughout the project as more than an exercise.

Become an InformIT Member

Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.