IT Employment

Our forums are currently in maintenance mode and the ability to post is disabled. We will be back up and running as soon as possible. Thanks for your patience!

General discussion


Understand underlying business processes

By MaryWeilage Editor ·
In this week's Application Developer Management e-newsletter, columnist Scott Withrow discusses the importance of underlying business processes in application design. Do you agree with Scott that in order to ensure the success of an application design, it's necessary to understand the business processes behind it? How well do you think system designers understand underlying business processes?

If you aren't already subscribed to the Application Developer Management e-newsletter, visit our subscription today and sign up for this free newsletter:

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

JAD includes this understanding

by OReilly In reply to Understand underlying bus ...

Joint Application Design (JAD) sessions include the people who already understand the existing processes better than anyone.
Why wast time trying to document and understand the "as is" state. Use the people who already know and spend time designingto "to be" state.

Collapse -

Funding discourages this good approach

by ttm135 In reply to Understand underlying bus ...

Scott -- You are on the money (in fact it is part of my business model!) Unfortunately you are not on the money, so to speak. While even many project manager will quickly agree with you, projects tend to be FUNDED by the VERTICAL silos of which you speak. Focus from the project management methodology of most firms seeks to get the immediate job done at least cost and quickest sign-off from as few users as possible, it would seem. The people holding the magnifying-glass purse strings are only satisfied when they can narrow the focus and burn the wood (and ants!) quickly -- they are not rewarded for the larger view of where the company is headed and how things fit together. Thus we sometimes see the 'successful' project that meets all requirements and a product is installed on time (and on various hungry performance reviews), only to be abandoned 6 months later when higher management or customers drive a re-write of encompassing business processes to chase some new competitive advantage -- perhaps by laying off all the staff trained on your new package!
Bottom line is the need to build into IT's business processes and the project management REWARD structure a recognition for LOGN-TERM and WIDER benefit/cost of any product, including the impact of any work on other business processes outside the silos. I am adding steps into my projects to address these (just items on checklists for starters) but this will remain an art for some time. It will always require building knowledge of underlying and sidelying business processes and market processes and building of relationships with key people who will be honest with you about these impacts. If a client will not pay for this thoroughness, I simply explain that they WILL pay SOMEONE for it later and that I require my staff to at the least assess the risk of impacts and possibly recommend decline of the project if they are too high -- the income I lose is less that the income I lose from a reputation of building stuff that is thrown away later or that does not truly have a clear net benefit to my client. - Tom Moore, Upware

Related Discussions

Related Forums