When guidelines become RULES......... Project Management

Guidelines are supposed to be just that...... but they can quickly transform into rules, which might tie down productivity.....and when you have managers modifying these at will, well... you have a sure recipe for disaster

Don't get me wrong, I am not saying these should not become rules, some of them deserve to become rules, but as an age old saying tells it all, " Partial Knowledge is THE MOST dangerous knowledge in any setting"

Please let me discuss use case documents to get my point across

The use case document was supposed to be

• in PLAIN LANGUAGE that everyone who reads it can understand it
• a few SIMPLE artifacts.
• a reasonably structured, but INFORMAL way of expressing functionality
• a medium to manage (add/delete/modify based on consensus) vision and goal

On the contrary it has become

• a chore which might not even justify the pain
• a vehicle to present systems internal activity repeatedly
• practically impossible to decipher without formal training
• difficult to develop/maintain with no sense of optimality

How do use cases go bad?

It is a bigger possibility that use cases go wrong in a structured environment than in an unstructured environment. There is only so much wiggle room in a structured setup.

In my opinion, the top most reason for a use case going bad is the perspective of the author

If it is a person with a developer background, it is hard for the perspective to change from "the system" to the business. A transaction in a business sense would mean from point A to point B, however when SMEs use this word the newly minted developer BA would just assume, without a second thought that a database has to be involved and it is a a transaction to create/modify or delete a record. And in many cases a database exists and it is quite possible that the transaction that the business user referred to is just that. But the very origination of the use case is in trouble because from that point on, the developer BA is never going to come to the same level as the Business User to think about the system and the result, too many instances of <<'include'>>, <<'extend'>> and too much use of classes in use case. Now why would you put a class in a use case. Remember use case is supposed to be in plain language. In this case a use case becomes too technical, too technical for a business user to understand properly and give his full opinion. This document has a better role as a Technical Document that has to be distributed in the development team. This has no place in the business circle.

If it is a person from the the business setup, then God help the developers. Even when the development team talks about a complicated database transaction, the only thing that is going on to the use case is "some interaction with the system". This may be a good document in the business circle, but it is just that, not going to help develop anything. And though the technical team is ultimately blamed for it, ,they are not the ones to be blamed.

This is the reason why a Business Analyst is called a "liaison" ( this word is overused and should be banned). A good use case comes when a guidelines are followed to a reasonable extent. In the first case the guidelines laid are made RULES and in the second instant they were not even followed.

A use case need not be in the format of

• Abstract
• Goal
• Preconditions
• Use case
• Work flow
• Postconditions
• Alternate Work flow
• Exception Work flow
• Wireframes
• Screenshots
• Appendix

This is an artifact that needs to exist when building a system, but a use case need not be this. The above document is a derivative, not the principal, but it is considered to be a principal nowadays, especially by Project Managers and this takes up a lot of valuable time during the limited interaction with the business users. These meetings should be used for a better purpose, not to go through work flows. It is these meetings that most of the non-functional requirements come out. Non functional requirements are also a big part. And usually these are the crux of a project failing.

At the same time, some guidelines should also be followed, the use case document is something that has to be approved by business users as well as the tech team. If the use case says "some system interaction", it is not going to help. It is not going to give the tech team an idea of how long the development is going to take.

Another major flaw in use cases nowadays is the sense of optimality. Estimating the number of use cases required to build a system is a passe. There are only two things today in use

Too many use cases doing awful little
Too few use cases doing an awful lot

Breaking up use cases optimally saves time and time is money.

My take on how to write good use cases and how to optimally break them up coming soon...