Developer

Translating from Business to Development


One of the biggest frustrations I experienced when I was performing development was that I was often too far away from the customer. Every layer of communications seems to add 10% at a minimum to the development time. Even worse was when non-technical people were doing the installation. The customer's actual needs always seemed to become transformed into some mixture of pseudo-techie sounding language, business school euphemism, and buzzwordian nonsense, to be transformed into a working product. All too often, "I have a spreadsheet of 30 sales reps who need to receive a report with these calculations weekly

About

Justin James is the Lead Architect for Conigent.

13 comments
JosB
JosB

Whenever I have to translate business to IT, I try to keep things as simple as possible. I ask them what they want and to explain that to me as if I don't know their business. Also, I don't want to talk about presentation, but about information. When they start talking their own business language, I pull them back and let them explain what they mean. This should produce the core specifications / requirements without any business language influence. This is not always possible, all business words that are left should be explained. Then I go to development with the specifications and let them decide whether or not they understand them. If not, back to business, let them clarify. When bringing IT and business together, I try finding the IT persons that know business language and business people that know how IT language. I ask them to explain in simple words what they mean and try to avoid any words that could be interpreted wrong. If I have doubt that they understood each other, I ask them to repeat what was just said to them in their own words. When specifications change after initial build, I want clear reasons from business why to do that. You want blue icons. Why? You want all data on one screen. What information is missing? There could be valid reasons to change (icon looks too much as an other icon, essential information is missing on a screen or presented at the wrong place). It could also be that there is no valid reason, but things have always been that way. That could be an interesting point to discuss. At the end it's all about expectations. When you know what the customer really wants, it's harder to fail. But it's difficult to find out exactly what they want.

Justin James
Justin James

Unfortunately, finding tech-savvy business people, and business-savvy tech people is not too easy. As a developer though, I *did* always find it awesome when I could get the business reasons for a decision to be made. It let me see where else that logic may need to be applied that the customer may not have noticed. It also let me see if maybe there was a better solution to the problem. "Make the icon blue" is a lot less helpful in the big picture than "we have a particular color scheme for the intranet that we are trying to standardize on." Expectation management... always a tough one. :) J.Ja

SnoopDoug
SnoopDoug

Justin, You guys ever consider Agile? Your post reminds me of the danger of rolling out a solution mostly baked. If the users love it, no problemo, if they hate it, you are toast. The danger is that once you get a huge part of the code written, it's too danged late to rearchitect. Using Agile gives you the luxury of giving it your best shot for the initial part of the application, say the login page and the next page or two. Users can take a look at these and tell you right away whether you are on the right track. It also gives them the *last* chance to change any GUI elements--the background, icons, etc. There's nothing like getting your beta out and a VP griping that the logo is too small, which cascades into a complete page redesign. And don't forget to get the key stakeholders to verify, in writing, when they okay a design change or the architecture. I recall once that a biz type (who just happened to be the spouse of a VP) complained about a field on one page, stating that we had promised to move it to another page. Since we did not have any written record of the design review, we had a pitched battle about this and I ended up telling the VP that since he was not at the meeting, he could not possibly know that the issue was never raised. Not a good career move, but it also saved the dev team from days of rework for a cosmetic change. doug in Seattle

Justin James
Justin James

What do you do to get the right specs from the business folks to the programming folks? Let me know! J.Ja

jslarochelle
jslarochelle

... and hard work. Among the important steps: Building a domain model that includes a good glossary of business terms and concepts Identifying the key use cases and scenarios (go through each UC with the client and make sure you idemtify the major alternate paths and exceptions) Build a software specification (allocate user requirements to software components and functions). Perform requirements review Of course the requirements do not have to be perfect and complete before you start working on the design. You can start working on the design (with CRC card for example) and this will help you identify problem area in the requirements. You should go back and fix those problems, go back to the design, and keep at it because practice makes "perfect". I really like use cases and scenarios because they work great with CRC card I like the Reponsibility Driven Approach to software design. JS

FE
FE

We have a team of business analysts who are people with both tech and business backgrounds. They act as interpreters between the business clients - internal and external - and the technical teams. We use a semi-agile process. We write and sign-off requirements, but do so in 30-90 iterations with frequent inspections by the clients. The requirements document starts with a Vision statement so the tech team can understand the business drivers behind the product. The functional requirements are captured with a use-case template. This allows the users to think in terms of users and their stories. This is typically easier for them. See "Software Requirements" by Karl Weigers and "Writing Effective Use Cases" by Alistair Cockburn for good books on the topic. Non-functional requirements are captured in ways that communicate to both the technical and business teams. The requirements are developed through intensive discussions led by the business analysts with the customer. The development team, testers, and other stakeholders are invited, but not required. Mockups may be used. At the close of the main requirements process for a release a formal walkthrough is held with all stakeholders. The sponsor formally approves the requirements and they are put under change management. Changes to the requirements from that point forward imply changes to scope and must be evaluated for budget and schedule impacts. The sponsor then makes an informed decision on whether to push the budget or schedule or both or move the requirement to a later release. The level of formality is adapted to the project. For large, high-stakes projects with many vendors or partners, a high level of formality is usual. For small, rapid, internal projects with less risky technology, we can be more relaxed. Sounds like a lot of work, but the business loves it. We have gone from constant bickering about whether IT delivered or not to the business actually saying "let's do requirements first". People feel like they have a voice. The developers feel like they have a stable target.

duckboxxer
duckboxxer

From what I have seen, the business people tell the team (starting at various levels of the team). From there, the team translates what it thinks they meant. The whole needs vs. wants translation. Then these are taken back to the business people/ client. This should use few technical terms and acronyms - otherwise the business end will not get it. This iterative process goes on till everyone agrees and is on the same page.

Justin James
Justin James

But it is tricky finding people who can do it well. J.Ja

Justin James
Justin James

On one of my tasks, I get a daily prototype revision from the coders, for this very reason. But they are getting a lot better. :) J.Ja

duckboxxer
duckboxxer

Yes, there is a lack of communication skills in the IT realm. Hence all the iterations. :)

annette.ibsen
annette.ibsen

make sure the the business people model and describe their processes. Then use BPEL to execute this. After that the developer use the BPEL to do the actual system.

Justin James
Justin James

... stuff like BPEL, ITIL, and other processes and such for transferring information from business to technical people are not institutionalized at many companies, and even when they are, there always seems to be a big push and a slow withdrawl so they barely get used. :( J.Ja

Editor's Picks