Comments on: How many degrees of separation are there between your developers and users?

By: Evolving Business And IT Rules To Match New Demand | WNW Design - Web Design & SEO

Tue, 13 Jul 2010 12:17:26 +0000

[...] rules technology can make sure that there are fewer degrees of separation between business and IT people and help IT embrace change. While adopting business rules has implications for business and IT [...]

By: bdevisser (Björn de Visser)

bdevisser (Björn de Visser) — Wed, 20 Jan 2010 10:03:59 +0000

Twitter Comment

@Lowrain Why people still hand code? @InfoPhil explanation: http://tr.im/KVlb > impedance mismatch between coders/biz [link to post]

- Posted using Chat Catcher

By: How to Snuggle with your Customer — Competing on Execution

How to Snuggle with your Customer — Competing on Execution — Wed, 21 Oct 2009 18:50:48 +0000

[...] is 3 too many. It’s hard to keep users happy with that disconnect” (via @dhague ). @jamet123 even counted the steps and sure enough, 6 degrees of separation: [...]

By: Looking at code from both sides with business rules — JT on EDM

Looking at code from both sides with business rules — JT on EDM — Fri, 18 Sep 2009 14:11:28 +0000

[...] Business rules won’t solve all your problems but it might reduce the number of degrees of separation between your business people and IT staff. [...]

By: James Taylor's Decision Management

James Taylor's Decision Management — Tue, 15 Sep 2009 15:16:00 +0000

Looking at code from both sides with business rules…

Sharon Machlis had a great piece over on Computerworld titled Opinion: I’ve looked at code from both sides now on her experience of being a developer on a project where she was usually a user. It’s an interesting experience that……

By: Getting business and IT alignment with business rules — JT on EDM

Getting business and IT alignment with business rules — JT on EDM — Wed, 22 Jul 2009 19:44:00 +0000

By: David Marten

David Marten — Sat, 18 Jul 2009 14:14:01 +0000

I agree with James, but I’d to a step further. First of all, I like to put things in the context of a Method. This may seem like fluff, but it really put’s things in perspective. There are lots of ways to structure a Method for implementing a solution of some sort…I use Discovery, Analysis, Design, Build, Test and Transition.

Now I can show the user how and when they can be involved. Clearly, the Discovery and Analysis phase is where stuff is described in business terms. So the test here is to ensure the user still understands what you plan on doing when you complete the Analysis.

Then while you get busy with the Design and test you can ask the user to put a number of Use Cases together which you’d then revise with them as you complete the Design Phase. And again, revise as you complete the Build so you can account for those Use Cases which were not planned for.

Then you can get them busy in the planning for testing, training and transition. How will they transition to production? A small group at a time or everyone at once.

So all in all, there are so many ways to keep the user involved and bought into the solution you’re building. It’s a hell of a lot better than throwing it over the fence and saying, “here you go….good luck”.