I have seen it again and again and again. The project I just rolled off of did it also. We started use cases before we even had scope and requirements nailed down. And, we started them and basically finished them without any review or feedback from the intended end users of the documentation – the development team. Doing it this way leads to one of two things: 1) Scurrying to rewrite the use cases, or 2) Having them ignored altogether.

Sometimes this is determined by a lack of resources, such as the redesign for the ecommerce company I worked for last summer. The dev team was up to their ears in other projects, so we in the product management team did our best to capture requirements and develop use cases. And strangely, the executive PM on my most recent project seemed to not even engage the development team until after all the use cases were completed. By the time we started getting feedback, it became clear that a large number of use cases were written for nought, as they were struck off the list due to being basic functionality that was a common component of off-the-shelf software. This along with some other factors, contributed to the project blowing its budget early on.

After creating the initial use case map, the guesswork begins. What is needed? What is desired? What format is preferred? What is extraneous and should be ignored? Are my first 3 use cases good, too detailed, too general? How should I do the next 100?

By getting feedback from the developers and architects who will be consuming the use cases, you can adjust your production to conform to what is needed versus what some manager’s experience was 3 years ago with use cases or what article her former boss read. The sooner the use case writer gets this feedback, the better her use of time, and the more useful her documentation will be.

While use cases are primarily written descriptions of a process, and are quite helpful in many circumstances, their value and desired format is rarely consistent from IT shop to IT shop. Many developers I have worked with prefer diagrammatic process flows. Some want only bullet point requirements statements. Some want wireframes. And some want a mixture of all.

As for me, I really don’t care which documentation format is desired near as much as I want them to tell me which one they want.  Sounds simple, right? Because it is. But many managers and PMs decide to double the pace to compensate for lack of direction. My recommendation?…

Let the Business Analyst meet with development for just 1 hour to discuss what type of documentation they prefer. And don’t just allow him, but empower him and facilitate him in case development says it is “just too busy”.  Buy coffee and doughnuts – or even pizza if absolutely necessary.  Remember, budgets exist outside of the development team, and having such a short, sweet meeting early on can and will save tens of thousands of dollars in precious time.  (By the way, I don’t think I have ever heard a developer tell me he was too busy for free pizza).

My style as a BA has been to go meet and greet as many possible constituents as early as possible on every new project.  This has fostered my high performance – award-winning performance, literally.  But amazingly, more and more I am seeing obstructionism by managers who seem to fear some sort of political backlash if they enable their team to be proactive.

In conclusion, there is lots of “opportunity” to increase effectiveness and efficiency in the development process early on.