There are plenty if references to "Light-weight" BusinessProcessModeling implementations, but all of them seem pretty heavy to me.  Recently, I was in charge of a 5-person team (if you include me) in charge of a specific software product.

I was in charge of development, there was a QA person, a support person, a marketing person, etc.  The problem was that I wasn't an expert in anything but development, I needed to spend most of my time doing development, yet I also had to be able to keep track of a software release process that depended on the tasks of many people with many interdependencies.

What I did to handle this situation was create a visual process model, backed by a database, and implemented in MicrosoftAccess form.  It was a real bitch whenever the diagram had to change, but other than that, it worked very well.  It provided many benefits normally seen only in "BusinessProcessModeling" systems, but is also was missing some of the hallmarks of BPM.  Some of its weaknesses turned out to be its greatest strenghts, and I'd like to implement something like that in, say RubyOnRails, with more flexibility in the layout.

After I implemented the system described above, I realized much of what I was doing seemed to be covered by MS Project, so I tried to implement the same thing there.  That was a complete non-starter.  MS Project won't let you do anything unless you first specify way more than you might ever want to track, and with way more precision and detail than may ever actually be meaningful.  After all that, you still don't get a very friendly diagram for your trouble.

My personally fabricated definition of FeatherweightBusinessProcessModeling has the following characteristics...
* Allows designing a visual process model from start to end, including branches and merges.
* Is appropriate for team or workgroup scale processes involving up to about 10 people and containing up to 20 tasks or so.
* Allows entering planned and actual start and end dates for tasks in the model.
* Allows several views, including planned, actual, and best-info.
* Does not actually run on its own or trigger automated processes.
* Does not enforce chronology for dependencies, since the diagram may turn out to be wrong, but still needs to be useful for tracking actuals prior to fixing the diagram (if that's even needed).
* Does not try to do fancy things like automatically start tasks when their dependencies are completed.  The diagram is simple enough to tell that kind of thing by looking at it.

- SteveJorgensen